Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

When adding a new SPN into the Kerberos domain, you have the option of mapping the SPN to a user. In general, I join the domain through Integrated Windows Authentication, and this creates a new computer account for the service, but now, I would like to try using Kerberos without IWA.

I believe I have a thorough understanding of how Kerberos authenticates clients for a computer host (good enough for what I'm trying to do) - but what exactly does mapping a SPN to a domain user do?

Edit: I am not asking about how SPNs work in general. I am asking specifically about the details of mapping a SPN to a domain USER.

Answer:

  1. Kerberos will allow that specific user to HOST this service - rather than authenticating with a computer host account, the server would be joined into the Kerberos domain under this specific user. Authentication occurs via this user.

Any further information would be greatly appreciated.

share|improve this question

3 Answers 3

up vote 4 down vote accepted

An AD user account will have a Service Principal Name only if it is used to run a service. As such, most AD user accounts will not have any Service Principal Names. The most common example of times when an AD user account will have SPNs is if that user account is used as a service account to run MS SQL, IIS, etc. If an AD user account is used to operate a service, but no SPN is registered in AD, then that service cannot use Kerberos.

In contrast, AD user accounts will always have a User Principal Name.

Service principal names are associated with the security principal (user or groups) in whose security context the service executes. SPNs are used to support mutual authentication between a client application and a service. An SPN is assembled from information that a client knows about a service. Or, it can obtain information from a trusted third party, such as Active Directory. A service principal name is associated with an account and an account can have many service principal names.

share|improve this answer
    
I was indeed trying to get at the case where a service is running under a user account. In what ways is this user account used by the service? –  lululoo Sep 23 '13 at 18:11
    
@lululoo The service runs under the security context of that user account. All processes in Windows need a security context under which to execute. –  Ryan Ries Sep 23 '13 at 18:17
    
I see. Thank you for that information. I will look into "security context" as I am not familiar with the concept. It seems like what I actually need is that second service (TestHost1) to run under the security context of that user account. –  lululoo Sep 23 '13 at 18:29

You should read the MSDN documentation if you're not even sure which problems SPNs solve. It is thorough and complete.

share|improve this answer
    
I did not ask about the problems which SPNs solve. Even if I did, linking me to the entire documentation does not point me in the right direction. Please try to consider my present state in understanding Kerberos a bit more before simply writing "RTFM". Thank you for the link though. –  lululoo Sep 23 '13 at 18:27

To fill in the gaps a bit, if your service needs to run in the context of a.domain user account, then that user account needs to have the SPN.

Where this is commonly found is with IIS application pools. If you have multiple IIS servers for an application behind a load balancer, you may not have the SPN assigned to a specific server, but to a domain user account, and the IIS application pools run in the context of that account. This would be particularly true if you want to impersonate the authenticated user with a "delegation" level token, and access another service on a remote computer.

How you acquire the authenticated user's token is not necessarily important. It can be either an integrated auth token, or a token that you build with the users' supplied credentials, for example with forms authentication. If using constrained delegation, you can impersonate the user without an existing auth token or password, all you need is the username.

But for any of that to work, an SPN is always required.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.