SPnego on SLES9 and IBM JDK 1.4

[MarcelRabe]

Hi all,

from <a href="http://help.sap.com/saphelp_nw04/helpdata/en/43/4bd58c6c5e5f34e10000000a1553f6/content.htm">SAP Help</a> I understand that the spnego login module is not tested on IBM JDK 1.4 and suse linux 9. I've implemented it (or at least i tried) and it seems like that either the browser does not sent a kerberos ticket (i don't see anything in a http trace) or that the J2EE server just doesn't even start the login module. Nothing appears in the logs.

But when a deliberatly make a faulty change in the spnego login module configuration, then it does show up in the default trace, so i guess it does "start up".

Anyway, anyone out there that can tell me that the IBM JDK, SLES9_64 and SAP SPNego login module is supported/works?

Much obliged

Marcel

[Former Member]

Hi Marcel,

The SPNegoLoginModule uses the Kerberos implementation functionalities of the underlying Java SDK. Therefore the OS should be no problem. We implemented SPNegoLoginModule on IBM JDK and AIX without problems.

Use SPNego test application (note 953660) to find out if general configuration has errors (UME, J2EE properties, getting service user credentials). After that double check the client configuration from help.sap.com installation guide. If your browser does not send a SSO2 cookie then your browser configuration is wrong or your SPN is not registered correctly...

Regards

Christian

[MarcelRabe]

Hi Christian

thnx. The guest continues then.

Rgds

Marcel

[MarcelRabe]

Hi Christian,

did you do anything special in regard to the IBM JDK configuration? For instance the SPNegoConfig test application doesn't work unless the com.sun.security.jgss.accept policy is configured. And according to the <a href="http://help.sap.com/saphelp_nw04/helpdata/en/43/4e80824d155f86e10000000a1553f6/frameset.htm">"manual"</a> this is not required.

The message returned from the testapp is: General failure, unspecified at GSSAPI level minor string: Cannot get credential for principal service <KPN>

The user itself is found and the Klist -e -f -k - K returns the correct key.

I've tried it with two users: one with ktpass that included /DesOnly /crypto DES-CBC-MD5 and one without those parameters (as I understood that for IBM JDK this would nog be necessary). Unfortunatly both do not seem to work.

It looks like the JDK cannot decrypt the ussr credentials, or?

Much obliged

Marcel

[MarcelRabe]

Ok solved.....

The error means that there is no key in the ticket cache. This was added by:

java com.ibm.security.krb5.internal.tools.Kinit -k -t myhost.keytab <kpn> <password>

for the user <sid>adm

and verified with

java com.ibm.security.krb5.internal.tools.Klist -f -e -a

After a reboot it worked fine

(PS Christian you were right about the browser config)

[Former Member]

Marcel,

Nice to hear you solved it.

Regards

Christian

[former_member245181]

Hi Guys,

I'm also trying to get SPNego working for SLES9 running on AMD x86_64 with IBM JDK 1.4.

I've got the resolution mode 'prefix' active.

When I try to login, I get the following message in the server's DefaultTrace file:

"> #1.5#00300571ACAE006600000029000033C900041E6C3150DFD6#1159349939527#System.err#sap.com/irj#System.err#Guest#1####00a9e5704e

0c11dbb1ca00300571acae#SAPEngine_Application_Thread[impl:3]_4##0#0#Error##Plain###org.ietf.jgss.GSSException, major code: 10,

minor code: 0

> major string: Defective token

> minor string: Token is not meant for me

> Ticket target name: HTTP/jcdep.<domain>@<REALM> > My name: host/jcdep.<domain>@<REALM>#"

I've run kerbtray and see a ticket : HTTP/jcdep.<domain>@<REALM>

I tried to get our AD guys to generate a keytab for HTTP/jcdep.<domain>@<REALM>, when I try this one I get the following in the DefaultTrace.trc :

> #1.5#00300571ACAE006900000011000041E000041E6C6AFC4791#1159350906924#com.sap.security.core.server.jaas.spnego.util.Configura

