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.
Related
Connecting remotely into a windows machine using the OpenSSH service provided by windows always starts an elevated session.
Is it possible to start a non elevated session and elevate after the fact? if so how?
Based on this github discussion: https://github.com/PowerShell/Win32-OpenSSH/issues/1652
bagajjal:
For admin users, ssh connection is an elevated session. Given you are
an admin and has elevated session, you can write to c:\windows.
This is by design.
jborean93:
The biggest issue when you were to use the limited token after an SSH
logon is that you cannot then get your elevated token. On an
interactive logon you can right click and say Run as administrator and
confirm through the UAC prompt but on a network logon like SSH there
is no way for UAC to prompt you. So if this was a functionality you
will never be able to swap from the limited to full token of your
admin account.
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
I'm creating a windows user by program an give the created user different privilege with LsaAddAccountRights. Among other things the privilege "SeSecurityPrivilege" which is needed to receive ACL information.
This works on a lot of different Windows versions: 7, 8.1x, 10.x, Server 2019: My program runs by the user can access the ACL of the files (with C# FileInfo.GetAccessControl()). But this did not work on Server 2008R2 and 2012R2. (ATM I could not test Server 2016). All Servers are Domain Controller. Checking privileges with "whoami /priv" shows, that the SeSecurityPrivilege is set on Server 2019 (but disabled), but the other server none of the privileges are shown.
Writing a program queering the privileges with LsaEnumerateAccountRights shows user has the privileges. Checking with PrivilegeCheck shows they are all disabled - on all Server (even 2019, where this is working).
Checking the group policy Group Policy at DC shows, that the Policy is assigned to the user.
Where is my problem? Why did this not work on the old Server version, but on the new one?
Even when a particular account holds a given privilege most of the time most processes will run with the privilege disabled. Use AdjustTokenPrivileges to enable the privilege on a per-process basis (ideally you only enable the privilege for the time it is actually needed and re-disable it afterward). Note that you use LookupPrivilegeValue to get the LUID that identifies a privilege to AdjustTokenPrivileges.
Is it possible to give someone access to the SiteMinder administration console, but in a read only fashion? We want some people to be able to see the configuration but not be able to modify anything.
SiteMinder Administrator accounts can be configured with fine-grained privileges that determine the administrative capabilities available to that administrator.
SiteMinder Administrator accounts are assigned rights to one or more security categories that define their administrative authority in the Administrative UI, such as managing authentication schemes. By default an Administrator account has access to every SiteMinder object related to an assigned security category.
Workspaces define a subset of SiteMinder objects. Assign a workspace to one or more Administrator accounts to filter the objects that are available to them, further controlling the scope of their administrative authority. An Administrator account whose authority is restricted by an assigned workspace is known as a scoped administrator.
Consult the SiteMinder Policy Server Configuration guide for more details...
I am working on the examination system and need to implement the following scenario:
User ( standard windows user ) completes the exam and then it is saved on the network share.
For security reasons the share does not have permissions for this user account. So I use impersonation API ( LogonUserEx, ImpersonateLoggedOnUser, RevertToSelf).
It all worked fine when the user with which I do the impersonation had admin privileges on the
local computer but the requirements are that it will be standard user.
With standard user the share is not visible. When I log in interactively with this user the share is visible and writable. So I assume that the standard user can not mount share when not logged in interactively. Is this correct? Is there a workaround?
The only time my code runs with elevated privileges is during the setup of the software.
I thought about using WNetAddConnection2 API but I need the share to be mounted to
this "hidden" user profile and not the administrator one that runs the setup.