Why AD changes not reflected on user permission OR why it takes so long for changes in AD to trickle down to SharePoint security.

When you create SharePoint security groups that are associated with AD groups, the expectation may be that any change in AD will immediately be reflected on the SharePoint site. For example is you removed a user from an AD group that is associated with the visitor group on your site, you probably expecting the user to be thrown out from the site in shame. while in reality the user, even though removed from the AD group, still hopping happily from one page to another and not being kicked out. Why?

So to save you time and the anxiety of needing to deal with the Profile Synchronization Service (PSS), let me calm you down with a cold water and a piece of lime, PSS has nothing to do with it. And no, you don’t need to rush and adjust your PSS service timer job, just let it enjoy the rest of the day, it’s not his fault .

Just as comment, PSS is important for sharing user AD information in SharePoint collaboration features,  not for security,  or for permission. For testing you can go on and delete a user from PS and still be able to login as this user (do it on a test account please and not your CEO account) .

Moving on then, so why does changes in AD don’t immediately effect the user. the reason is related to SharePoint security model that is based   on a security token holding user claims, in other words, when a user first logs into his computer he is being greeted by the Operation System, Miss OS,  with a gift in a form of a security token, which is an object holding a list of per values with user information from AD, including user profile, and the security groups he has access to. From that point the user is carrying this Snapshot information wherever he goes, SharePoint is using this information to allow or decline access based on the user security settings in this token.

Remember this token is a snapshot in time when the user logged in, any change you make to AD after the user already has the token doesn’t updates the token in real-time. The token has a refreshing interval that can be changed with PowerShell.

Using the following command will present the security token information:

Get-SPSecurityTokenServiceConfig

This is the code to change the WindowsTokenLifetime’s default value from 10 hours to two min.

$mysts = Get-SPSecurityTokenServiceConfig
$mysts.WindowsTokenLifetime = (New-TimeSpan -Minutes 2)
$mysts.LogonTokenCacheExpirationWindow
$mysts.Update()

End result using  the above code :

Sharepoint Window token