This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
We already made a few updates from SharePoint 2013 to 2016 or 2019 successfully. When using ADFS-Authentication and preserving the same SiteCollection-URL on the new SharePoint Server, some users may still have an Authentication-Cookie for the URL but they can't work anymore with the new SharePoint until they logout from ADFS and login again (either via Logout-Link https://adfsurl/adfs/ls/?wa=wsignout1.0 or by deleting all Browser-Cookies). The detailed error in ADFS is: Microsoft.IdentityServer.Web.InvalidRequestException: MSIS7042: The same client browser session has made '6' requests in the last '1' seconds.
We never expecience such issues in production since years, but just when updating/moving the SiteCollection to a new SharePoint server. So I think this is not a general configuration-issue but has to do with the actual SharePoint-Server-Upgrade and outdated/obsolete user-cookies.
What can we do to prevent this issue when performing a SharePoint-Update?
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(313.6, 51%, 40%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EED%3C/text%3E%3C/svg%3E)
I'm checking how the things are going on about this issue. Whether the post helps you?
You can accept the post as answer if it helps.
@BenjaminFreitag-8735 did you ever find a solution to this issue? We started seeing the same issues on one of our SP farms and it is difficult to reproduce for testing. However, in our ADFS logs, we see the error daily from different users. Like you, have set our ADFS token life to 8 hours and our SharePoint token is set to the default 10 minutes. It would be nice to find out why SharePoint is not accepting the cookie. Our workaround has been to have users open the site in a different browser, but it is not a solution. We have not made any updates to our SP or ADFS farm since this started happening in April 2020, but have applied the monthly security patches to the OS.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(316.8, 51%, 40%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EBF%3C/text%3E%3C/svg%3E)
No, we just recommended affected users to delete the browser cookies.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(272, 64%, 36%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ERM%3C/text%3E%3C/svg%3E)
Please check the user bookmarks. When user bookmarked urls Delete cookie option is not clearing cookies. So, we need to Uncheck first one and then check all remaining items to clear cookies.
Also, please check the user bookmarks. When user bookmarked urls Delete cookie option is not clearing cookies. So, we need to Uncheck first one and then check all remaining items to clear cookies.
We made another migrations to SharePoint Server Subscription Edition and ran into the same issue again. SharePoint has this in the Event-Log:
Cookie signature validation failed. This might indicate an issue with the configured STS Signing Certificate. Input Value: '05.t|adfs|@mail.com,05.t|adfs|@mail.com,https://my-sharepoint.com/,....', Signature Bytes: ...
How can this be prevented? Is it necessary to migrate the STS Signing Certificate from the old SharePoint server to the new one? Or should the ADFS realm be changed?
It looks like an existing the FedAuth cookie remains in the Browser for a few days (CookieLifetime default is 5 days). Because of this, no new FedAuth cookie is issued by SharePoint STS.
I didn't find any way to export the STS Signing Certificate ("SharePoint Root Authority"?) with the private key.
Changing the ADFS realm didn't fix this nether.
I found a workaround: Change the FedAuth Cookie name. It will issue a new FedAuth-Cookie, that works side by side. Example in web.config:
<cookieHandler mode="Custom" path="/" name="FedAuth2025">
This issue is more related to lifetime of tokens. You could change the LogonTokenCacheExpirationWindow to be less than the SAML TokenLifetime by the PowerShell command.
$sts = Get-SPSecurityTokenServiceConfig
$sts.LogonTokenCacheExpirationWindow = (New-TimeSpan –minutes 1)
$sts.Update()
iisreset
For more detailed information, you could refer to the article below.
The same client browser session has made '6' requests in the last '11' seconds.
Thanks for your feedback. We set the SAML TokenLifetime (of ADFS RelyingPartyTrust) to 14 days and $sts.LogonTokenCacheExpirationWindow is set to 10 Minutes (default), so LogonTokenCacheExpirationWindow is less than the SAML TokenLifetime and the issue still occurred. So I think it must be something different or it's because of the 14 days?
We set the TokenLifetime to 14 days so users don't have to login again and again, since all users must use the web-based ADFS-Login and complained about too many login prompts every day or even every few hours. Is this related? If yes, what's the best solution to accomplish the login-prompt-issue? Would it be better to increase ADFS KmsiLifetimeMins to 14days instead and find a way to have KMSI enabled by default?
This is not required.
Please check the user bookmarks. When user bookmarked urls Delete cookie option is not clearing cookies. So, we need to Uncheck first one and then check all remaining items to clear cookies.