WARNING! This post was authored in 2012 and should no longer apply to most domains. Unless you are running an NTLM only domain (really?), you should validate your SPNs!
See this Microsoft article for details on SPNs.
———————————————————————
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.
Thanks , issue Fixed
I know this is really old – but after all the comments, I really felt the need to say something….
You all realise this advice is really bad…? You should not be changing this order….. Negotiate allows for Kerberos Authentication before trying NTLM.. Changing this order simply lowers your overall security without resolving the real issue. Think of it this way…. Imagine you have a choice of two front doors…… One has a tiny little lock on a door made of straw, and the other has a gigantic reinforced lock made of steel….. Now suppose that you were having problems with the gigantic reinforced lock………… To “fix” things, you decide to swap over to the door with the tiny little lock on a door made of straw… The problem is fixed, you can open it……. (so can anyone else!)….. Yes, you’ve solved the problem – but at what cost?
In this example, Kerberos is the steel strong door and NTLM is the flimsy straw door. Would you build a house in your city with a straw door? Fix whatever is breaking your kerberos authenticaiton…! Maybe it’s an SPN -maybe you’re using a HTTP alias that is not defined as an SPN, maybe you need to set up delegation?
Ugo is right. NTLM has known security issues. Fix the SPN.
Damien,
We agree, in a kerberos world fixing the SPN is the correct solution. We also would say that in a kerberos world, this issue simply doesn’t exist as the SPN is setup by default (I.E it will just work).
Looking back through our notes (the post is from 2012 after all), these issues occurred on NTLM domains. If your domain is an NTLM only domain, the solution is still effective and viable. Please do not take this as a statement that we recommend NTLM only domains (we do not). We do, however, understand that NTLM only domains do still exist in the wild for a variety of reasons and those domains may still encounter this issue.