Operating System - HP-UX
1748089 Members
4849 Online
108758 Solutions
New Discussion юеВ

Re: Problem setting up LDAP-UX with AD - continued...

 
SOLVED
Go to solution
Jeffrey W Watts
Advisor

Re: Problem setting up LDAP-UX with AD - continued...

PAM Kerberos 1.26
Doug G Williams
Advisor

Re: Problem setting up LDAP-UX with AD - continued...

Finally had chance to get back to looking at it again. I found issue to be that we are migrating existing unix users to AD, and keeping the existing Unix login name, while our Windows login name is different also, thus Windows is sAMAccountName and Unix is uid. I need to find a way of mapping them since pam krb not doing it under the covers like pam ldap does.
Doug G Williams
Advisor

Re: Problem setting up LDAP-UX with AD - continued...

Well, at last an answer from HP support but not happy news since Option 1 is our only viable option. I include so perhaps others not toil needlessly:

Mr. Williams:
I received the official word from the lab. You were right from the start. The pam_ldap library will authenticate users with the "uid" but this is not a supported configuration when binding to a Microsoft ADS. My testing's worked with pam_ldap not pam_krb5, when the profile does not specify "objectGUID". The pam_ldap module is not supported because it does not support the password management over LDAP with ADS. Thus only pam_krb5 is the officially HP supported library when binding to an Active Directory server.

Here is the reference which discusses this support. It is also in the LDAP-UX Client 5.0 Release Notes as well:
http://bizsupport2.austin.hp.com/bc/docs/support/SupportManual/c02549991/c02549991.pdf
LDAP-UX Integration B.05.01 Release Notes, Pg. 26:
2.7.15 Supported features for particular directory servers
The following shows the supported features for particular directory servers:

Feature HP-UX Directory Microsoft ADS
-------------------------------------------------------------
...
pam_ldap Supported Not Supported[4]
...
4. pam_kerberos has been integrated with LDAP to fully support Windows domain
authentication and should be used instead of pam_ldap.


You have two options:
1. You can use the unsupported pam_ldap library to meet your users need of logging in to the LDAP-UX client with their uid.
2. Or, you can change your AD accounts with a script to have their uid match their sAMAccountName. This should not affect the existing uidNumber or gidNumber.

Unfortunately, changing the Kerberos Client code to authenticate with the user's uid won't fix this problem. It is the Windows KDC which is denying the Kerberos Client Windows logon request. This can be validated by trying to login to the Windows system with the uid while the sAMAccountName (Windows) is set different from the uid. Here you will see that you can not login to the Windows system with the uid because the KDC is denying the uid (typically for UNIX) login. Now this might be able to be changed with a Windows policy change but obviously this is out of scope for your contract and I am definitely no Windows expert. Also this potential policy change could affect how users login to the Windows systems