Single Sign On with Kerberos breaks JNDI Adapter to AD

[AndyMiner]

We have Windchill/PDMLink 9.1 M040 installed on solaris 10. We have set up basic auth against the corporate ldap (MS Active Directory) and we have an Info Engine adapter setup to map users and groups in AD. This all works well.

We recently setup single sign on using kerberos and this works well for authentication. However, the adapter grabs the REMOTE_USER value which is now set to <userid>@<userdomain> instead of <userid> for kerberos. This value does not map to any attribute in our AD and, therefore, the adapter reject it and doesn't allow any userId in. It appears that if I could remove the @<userdomain> portion of the REMOTE_USER variable after authentication then the adapter would work as expected.

Is there a way to remove the @<userdomain> portion after Apache authenticates but before the adapter grabs it to use it?

Thanks in advance for any help.

[pwilliams-3]

Andy,
Yes you can do this, in fact, PTC documented how to do this. I forget
which guide it's in. It's either the Advanced Install Guide or the
Advanced Deployment Guide.

Patrick Williams
Sr. Systems Engineer II
Mechanical Engineering Solutions
Missile Systems
Raytheon Company

+1 520.545.6995 (business)
+1 520.545.6399 (fax)
-

TU/M12/8
6221 S Palo Verde Rd
Tucson, AZ 85706 USA
www.raytheon.com



This message contains information that may be confidential and privileged.
Unless you are the addressee (or authorized to receive mail for the
addressee), you should not use, copy or disclose to anyone this message or
any information contained in this message. If you have received this
message in error, please so advise the sender by reply e-mail and delete
this message. Thank you for your cooperation.

[rwelch]

Andy,

There was a new switch added to mod_auth_kerb that addresses this
issue. If you are running version 5.4 or above, you can
add

KrbLocalUserMapping on

to your Apache configuration file (conf/extra/app-Windchill-Auth probably) to
strip the "@realm_name" off of the value of REMOTE_USER.

It works for us....we just figured it out this morning, actually.

Ron