At ArmgaSys, we consume SSL certificates at a ferocious rate. Lync, Exchange, OWA, and UM all require SSL certificates to secure the multitude of communication channels.
While much debate rages around “Should I purchase a public certificate which will only be used on internal servers”, the reality in the field is many companies choose to leverage Active Directory Certificate Services. This is done for one very good reason: Internally generated (and trusted) certificates are free.
One of the issues we run into when requesting new certificates from ADCS is the dreaded 401 Unauthorized issue with Certsrv.
The Scenario
- Type the URL for your Certificate Server
http://[domain server]/certsrv - You are prompted for administrator credentials
- You enter said credentials
- You are again prompted for administrator credentials
- You enter said credentials
- You are presented with a 401 Unauthorized error message
- You bang your head against your desk in frustration
Root Cause
The IIS server is not negotiating your credentials correctly.
Solution
- Logon to the server hosting the Active Directory Certificate Services
- Launch Internet Information Services (IIS) Manager
- Drill down and click on the the CertServ application
(Usually Server –> Sites –> Default Web Site –> CertSrv)
- Click and open the Authentication icon in the home view
- Click once on Windows Authentication to highlight the entry
- Select Providers from the action pain (located a the right of the IIS Manager)
- Move the NTLM provider to the top of the list. It *must* be the first enabled provider
- Restart IIS using IISRESET at the command prompt
Happy Certificate Issuing!
Thanks! This was exactly what I was looking for. 😉
Fixed me! Hurray!
And this is why I value the tech community. It would have taken me a long time to track this down. Much appreciation for posting this simple yet important solution.
Hello,
Thanks for this helpful information on IIS.
I am curious why NTLM needs to be listed first(above Negotiate).
If Negotiate is first I thought it would try both and if Kerberos failed it would use NTLM. Is this not the case?
Thanks for your help.
Lee
Thank you! I wonder why it would not work with the default settings.
Saved my day. Thank u
Fixed it for me. 🙂
I hope Microsoft adds your solution to their knowledge base soon. Helped me very much, thanks a lot.
I love you man! (puts cold compress on head)
u rock!
ty m8!! it actually works!
Thank you, worked perfectly
Thanks man. It works like a charm.
You saved me a bunch of pain with your well written solution, thanks!!
This solved the issue for me too! 🙂
NB: in another domain I administer I did not have any problems logging in to https://localhost/certsrv – and that CA server also had the same “Negotiation” before “NTLM”. So on that server “NTLM” did not need to be first in the list. Same server OS and patch level (2008R2 w/Enterprise CA)
You should not have to change the order. The underlying issue should be resolved without changing the order as a work around. The underlying issue is that SPN for the service is missing.
Ugo, that may be true.
But, changing the order solves the issue quickly without having to delve into SPNs. Easy always wins!
Thank-you so much! I had found this solution on other sites but they didn’t include step 8! I was restarting the web site instead of IIS, which didn’t take the change.
Thank you, thank you, thank you!
I can’t believe this is not configured out-of-the-box. Quite incredible.