This questions is a followup to Why is SeCreateSymbolicLinkPrivilege ignored on Windows 8?
Given:
Question: Is it possible to add the SeCreateSymbolicLinkPrivilege
to the Standard User Token created by Windows for an admin user?
Appendix
Non elevated admin user:
C:\dayforce\SharpTop>whoami /priv
PRIVILEGES INFORMATION
----------------------
Privilege Name Description State
============================= ==================================== ========
SeShutdownPrivilege Shut down the system Disabled
SeChangeNotifyPrivilege Bypass traverse checking Enabled
SeUndockPrivilege Remove computer from docking station Disabled
SeIncreaseWorkingSetPrivilege Increase a process working set Disabled
SeTimeZonePrivilege Change the time zone Disabled
C:\dayforce\SharpTop>
A regular user:
C:\Windows\system32>whoami /priv
PRIVILEGES INFORMATION
----------------------
Privilege Name Description State
============================= ==================================== ========
SeShutdownPrivilege Shut down the system Disabled
SeChangeNotifyPrivilege Bypass traverse checking Enabled
SeUndockPrivilege Remove computer from docking station Disabled
SeIncreaseWorkingSetPrivilege Increase a process working set Disabled
SeTimeZonePrivilege Change the time zone Disabled
SeCreateSymbolicLinkPrivilege Create symbolic links Disabled
C:\Windows\system32>
Notice a regular user has the SeCreateSymbolicLinkPrivilege
privilege, because I have enabled it in the Security Policy. But the admin user is screwed, because doing so does not affect its Standard User Token!
(this is a nonanswer to the actually-asked question, but it is an attempt at an answer for what I perceive to be the actual goal)
I feel your pain -- I've been looking for a way to permit an admin user running nonelevated to create Symbolic Links, without success ...
I've investigated altering the process token (of "explorer" perhaps) to add the SeCreateSymbolicLinkPrivilege privilege, but it appears that there is no way to alter the privilege set of an existing token. Even if your patch process runs as SYSTEM and/or has the SeTcbPrivilege privilege.
I've investigated using CreateRestrictedToken to create your "own" nonelevated process, but with the SeCreateSymbolicLinkPrivilege privilege left enabled. But all anecdotes I've read about CreateRestrictedToken suggests that the resulting token cannot be made sufficiently similar to an "authentic" nonelevated token. There were insurmountable issues with the integrity level, or with the elevated flag associated with the token.
No matter what users you assign to the create-symlink user right in security policy manager, if your process runs nonelevated (from a user with admin), the SeCreateSymbolicLinkPrivilege privilege gets removed. This happens even if the only user added is "Everyone".
Microsoft really fouled us up on this one, there appears to be no good workaround. There is a possibly hackish solution though ...
Now for the hackish solution - during logon of the user, start a background program (elevated) which will create symlinks on behalf of other processes. This will need to use some sort of IPC, perhaps named pipes, to receive create-symlink-requests from the client process. It's ugly, and probably slow, but other than running Elevated (or disabling UAC), or removing the user from the Administrators group, I don't see any other way.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With