Server Swap Leads to SPN Discovery

Wednesday, March 06, 2013 10:01 AM by nairdo

I thought I understood DNS and naming enough to make a seamless server swap/upgrade, however during our test attempt to 'upgrade' one of our internal servers we ran into problems that ultimately was due to something called the "Service Principal Name".

Here was the scenario...(the server names used below have been changed to protect the identity of the guilty)... also this was done in a test environment first so no actual users were harmed during our discovery...

  1. Our users access this webserver via it's logical name, http://chms/.  That logical name also happens to be the actual Windows server name, "CHMS".
  2. Our new server is called CHMS01 and http://chms01/ works fine, however we wanted our users to continue using the logical service name, http://chms/
  3. Problem - when we updated the "chms" A record in our DNS to point to the IP address of the new CHMS01 server, IE users began receiving an authentication challenge which they don't usually get.  Even worse, if they entered their correct credentials, it would not accept them.  No bueno.

After Derek and I did some theorizing about what must be happening behind the scenes that might be causing this weird behavior, we consulted Google.  After 30 minutes of reading we both came upon something neither of us had ever encountered before, the SPN or Service Principal Name.

Looking at our CHMS server using the command "setspn -l CHMS" we saw that it indeed had a record that was causing the interference:

Registered ServicePrincipalNames for CN=CHMS,OU=Servers,OU=Computers,OU=Resources,DC=centralaz,DC=com:
        HOST/CHMS
        HOST/chms.centralaz.com

Without wanting to spend too much more time on understand the SPN, I concluded it's basically a Kerberos authentication safety measure that prevents automatic credential passing to a server other than the 'principal'.  Once we removed those records using the "setspn -d HOST/CHMS CHMS" and "setspn -d HOST/chms.centralaz.com CHMS" records, IE passed credentials to CHMS01 without any issue.

We'll probably make CHMS01 the principle for those "chms" entries by using the "setspn -s HOST/CHMS CHMS01" and "setspn -s HOST/chms.centralaz.com CHMS01" commands, but for now it did not make a difference in getting things working again.  Anyhow check out Derek's blog if you want to hear his perspective on this topic.

Comments

    No Comments

New Comments to this post are disabled

Powered by Community Server, by Telligent Systems