I have a windows vm and have created an Admin user, let's say - AdminUser. I have mounted an azure file share to that user to Z: drive. The share can be accessed by unc path or the drive path. I also have a c# utility that checks if path exists and it returns true when I run it. This is all good. Now when I created a windows service with that utility and with same user credential, it throws an error that the path doesn't exist.
Things to note -
The service user or the user I used to login is a local adminstrator user and while creating the service, I had provided as "./AdminUser" to CreateService. Also provided password to config.
The VM is also connected to a domain. So I have users from default-domain\* and connected-domain\*. The connected-domain linked to an azure active directory.
Is there any other type of user I need to set as log on to service?
I can see here it says the local user can't access network resources but I am wondering since I mounted the path with proper credentials, does this matter?
Update:
Got the same issue when using running as with the exe.
runas /user:USERNAME “C:\full\path\of\Program.exe”
We have to use cmdkey to store the credentials that can be used by SMB later. Launch a cmd.exe with the user that you want to use for the service using either context menu or command e.g.
runas /user:default-domain\domainServiceUser cmd
Then in the new command shell use cmdkey
cmdkey /add:<storagteAccountName>.file.core.windows.net\<shareName> /user:AZURE\<storageAccountName> /pass:<storageAccountKey>
Rerun the service and it should work.
If you want to also mount this as a persistent drive, you can use
Command Prompt
net use z: \\<storagteAccountName>.file.core.windows.net\<shareName> /persistent:yes
Powershell
New-PSDrive -Name Z -PSProvider FileSystem -Root "\\<storagteAccountName>.file.core.windows.net\<shareName>" -Persist
Make sure that the user is exactly the same that would be used for the windows service including the domain i.e. use default-domain\domainServiceUser or ./AdminUser for running the cmdkey.
Though the user account is same, when the windows service runs as a 'user' the logon session that it gets is different than the interactive user session (which has the Z drive). Unless you programmatically load the Azure fileshare as a network drive in your code that is part of the Windows service, you won't be able to access it.
Related
All,
We are using Azure File Share, and we are mapping this file share on the Azure VM (Windows).
On this VM we have multiple local user accounts, this VM is not part of the AD.
Now, this mapped drive is not visible to other local user accounts, is there any way we can map the drive so that all the local users can see it. any suggestion would be much appreciated.
Thank you.
Step1:Download the SysinternalsSuite and unzip it
https://download.sysinternals.com/files/SysinternalsSuite.zip
Step2: Open the Command Prompt with administrative mode and navigate to the SysinternalsSuite folder.
Step3: Run the below command.
psexec -i -s cmd.exe
Step4:It will open another command prompt window with a system account. Run the below command to map the drive.
net use T: \mystorage.file.core.windows.net\drive /pass:6ymdZxhlfjhgjslahdgdkhsgdjru123455MoVVdqiSutRh38O1g== /user:"Azure\mystorage"
Step5: Log off the user and login back in. The Drive will be a map for all the local user accounts.
Please Note: When you restart the server, the drive will disappear.
I have a network path named P:\ and when I run PowerShell in standard mode I can access it just fine. But when I run PowerShell with Administrative Rights it says it can't find a drive named P:
How to access the path?
When you run PowerShell in standard mode, you say: run PowerShell with the current already authenticated credentials and session and context. This includes all drive mappings inside your current session.
When you run PowerShell as Administrator, the first question is: how do you verify that the Credentials are valid? You can't just look at the username and assume that you can re-use the existing session e.g. you have to explicitly check, exactly at this moment, to see that you are a member of the Administrators group. To validate the credentials, PowerShell performs an authentication check, and in turn, gets a new authentication ticket. This new authentication ticket creates the basis of a new context that your new PowerShell session is running from.
Since it's a new session, running under a completely new context, with new authentication ticket, it inherits no mapped drives because the current administrative session hasn't authenticated with any of your mapped drives. Only your other "non-administrative" or "normal" session has authenticated with any of your mapped drives.
This means that your administrative session starts by default without any mapped drives from your previous session, and it doesn't matter about access or rights, you simply haven't authenticated with your new authentication ticket. This means that, after launching as Administrator, you will have to manually re-map all your drives, as you will have to re-authenticate all the mappings with your new authentication ticket.
Basically, if you need access to mapped drives inside an administrative session, you will need to remap them.
EDIT:
But, as per #ErykSun's comments, #ErykSun brings up the only workaround by setting: EnableLinkedConnections. This is a very specific workaround that only works on GPO mapped drives at logon with the right UAC settings.
This "new session" issue is caused because of the new "feature" Microsoft introduced: UAC elevation (aka. stop running everything as Administrator). In order for certain legacy applications to work, Microsoft had to add this registry Key to create a workaround for mapped drives, e.g. most notably if you need to run something off a mapped drive as administrator (it's a poor user experience to run something off a mapped drive and promptly have it crash because it can't find itself or other files it needs).
How it works is pretty clever. On logon, it will create two sessions at the same time. Your regular non-elevated session, but also an elevated administrative session. At logon, when drive mappings are created, the system creates symbolic link objects that associate the drive letters to the UNC paths.
Note: This is only at logon, and so the caveats are that it only applies to GPO mapped drives.
Drives mapped via login scripts won't work because you have already "started" your session, and there is no link. Same with drives manually mapped during your session. Also when the UAC policy is configured to Prompt for credentials this won't implicitly create the second administrative session (you assume that the user is not an admin) and so running as administrator will create a new session, with the same above issues.
On that note, you can enable it through GPO:
In Local Group Policy Editor, locate the following Group Policy path:
Local Computer Policy\Windows Settings\Security Settings\Local Policies\Security Options
Configure the following policy to Prompt for consent:
User Account Control: Behaviour of the elevation prompt for administrators in Admin Approval Mode
Or via setting the registry key:
Open regedit
Locate and then right-click the following registry subkey:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
Select 'New' and click DWORD (32-bit) Value
Name it: EnableLinkedConnections
Right-click EnableLinkedConnections, and then click 'Modify'
In the 'Value data' box, type 1, and then click OK.
Exit Registry Editor, and then restart the computer
Is there a Windows C++ API to execute a command as a different user ? I am trying to mount a CIFS share from a service which is running as sys admin and I am currently logged in as a Kiosk user so when I try to mount the share using "net use .." I get access denied.
With CreateProcessWithLogin, you can execute a command with an arbitrary user provided you have valid credentials. Alternatively, can can use a combination of LogonUser and CreateProcessAsUser / CreateProcessWithToken.
Rather than requiring credentials including a password stored as plaintext (not recommended from a security POV), you could also grant required permissions to the kiosk user so that the current user context is sufficient for accessing the data and/or mapping the network drive.
If that is not an option, your application could have a manually configured persistent network drive as a prerequisite. The credentials would then be managed by Windows.
I'm using WinRS to run an executable on a remote machine. That executable, in turn, needs to access a UNC network share. I'm on a Windows network with AD, and running everything as a domain admin account (not a local account) that is a machine admin of the servers in question, and has Full Control (folder and share) of the network share. But when I use WinRS to run a remote process, that remote process doesn't seem to have network access. The simplest example I could distill it down to is:
winrs -r:RedServer dir \\BlueServer\SomeSharedFolder
which gives the error
Access is denied.
Note that WinRS itself works on RedServer, because this runs fine:
winrs -r:RedServer dir C:
So, it sounds like a permissions issue, right? But to prove this account does have Full Control over the \\BlueServer\SomeSharedFolder share, I logged into RedServer with that same account and ran this at the command prompt there:
dir \\BlueServer\SomeSharedFolder
It ran fine, giving me the contents of that folder. It's only the combination of WinRS + UNC path that causes errors.
Is there something I need to configure differently, or is this a limitation/safeguard of Windows? I experienced a similar limitation with Sysinternals' PsExec.exe; I could access anything on the target machine, but nothing on the network. Incidentally, I found a somewhat-related SO question here: "Error when creating mapped drive using winrs", but no answers there.
What you describe is a double hop scenario which requires additional configuration on the client and server to support. A double hop scenario is remotely logging in to a Windows server and then accessing a remote network share:
client -> server -> file share
You can accomplish this via CredSSP or Kerberos delegation.
CredSSP authentication is intended for environments where Kerberos delegation cannot be used. Support for CredSSP was added to allow a user to connect to a remote server and have the ability to access a second-hop machine, such as a file share.
While I haven't tried these instructions, they seem like a reasonable place to start. Additionally this blog post by Travis Gan appears to be helpful.
Using Windows 7 Enterprise with SP1, but I'm hoping to get a generic answer that would apply to Windows XP/2003/2008/Vista/7.
From a command prompt, I execute a net use command to map the Z: drive to a share on another computer, but I don't use my current credentials, I specify a different domain and user to map the drive.
net use z: \\rd-pc2037\C_DRIVE password /user:rd-pc2037\Administrator
The command completes successfully. Now that the drive is mapped, how can I find what Domain and Username I used to successfully map the drive? I can't seem to find what I want with the net use command.
C:\Users\rdomarat>net use
New connections will not be remembered.
Status Local Remote Network
----------------------------------------------------------------------------
OK Z: \\rd-pc2037\C_DRIVE Microsoft Windows Network
The command completed successfully.
C:\Users\rdomarat>net use Z:
Local name Z:
Remote name \\rd-pc2037\C_DRIVE
Resource type Disk
Status OK
# Opens 0
# Connections 1
The command completed successfully.
Checking the properties of the share in Windows Explorer and looking at the security tab showed me what permissions different people would have, but I didn't see how which DOMAIN\User I had used. I searched through the registry with limited success as well.
Any thought?
WMI is your friend:
> wmic netuse where LocalName="Z:" get UserName /value
UserName=rd-pc2037\Administrator
[anonymous suggestion 2022-08-07]:
Since Microsoft is gradually moving away from WMI,
Powershell/CIM is your future friend:
Get-CimInstance -classname Win32_NetworkConnection | select-object Remotename,Username
None of these answers help when using alternate credentials. They only show the current, local user. That doesn't help.
To view all stored credentials, use...
rundll32.exe keymgr.dll, KRShowKeyMgr
According to http://technet.microsoft.com/en-us/library/cc957215.aspx
the information you want is in the registry.
I have tried the wmic-command but it showed me the locally logged in user and not the "used DOMAIN\login"
The critical info from the link above:
Registry entry HKCU\Network\{Drive letter}\UserName is a REG_SZ that specifies the username (including domain name) whose credentials were used when the network drive was mapped.
Windows 11 -- some of this is useful, however Windows is still telling me that it has connected to a drive not listed in Windows Explorer, but which is not listed in computer, manage or net use or any of the options above. So Windows is storing connection information somewhere else.
There really should be a way to remove or replace persistent connections globally by username or servername.