In Win/AD, does kerberos authentication require the services accounts to be the same

active-directorydelegationkerberos

I am trying to isolate the cause of a KRB5KDC_ERR_BADOPTION (13) that I am seeing come back in a WireShark trace.

I have set an SPN to associate xxx/server.fqdn:port with the domain account that the xxx service is running under on the target server (lets call it domain\target). The server service that is will be acting as the delegate is running on a different service account (e.g. domain\delegate). Is this allowed? Or do all of the services need to be running under the same service account (i.e. the service account being used by both the target service and the middle-man service are running with the same AD service account, with appropriate SPNs set up for both services associated to that same AD service account)

Best Answer

No they dont need to be the same. But they do need to be in the same domain. See http://blogs.technet.com/b/askds/archive/2008/06/13/understanding-kerberos-double-hop.aspx . You might find http://blogs.technet.com/b/tristank/archive/2007/06/18/kdc-err-badoption-when-attempting-constrained-delegation.aspx useful.

Related Solutions

Need help in setting up SPN for Kerberos Authentication

Since you are running the application pool as TEST\user-iis, you must apply the SPN to that account. It is generally accepted that you should also include another SPN for the short name of the host as well.

setspn -a http/test-iis.test.net TEST\user-iis
setspn -a http/test-iis TEST\user-iis

And just for clarification, all setspn is doing with these commands is modifying the "servicePrincipalName" attribute of that user account. If you open the Properties dialog for it and go to the Attributes tab, you can scroll down to servicePrincipalName, open it up, and see the changes you made.

Regarding your ping issue, check the Windows firewall on the IIS box. ICMP is not enabled by default.

Windows – Can someone please explain Windows Service Principle Names (SPNs) without oversimplifying

A Service Principal Name is a concept from Kerberos. It's an identifier for a particular service offered by a particular host within an authentication domain. The common form for SPNs is service class/fqdn@REALM (e.g. IMAP/mail.example.com@EXAMPLE.COM). There are also User Principal Names which identify users, in form of user@REALM (or user1/user2@REALM, which identifies a speaks-for relationship). The service class can loosely be thought of as the protocol for the service. The list of service classes that are built-in to Windows are listed in this article from Microsoft.

Every SPN must be registered in the REALM's Key Distribution Center (KDC) and issued a service key. The setspn.exe utility which is available in \Support\Tools folder on the Windows install media or as a Resource Kit download, manipulates assignments of SPNs to computer or other accounts in the AD.

When a user accesses a service that uses Kerberos for authentication (a "Kerberized" service) they present an encrypted ticket obtained from KDC (in a Windows environment an Active Directory Domain Controller). The ticket is encrypted with the service key. By decrypting the ticket the service proves it possesses the key for the given SPN. Services running on Windows hosts use the key associated with AD computer account, but to be compliant with the Kerberos protocol SPNs must be added to the Active Directory for each kerberized service running on the host — except those built-in SPNs mentioned above. In the Active Directory the SPNs are stored in the servicePrincipalName attribute of the host's computer object.

For more information, see: Microsoft TechNet article on SPN, Ken Hornstein's Kerberos FAQ

Best Answer

Related Solutions

Need help in setting up SPN for Kerberos Authentication

Windows – Can someone please explain Windows Service Principle Names (SPNs) without oversimplifying

Related Topic