Refreshing a Windows access token

Devilsbane

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?

RobertKaucher

I'm pretty sure this cannot be done without a logon. The refresh you are talking about is at the AD level and not the local machine, I believe. I'm not 100% sure about this - but that is how I understand the local authentication/authorization mechanism to work.

Edit: I just found this.

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.

http://technet.microsoft.com/en-us/library/cc783557(WS.10).aspx

Devilsbane

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

hiddenknight821

Wouldn't that create an exploit if you are able to do this while they're still logged on?

Devilsbane

hiddenknight821 wrote: »

Wouldn't that create an exploit if you are able to do this while they're still logged on?

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.

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.

Devilsbane

I'm thinking it isn't possible. Just read this response...

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.

Since the access token is associated with processes, even if you were able to refresh it the processes already running (which is all of the system properties) already have the old token. You would also need to somehow force them to adopt the new one which is likely not possible. Still doesn't explain why permission changes often work on the fly...

hiddenknight821

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.

I was only curious, because I wonder if the AD was designed that way intentionally, so that way no one can take advantage of the exploit even when it's done temporarily. I'm not quite so sure either! Looks like you would have to do it one way.

RobertKaucher

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

That would be refreshing the Kerberos tickets - which would have nothing to do with local security token. The local security token is built by LSA which is run once at start up and if it is killed will reboot the computer - I'm pretty sure there was a worm in the pre-SP2 XP days that tried to compromise LSAS.exe and frequently caused the PC to enter a boot loop.

The difference between a local security token and something like Kerberos in an AD environment is because it is working at a session level; which means it only appears different from the users perspective. You can refresh a Kerberos ticket and then reauthenticate to SQL Server or a web site with a new token because you *ARE* in fact logging into the service again. If you need to refresh your local security token, your connection with LSAS must be restarted - meaning you need a new Windows session - meaning log off and back on.

If an application were allowed to switch its security context without exiting first there would be too many chances for exploits that could elevate privilege silently.

Notice that UAC takes care of this because a proxy intercepts the application requesting to start, checks if it needs to run as admin and then launches it in admin mode. If it does not need to have admin level permissions it uses a reduced version of your token to run.

it_consultant

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?

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

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.

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

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?

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

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.

We do that. Do you think people actually read their emails?

crrussell3

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.

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?

RobertKaucher

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?

He is trying to kick people out of the local administrators group without forcing them to log off and back on again.

RobertKaucher

Devilsbane wrote: »

We do that. Do you think people actually read their emails?

It mitigates responibility, that's all.