Keytab Validation

Setting up Kerberos authentication for the Oracle Databases or WNA with Access Manager is so simple if things go as per plan. To ensure smooth build process, it will be very helpful to perform some form of sanity checks wherever possible. One such check in process of Desktop SSO configuration is validating Keytab.

For a Keytab to successfully function the Key Version Number (KVNO) used by the Key Distribution Center (KDC) and the service principal keys stored in keytab file for services hosted on the system must match.

If not, tickets validation and thus end user authentication will fail. When tracing or debugging is enabled on the products using Keytab, messages similar to following will appear suggesting KNVO mismatch:

• Specified version of key is not available
• Invalid KNVO for Kerberos authentication

Oracle SQLplus clients configured for Kerberos authentication fail with following message.

ORA-12631: Username retrieval failed

Note that ORA-12631 is a very broad error.

The KVNO can get out of synchronization when a new set of keys is created on the KDC without updating the keytab file with the new keys.

Verification process:

We can verify KNVO using the following process:

From Keytab

On he server, where Keytab is located:

$ klist -k -t /app/kerberos/keytab

The out put will look like:

Service Key Table: /app/kerberos/keytab

Ver     Timestamp                   Principal
6 31-Dec-1969 16:00:00 oracle/db1.ziontech.demo@ZIONTECH.DEMO

If klist command is not available, we can use oklist available under Oracle database  $ORACLE_HOME/bin

From KDC

Most of the enterprises use Microsoft Key Distribution Center (KDC), which is part of the Active Directory domain services. It uses the Active Directory as its account database and the Global Catalog for directing referrals to KDCs in other domains.

The KNVO for an user object in Active Directory is stored under an operation attribute called msDS-KeyVersionNumber. This can be obtained by following LDAP query:

ldapsearch -h ad.ziontech.demo -p 389 -D "testuser1@ziontech.demo" -w "Welcome1" -b "DC=ziontech,DC=demo" -s sub servicePrincipalName=oracle/db1.ziontech.demo msDS-KeyVersionNumber

The output will look like:

CN=db1,CN=Users,DC=ziontech,DC=demo
msDS-KeyVersionNumber=6

Compare value of msDS-KeyVersionNumber with value under Ver in Keytab. They should match. If not, regenerate keytab using ktpass and replace the current keytab file.

In the above ldapsearch command, options represent the following:

-h hostname of the Active Directory server
-p Active Directory LDAP port
-D BindDN. You can use the default admin account or any other service account with proper read privileges
-w Specify password for Bind DN.
-b root of LDAP tree

Change servicePrincipalName value (oracle/db1.ziontech.demo in above example) according to your environment. Usually, it is same as principal (without @REALM part) found in Keytab.

601