Understand how Kerberos secret keys are shared on Windows™.
At this point, IIS Kerberos Authentication is working out of the box, but we don't see in the configuration how to share secret key between the User, Service and KDC as described in Kerberos Main Concept.
On Windows, secret shared keys are derived from password depending on the type of the key:
| Type of Key | Description |
|---|---|
| User keys | When a user is created, the user's password is used to create the user key. In Active Directory service domains, the user key is stored with the user's object in Active Directory. At the workstation, the user key is derived from the password when the user logs on. |
| System keys | When a workstation or a server joins a Windows domain, a new computer account is created and a password is automatically generated. |
| Service keys | Services use a key based on the password of the Windows account assigned to the process that is hosting the service. When using built-in accounts such as Network Service or Local System this account is the host computer account [see System key]. However, the process that is hosting a service can also be configured to use a domain user account. |
Figure 1. Secret Keys (User and Computer)
The link between Kerberos Service Name (described in Kerberos Service Name and Used Kerberos Service Name) and the corresponding user account must be made, linking the Kerberos Service Name with correct secret key. This is made through the Service Principal Name. Service Principal Names (SPNs) are unique identifiers for services running on servers. Every service that uses Kerberos Authentication needs to have an SPN set for it, so that clients can identify it (the service) on the network. If a SPN is not set for a service, clients have no way of locating that service.
Figure 2. Service Principal Name
At this point, having understood the previous information, you may have this question: Why does my IIS Kerberos Authentication work without defining any SPN?
That is a good question. It works because:
- By default, Windows has a list of built-in SPNs that are mapped on HOST SPN, and HTTP is in this list.
- By default, IIS is run as the Network Service account; in other words, the account used is the host computer account.
- By default, the SPN HOST points to the computer account.
This mechanism to derivate the secret key from the user's password has some side effects:
- No secret key file to share, this is implicity done through the password.
- If you change the account that launches a service, you may have to set/change/remove the SPNs. For example, If you change the user that run IIS without setting/changing the underlying SPN, IIS Kerberos Authentication will no longer work.
- You have to remember under which identity each Kerberos service runs.
External References:
- Kerberos Technical Supplement for Windows
- Troubleshooting Kerberos Delegation - Infrastructure
Requirements - Service Principal Names - Table 1: Built-in SPNs Recognized
for Computer AccountsNote: Download the document to access this information.