This appendix describes how to configure Microsoft Active Directory for Kerberos authentication. To enable Kerberos authentication in Microsoft Active Directory, you must:
Add a server user for Kerberos single signon.
Create a keytab file and map user credentials to a service principal.
To add a server user:
On a Windows 2003 domain controller, select Start, Control Panels, Administrative Tools, Active Directory Users and Computers.
From the menu bar, select Action, New, User.
Enter values in the Full name and User logon name fields. You should use your own internal naming conventions. For example,
Full name: Kerberos Server
User logon name: krbsrv
Note. The First name, Last name, and Initials fields are not important, but you must specify the Full name and User logon name. Kerberos authentication uses the User logon name only.
Click Next.
Use this table to set the password and check box values:
Field |
Value |
Password |
<your_complex_password> |
User must change password at next logon |
Cleared |
User cannot change password |
Selected |
Password never expires |
Selected |
Account is disabled |
Cleared |
Click Next and then click Finish.
To generate the keytab file and map the service principal name:
Note. These steps assume that the server user is krbsrv and the domain is example.com.
Open a command window by selecting Start, Run and then entering cmd in the Open field.
In the command window, enter
C:\>ktpass -princ HTTP/www.example.com@EXAMPLE.COM -mapuser krbsrv@example.com -⇒ crypto RC4-HMAC-NT -ptype KRB5_NT_PRINCIPAL -pass krbPass! -out c:\temp⇒ \krb5.keytab
This calls the ktpass utility with these parameters:
Parameter |
Value |
Description |
|
|
Specifies the service principal name in the form user@realm. |
|
|
Maps the name of the Kerberos principal specified by the princ parameter to the specified local user name. |
|
|
Sets the encryption type to use. |
|
|
Sets the principal type to Kerberos 5 for Microsoft Windows |
|
|
Causes the utility to prompt you for a password |
|
|
Specifies the name and location of the Kerberos version 5 .keytab file to generate. |
When prompted for the password, enter some value. This resets the password and does not have to match the one used when the user was created.
Note. Make sure that the password meets domain security requirements or the utility fails.
Verify that the command window output is similar to the following text. If so, the mapping is complete and the keytab file krb5.keytab is in the C:\temp directory.
Key created. Output keytab to c:\temp\krb5.keytab: Keytab version: 0x502 keysize 83 HTTP/www.example.com@EXAMPLE.COM ptype 1 (KRB5_NT_PRINCIPAL) vno 15 etype 0x17 (RC4-HMAC) keylength 16 (0xdd74540caa4a230af2ed75558a37995d)
Service Principal Name Considerations
The SPN can include any possible URL. Valid SPNs for the example.com domain include:
HTTP/mail.example.com@EXAMPLE.COM
HTTP/other.domain.net@EXAMPLE.COM
HTTP/localhost@EXAMPLE.COM
HTTP/192.168.1.100@EXAMPLE.COM
Browsers request the client-to-server tickets based on the URL that the user enters. If a page, for example http://www.example.com/page.html?param=value, requests authentication, then the browser requests a client-to-server ticket for an SPN that is based on the website domain name: HTTP/www.example.com@EXAMPLE.COM.
Although http://192.168.1.100 and http://www.example.com might refer to the same physical machine, an authentication request from http://192.168.1.100 requests a client-to-server ticket for HTTP/192.168.1.100@EXAMPLE.COM only, not HTTP/mail.example.com@EXAMPLE.COM. In other words, an SPN mapping which uses the server DNS name is not applicable when the client visits the server site using its IP address.
In addition, Microsoft Active Directory will not proceed with the client-to-server ticket exchange unless the server machine is either in the same domain as the directory server or in a trusted domain. For example if http://mail.example.com references a machine on the directory server domain (or a domain it trusts), then the Kerberos ticket exchange proceeds. If http://mail.example.com is not in the same domain or a trusted domain of the directory server, then the exchange does not proceed, regardless of the site’s URL.
See Also
Consult your Microsoft Active Directory documentation for more information.
http://technet.microsoft.com/en-us/library/cc753771(WS.10).aspx