Kerberos errors

As extension of the previous blog on Windows Native Authentication with Oracle, this little piece of info:

Kerberos Error 68.
Kerberos testing (kinit -k -t command) responded with

kinit: KRB5 error code 68 while getting initial credentials

Searches revealed:

KDC_ERR_WRONG_REALM 68 Reserved for future use
is being returned by Active Directory because your users are attempting to obtain a Kerberos TGT for a realm that is not hosted on the server to which they are authenticating.
The existing MIT Kerberos distribution that you are using does not know how to respond to this error. Windows machines can attempt to search the Active Directory Global Catalog in order to determine the actual principal name to use for authentication.

The krb5.conf file had port 88 specified on (one of the member) Active Directory server. Changing that to port 3268 (which is the Global Catalog port), changes the error into this:

kinit: Cannot contact any KDC for requested realm while getting initial credentials

I think this means the realm (domain in AD speak) is not serviced by this server. Problem is: where is it serviced.
Addition.
OK - got that solved; you can specify many Kerberos servers in the [realms] section of the krb5.conf file. Doing so resolved the issue of error 68.

Kerberos Encryption
Now, the next problem arises:

kinit: Bad encryption type while getting initial credentials

klist
There is a handy utility, klist, that can help out here. Klist can read the keytab file, and display all kinds of details, one of which is the encryption type used. Previous keytab files revealed RSA-MD5 was used, the latest one revealed CRC32:

klist -k -e -K -t FILE:/home/bortel/second.keytab

Keytab name: FILE:/home/bortel/second.keytab
KVNO Timestamp Principal
---- ----------------- --------------------------------------------------------
1 01/01/70 01:00:00 HTTP/[nondisclosed] (DES cbc mode with CRC-32) (0x3e4986bc07972cda)


Keytab name: FILE:/home/bortel/first.keytab
KVNO Timestamp Principal
---- ----------------- --------------------------------------------------------
4 01/01/70 01:00:00 HTTP/[nondisclosed] (DES cbc mode with RSA-MD5) (0x855d98e6793186e9)

With the first keytab file (listed as second entry), WNA works without any changes from the Oracle examples. The second keytab file (listed on top) has a different encription type, compared to the first. This might explain the encryption error...
Sure enough; altering the krb5.conf file, adding enctypes, so that the file reads the following resolved that issue:

[libdefaults]
default_realm = HOME.LOCAL
default_tkt_enctypes = des-cbc-crc
default_tgs_enctypes = des-cbc-crc
clockskew = 300

[realms]

Another enctype would be des-cbc-md5. This looks like the default one, as I did not specify enctypes in an earlier krb5.conf file.

Windows 2000 versus Windows 2003?
Now for the underlying reason, I can only guess. Is this a MS Windows issue? Did MS change from des-cbc-crc to des-cbc-md5 between Windows 2000 Server and Windows Server 2003? Seems unlikely, unless MS Windows always tries CRC32 as well as MD5.

Anyway, the problems I was facing were resolved, as this shows:

kinit -k -t /home/bortel/second.keytab HTTP/[nondisclosed]
klist
Ticket cache: /tmp/krb5cc_879
Default principal: HTTP/[nondisclosed]@HOME.LOCAL

Valid starting Expires Service principal
01/30/08 09:39:37 01/30/08 19:39:37 krbtgt/HOME.LOCAL@HOME.LOCAL

klist also allows to show the encryption type used:

klist -e
Ticket cache: /tmp/krb5cc_879
Default principal: HTTP/[nondisclosed]@HOME.LOCAL

Valid starting Expires Service principal
01/30/08 09:39:37 01/30/08 19:39:37 krbtgt/HOME.LOCAL@HOME.LOCAL
Etype (skey, tkt): DES cbc mode with CRC-32, DES cbc mode with CRC-32