After adding a user to the local Administrators group... even though the user is in the local group, they still don't have effective permissions as a desktop Administrator. They have to at least logoff/logon or reboot for the permissions to take effect. I was wondering if there's a way to do this via command-line in a seamless fashion.
This resource:
http://woshub.com/how-to-refresh-ad-groups-membership-without-user-logoff/
says, you can use:
klist -li 0:0x3e7 purge
However, after I ran that command, it didn't make any difference; I still had to logoff/logon or reboot for effective permissions to take place.
There are two things in play here:
What the local machine thinks your privileges are
What other machines think your privileges are when you connect to them
Purging the ticket cache with klist purge will remove your user ticket cache. This will affect (2), in that when you go try and communicate with another service you must first get a new TGT, which is the thing that actually contains your group membership information. This is why your membership information is cached for 'a while', i.e. because the TGT sticks around for a while, and when you ask for a ticket to another service, the Domain Controller literally just copies the contents of the TGT to the newly requested ticket, and that TGT can exist for a week or more.
Getting a new TGT will always return exactly what the DC thinks your membership is.
Affecting (1) is more complicated. Windows stores this information in what's called an NT Token, which is immutable for the lifetime of a logon session. The NT Token gets your group membership during logon. Windows asks the DC for that information, and copies it into the NT Token on receipt. This is why it appears as though your membership doesn't change, that is, because Windows hasn't gone off to get your new membership information and hasn't refreshed your NT Token (because it can't, because it's immutable).
As it happens though, a logon session is not forever, and actually only exists between session unlocks. Your membership information will get refreshed shortly after a lock/unlock once it communicates with DC.
0x3e7 is the ID of the SYSTEM account, not the user you are trying to manage. Issue just klist to get the ID of your currently logged on user. You can issue just:
klist purge
to delete the cached kerberos tickets of the currently logged on user. After that, just access a ressource where you need a kerberos ticket (e. g. a network share) and you will get new cached kerberos tickets automatically. If you don't have a particular network share, access the default share of your domain (just your domain name): \\mydomain.com
If time does not matter and you just do not want to login again, you can wait at most 10 hours. That's the default time span, after which a kerberos ticket will automatically be renewed.
Related
Lenovo's system update program can be started without administrator right. When the service starts, it creates a temporary administrator account to perform the installation.
Why can a windows application have right to create an administrator-level account? How can I achieve it when I want to create a similar program?
It's related to TVSU. A design point of TVSU is that even limited users can install updates from Lenovo. And to accomplish this, the TVSU service creates a temporary admin account with a randomized username and password, then uses it to do the installations on behalf of the limited user. This is the only time the account is created. The account is not created when an admin user does updates, because the admin user already has the permissions needed to do installations.
The account is supposed to be deleted after the TVSU session finishes, but I'm aware of a case where this doesn't happen and the account stays around. However there isn't any security risk to this because both the account and password are random and not known by anything except the specific TVSU process that created them, and this process ended the last time TVSU was closed. You can safely ignore the account, delete the account, or else it should be deleted the next time TVSU is run.
This questions is a followup to
Why is SeCreateSymbolicLinkPrivilege ignored on Windows 8?
Given:
The user is in the Administrators group
Turning off UAC is not an option for me.
Running elevated is not an option.
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.
(Skip to the bottom for the TLDR version.)
OK - so I have searched (really!) and all other UAC articles I have found seem to center on enabling, disabling, detecting or hiding UAC. My issue is not one of those, so here goes:
My user used to have the standard dual-token setup where I was in the Administrators group and the UAC's Consent UI would just ask me if I wanted to proceed. Now, we have separate administrative-level accounts that we need to use, and I have to authenticate with this new user. The problem I am having is that previously, starting an app as Administrator just elevated my current user, where now if I use the credentials of the new administrative user, whatever I am running runs AS that new user.
As an example, previously elevating CMD and typing whoami into the command prompt used to return my normal/current user, where it now returns the new administrative user.
This has serious negative consequences - since this is a new user, and an Administrative-level one, if any files are created using this new user, my normal user cannot write to or delete them unless I manually adjust permissions and ownership. If I use my development environment under the new account (e.g. I need to debug a service or work with a driver) and rebuild something, I end up with a bunch of files that I cannot manipulate unless I am an administrator. Likewise if I add a file while running as this new account - my SCM tool will not be able to update that file later unless it also runs under this new administrative account.
Also, Since a profile is associated with this user, things run under a completely different environment (different %USERNAME%, %USERPROFILE%, %LOCALAPPDATA%, etc.)
Installing an application will also work incorrectly if it is installed just for the current user (e.g. the "Just Me" option), instead of for all users. Things that are licensed to/in my normal user account also fail to function if run under the new account, because things are running as that new user.
The ripple effects of this change are getting larger and larger the more I work with it. So...
[TLDR] Is there a way to get temporary elevation of the current user without that user having the normal dual-token setup you get from being in the Administrative group? Or are you stuck with the impersonation behavior?
The DC is set up to lock out after three failures however this particular member that has some different applications is getting locked out after one failure. Any ideas what could be causing this to happen?
This mostly happens when the user has logged on to another device with their credentials then changed their password. Now the other device/service is trying to log on/run with the old cached credentials. This has happened to me a few times before because I have tasks running on multiple servers under my credentials and after changing my password (90 days) I forgot to change them on the other machines. Try having the user log out or shut off all devices they have used then reset their credentials. That worked for me. Microsoft also has tools to figure out where these credentials are being used.
I've read all the posts on Stack Overflow about CreateProcessAsUser and there are very few resolved questions, so I'm not holding my breath on this one. But it seems like I'm definitely missing something, so it might be easy.
The target OS is Windows XP. I have a service running as "Local System" from which I want to create a process running as a different user. For that user, I have the username and password, so LogonUser goes fine and I get a token for the user (in this case, an Administrator account.) I then try to use that token to call CreateProcessAsUser, but it fails because that token does not come with SeAssignPrimaryTokenPrivilege - however, it does have SeIncreaseQuotaPrivilege. (I used GetTokenInformation to dump all the privileges associated with that token.) According to the MSDN page for CreateProcessAsUser, you need both privileges in order to call CreateProcessAsUser successfully.
It also says you don't need the SeAssignPrimaryTokenPrivilege if the token you pass in to CreateProcessAsUser() is a "restricted version of the calling process' primary token", which I can create with CreateRestrictedToken(), but then it will be associated with the Local System user and not the target user I'm trying to run the process as.
So how would I create a logon token that is both a restricted version of the calling process' primary token, AND is associated with a different user? Thanks!
Note that there is no need for user interaction in here - it's all unattended - so there's no need to do stuff like grabbing WINSTA0, etc.
SE_ASSIGNPRIMARYTOKEN_NAME is a privilege you can enable in your process/thread with OpenProcessToken/OpenThreadToken+LookupPrivilegeValue+AdjustTokenPrivileges (It is easy to confuse this with TOKEN_ASSIGN_PRIMARY, and MSDN says you need both to attach a primary token to a process)
On this XP:SP2 machine, just calling LogonUser(...,LOGON32_LOGON_INTERACTIVE,...)+CreateProcessAsUser works just fine without messing with any privileges (Using a fake cmd.exe service, but that should not matter)
This quote on MSDN:
If the necessary privileges are not
already enabled, CreateProcessAsUser
enables them for the duration of the
call
and the fact that you are running as SYSTEM and should be able to enable any privilege leads me to believe that this assign primary stuff is not the problem.