As I was working on understanding the process for expiring login cookies recently, I found what seemed like a pretty big problem. For SAML claims users, once they got their login cookie from ADFS, they would never seem to time out. Meaning they could close the browser, and several minutes or even hours later open the browser again and just navigate directly to the site without having to reauthenticate to ADFS. In addition the Office 2010 client applications worked the same way. I finally figured out the multiple pieces that were causing that and so I’m documenting them here.
First a really, really brief background. When you navigate to a SharePoint site secured with SAML claims the first time, it will redirect you to get authenticated and get your claims. Your SAML identity provider (a.k.a. IP-STS) does all that and redirects you back to SharePoint. When you come back into SharePoint we create a FedAuth cookie and that’s how we know you’ve been authenticated. To make for smoother end user experience we write the FedAuth cookie value to the local cookies folder. On subsequent requests for that site, if we find a valid FedAuth cookie for the site we’ll just read the cookie and take you right to the SharePoint content without authenticating again. This can be a bit of a jolt to those of you who are used to ADFS 1.x and SharePoint 2007, because with them all Web SSO cookies were session based so we didn’t save them to disk. When you closed your browser for instance, the cookie went away so you had to reauthenticate each time you closed and opened your browser. That is not the case with SharePoint 2010.
UPDATE #1: We found a change that can be made to the SharePoint STS to make it work with session cookies again, as it did in SharePoint 2007. This PowerShell will make the change:
$sts = Get-SPSecurityTokenServiceConfig$sts.UseSessionCookies = $true$sts.Update()iisreset
After doing this you will see that there is no longer a FedAuth cookie written to disk. To change things back to the default behavior just reverse your steps:
$sts.UseSessionCookies = $false$sts.Update()iisreset
So, how do we configure this behavior to get a SAML token with a nice manageable lifetime? Here are the things you need to look at:
UPDATE #2: Rich Harrison was good enough to provide this nugget for updating the TokenLifetime in ADFS for the relying party:
Set-ADFSRelyingPartyTrust -TargetName "SPS 2010 ADFS" -TokenLifetime 5 where "SPS 2010 ADFS" is the name of the Relying Party Trust entity in AD FS 2.0.
So, if you want to set the TokenLifetime of the relying party in ADFS at creation time, you need to do so using PowerShell. Here’s the little one line script I used to create my relying party:
Add-ADFSRelyingPartyTrust -Name "FC1" -Identifier "https://fc1/_trust/" -WsFedEndpoint "https://fc1/_trust/" -TokenLifetime 2 -SignatureAlgorithm http://www.w3.org/2000/09/xmldsig#rsa-sha1
After creating the relying party this way you need to manually:
$sts = Get-SPSecurityTokenServiceConfig
$sts.LogonTokenCacheExpirationWindow = (New-TimeSpan –minutes 1)
Now, once you configure these settings correctly the login expiration for SAML users works correctly. I can open and close my browser window and continue to get back into the site without being redirected back to SharePoint for 2 minutes. After that time though it correctly makes me reauthenticate to ADFS.
This was a nice article which I found while searching for setting the expiration time for the STS token. I am using forms authentication with a custom provider and custom login page. Everything works fine(authentication,authorization) except for the "persistent cookie (say for 365 days)" mechanism which I don't know how to get it to work. The basic requirement is that when a user selects "remember me", he should never be logged out (never). When he does not select remember me, it should default to a session cookie and not a persistent cookie.
In SharePoint 2007, you could could create a new cookie out of the forms authentication ticket with the required timeframe (365 days) and you were all set. Once remember me is selected, you will always be logged into the site even after many days of inactivity.
With claims authentication, since the token lifetime is controlled by the STS service and has few defaults for formstokenlifetime (which is 10 hrs). How do I set this value depending on whether user selects "remember me" or not ? Though this formstokenlifetime can be set at the STS service level, but how do I set it at a request level ?
Any pointers will be really helpful.
When you tested this (LogonTokenCacheExpirationWindow = 1 min and SAML token lifetime = 5 mins), did you still have session cookies enabled?
Travis Nielsen | PointBridge
Sorry. Disregard. I just found KB 2462541 and it resolved the looping issue I was seeing.
I have the follow situation: TokenLifetime on ADFS STS for SharePoint setted for 10 hours and token cache on SharePoint (if I right understand - it is LogonTokenCacheExpirationWindow) setted to 1 minute.
But I see in logs from time to time that after 15-20 minutes user may be redirected to ADFS STS. It was initiated by sending from _trust FedAuth cookie with expiration DateTime.MinValue (31 dec 1969). We have NLB on our solution, may be SPTokenCache not adopted to work with NLB?
Was you faced with the same situations? What may you recommend?
We have SP2010, ADFS for claims, and see the following:
Completely random ADFS errors. We have tried the MS cumulative patch release on 31st Dec 2010. We have tried setting the ADFS lifetime to 0 which is forever, so higher than the sharepoint lifetime. We are using FedAuth persistent cookies.
This has been going on for months and everything we try produces random ADFS errors. We are not pushing the back button, which I know is a known fault. Just click to the site, ADFS does its thing, use the site and randomly we get the ADFS error, even after a few minutes. Tried clearing down cookies too!
Also, we get similar issues with different parts Office 2003 and Office 2010 when going direct to sharepoint to get/put files etc. Are they supported with ADFS properly.
Is ADFS and Sharepoint 2010 and Office 2003/2010 all supported together?
Any help gratefully received!
We are using Form Based Authentication in 2010 and one of the requirements is to auto logout the site after certain amount of idle time. I used the following Powershell command to set the expiration time for the form token. The problem is it logout every 3 minutes even I'm working on the site. Do you know how to set it properly? Thanks.
Set-SPSecurityTokenServiceConfig -FormsTokenLifetime 3
Hi Steve, I've documented how the LogonTokenCacheExpirationWindow property works in this post
I've spent quite a while with the Reflector opened, testing the different scenarios. Hopefully this can save people time when trying to understand it.
We are also facing the same issue and would like to turn off persistent cookie and use session cookie.
But the difference is we are using Forms-based authentication for our site.
Can you let me know if we can apply the same fix detailed by you here?
$sts.UseSessionCookies = $true
One more thing, the KB 2462541 hotfix is also not applied in our environment.
Can you also let me know if we have to apply this hotfix before we try the above solution?
Hi Vitaly, Hi Steve
I have the same problem than Vitaly. This probleme occures when i use ADFS with Multi-tenancy site collection. If i use a classic Site Col with ADFS, everythig seems Ok. Any idea please ?
Thanks Steve for your posts. I'm thinking i might require something similar to achieve the following:
I have two SP Web Applications on a farm (for example X.mydomain.com and Y.mydomain.com) both configured with ADFS claims authentication. Hence on ADFS 2.0 I created two relying parties (one for each site).
All is working fine, however, for one of these web applications (Y.mydomain.com), I require that the system will always force re-authentication. i.e. Whenever user accesses Y.mydomain.com system should always prompt for credentials (even when hopping to from X.mydomain.com). Is this possible?
I was reading your ADFS articles. I am facing peculiar issue, may be you came across same issue. Please guide me if you have any solution on my problem. any help will be appricate.
My Environment is:
1.SharePoint 2010 farm with ADFS claim based authentication where current token expiry is 50 min
Whenever user open any word or excel file through Office Web Application (OWA) and keep drafting large documents when ADFS refresh (i.e. ADFS initiate token reissue ) happens, users start getting below exceptions. Same time user lost his changes from last saved instance till the time error popup.
1.Excel : “Either due to communication issues or server problem, you need to be rejoined to your editing session”
2.Word: “You do have permission to open this file”
We were able to replicate bug very easily.
During ADFS refresh, user data should remain intact.
1.Is it possible to achieve this by sliding session? or do you think any other solution to come over this issue.
2.By increasing ADFS Fedauth cookie expire. But this will lead to security threat and this will not resolve issue 100%.
Please share your valuable advice. Thanks for your efforts in advance.
-Sudarshan S Vatturkar
when we don't use SessionCookie ($sts.UseSessionCookies = $false), do you know where exactly does SharePoint save the persistent cookie on the disk drive? (Physical path name). Can we check/ configure this location?
Thanks for your help.
I have a following situation. Have a Sharepoint farm with 8 Front end servers with 2 of them allocated for Central Adimin. I have to setup the fedAuth cookie as session cookie to ensure, the session get removed when the user closes the browser. Ran the
following PS script to configure session cookies. $sts = Get-SPSecurityTokenServiceConfig $sts.UseSessionCookies = $true $sts.Update() iisreset Even after this configuration, I see FedAuth is being set as Persistent cookie with an expiration date. FedAuth
cookie is setup as Persistent cookie intermittently. Any insight on this intermittent behavior will be very helpful.
Does setting the TokenLifetime have any affect on this. It needs to be set per Relying Party Trust.
Get-AdfsRelyingPartyTrust -Name "Your Relying Party Trust Name"
Set-AdfsRelyingPartyTrust -TargetName "Your Relying Party Trust Name" -TokenLifetime 720 (12 Hours)