SAP Consulting has implemented a so called SPNegoLoginModule (a JAAS
login module for NW04 as of SPS12) which
allows Windows Integrated Authentication from IE Browsers to SAP J2EE
Engine via the Simple and Protected Negotiation Protocol. Underlying
security protocol is Kerberos. The login module uses the classes in the
package org.ietf.jgss whose implementation is a Kerberos implementation
that's part of JDK 1.4. The general impression is that the SUN Kerberos
implementation performs well, however, we seem to have found a bug. The
bug occurs when you configure a Java process to acquire Kerberos
credentials for 2 different Kerberos realms (in our case 2 different
Windows Domains) and you provide UNC path names for the keytab files. In
this case, keys from the second keytab file cannot be read. If the path
names are local, everything works fine.
I've recreated the error in a small test tool that is attached. It is
easily reproducable that everything works as desired if you do not use
UNC path names.

More technical explanations: The Sun Java APIs allow to acquire Kerberos
credentials only by processing a login module stack. For a given realm
that I want to acquire credentials for, I need a user in that realm and
a keytab (a file that contains a Kerberos key for a Kerberos Principal)
file. (It also works with other mechanisms but this is the one that is
relevant for us). Then I configure a login module stack with a
com.sun.security.auth.module.Krb5LoginModule and I pass the keytab file
and the principal as a parameter. For each additional principal I want
to acquire credentials for I need to add an additional Krb5LoginModule
with the appropriate configuration to the stack.

Now we encountered problems when we performed the configuration within
the J2EE engine with 2 different Windows domains. We need this because
we want to get Windows Integrated Authentication for users in 2
completely separate unrelated Windows domains. Fortunately, I could
isolate the problem within a small utility.

The attachment dings.jar contains the test tool and the test output. In
"01 - error" you can find the error. The key is not found in the file
referenced by the keyTab parameter in the second Krb5LoginModule. In the
test "03 - success" you can see that the corresponding keyTab is not the
problem because the key can be read if only one Krb5LoginModule is in
the login module stack. In "05 - success" you can see that everything
works perfectly fine when the keytab files are referenced not with a UNC
path but a local file path.

Steps for reproducing the problems
----------------------------------

The attached dings2.zip contains
the following files:
go.bat - batch file to start the tool
test.java - test code
test.class - compiled test code

What you need to do is easy to explain:

- Have 2 MS domains. Create a user in each of the domain and create a
  keytab file as explained in section 7.3 and 7.4 in the documentation.
  Use them instead of keytab.ume and keytab.msctsc.
- Use the jaas.conf and krb5.conf contained in "01 - error". Adjust the
  following parameters according to your environment:
  * Names of the Kerberos Realms in krb5.conf
  * Addresses of KDCs in krb5.conf
  * principal parameter in jaas.conf
  * keyTab parameter in jaas.conf
- Then start the tool like in the error01-output.txt (use go.bat instead
  of gowdf.bat).

Additional information about the Login module can be found in the
attached documentation.