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.
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 = Get-SPSecurityTokenServiceConfig
$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)