Appendix: Enabling Kerberos Authentication in a Microsoft Active Directory Environment

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.

Adding a Server User for Kerberos Single Signon

To add a server user:

1. On a Windows 2003 domain controller, select Start, Control Panels, Administrative Tools, Active Directory Users and Computers.

2. From the menu bar, select Action, New, User.

3. 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.

4. Click Next.

5. 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

6. Click Next and then click Finish.

Generating the Keytab File and Mapping the Service Principal Name

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.

1. Open a command window by selecting Start, Run and then entering cmd in the Open field.

2. 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
   -princ	HTTP/www.example.com@EXAMPLE⇒ .COM	Specifies the service principal name in the form user@realm.
   -mapuser	krbsrv@example	Maps the name of the Kerberos principal specified by the princ parameter to the specified local user name.
   -crypto	RC4-HMAC-NT	Sets the encryption type to use.
   -ptype	5_NT_PRINCIPAL	Sets the principal type to Kerberos 5 for Microsoft Windows
   -pass	*	Causes the utility to prompt you for a password
   -out	c:\temp\krb5.keytab	Specifies the name and location of the Kerberos version 5 .keytab file to generate.

3. 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.

4. 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