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
Related
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.
I have a service that runs as the "Local System" user. I would like to edit an entry in the registry from this service. This entry lives in HKEY_LOCAL_MACHINE. Everything goes find except that the entry is not updated. My service seems to have access to a virtual registry. When I execute regedit from this service I access a registry different from the "real" one (the one I access by executing regedit from the desktop for instance).
How can I access the "real" registry from my service?
I'm curious to know the order of Windows startup during a user login. Does anyone know?
Basically, my application was being invoked by login script that a GPO calls. While 3rd party EXE was being invoked, it was failing to start.
Then, through trial and error, I found that HKCU...\RunOnce keys execute after the login script. Same result, the EXE was being called, but failing to start.
What worked: updated the login script create a shortcut in the user's Startup folder. Now the EXE starts up as expected.
I know that AutoRuns can tell me all the locations where startup items can be placed, does anyone know the execution order as a whole? I was able to find that Run and RunOnce keys get called asynchronously. I can keep testing each startup item that AutoRuns states, but this could take days.
I'm mostly interested in Windows 2003 Server login startup flow, but I would suspect its very similar to other Windows flavors in use today.
Source: Understanding the Startup Process - Windows 7 Tutorial
The normal startup sequence for Windows 7 is:
Power-on self test (POST) phase
Initial startup phase
Windows Boot Manager phase
Windows Boot Loader phase
Kernel loading phase
Logon phase
Kernel Loading Phase The Windows Boot Loader is responsible for loading the Windows kernel (Ntoskrnl.exe) and the HAL into memory.
Together, the kernel and the HAL initialize a group of software
features that are called the Windows executive. The Windows executive
processes the configuration information stored in the registry in
HKLM\SYSTEM\CurrentControlSet and starts services and drivers. The
following sections provide more detail about the kernel loading phase.
Logon Phase
The Windows subsystem starts Winlogon.exe, a system service that
enables you to log on and log off. Winlogon.exe then does the
following:
Starts the Services subsystem (Services.exe), also known as the SCM. The SCM initializes services that the registry entry Start
designates as Autoload in the registry subkey
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Servicename.
Starts the Local Security Authority (LSA) process (Lsass.exe).
Parses the Ctrl+Alt+Delete key combination at the Begin Logon prompt (if the computer is part of an
AD DS domain).
The logon user interface (LogonUI) feature and the credential provider
(which can be the standard credential provider or a third-party
credential provider) collect the user name and password (or other
credentials) and pass this information securely to the LSA for
authentication. If the user supplied valid credentials, access is
granted by using either the default Kerberos V 5 authentication
protocol or Windows NT LAN Manager (NTLM).
Winlogon initializes security and authentication features while PnP
initializes auto-load services and drivers. After the user logs on,
the control set referenced by the registry entry LastKnownGood
(located in HKLM\SYSTEM\Select) is updated with the contents in the
CurrentControlSet subkey. By default, Winlogon then starts
Userinit.exe and the Windows Explorer shell. Userinit may then start
other processes, including:
Group Policy settings take effect Group Policy settings that apply to the user and computer take effect.
Startup programs run When not overridden by Group Policy settings, Windows starts logon scripts, startup programs, and services
referenced in the following registry subkeys and file system folders:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Runonce
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows\Run
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce
SystemDrive\Documents and Settings\All Users\Start Menu\Programs\Startup
SystemDrive\Documents and Settings\username\Start Menu\Programs\Startup
Several applications might be configured to start by default after you
install Windows, including Windows Defender. Computer manufacturers or
IT departments might configure other startup applications.
Windows startup is not complete until a user successfully logs on to
the computer. If startup fails during the logon phase, you have a
problem with a service or application configured to start
automatically.
If you want further information check the source link.
I'm writing a Windows device driver for a custom USB device, but am having trouble opening the device from my user program (using CreateFile) when the user program is run as a domain user. If I run as a local user, or as an administrator (or 'Run As' administrator) I can open the driver fine, but as a domain user GetLastError returns 5 (access denied).
I originally had this problem with local users too, and found I had to add the following SDDL entry to the .inf file, which solved the problem for local users:
HKR,,Security,,"D:P(A;;GA;;;SY)(A;;GA;;;BA)(A;;GRGW;;;BU)
From this reference:
http://msdn.microsoft.com/en-us/library/windows/hardware/ff563667(v=vs.85).aspx
When I discovered that domain users did not have access I thought that simply adding them to this SDDL entry would give them access, but it doesn't seem to work: I still get access denied. I've even tried extreme solutions such as giving all users (everyone (WD), unauthenticated users etc.) full access, but this doesn't work either, which makes me think the problem lies elsewhere; i.e. something else is denying domain users access which takes precedent over the permit in the SDDL entry in the driver inf.
So my question is, what am I missing that is required to give domain users (or all users) access to connect to the driver? Or are there any other solutions to this problem (such as connecting to the driver as a service and then accessing this service from the user program)?
HKR,,Security,,"D:P(A;;GA;;;WD)"
set everyone can access, try it!
According to < Windows via C/C++ >:
With Windwos Vista, if a user logs on
to the system with an account that
grants high privileges such as Admin,
in addition to the security token
corresponding to this privileged
account, a filtered token is also
created but granted only with the
privileges of a Standard User.
I am wondering, if a user logs on to the system with an account that is even less privileged than Standard User, does the system still create some extra filter token for it? I don't think it is necessary and it doesn't make any sense for the system to do that.
Thanks.
The short answer is that unless the user is an administrator, only a single token is present to represent the user.
When a standard user logs on to a computer a new logon session is created and they are presented with a shell application such as Windows Explorer that was created by the system and associated with the user’s newly created logon session by means of a token. This effectively limits what the user can do since Windows Explorer can only run those applications and access those resources that the user’s logon session permits based on the permissions and privileges specified by the token.
When an administrator logs on to a computer things are a little different and this is where Windows Vista (and Windows 7) differs dramatically from previous versions. Although the system creates a new logon session, it creates not one but two different tokens representing the same logon session. The first token grants all the permissions and privileges afforded to the administrator while the second token is a restricted token, sometimes called a filtered token, offering far fewer permissions and privileges. This restricted token offers practically the same capabilities and constraints as would be granted to a standard user. The system then creates the shell application using the restricted token. This means that although the user is logged on as an administrator, applications are by default run with limited permissions and privileges.
When the administrator needs to perform some task that requires additional permissions or privileges not granted to the restricted token, he or she can elect to run an application using the full security context provided by the unrestricted token. What protects the administrator from malicious code is that this elevation to the unrestricted token is only allowed after the administrator has confirmed the desire to use the unrestricted token by means of a secure prompt provided by the system. Malicious code cannot suppress this prompt and thereby gain complete control over the computer without the user’s knowledge.
When the built-in Administrator account logs on to a computer it appears as if it is treated differently to other users that are part of the Administrators group because it doesn’t receive elevation prompts. This is controlled by a group policy setting entitled “User Account Control: Admin Approval Mode for the built-in Administrator account”. Admin approval mode refers to the elevation prompt that requires an administrator to approve the elevation to the unrestricted token. By default this group policy setting is disabled which means that when the built-in Administrator logs on to a computer it only receives a single unrestricted token. If you enable this group policy setting then the built-in Administrator account will receive a new logon session with two tokens just like the other users that are part of the Administrators group.