tionHelper#sap.com/irj#com.sap.security.core.server.jaas.spnego.util.ConfigurationHelper#Guest#1####4146f6c04e0e11dba1d700300

571acae#SAPEngine_Application_Thread[impl:3]_21##0#0#Error##Java###Error during credentials acquiring.

> [EXCEPTION]

> #1#org.ietf.jgss.GSSException, major code: 11, minor code: 0

> major string: General failure, unspecified at GSSAPI level

> minor string: Cannot get credential for principal service host/jcdep.<domain>@<REALM>

Note : setspn was run on the AD with the syntax :

setspn -A HTTP/jcdep.<domain> j2ee-dep-jcdep

When the AD guys run "setspn -L" they see both SPNs (host and HTTP).

I've even tried Kinit like Marcel did, but I had to specify the kpn and realm on the command line because it couldn't determine this for some reason (even though it's specified in the krb5.conf) :

"/opt/IBMJava2-amd64-142/bin/java -Djava.security.krb5.kdc=<AD server> -Djava.security.krb5.realm=<REALM> com.ibm.security.krb5.internal.tools.Kinit -k -t /usr/sap/DEP/JC04/ktpass/j2ee-dep-jcdep.keytab host/jcdep.<domain>@<REALM>

i. Done!

ii. New ticket is stored in cache file /home_sap/depadm/krb5cc_depadm

"

Any tips why the portal (EP7) sees my browser ticket and complains that it's not for the portal ?

Thanks for your time,

Regards

Anthony

[Former Member]

Hi Anthony!

In your Login Module Stack - what is the value of parameter com.sap.spnego.jgss.name?

Did you try the spnego config tool mentioned above?

Regards

Christian

[yonko_yonchev]

Hi Anthony,

try to run the ktpass command on the ADS again, but this time use http/jcdep... for a KPN (you've done this already but for a KPN host/jcdep...). You'll also need to transfer the keytab to the J2EE Engine again but hopefully this will fix the problem.

Regards,

Yonko

[former_member245181]

Hi Christian and Yonko,

Christian : The value of com.sap.spnego.jgss.name is "host/jcdep.<domain>@<REALM>"

If I change this, will I not need the AD user re-created with the krb5principalname set to the new value (ie HTTP/jcdep.<domain>@<REALM>) ? We did try this early on, but it didn't seem to work. I could try it again and let you know the error.

I can't seem to run diagtool (note 958107), I've got a message posted with SAP on marketplace regarding this. We've deployed the spnego config tool and I've tried it out, here's the results :

Java System Properties Test page:

javax.security.auth.useSubjectCredsOnly false

java.security.krb5.conf /usr/sap/DEP/JC04/ktpass/krb5.conf file found

com.ibm.security.jgss.debug all

com.ibm.security.krb5.Krb5Debug all

J2EE User test page (test for my AD user "graya"):

Searching for user with krb5principalname = [graya] ...

Searching for user with uniquename = graya... User GrayA found.

J2EE user - Acquire Credentials (test for host/jcdep.<domain>@<REALM>):

Acquiring credentials for user [host/jcdep.<domain>@<REALM>]

succeeded: --- GSSCredential --- Number of mehanism credentials: 1 [1] Kerberos credential, mechanism: 1.2.840.113554.1.2.2 Owner: host/jcdep.<domain>@<REALM> Usage: accept only StartTime: 9/28/06 9:01 AM InitLifeTime: unknown AcceptLifeTime: indefinite Krb5Client: host/jcdep.<domain>@<REALM> Krb5Server: unknown --- End of GSSCredential ---

J2EE user - Acquire Credentials (test for HTTP/jcdep.<domain>@<REALM>):

Acquiring credentials for user [HTTP/jcdep.<domain>@<REALM>]

failed: org.ietf.jgss.GSSException, major code: 11, minor code: 0 major string: General failure, unspecified at GSSAPI level minor string: Cannot get credential for principal service HTTP/jcdep.<domain>@<REALM>

If I change the value of com.sap.spnego.jgss.name to the HTTP/jcdep..., will it not just complain along the same lines as this test ?

Yonko :

I already tried to get the AD guys to generate a keytab using ktpass for HTTP/jcdep.... but when I use that keytab :

1) I don't see any ticket in my kerbtray when I try to access the portal

2) I get this error in the DefaultTrace :

