How to Set up Kerberos Summary This guide guide provides the steps required to set up Kerberos Configure the Application Server User Account on the Domain Server The following instructions are based on Windows Server 2003. Setup steps for newer Windows Server versions will be mostly identical. 1. Click Start > Administrative Tool > Active Directory Users and Computers. 2. Click on the Domain name, for example the above screen uses Devzone.local, to expand a list of system Users then click Action > New > User. 3. Enter the application server hostname, for example, ws44x in the Full Name field. 4. In the User logon name field enter the applicable User name. 5. In the User logon name (pre\windows 2000) field enter the applicable logon name.
The string entered in the User login Name field should belong to the User Accounts group, for example, CN=ws44x,OU=User Accounts,DC=Devzone,DC=local. The name should not be identical to the computer name. If the names are the same, the command to set the service principal name, that is setspn, may incorrectly update the computer name record. Therefore the User login name should be set to something like ws44x.user. 6. Click the Next button. 7. Check the details in the resulting screen and if correct click the Finish button.
8. Launch the command prompt, Start / Run / CMD.EXE / OK, then enter the setspn command to register the Server Principal Name. Note: The setspn command on Windows Server 2003 systems has limited functionality. This means whether the nominated account is a computer name or a user name it cannot be specified. This would not be problematic unless the account name appears under both Computers and User Accounts in Active Directory. If the account name appears under both Computers and User Accounts, the command should be run from a Windows 7 (or higher) workstation which has logged into the AD server. In this case the command to use is: setspn -U -A HTTP/ws44x.devzone.local ws44x.user Generate the keytab file: Create the key-tab using the Java version 7 ktab command: ktab a HTTP/ws44x.devzone.local@DEVZONE.LOCAL Secret1 n 0 k ws44x.keytab In the above example Secret1 should match the password entered when the User account was created. Configuring the Application Server Ensure that your registration includes the krb module. If it does, there are three system parameters for Kerberos that must be completed.
Parameter No. 8951 singlesignontype KRB5 Parameter No. 8963 singlesignonspnegokrb 5Conf c:/program Files/Softlink International/Library Server/krb5/krb5.conf Parameter No. 8964 singlesignonspnegologi nconf c:/program Files/Softlink International/Library Server/krb5/login.conf 1. Copy the generated keytab file to c:/program Files/Softlink International/Library Server/krb5/. 2. The krb5.conf file should contain the following: [libdefaults] default_realm = DEVZONE default_tkt_enctypes = rc4-hmac aes256-cts-hmac-sha1-96 aes128-cts des3-cbc-sha1 des-cbc-md5 des-cbc-crc default_tgs_enctypes = rc4-hmac aes256-cts-hmac-sha1-96 aes128-cts des3-cbc-sha1 des-cbc-md5 des-cbc-crc permitted_enctypes = rc4-hmac aes256-cts-hmac-sha1-96 aes128-cts des3-cbc-sha1 des-cbc-md5 des-cbc-crc [realms] DEVZONE = { kdc = devzone.devzone.local default_domain = DEVZONE } [domain_realm].devzone = DEVZONE Note 1: Replace DEVZONE with the name of your domain. Note 2: In multi-corporation deployments, the krb5.conf file is a shared resource - each corporation using Kerberos must specify the exact same file. The file is also used for secure LDAP configurations. 3. The login.conf file should contain the following attributes: Krb5LoginModule { com.sun.security.auth.module.krb5loginmodule required keytab=file:///c:/program Files/Softlink International/Library Server/krb5/ws44x.keytab principal=http/ws44x.devzone.local@devzone.local host=http://ws44x.devzone.local:8080/ usekeytab=true debug=true storekey=true isinitiator=false; }; 4. The setting debug=true should be removed once a working configuration has been established. 5. When accessing a system from a workstation in another domain and Kerberos is active, the user may receive a BASIC authentication input box, prompting for a user name and password. DO NOT enter you login details as they will be sent non-
encrypted over the network. You can instead simply enter any characters then press enter to access the system as the regular OPAC user. If the Application Server is to be Available to Non-domain Workstation Users 1. Configure a separate URL alias in the DNS server. 2. Set the above host setting to match the internal URL. This will ensure the Kerberos functionality is only active when domain users access the system. Alternatively, you can add the sso web argument to the URL to bypass Kerberos functionality, for example, http://ws44x.devzone.local:8080/oliver/login?sso=false. Configuring the Client Workstation The client workstation needs to be a member of the Domain Server domain. When using IE, the browser needs to detect the application server URL as a member of the local zone.
Troubleshooting The jboss-log4j.xml file in server/sahara/conf contains a couple of pre-defined logging categories for the kerberos module. These may be set to "TRACE" to assist with the deployment but should be set back to default values once a valid configuration has been confirmed. It is also possible to obtain further logging of the dependent java libraries by setting the following property in run.bat -Dsun.security.krb5.debug=true Setting debug=true in the login.conf will also turn on additional logging information. The debug setting also ensures the two configuration files specified by the system parameters are re-read with each login request. Common Errors Error The browser returns an NTLM token or displays a BASIC authentication user/password input box. Reason The SPN is not correctly registered. 1. Issue the klist command from the client workstation and check whether a ticket exists for the application server. 2. Issue the ldifde command on the AD server. Inspect the resulting export file. Check to ensure there is a single line serviceprincipalname: HTTP/ws44x.devzone.local associated with the record
dn: CN=ws44x.local,OU=User Accounts,DC=Devzone,DC=local 3. Issue the command setspn X to search for duplicate SPN s (requires win7 version of setspn). GSSException: Defective token detected (Mechanism level: GSSHeader did not find the right tag) (Mechanism level: Encryption type AES256 CTS mode with HMAC SHA1-96 is not supported/enabled) (Mechanism level: Specified version of key is not available (44)) (Mechanism level: Invalid argument (400) - Cannot find key of appropriate type to decrypt AP REP - AES256 CTS mode with HMAC SHA1-96) (Mechanism level: Clock skew too great (37) (Mechanism level: Checksum failed) Ensure the application server FQN has been added as a local site on the local intranet. Note: adding this in IE also affects chrome. Ensure you are accessing the application via the FQN. This can occur when attempting to access the library server from the same machine. The Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files should be installed. The keytab should be re-generated with Key version number (KVNO) set to zero. You can do this with the Java 7 version of the ktab.exe program, like this: ktab.exe -a HTTP/ws44.softlink.net.au@KRTEST <password> -n 0 -k ws44.keytab.3 You can verify the KVNO's of a keytab with the following command: klist -e -k ws44.keytab The JDK of ktab.exe also needs JCE unlimited strength policy files (as above). Install this then re-create the keytab file. This can occur when the system time on the KDC and workstation are not synchronised. 1. The password entered into the keytab file does not match the user password on the KDC The SPN was mapped to a computer name account.