When our customers install our software, they often opt for a "split install", where the services run on one box and the database is on another box. The services might talk to other services, or the database might contain stored procedures that need to talk to another database.
This leads us into the murky world of Kerberos and SetSPN.
I was about to send the support guys an email breaking down the difference between the various authentication levels supported by Windows, but I realised that my knowledge gets a bit vague about the difference between impersonate and delegate, and I'm really sketchy when it comes to Kerberos.
Can anyone enlighten me?
Authenticate (authn) means to identify a user. Authorize (authz) means to determine what rights an authenticated user has. An Anonymous user has not been authenticated but may have some rights on the system (a "guest"). Impersonate and delegate are two sides of the same coin. I impersonate you if I use your identity to do an action; you delegate me the right to impersonate you and take some action.
Kerberos (or "Kerb") is a token-based authentication scheme. That is, it's a way to let users log in and be properly identified (authn) and given rights (authz) in system.
Per comments: You don't need Kerb for delegation, but it's built in to Server 2003. You can also use NTLM, SSL Certificate Mapping or Digest Authentication. But none of those is as robust and flexible as Kerb. You also have the option to do constrained delegation which allows a delegation only to a certain services. The reason is that you need a trusted 3rd party to validate your token. Basically, the flow goes like this ...
- I authenticate to my domain.
- That domain issues a certificate to me. That cert makes claims about me.
- I take that cert and give it to the service I want to allow me to do something
- The service takes that cert and Valida's it with a trusted certificate authority
- The service gives or denies access based on communication with the certificate authority
It's a deep subject as you know. :) Here is a good article on some of the above options. Also, check out this web cast -- it's about ADFS, but it does a good job on the concepts that might help.
You might want to brush up on Kerberos on Ken Schaefer's web site. His Kerberos FAQ rocks.
Adding to the above answer, delegation is having one server authenticate to another server using the client's original authentication. With Kereberos, this is relatively easy to accomplish - you just allow the first server to "re-issue" the client's authentication token. The alternative (NTLM) doesn't allow for delegation easily/securely since its a challenge/response authentication - the only way for the server to authenticate to the secondary server is if it can respond to the challenge/response, and to do that it would need the client's password.
I've got a ServerFault answer regarding Kerberos Delegation that might be interesting.
