通过

Kerberos FatFingeritis? How to set your Kerby SPNs the safe way

  • 项目

<A Microsoft PFE’s Note from the Field>

So in my day to day SharePoint support endeavors one of the
classic cases that come in from time to time is customers trying to implement
Kerberos into their Farms.   One of the
issues I see pop up a lot is duplicate SPN’s.  

The classic method (via the command line) is to run the
following command to create an SPN:

Setspn –a http/<FQDN or Netbios Name>  Domain\usercredential

For example   Setspn –a
http/connect.sharepoint.com
sharepoint\content1 

This would create an SPN to be used to create a valid
Kerberos ticket for the http/connect.sharepoint.com  site.  
Easy stuff here and you can verify this by going into ADSIEdit and open
the properties for the Content1 Service Name.

But how do we get the issue with Duplicate SPN’s.   Usually this comes down to poor planning
before you turn on your computer.   Say
as an example (and one I see often) you didn’t think this through and plan your
AuthN properly.  Or say you just made a
simple “FatFinger” or had a “Brain Cramp”… it happens.   For illustration purposes lets go with the
idea that you created the above mentioned SPN but for some reason you tried to
run the Setspn command again using a different account.  Voila! that’s where we are in trouble.   In my example I created two SPN entries
pointing to the same site but I used two different service accounts.   SPContent and SPContent1.   As you can see in the screenshot below I get
an Event ID 11 thrown which if you can read the text is basically telling me
exactly what I need to know to go forward and fix the issue.


 
 
  So is there a way to verify this before I go and run the
command?   Absolutly.    If you enter the command Setspn –x you will
get a list of any duplicates that exist in your environment.

 

  Let’s take this one step further and combine
both the –A and the –X into a single FatFinger Proof method of creating our SPN’s

Operation ABORTED!!!   
So if we look at the above output were shown the same information as the
Setspn –x but we are also combining this with the ability to add an SPN.   In both of these outputs you can clearly see
that in my demonstration I tried to create an SPN for the same site
http/connect.sharepoint.com but I used separate accounts.    Also note that I can use the same account
for multiple hosts if I so choose.. in this case im using Spcontent1 for both
http/connect and http/my.   

So in a perfect world when you are doing this work and you don’t
have any duplicates you can use either the setspn –x initially to see if any
duplicates exist or do what I always do… use the setspn –s and cover everything
in one sweep.  In the above example if
there were no duplicates the process would successfully finish and presto chango
you have your SPNs created

 

Hope this helps someone out there J  Cheers!

Comments

  • Anonymous
    January 01, 2003
    Thanks for posting this guidance Bob. Cheers. Craig

  • Anonymous
    January 01, 2003
    WOW ! great article.. The workaround is attractive and asks not to much effort! Keep going.. Gokan