Skip to Main Content
Return to Navigation

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.

Consult your Microsoft Active Directory documentation for more information.