Book now with code EOY2025
When a user is authenticated, the Local Security Authority (LSA) creates an access token — in this case, a primary access token — for that user. An access token contains a security identifier (SID) for the user, all of the SIDs for the groups to which the user belongs, and the user’s privileges. If you add a user to a group after the user’s access token has been issued, or modify privileges assigned to the user account, the user must log off and then log on again before the access token will be updated.
hiddenknight821 wrote: » Wouldn't that create an exploit if you are able to do this while they're still logged on?
Theoretically you could use undocumented NtCreateToken to forge a token and launch a new process with it. But obviously it will not have any effect on already running processes. Also I would highly recommend to stay away from this solution as it has so many issue under the surface. Many people reported trying this road an yet I haven't seen even one successful implementation.
Devilsbane wrote: » How would that be an exploit? I'm not looking to modify the token itself, just force it to do a refresh. The only exploit I can see is if the user was temporarily added to a group, token refreshed, and then access removed. The same could be done by having them log off and then back on.
Devilsbane wrote: » Yeah, I read through that too. Just seems a little harsh that a logoff needs to be done. I thought there must be some sort of gpupdate command or something to refresh without forcing a user to logoff... or at least a refresh when the kerberos ticket needs to be renewed. I was reading on some forum where klist could be used. But then somebody else said they tried that and it didn't work. Looking for other ideas now
Devilsbane wrote: » Currently I am looking to remove some users from the local administrator group. However, until the access token is refreshed the affected users will likely keep their administrative rights until they log off. How can I force a refresh? Does this get refreshed every 8 hours when the ticket is refreshed?
it_consultant wrote: » Why don't you remove them from the local user accounts and then force a Windows update or something to get them to reboot their machines? IT guys, half of our job is covert.
Devilsbane wrote: » I had already created a script using the shutdown /r command and giving them 30 minutes. But management is concerned about potential data loss that exists when forcing a shutdown. It is a damned if you do damned if you don't situation. I know what your thinking... 30 minutes is plenty of time to save your data. Yes we are covert, which is why these access removals will occur at night. Likely nobody will be seated at their computer for 8 or more hours at which point the reboot would already be completed. An alternative would to be not to use the /f switch and not force the shutdown... in which case the user just clicks cancel and the shutdown is aborted. Maybe the solution to this is just to give them 10 or 12 hours so that the countdown is still going when they come in?
RobertKaucher wrote: » I would go with the final option. Send out an email and telling people that desktop/laptop systems will need be rebooted between the hrs of x and y on day z and that if they leave their system on they should not leave any programs open before they leave. You don't have to mention why or anything like that.
Devilsbane wrote: » I've never understood this access token thing. In theory it makes sense, but time and time again I've made permission changes on the fly and found that the new access was granted or was revoked without a logoff or reboot. It is very confusing.... Unfortunately in this scenario we are removing access AND that access happens to come with a generous amount of rights so I want to make sure that the access is removed and not preserved for possibly months.
crrussell3 wrote: » What permission changes are you talking? 1. You explicitly allow/deny a user account to a resource, it will be automatic without a log off/on. Their user account sid is already included in their access token, hence it is instantaneous. 2. You add user account to group, which has allow/deny to a resource, that takes a log off/on as that group sid isn't part of the access token. 3. Am I missing what you are seeing?
Devilsbane wrote: » We do that. Do you think people actually read their emails?
Use code EOY2025 to receive $250 off your 2025 certification boot camp!
