Wow, that is a lot of delegating…seriously how many times can you say it in one sentence. Today’s post is one that threw me for a loop. As a domain admin I have the right to configure constrained Kerberos delegation. There may come a time when you want to delegate that out to a user or group.
My first thought was to assign the user/group Full Control on the OU that included the accounts. At this point I would run the following command
setspn -a http/workstation01 adminprepbrian
Surely Full Control would grant me the permission to do this…Failed!!! Insufficient access rights. It is not a “permission” that is needed, it is a “User Right”. So where do you go to assign rights to work with constrained delegation and what User Right is it? Well, you won’t find it in the Local Security Policy.
The User Right that you need to grant is SeEnableDelegationPrivilege. Now where and how do I grant this User Right. Well it turns out you still should delegate Full Control to the user/group that you want to grant this User Right too. Then on a DC you must run the following command:
ntrights -u adminprepbrian +r SeEnableDelegationPrivilege
Just make sure to modify that domain/user to match your environment. Now when I run the Setspn command it works because that account has the correct User Right. You may have to wait for replication to occur if you are in a distributed environment.
SPNs seem to get more and more use these days so I thought it be nice to give an explanation of what SPNs are.
SPNs are used for mapping a service to a user account. You will find SPNs used predominantly with Delegation and Impersonation and a lot of times this is between a web server and another server hosting a service that requires Kerberos authentication. The key here is that Kerberos authentication is required and thus this is primarily used within an organization or a trusted company. An example of this would be when an end user logs on to a web server which then logs on to a SQL server. The web server is trying to authenticate against the SQL server using the web users credentials but it doesn’t have the right to do that type of delegation. If that were the case I don’t think online banking would be…well online. :,,) Now this is only the case when the web and SQL instances are on separate servers. If they were on the same server you would not need to worry about SPNs.
Kerberos is the key here. Kerberos authentication happens all the time and is very common. The special part of Kerberos authentication is that it requires a ticket that ensures each party is who they say they are. This ensures that a hacker can’t impersonate another user. The only type of delegation that Windows allows is a Kerberos connection. In short the user knows how to contact and authenticate with the web server but has no idea who the SQL server is but needs data from it and needs to authenticate…thus delegation and impersonation needs to occur.
An SPN is a name that Kerberos clients use to identify a service for computer that is also using Kerberos. In fact you can have multiple instances of a service running on a system and each could have its own SPN. SPNs have a specific format that they use which looks similar to this – <service class>/<host>:<port>/<service name> The only parts that are required are the serviceclass and host. For example, HTTP/www.adminprep.com would be an SPN registration for any page on that webpage. You would use the port option if you wanted to specify a port with the service, like this – MSSQLSvc/sqlservername.adminprep.com:3411. More info on the formatting of SPNs can be found here.
SPN names can use short NetBIOS names or long FQDN names. I recommend always using FQDNs as you can have potential name conflicts in a multi-domain forest with short names.
For a more detailed looked into SPNs i’ve provided a few links below along with links to common issues. However the first place you should go is to this TechNet article.
Service Principle Name (SPN) Resources and Issues