#1.5#00300571ACAE006900000011000041E000041E6C6AFC4791#1159350906924#com.sap.security.core.server.jaas.spnego.util.ConfigurationHelper#sap.com/irj#com.sap.security.core.server.jaas.spnego.util.ConfigurationHelper#Guest#1####4146f6c04e0e11dba1d700300571acae#SAPEngine_Application_Thread[impl:3]_21##0#0#Error##Java###Error during credentials acquiring.

[EXCEPTION]

#1#org.ietf.jgss.GSSException, major code: 11, minor code: 0

major string: General failure, unspecified at GSSAPI level

minor string: Cannot get credential for principal service host/jcdep.<domain>@<REALM>

Thanks in advance,

Anthony

[Former Member]

Anthony,

1.) set com.sap.spnego.jgss.name to "HTTP/..." since the browser requests a kerberos ticket for HTTP service which is then send back to j2ee server.

2.) Also problematic is that HTTP/ is not found resp. authenticated via SPNegoTestApp. This might indicate that either SPN is not set up correctly, or that you have the wrong keytab file on J2EE side...

Does the testapp find user "HTTP/.."? -> If no might be SPN issue

Does the testapp authenticated the user? -> If no might have the wrong keytab.

Regards,

Christian

[former_member245181]

Hi Guys,

Another point to consider, I'm not sure if this will impact on things but I will tell you anyhow :

The portal is running on a virtual cluster environment. Even though the portal components (scs, jc, db) are running on the same server, they have the potential to run on any node within the cluster. We access the portal using it's virtual hostname and IP, and are not really concerned where exactly the components are physically running as we're directed to them anyway.

I'm thinking that any communication between the Portal -> AD, the AD will see the real IP and hostname of the physical node the portal is running on. The jcdep.<domain> name is the portal's virtual name for outside access.

Perhaps I need to generate the key using the hostname and domain of the physical node ?

What are your thoughts regarding this ?

Thanks in advance,

Anthony

[yonko_yonchev]

Hi,

You can try this, though I think the AD sees the virtual address - judging from your original post with the error message at least.

BTW...following what I suggested you seem to get the same error as Marcel a couple of posts above. He also posted a solution - try it out. Apparently the problem in this case comes down to no ticket in ticket cache.

Regards,

Yonko

[former_member245181]

Hi Yonko,

I already did the Kinit (please see my 1st post).

I'll change the com.sap.spnego.jgss.name to the HTTP/jcdep... again (as Christian suggested) and then post the error.

Thanks for your time,

Anthony

[former_member245181]

Hi Christian,

I've now tried changing the com.sap.spnego.jgss.name parameter to HTTP/jcdep..... This means that now the keytab I'm using was generated for host/jcdep... and the command "/opt/IBMJava2-amd64-142/bin/java com.ibm.security.krb5.internal.tools.Klist -e -f -k -K /usr/sap/DEP/JC04/ktpass/j2ee-dep-jcdep.keytab" shows :

"Key table: /usr/sap/DEP/JC04/ktpass/j2ee-dep-jcdep.keytab

Number of entries: 1

[1] principal: host/jcdep.<domain>@<REALM>

KVNO: 4

Encryption type: DES CBC mode with MD5

Key: <key>"

The command "/opt/IBMJava2-amd64-142/bin/java com.ibm.security.krb5.internal.tools.Klist -f -e -a" as <sidadm> shows :

"Credentials cache: /home_sap/depadm/krb5cc_depadm

Default principal: host/jcdep.<domain>@<REALM>

