KPN different from UserPrincipalName (SPNego confguration)

[MarcelRabe]

Hi,

i had SPNego working on a webas, but after a upgrade from 6.0 to 7.0 and after the network administrators changed the FQDN from <i>host.domain.local</i> to <i>host.subdomain.domain.country</i> it stopped working.

I've tried almost everything but still no succes. The DIAGTool reports an interesting error that should help me but it doesn't seem to make any since. See below:

User = CN=j2ee-lp1-host,CN=Users. Input KPN is different from userPrincipalName.

Input KPN = host/host.suddomain.domain.country@<b>DOMAIN.LOCAL</b>

userPrincipalName = host/host.suddomain.domain.country@<b>Domain.Local</b>

The userPrincipalName is not recorded in UpperCase in the KDC (in our case windows 2003 ADS) but with only 1 capital for domain and one for local. This was already the case before but now it seems to be a problem.

Did this change between NW04 and NW2004s?

Kind regards

Marcel

[yonko_yonchev]

Hi Marcel,

AFAIK, the Kerberos domain always had to be entered in upper case, regardless of how it was stored in the ADS. If you haven't already done this change the domain name in to capital letters where relevant.

On a side note, take a look at SAP Notes 968191 and 994791. The latter note contains information about wizard based configuration for using Kerberos with SPNego, though in your case it might be more reasonable to update the case of the domain name where relevant.

Hope this helps you out.

Regards,

Yonko

[MarcelRabe]

Hi Yonko

I changed the userPrincipalName attribute to contain capitals and this at least got rid of the error, but it still didn't solve my problem.

When I run the Diagtool I get a lot of information but it all comes done to the same thing: Pre-Authentication failed (24). This is most commonly caused by using a wrong password, but the question is <i>what password?</i>. Since the only place where I enter passwords is during the creation of the keyTab, is this the password in question? I'm 100% sure it's the correct one.

However, I've also used the 'old' SPNegoConfig tool which returnd the following interesting information:

<i>Searching for user with krb5principalname = [host/hostname.sub.domain.country@DOMAIN.LOCAL] ...

The user could not be found by this name. Please check the configuration of UME and the service autehtication context com.sun.security.jgss.accept configuration.</i>

But when I remove the @DOMAIN.LOCAL part it finds the service user.....

<i>Searching for user with krb5principalname = [host/hostname.sub.domain.country] ...

User j2ee-sid-hostname found.</i>

So it seems to me that the KPN prefix configuration doesn't work correctly, right?

I've tried the SPNegoWizard without success....Actually it gives me the exact same error.

Marcel

BTW I awarded 6 points

[yonko_yonchev]

Hi Marcel,

it seems to me that the user resolution is not working ok.

Double check if all is ok with the attribute mapping in the UME data source configuration file. Also, see if the KPN is enterred correctly in the Krb5LoginModule of the com.sun.security.jgss.accept policy configuration.

Thanks for the points - hope it's fixed this time around.

Regards,

Yonko

[MarcelRabe]

Hi Yonko,

when setting the KPN to host/host.domain.com@DOMAIN.COM does the first part after host (/host.domain.com) really has to be the FQDN of the J2EE server or can it be anything as long as it matches the userprincipalname on the ADS?

Since the FQDN changed the SSO stopped working, and this caused more than one problem.

Marcel

[Former Member]

Hello Marcel,

When changing the FQDN of the AS Java host you have to take care of:

- the FQDN must match one of the service user SPNs

- the service user credentials muste be exported (via keytab file) onto the AS Java filesystem

So you have to:

- change (add) the SPN in order to match the FQDN of the AS Java

- export the credentials to keytab and replace the keytab in AS Java

Kind regards,

Tsvetomir

[yonko_yonchev]

Hi Marcel,

AFAIK it has to be the FQDN. In this line of thought, did you update the keytab on the ADS and also the one made available to the J2EE engine with the new FQDN?

If you didn't, this could be the reason why SSO is not working. Obviously the error happens when the Kerberos implementation of the JDK (in the com.sun.security.jgss.accept policy configuration) is called to determine the user id from the session token retrieved by the SPNegoLoginModule.

I'd suggest you open a support ticket if this still doesn't help.

Regards,

Yonko

[MarcelRabe]

Hi guys

thanks. Points awarded. As suspected the KPN prefix mechanism was not configured entirely correct. But since this was already working I made sure that I changed the KPN to the real FQDN and added the SPN's for the aliasses (which are also FQDN, sort of). This did the trick, so I'll keep that in mind.

PS I had already made a seperate keytab on the J2EE host, but recreated it after the FDQN change.

Cheers

Marcel