I also noticed that AD group membership changes didn't sync - even after telling the User Profile Service to do a full sync!
I remember stumbling on something about AD group memberships in SharePoint 2013 (though this applies to 2010 as well with ADFS) regarding claims-based authentication and an expiration or cache of some kind. Using two articles (here and here) with MS documentation (here, here, here, and here), I found the fix: update the Security Token Service timeout to a shorter time and update the Windows and Forms token timeouts to a shorter time as well.
Be aware - the following powershell (that you have to run from the SharePoint 2013 Management Shell) tells the STS (Security Token Service) to reduce the amount of time a user token is valid (as far as the STS cares) and then lowers the expiration timeframe for claims token handed out by the STS. This would increase network traffic (refer to articles up there for more detailed explanations) and could make your SharePoint a bit unstable if your timeouts aren't in this pattern of TokenTimeout > Windows/FormsTokenLifetimes > LogonTokenCacheExpirationWindow:
$cs = [Microsoft.SharePoint.Administration.SPWebService]::ContentService $cs.TokenTimeout = (New-TimeSpan -hours 4) $cs.Update() $sts = Get-SPSecurityTokenServiceConfig $sts.FormsTokenLifetime = (New-TimeSpan -hours 2) $sts.WindowsTokenLifetime = (New-TimeSpan -hours 2) $sts.LogonTokenCacheExpirationWindow = (New-TimeSpan -minutes 30) $sts.Update() iisreset
You can play with the times to be much shorter if you are just trying to fix an issue immediately but the ContentService's TokenTimeout HAS to be greater than the TokenLifetimes which HAVE to be greater than the CacheExpirationWindow. I'm playing with these settings for now and will update later if I end up changing them.