Incident :
User added to Domain security group in few hours time still cannot log in the SharePoint site which is have permission
Root cause :
User before add in to domain security group already have the SharePoint authentication token ,this will cause SharePoint will not update for at least 10 hours.
Resolution \ work around:
- change the WindowsTokenLifetime from default 10 hours to N hours
- second method which is wait for 10 hours and at the same time grant individual permission first.
more information from :
https://community.spiceworks.com/how_to/86169-sharepoint-2013-permissions-controlled-by-ad-security-group-will-not-update
You have a site, list, or library with permissions assigned to an Active Directory security group instead of a SharePoint group or individual. When you add a user to or remove a user from the security group within Active Directory, their permissions on the SharePoint site are not updated right away.
3 Steps total
Get-SPSecurityTokenServiceConfig
$mysts=Get-SPSecurityTokenServiceConfig
$mysts.WindowsTokenLifetime=(New-TimeSpan -Minutes 60)
$mysts.Update()
WARNING: We've experienced some issues with this new setting. If you set the WindowsTokenLifetime to 60 minutes, please be aware that users who are editing a page must save and close that page within the 60 minute timeframe. We've had users making changes to wiki pages who spent hours working on a draft, then clicking on save and seeing all of their work lost. It turns out that when a user submits their changes by clicking the "Save" button, the request is sent back to SharePoint which sees that the user's credentials have expired. SharePoint then throws out any changes and directs the request back to the authentication page to re-authenticate. If the user is being logged in automatically (i.e. a corporate intranet), SharePoint redirects them back to the page they were editing, but without any of the changes.
This has been a HUGE problem for us. In the end, we changed the WindowsTokenLifetime back to 10 hours. Better for us to wait until the next day before the occasional Active Directory change takes effect than to risk losing hours worth of work.
