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

UltraSearch - manual install

Because of switching operating systems, my iAS repository needs rebuilding. And of course, UltraSearch was forgotten.
So, after adding UltraSearch, I still needed the wksys user in the database. Have been looking for it once beore, and now decided to make a 'note to one self'. Of course, the Database Creation Assistent is useless, because it does not recognize the already installed instance, as so often.

SQL> set echo on
SQL> spool ultrasearch_inst.log
SQL> @$ORACLE_HOME/ultrasearch/admin/wk0setup.sql /oracle/db/10gRel2 "" SYS change_on_install "as sysdba" wksys SYSAUX TEMP "" "FALSE" DATABASE "" /oracle/db/10gRel2/jdbc/lib/classes12.zip /oracle/db/10gRel2/jlib/orai18n.jar /oracle/db/10gRel2/jdk/bin/java /oracle/db/10gRel2/ctx/bin/ctxhx cs-frank03:1521:o10gr2 cs-frank03:1521:o10gr2 /oracle/db/10gRel2
SQL> spool off
SQL> exit

Test with:

select comp_name, version, status from dba_registry
where COMP_ID='WK';

Once bitten twice shy.

Or should it be "Three strike - you're out!"?
Strike one: MicroSod started complaining about the validity of my XP install - out.
Strike two: tried Ubuntu 7.10 instead - graphics (solved) and networking issues; tried for two days - out.
Strike three: running CentOS 5.1 now. Graphics is OK - nVidia recognized, network is a known issue on an Asus P5B, and the solution is to prepare a driver disk for the installation, and make a new r8168 network module afterwards. I know, that sounds strange, but the driver (install with "linux dd") was not included in the install; during install, the network was activated correctly, after a reboot, network failed to start.

Anyway - download the latest driver, and -as root- perform:

# cd /tmp/r8168-8.004.00
# make
# depmod -a

# modprobe r8168

# ifconfig -a

You should now see an active network link (eth0). Just add a line "alias eth0 r8168" to /etc/modprobe.conf and configure the interface. Reboot to see if everything works.