3

I found several references (see below) on blogs that the setspn.exe utility should be run from either a client or server machine in the domain, but not from the domain controller itself.

http://www.petri.co.il/how-to-use-setspn-to-set-active-directory-service-principal-names-2.htm http://blogs.msdn.com/b/russmax/archive/2009/10/20/configuring-kerberos-authentication-in-sharepoint-2010-part-1.aspx

What is the reason for this? What happens if I run setspn.exe on the domain controller anyway? I'm asking because an SPN I set disappears after a little while.

MvdD
  • 173
  • 2
  • 4
  • 10

2 Answers2

4

I'm not sure why they say, or said that, but I don't believe it's valid, at least not anymore, or not for the general case.

In fact, the MSDN documentation for registering an SPN for SQL Server 2014 Report Server explicitly directs you to login to a domain controller to run setspn.

HopelessN00b
  • 53,795
  • 33
  • 135
  • 209
  • Interesting, this conflicting information. Can't think of a reason why you would have to run the utility on the domain controller either. I would assume that no matter where you run the utility, the SPN gets registered in Active Directory. – MvdD Jun 04 '14 at 20:37
2

Possibly because of the real or imagined impact on DC performance: http://blogs.technet.com/b/askds/archive/2013/07/01/interesting-findings-on-setspn-x-f.aspx

... but I can't find a "this will bork AD" reason for the recommendation.

Brian Alletto
  • 151
  • 4