SharePoint custom claim provider getting access denied issue second time

Question

I am using the custom Claim Provider(SSO) to authenticate the external users to SharePoint Site. Site Working fine our live server.

But Client live Server I am getting the Access denied message 2nd time.But when i click to the go back to site access denied message gone. "go back to site" and the access denied is not an issue then.

Both sites are secure (SSL Implemented) Site.

SharePoint Server Logs showing following information.

Forms authentication failed for the request.

Reason: The ticket supplied was invalid.

• This is may be related to the Certificate issue.
• Client Firewall issue
• Cookies are not deleted when browser closed

Login Process:

• Login to the external Site
• Click to the custom Claim Provider link it will open the external site new tab.
• redirect to the SharePoint Site.
• Without sign out from the SharePoint Site close the tab.
• Again Click to the custom claim provider link.
• Redirected to the SharePoint Site "Access denied".
• When i am click to "Go back to site". Access denied is not an issue.

Please help me out with this problem.

Answer 1

There are three cookies that are downloaded from when a user is redirected to that site.

• ASPAUTH
• ASPNET Session ID
• FedAuth

The first two (ASPAUTH and ASPNET Session ID) expire when a browser session closes. However, FedAuth has a dated expiration of an hour after the website is visited. FedAuth also contains an encrypted key for SSO that, it gets generated every time an AD user logs in.

At this point, we wanted to verify what the session cookie state was in are site. We used the existing powershell window opened and enter the following command

-Get-SPSecurityTokenServiceConfig

UseSessionCookies is false

As you can see “UseSessionCookies” was set to False. We ran this bit of code to set that property to “True” - $config = Get-SPSecurityTokenServiceConfig - $config.UseSessionCookies = $true - $config.Update()

After submitting the command, we tested the site. few times and we found no trace of the Access Denied message. Even after closing and/or deleting cookies, the site continues to come up and authenticate normally.