SSO(Single Sign-On) doesn’t work for a SharePoint Application Published through Forefront UAG(Unified Access Gateway) when we use Client Certificate Authentication(CAC) to Authenticate on the UAG Portal
Scenario
I am sure a lot of us would have worked on Client Certificate Authentication configuration on UAG Portal.
In this case as well we had that configured on the UAG Portal which we used for Publishing an Internal SharePoint Server. And the Client Certificate Authentication was working fine as well, as we were being Prompted for the Client Cert when we were going to the UAG Portal. We could successfully Log-In to the UAG Portal after selecting that Certificate.
Client Certificate Authentication set up on UAG is a bit complex and it makes use of Customizing a few INC files on UAG. Recently one of my fellow colleagues has written a very nice Blog on how to configure Client Certificate Authentication on UAG, here is the link for that Blog:
Let’s continue with further details of the issue, so now when we were trying to access the SharePoint Application after logging on to the Portal, we were getting an Error “You are not Authorized to view this Page”.
This meant that the SSO to the Application was not working. And the only Option to configure SSO on UAG while using Client Certificate Authentication is KCD(Kerberos Constrained Delegation). Have a look at the article below to have more information on how to configure KCD for SSO on UAG:
https://technet.microsoft.com/en-us/library/ee690467.aspx
Troubleshooting
We collected the UAG Trace in order to investigate the Failure to do SSO. Please have a look at the Article below in order to get a better understanding on how to collect UAG traces:
https://blogs.technet.com/b/ben/archive/2010/09/03/uag-tracing-made-simple.aspx
When we tracked the session for our SharePoint access in the Trace, we could see the below Response coming from the SharePoint server:
As you can see above we were getting “401 Unauthorized” from the SharePoint Server for our Request. Which was expected as the user was not Authenticated. But the part which was NOT expected was the “WWW-Authenticate” Header. If you see above the Rounded Off Portion, the server is ONLY sending NTLM and BASIC options in that Header.
And, as we had KCD(Kerberos Constrained Delegation) configured in the SSO for SharePoint Application on UAG, we expected NEGOTIATE or KERBEROS Options coming as well from the SharePoint Server. Then only we will pass on the Credentials to the server, otherwise not.
SO, we went on the SharePoint Server and checked for the Authentication Providers and came to know that only NTLM was configured there. That’s the reason we were only getting the Option NTLM in the “WWW-Authenticate” Header coming from the SharePoint Server in the 401 Response.
We selected the option “Negotiate(Kerberos)” in the Authentication Provider settings. Please follow the steps below to change this setting:
Browse to Central Administration and navigate to Manage Web Applications in the Application Management section:
Select Classic Mode Authentication.
Configure the port and host header for each web application.
Select Negotiate as the Authentication Provider.
After making the above change we could successfully access the SharePoint Application after logging on to the UAG Portal.
Blog Written By
NITIN SINGH
SUPPORT ESCALATION ENGINEER, FOREFRONT EDGE SECURITY, MICROSOFT
Comments
Anonymous
May 16, 2013
Hi, I truly like to reading your post. Thank you so much for taking the time to share such a nice information. I'll definitely add this great post in my article section. www.certificate-attestation.in/certificate-authentication.htmlAnonymous
May 20, 2013
Good to know that you liked this Post. I will keep coming up with these kind of Posts in the future as well.