Number of entries: 1

[1] Service principal: krbtgt/<REALM>@<REALM>

Valid starting: Wednesday, September 27, 2006 at 8:56:40 AM

Expires: Wednesday, September 27, 2006 at 6:56:40 PM

Encryption type: DES CBC mode with MD5

Flags: INITIAL;PRE-AUTHENT

Addresses, count: 1

uan105"

Interestingly enough, the "uan105" in the above Klist output is the physical hostname of the node where the portal is currently running. Could this be a problem as it differs from the virtual hostname "jcdep.<domain>"?

Anyway, with the abobe set, I get the following error in the DefaultTrace when I try to login :

"> #1.5#00300571ACAE006B0000000C000013D800041E8E73083174#1159497070802#com.sap.security.core.server.jaas.spnego.util.Configura

tionHelper#sap.com/irj#com.sap.security.core.server.jaas.spnego.util.ConfigurationHelper#Guest#1####91bccb204f6211dbb95400300

571acae#SAPEngine_Application_Thread[impl:3]_8##0#0#Error##Java###Error during credentials acquiring.

> [EXCEPTION]

> #1#org.ietf.jgss.GSSException, major code: 11, minor code: 0

> major string: General failure, unspecified at GSSAPI level

> minor string: Cannot get credential for principal service HTTP/jcdep.<domain>@<REALM>

> at com.ibm.security.jgss.i18n.I18NException.throwGSSException(I18NException.java:1)"

When I run the spnego config test, and enter "HTTP/jcdep... in the "J2EE User - Acquire Credentials" test, should it be successful ? At the moment, I only get success from this test if I use "host/jcdep...."

Thanks for your time,

Regards

Anthony

[yonko_yonchev]

Hi Anthony,

What is happening after this last test is that the keytab has an entry for a KPN <b>HOST</b>/jcdep.<domain>@<REALM. At the same time the SPNegoLM looks for a ticket for the KPN <b>HTTP</b>/jcdep<domain>@<REALM> (given the changed config for the parameter com.sap.spnego.jgss.name).

So what should fix this is the following:

1. registed both host/jcdep.<domain>@<REALM> and http/jcdep.<domain>@<REALM> as KPNs in the keytab. Once you do this, by running the klist command you should see entries for the host/jcdep.<domain>@<REALM> and http/jcdep.<domain>@<REALM> KPNs.

2. In the parameter com.sap.spnego.jgss.name you should have http/jcdep.<domain>@<REALM> for a KPN.

As for SPNs, register such (with setspn) only for alternative DNS aliases you'd use to access the portal. If you've registered http/jcdep.<domain>@<REALM> as a SPN, unregister it.

Regards,

Yonko

[former_member245181]

Hi All,

Thanks to Yonko and Christian for your time. After playing around and many tests, here's what had to be done in the end to get this to work :

- We are using the keytab generated for the KPN : HTTP/jcdep.<domain>@<REALM>

- Finally got a new version of diagtool that worked, then found that there was a mismatch between the KPN HTTP/jcdep.<domain>@<REALM> and the UPN for the j2ee-dep-jcdep service user which was specified as HTTP/jcdep.<domain>@<realm> (lowercase). The message in the diagtool output was "Input KPN is different from userPrincipalName."

The AD guys could not easily change this on their side as apparently the UPN is not case

sensitive. It turned out that this message doesn't really matter.

- The com.sap.spnego.jgss.name = HTTP/jcdep.<domain>@<REALM>

- With this set, I was still not able to authenticate until I put my pc userid into the local administrators group on my pc. After taking this issue to the desktop team, it seems that there is a registry entry that must be accessible for SPNego to work. The exact name of it I'm not 100% sure, but it's got the word 'Trace' in it's name.

So it's now working for us, but what a hair putting exercise it was!

Regards

Anthony

[Former Member]

Hello Anthony,

do you know what settings do you need in registry to get Kerberos work?

Thanks for respond

Karol