Prerequisites for Kerberos Configuration

Encryption for Kerberos/SPNEGO SSO

Kerberos does not have any restrictions for the encryption algorithms that are used. Ensure that you have a common encryption type for the Kerberos configuration file, Kerberos keytab file, Kerberos SPN, and Kerberos client.

For example, if the Kerberos client uses the RC4-HMAC encryption, the target server must also support the RC4-HMAC encryption. Also, the Kerberos configuration file must list RC4-HMAC first in the default_tgt_enctypes and default_tkt_enctypes parameters.

Microsoft® Active Directory configured with LDAP

Kerberos/SPNEGO authentication requires a Key Distribution Center (KDC) and an authorization server.

IBM® Engineering Lifecycle Management supports a deployment with Microsoft® Active Directory domain controllers that run on a Microsoft Windows Server system only. Each Active Directory domain controller functions as a Kerberos KDC and an authorization server. Active Directory also functions as an LDAP server.

Engineering Lifecycle Management Server must be part of the Kerberos Domain

For Engineering Lifecycle Management applications to run with SPNEGO, the server that hosts the application must be part of the Kerberos Domain.

Deployments often might have multiple Microsoft Active Directory domain controllers with a trust relationship. Usually, these trusts are bidirectional, and they can be configured both within a Kerberos forest and externally.

In a typical deployment, the WebSphere® Liberty server Server is configured on one domain controller, and client computers that are configured on another domain controller. With a trust relationship, browser clients and rich clients can use cross-realm authentication to access Engineering Lifecycle Management applications that are running on WebSphere Liberty server. For more information about deploying multiple Active Directory domain controllers, see Administering Domain and Forest Trusts.

Principal name, Keytab, and Kerberos configuration file for Engineering Lifecycle Management

To configure Engineering Lifecycle Management with Kerberos/SPENGO, you need a service account that is dedicated for Engineering Lifecycle Management Server, which is mapped to the Public URI as the principal Name for the service account. Next, you need to create a Keytab file that is configured to the Service account and a Kerberos config file that will be used by the WebSphere Liberty server servers hosting Engineering Lifecycle Management applications.

Map an Active Directory service account to Service Principal Name (SPN).

The principal name must match the public URI planned for the Engineering Lifecycle Management server. If Engineering Lifecycle Management is deployed on a distributed topology, the public URI is ideally your IBM HTTP Server or any Reverse proxy.

The hostname specified when creating the SPN should match with the public URI of Engineering Lifecycle Management, which means it might be your Webserver (IBM HTTP Server) or Liberty Server depends on your scenario.

For example, in the following command, elm.example.com is used as the Public URI for Engineering Lifecycle Management application and must be used as principal name mapped to a domain user named krbelm_user.

C:\> setspn -a HTTP/elm.example.com krbelm_user
Registering ServicePrincipalNames for
CN=krbelm_user,CN=Users,DC=MYDOMAIN,DC=EXAMPLE,DC=COM
HTTP/elm.example.com
Updated object

Create a Kerberos keytab file Public URI of Engineering Lifecycle Management

Generate the keytab file that uses Microsoft tool ktpass command on Active Directory Domain Controller Server (KDC server).

For this command, example hostname is elm.example.com and the domain controller host is myAd.example.com. The domain controller name is mydomain.example.com and the Kerberos realm name is MYDOMAIN.EXAMPLE.COM, which is the domain controller name in all uppercase letters.

C:\> ktpass -out krb5.keytab -princ
HTTP/elm.example.com@MYDOMAIN.EXAMPLE.COM -mapUser krbelm_user -mapOp set -
pass security -crypto AES256-SHA1 -ptype KRB5_NT_PRINCIPAL
Targeting domain controller myAd.MYDOMAIN.EXAMPLE.COM
Using legacy password setting method
Successfully mapped HTTP/elm.example.com to krbelm_user.
Key created.
Output keytab to krb5.keytab:
Keytab version: 0x502
keysize 107 HTTP/elm.example.com@MYDOMAIN.EXAMPLE.COM ptype
1 (KRB5_NT_PRINCIPAL) vno 3 etype 0x12 (AES256-SHA1) keylength
32(0x148d643db283327d3f3d44547da67gj688hh668cade)

Create a Kerberos configuration file

The Kerberos configuration file contains client configuration information. This information includes the locations of KDCs for the realms of interest, defaults for the current Kerberos realm, and mappings of hostnames onto Kerberos realms. For Liberty servers, you must create this file manually.

• default_realm: Identifies the Kerberos realm for the client (all letters in uppercase)
• default_keytab_name: Provides the file system location of the Kerberos keytab file
• default_tgs_enctypes: Identifies the supported list of session key encryption types that the client should request when making a TGS-REQ
• default_tkt_enctypes: Identifies the supported list of session key encryption types that the client should request when making an AS-REQ
• kdc : Specifies a list of the hostname of the Kerberos Key Distribution Center (KDC) for this realm and port number
• domain_realm: This section provides a conversion from a domain name or hostname to a Kerberos realm name.

[libdefaults]
    default_realm = MYDOMAIN.EXAMPLE.COM
    default_keytab_name = FILE:C:\krb5.keytab
    default_tkt_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 rc4-hmac
    default_tas_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 rc4-hmac
    forwardable = true
    renewable = true
    noaddresses = true
    clockskew = 300
[realms]
    MYDOMAIN.EXAMPLE.COM = {
       kdc = maAd.example.com:88
       default_domain = example.com
    }
[domain_realm]
    .example.com = MYDOMAIN.EXAMPLE.COM