SharePoint Web App randomly re-authenticate RRS feed

  • Question

  • Our sharepoint web application re-authenticates with ADFS randomly. this causes our sharepoint Learning Kit failure as it pings the server every 10 minutes with POST, but the re-authentication changes it to GET. Our client is very angry with it as we cann't fix the issue.

    Fixed: After switch another 3 servers on (4 servers with LB), the session works as expected which will be re-authenticated after ADFS Tokenlifetime - ServiceTokenCacheExpirationWindow.

    We have dount that the default MaxLogonTokenCacheItems (250) has performance issue if the server has memory pressure.

    We didn't change it as we will need someone from microsoft to confirm what is the real meaning of MaxLogonTokenCacheItems.

    Monday, July 23, 2012 2:16 AM

All replies

  • Hi Jack,

    Before you  fixed the issue, please find the error why your SharePoint learning Kit is failed. Now, If you want to let your client not re-authenticates, you can doing some settings on your IE client.

    Inside of internet explorer > internet option > Security > Custom Level > Security Settings. There is a section called User Authentication.  Please  select the radio dial called "Automatic logon with current user name and password."



    Tuesday, July 24, 2012 8:34 AM
  • Thanks for the response. The site is extranet, there are more than 10,000 users from different companies.
    These users have user login in our ADFS server and use ADFS claims authentication to access our SharePoint web site.
    We cann't ask our users to change their IE setttings, these settings are disabled and control by their network administrator in most companies.

    There are somethings wrong with the SharePoint, it randomly redirects users to ADFS authentication.

    Similar issue has been reported:


    here is one of our trace, I am happy to provide more information.

    Random reauthentication

    Wednesday, July 25, 2012 6:03 AM
  • There must be an network connectivity issue. In your farm, Make sure all your Web servers are functional. Check by accessing the site with the front end server. for example for web server abcd, check your web application http://abcd/ inspite of accessing it with its DNS name.

    Further, Check , you load balancer is functioning well.

    Ashish Ranjan (Please click "Marked As Answer" if a post solves your problem or "Vote As Helpful" if a post has been useful to you)

    Wednesday, July 25, 2012 6:21 AM
  • We are thinking about the following settings:

    MaxLogonTokenCacheItems: We are thinking to change this value. Is the default 250 too small to handle up to 10,000 concurrent users?
    We checked the memory usage, it uses 7G out of 8G.Does garbage collector remove user's token from MaxLogonTokenOptimisticCacheItems randomly if the there is memory stress.
    UseSessionCookies: We change this to true. Does this affect the random timeout?
    We cannot replicate the issue in our DEV envi, we are not confident enough to try PROD as the servers are shared by many live web sites.
    Our server settings:
    SecurityTokenServicePublicUrlSuffix         : /_vti_bin/spsecuritytokenserviceactive.svc
    SecurityTokenServiceMetadataPublicUrlSuffix : /_vti_bin/spsecuritytokenserviceactive.svc/mex
    LocalLoginProvider                          : Microsoft.SharePoint.Administration.Claims.SPLocalLoginProvider
    TrustedLoginProviderNames                   : {www.XXXXX.au}
    TrustedLoginProviders                       : {www.XXXXX.au}
    TrustedAccessProviders                      : {}
    UseSessionCookies                           : True
    WindowsTokenLifetime                        : 10:00:00
    FormsTokenLifetime                          : 10:00:00
    ServiceTokenLifetime                        : 10:00:00
    MaxLogonTokenCacheItems                     : 250
    MaxLogonTokenOptimisticCacheItems           : 100000
    LogonTokenCacheExpirationWindow             : 00:10:00
    MaxServiceTokenCacheItems                   : 250
    MaxServiceTokenOptimisticCacheItems         : 100000
    ServiceTokenCacheExpirationWindow           : 00:10:00
    Name                                        : SecurityTokenServiceManager
    TypeName                                    : Microsoft.SharePoint.Administration.Claims.SPSecurityTokenServiceManager
    DisplayName                                 : SecurityTokenServiceManager
    Id                                          : e99ec379-acaa-4ebc-a268-2c5620cb663d
    Status                                      : Online
    Parent                                      : SPSecurityTokenService Name=SecurityTokenService
    Version                                     : 104616
    Properties                                  : {}
    Farm                                        : SPFarm Name=IPSPS40__ConfigDB
    UpgradedPersistedProperties                 : {}

    Wednesday, July 25, 2012 6:28 AM
  • There must be an network connectivity issue. In your farm, Make sure all your Web servers are functional. Check by accessing the site with the front end server. for example for web server abcd, check your web application http://abcd/ inspite of accessing it with its DNS name.

    Further, Check , you load balancer is functioning well.

    Ashish Ranjan (Please click "Marked As Answer" if a post solves your problem or "Vote As Helpful" if a post has been useful to you)

    We do have load balancer, as we found there are issues with ADFS claim authentication. we have removed other web servers, all traffic go to one server at the moment. This doesn't fix the issue.
    Wednesday, July 25, 2012 11:36 PM
  • Couple of Questions:

    1. What are specs on the Web Servers in the farm in the farm?
    2. What version of SharePoint are you running? (version number as  well)
    3. What is the topology of the farm?  What else is running on the FEW’s?

    Couple of Thoughts:

    1. The default setting for a timeout is 20 Minutes.  Meaning if the user is inactive on the page, they will be signed out after 20 Minutes.  You can change this using powershell.  Are these users getting prompted when actively browsing the site before the 20 min inactive timeout?
    2. 8GB RAM is really low for 10,000 concurrent users if that’s the total memory on the few servers.

    Thursday, July 26, 2012 1:51 AM
  • Hello Jack,

    As the author of the post you previously mentioned with the same problem I am interested in this MaxLogonTokenCacheItems that you speak of.  We are currently working with Microsoft to debug our issue.  The most recent thing they just told us was to change MaxLogonTokenCacheItems to 10000 AS WELL AS MaxSeviceTokenCacheItems to 10000.

    Can someone explain WTH those are?  They seem unrelated to our problem where we can do an iisreset of our sharepoint site, and only one person logged in can reproduce our random re-authenticate within 30mins.  Why would these limits have any play in that?

    HOWEVER that being said.  We did do what Microsoft said and as of right now it seems to be working.  Yes we are less than one day trying these settings but we have not had a re-authenticate happen yet after a few hours.   The jury is out but it is seems promising atm.  I'll post back if we get a fail...


    Wednesday, September 19, 2012 10:30 PM
  • Ok our tests are in now.  This is what we see though testing (my problem is referenced here http://social.msdn.microsoft.com/Forums/is/sharepoint2010general/thread/e13871ce-5b6f-4a3c-bc04-fbce47870856)

    MaxServiceTokenCacheItems = 250
    MaxLogonTokenCacheItems = 250
    Result = Booted in 5-10 minutes

    MaxServiceTokenCacheItems = 10000
    MaxLogonTokenCacheItems = 10000
    Result = Cannot break +30 minutes

    MaxServiceTokenCacheItems = 25
    MaxLogonTokenCacheItems = 25
    Result = Booted quickly (1-2 minutes)

    MaxServiceTokenCacheItems = 25
    MaxLogonTokenCacheItems = 10000
    Result = Cannot break (40  minutes)

    MaxServiceTokenCacheItems = 10000
    MaxLogonTokenCacheItems = 25
    Result =  Booted (1-3 minutes)

    What we have here is what would appear to be something that alleviates our problem...  MaxLogonTokenCacheItems being set to a higher value is providing relief.  I am not saying this is a solution until I hear from SOMEONE AT MICROSOFT as to why this is or whether it is a valid thing to do.

    Microsoft states about MaxLogonTokenCacheItems: The strong cache keeps the most recently used items to guarantee the token is alive during the life of the request. The weak cache can release resources by garbage collection under memory pressure.

    Until I have the following questions answered I consider this a temporary fix:

    1. What does it mean for us to make it 10000?  Does it mean that we will start experiencing issues that are memory related in another area?  

    2. Why does this only appear for our ADFS users and not our Active Directory/Windows Auth users, or forms based users?

    3. Is setting the value to 10000 simply covering up a real bug that we may see in an upcoming patch?

    If someone at Microsoft could answer these question for us we would so appreciated it. :)


    Thursday, September 20, 2012 10:40 PM
  • We are working the same problem.  Our setup is claims over forms with a custom membership/role provider.

    Here's my current understanding of the auth problem.  When you authenticate, a FedAuth cookie is created.  A corresponding copy is saved in the token cache of the server that authenticated you.

    If you have multiple servers and you don't have sticky sessions, then you could be redirect to another server, which does not have a copy of the cached information.  Thus, you need to login again.

    Or, if you limit is too low (like the default of 250), then the info is thrown out, and you have to authenticate again.  The tests show that.

    Or you could have both!


    Thursday, November 1, 2012 3:19 PM