kerberosspn

Why an invalid service principal name (SPN) can be created using setspn


Today, I was able to create totally random and invalid SPN using the setspn command, but I dont understand why invalid SPNs are allowed. For example:

setspn -s RandomSvc/randomname.random.random valid_user was run successfully for valid_user in my domain (I substitute the actual user name here, but the user is a valid user in the domain).

Then if I do setspn -l valid_user, it will list this invalid entry.

I guess nobody can actually connect to this service since it does not exist. however, if I try to add a valid SPN, but typed it by mistake, I won't notice it until my application gives me an error. So why setspn does not do any validation (other than checking for duplicate with -s)?


Solution

  • The setspn command won't stop you from creating an invalid SPN, and for good reason, so there is no actual problem here believe it or not. Your definition of a valid SPN - that of a representation of an actual service running on an actual machine having a host name in DNS which can be reached over TCP/IP, is not going to be enforced by setspn for reasons I am about to describe. According to a KDC, while an SPN represents an actual service running on an actual machine having a host name in DNS which can be reached over TCP/IP, it doesn't actually have to be real at the time though. Here's why. Have you considered the case where perhaps the service, or even the machine it will be run on, will be installed later? The service and even the machine it is running on, and the DNS entry for said machine, doesn't have to be in place in the here and now when you create the SPN. Setspn.exe is simply a rudimentary tool which exists that allows you to create SPNs which will conform the RFCs for Kerberos. Its up to you to architect it right though, it's not going to hold anyone's hand in the process. I work for a large company and create SPNs all the time for services, and even for machines, which do not yet exist. That way the Developers or sys admins don't have to contact me to have an SPN created after the fact. They are following a project plan and savvy managers are going to have the SPN, DNS entires, IP addresses for machines, all planned out and created ahead of time before the OS admins get around to actually spinning up a live server for such use. So if setspn prevented people from creating an SPN for a service which is not yet up and running, there would be some very angry system admins out there. That is why it is allowed to create "invalid" SPNs, when you think it shouldn't. If you want something to do extra layers of validation not afforded by the generic setspn.exe, to catch mistakes before your application does, then you will have to create such a thing yourself. Ask yourself though, is this worth the time for something so specific? I mean, how often are you creating SPNs? This should all make sense to you now. I periodically run a setspn -X to catch duplicate sin my domain. I've never had the time, but I suppose I could also list out all the current SPNs in the domain and check if they are each currently valid, and take corrective action if they weren't. I'm sure there are probably more than a few which no longer are active. I don't consider it that big of a deal.