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

[grahamswilson]

...from http://forums13.itrc.hp.com/service/forums/questionanswer.do?admit=109447627+1265135929967+28353475&threadId=1382044.

Hi Jeffrey - thanks for the previous answer in your original thread (above).

This way I can give you points for your trouble! :)

I'm still getting to grips with this, but getting there slowly...

One question I do have for now - you mentioned that you don't have the Identity Management for UNIX snap-in installed as that isn't required. How do AD users, when logging in to your HP-UX servers, get UID, GID, shell, etc. etc. information? Don't those have to be defined within the properties of the AD user (which you need the snap-in to enter those details)?

Also, I was assuming the LDIF file was used independently to extend the AD schema - so that the extension could be done "outside" and separate to the HP-UX driven config utility...but it sounds like you're saying that that's NOT the case and the LDIF isn't used to extend the schema, and is just used on the HP-UX server...or did I misunderstand?

Cheers,
Graham.

[Steven E. Protter]

Shalom Graham,

I've been through this and shared your pain.

Only certain conditions will allow this process to succeed.

Windows Server 2003 must be Release 2, or include a number of patches or the procedure indicated in the HP-UX integration document will fail.

To answer your specific question, the /etc/nsswitch.conf file will include information pointing to the LDAP server.

This will, all other things being correct, provide ID information to users on the HP-UX system that are in the AD server.

SEP

[grahamswilson]

Thanks SEP - I know I'm all set on the AD side in terms of 2003R2 and the RFC2307 schema...

What I'm still (trying to) getting to grips with is what the LDAP-UX schema update is, whether it is actually even required!, and if so, does it/can it be done seperately with an LDIF file instead of through the configuration utility...

[Jeffrey W Watts · Accepted solution]

There are a couple of parts to Identity Management for Unix from what I've been told (I have never worked professionally on Windows). There's a snap in to Users and Computers that allows you to set the four attributes that are needed: gidNumber, loginShell, uidNumber, and unixHomeDirectory (I map gecos to displayName).

However I believe there's also Microsoft's NIS support, including an NIS server. I don't believe that it's possible to install the snap-in without getting the NIS support, and our admins don't want it on the domain controllers. I wouldn't blame them.

Anyhow, during the transition our AD admins used ADSI edit to do the field changes (since our pool of users isn't very big), and they created a webform that our Account Administrators can use going forward that populates the four fields on existing accounts. In our environment it's trivial to populate those four fields as we have everyone in the same base group, everyone has the same shell, their home directory is based on their domain and username, and their uidNumber is their PeopleSoft ID. Very easy to determine programmatically.

I don't know what kind of Windows environment you're in, and if your admins are cool with installing IMfU then it should be a bit easier for you - just make sure that the folks adding users don't screw up the data entry.

My larger point was that you don't need IMfU to actually provide the services - there's no "support" that's being provided, the only piece you're using is the GUI snap in.

As far as the LDIF goes, that's just the format of the file (LDAP dump, essentially). In the previous thread we were talking about two different files.

Originally, I was thinking I needed to extend the schema and I asked for an LDIF of the the schema changes so that my AD admin could extend it manually. Once I realized that I didn't need to extend the schema I had Monty@HP Support send me a working LDIF of the ldapux_profile.ldif. This profile contains the LDAP configuration, and serves the same function as /etc/ldap.conf on other servers where NSS_LDAP is used.

In a "normal" LDAP-UX deployment this file consists of the data downloaded by ldapuxclientd from the AD server (from the Profile object created by the schema extension) and compiled into the profile cache (ldapux_profile.bin). I short-circuited that behavior. Once I adapted it to my environment (which is trivial if you've done this before, and a little daunting if you're new) everything worked just great.

To summarize, this is how I believe the LDAP-UX client daemon works, by default:

1) Looks at ldapux_client.conf under the [profile] section to see where to find it's profile information and how to generate the profile cache once it's downloaded.
2) It downloads the profile information from the LDAP server and generates the profile cache (ldapux_profile.bin) using create_profile_cache by default.
3) It uses the profile cache and the authentication cache (pcred) and does its business.

In what we're doing, here's what's happening:
1) ldapuxclientd reads ldapux_client.conf and finds nothing under [profile], and as a result does nothing.
2) It uses the profile cache already present and the authentication cache (pcred) and does its business.

Essentially we cut out the middle step. HP was nice enough to make the requisite tool (create_profile_cache) standalone, and was nice enough to have that tool be able to read from a flat file, making this method trivial to execute.

I'd argue that for fairly consistent and static environments (and I'd argue that most environments are like that), it's much easier to do things this way as the configuration can be deployed non-interactively. It's very easy to script this deployment method. Here's a sample of how to deploy an updated profile (should your domain controller change, for example):

# scp -p updated_ldapux_profile.ldif server.example.com:/etc/opt/ldapux/ldapux_profile.ldif
# ssh root@server.example.com create_profile_cache
# ssh root@server.example.com "/sbin/init.d/ldapclientd.rc stop"
# ssh root@server.example.com "/sbin/init.d/ldapclientd.rc start"

That's it. If you change your auth add pcred to that as well. The nice thing about pcred is that if you use the same bind account on multiple servers you can use the same compiled pcred file as well. I seem to recall that "restart" didn't work right with the ldapclientd.rc script, but it could have been PEBCAK on my part - I just put both lines in the script early on and never bothered to figure out why it didn't work that once, so YMMV.

Overall I found the LDAP-UX product to be very nice to use, and found that it had great documentation, with the sole exception of the setup utility, which I found to be awkward and somewhat unnecessary (at least for our environment). I think that if the local profile method that I used is documented better and if certain things (like handling of spaces and unusual characters) within the setup program are handled better HP will have a truly excellent product.

Please take everything I say with a grain of salt. I had never done any in-depth work with Unix/Linux authentication, LDAP, or Kerberos before I started this project last July. I was tasked with migrating all authentication to AD and I Googled my way through mountains of outdated HOWTOs and misleading information. I do not have any in-depth knowledge of Windows or HP-UX - my expertise is in Linux, IRIX, and some Solaris. I feel I have a very good working knowledge of the technologies, but not a comprehensive understanding.

Coming from this background, I found that it took me a week to figure out how to get this done in Linux, and about a month to fine-tune (mostly because nscd is a piece of crap). By way of comparison, it took me about a month to figure out how to get this done in HP-UX (because of the setup utility and the schema extension), but only a week to fine-tune it. If the local profile option were documented better I think that LDAP-UX would be much easier to set up and deploy than the current solutions in Linux (though if SSSD ships with RHEL6 that might change).

Good luck, feel free to ping me with other questions. I have this thread set up to email me on responses.

[grahamswilson]

Hi Jeffrey,

thanks - I've got tied up with other things at the moment, but your answer certainly helps.

When I get this back to the top of the pile, you may see more questions!

Cheers,
Graham.

[Doug G Williams]

Thanks Jeffrey for the info. I had similar need and found this post. Everything works well following your steps except small twist of LDAP users not being able to su to root. I am pretty sure it is related to pam.conf (likely the su entries) but have not pinned down the fix. Is your pam.conf like the attached? Thanks for info and thanks again for providing solution to ldapux trick.

[Doug G Williams]

Fixed problem by changing to:
su auth sufficient libpam_unix.so.1 try_first_pass

Still a bit confused about when to use /etc/pam.conf krb modules (which will not work for me) rather than the ldap modules (which do work). Our linux admin uses krb modules and did not have to have keytab file, yet I can't get the hp-ux servers to authenticate with krb. I suspect ldapux absolutely requires the host added as AD user and keytab file generated?

[Doug G Williams]

Well, me again. :) My previous email of fix was completely useless. Turns out problem was actually the "su" in my path. Was using /usr/local/bin/su which causes problem. Using /usr/bin/su works correctly.

[Jeffrey W Watts]

Hey Doug, glad to hear that you figured that problem out. Funny how simple things like that can cause problems. :)

I'm assuming that you're connecting to AD, what specific problems are you having using Kerberos? One thing you must make sure you're doing if you're using Kerberos is to make sure you have the KRB5CLIENT package installed - the Kerberos shipping with HP-UX is very out of date.

I found Kerberos to be refreshingly easy to configure, and very reliable to use. If you have the Samba 'net' command installed you can also use it to generate a local keytab, though if you're using AD for DNS as well make sure it doesn't set a DNS expire time in AD.

[Doug G Williams]

Hi Jeffrey. Everything works great on the 4 servers I've configured so far, including 11.23 and 11.31. But I was curious whether in your /etc/pam.conf you use libpam_krb5.so.1? I use libpam_ldap.so.1 since it will not work with the libpam_krb5.so.1 library. A few years back I setup on Solaris servers and used krb5 library module in pam.conf to authenticate and was thinking this should setup the similar way. I can generate a kerberos ticket with kinit and authenticate from command line fine, but will not work authenticating via pam.conf when using krb5.so.1. I am guessing, probably wrongly, it may be the attributemap mappings in my ldapux_profile.ldif likely are not mapped correctly for krb5 attributes to rfc2307 attributes? But in any case, I'm perfectly fine using the ldap library module as everything works great, and deploying to the other servers now with same setup. Was just curious. Again, many thanks for your "pioneering"!! :)

[Jeffrey W Watts]

Doug, you're a bit on the wrong track. Kerberos is an authentication service. That is, it verifies that you are who you say you are. Basically, it simply verifies by a password that UserA is actually UserA. It doesn't know about anything else (uidNumber, gidNumber, gecos, etc). As such, RFC2307 and other types of user info don't have anything to do with it. So don't worry, your LDAP configuration won't break Kerberos. :)

On the same note, libpam_ldap.so doesn't know about that stuff either (nor do any PAM auth modules). They only check to see if the user exists or not (by querying the NSS libraries).

A good way to think about all of this is to break it into three pieces. There's user information, provided by the "passwd", "group", and "shadow" entries in /etc/nsswitch.conf. In our example here we're using LDAP-UX to get that information. NSS-LDAP is used everywhere else.

The next piece is authentication, handled by PAM (/etc/pam.conf). Folks can use Kerberos, LDAP, local Unix, etc, individually or in combination.

The last piece is authorization, handled also by PAM. A method I've used for using LDAP group-based authorization on HP-UX is to use the pam_authz module that comes with LDAP-UX, it's very similar to the pam_access module on other systems, and is very flexible.

I would point out that you should use some kind of access restriction for your LDAP users, as otherwise EVERY LDAP user with unix attributes will be visible to your Unix systems and thus able to log in.

Finally, in regards to your problem with libpam_krb5.so, have you applied the latest PAM_KRB5 patch? I had problems with the older versions as well.

[Doug G Williams]

Thanks Jeffrey for the info. After I had noodled a bit about those attributes mapping I pretty much reached the conclusion that they are not the reason for not being able to use krb5 library authentication. I keep coming back to needing the keytab file on the client and having the client joined to AD. I tried generating the keytab using samba net as well as mksutil, but unfortunately I do not have rights to access the AD server, and so fail. I found that our Linux admin uses winbind, but of course, he also is an AD admin, so he has the muscle to get his stuff working. :) I have made a request/ticket for them to add a hp-ux client into AD and generate a keytab for me so I can test. I will let you know how it goes. I installed the latest pam kerberos, krb5client, ldapux packages on all our servers so that probablly not the issue. Thanks again.

[Jeffrey W Watts]

Doug, the keytab is not required for users to authenticate. You're having some other issue. The keytab is essentially a stored key that can be used to authenticate a given credential non-interactively. The keytab generated by 'net' would have keys in it for the computer account that 'net' would have created in AD.

Can you do a 'kinit ' successfully? Does a subsequent 'klist' show your keys?

Kerberos is very simple to configure and works very reliably. If you're having trouble with it I'd imagine it's because of one of three reasons:

1) You have your /etc/krb5.conf misconfigured. Please post it here (sans private info) so we can look at it.
2) There's a firewall in between, or you're using DNS to find KDCs and DNS is serving up SRV records to unreachable KDCs. (I've run into this one before).
3) You don't have the requisite patches installed. Please give a list of the patches on those servers matching the strings "PAM" and "Kerb".

As far as Winbind goes, in general it's an inferior solution. It's "easier", but has other, more subtle issues that generally make it unsuitable for enterprise use. That's a discussion for another time, though.

[Doug G Williams]

Jeffrey, yes, I can do kinit:
# kinit doug
doug@EXAMPLE.COM's Password:
# klist
Credentials cache: FILE:/tmp/krb5cc_0
Principal: doug@EXAMPLE.COM

Issued Expires Principal
Aug 13 03:10:35 Aug 13 03:20:35 krbtgt/EXAMPLE.COM@EXAMPLE.COM

I am confused in why ldap authenticates to AD but not kerberos? Seems like if it can find the correct user/password for one method, it would for the other? I have attached relevant file contents. Many thanks!

[Jeffrey W Watts]

Hey Doug, thanks for the info.

Since Kerberos clearly works, your problem is most likely somewhere in your /etc/pam.conf. Can you provide that, along with any relevant output in the logs?

By the way, you have your krb5.conf configured for DES only. That may cause you problems with newer versions of Windows and Kerberos, as it seems that everyone is moving away from it as a technology. I recommend you use the following line in your /etc/krb5.conf instead for your encoding types:
rc4-hmac des-cbc-md5 DES-CBC-CRC

Finally, telnet sucks. I'd recommend using SSH instead. Make sure usePAM is on in /etc/ssh/sshd_config. :)

[Doug G Williams]

Hi Jeffrey. Attached pam.krb5. When testing, I just copy pam.krb5 to pam.conf, then touch pam.conf (just in case). Thanks for recommendations.

[Doug G Williams]

Ah, I think I may see the problem (forcing me to actually look :) ) the sufficent/required needs to be switched between krb5 and unix

[Doug G Williams]

Nope, that was not it :(

[Jeffrey W Watts]

I think I may have figured it out. You're using telnet to test this, but you don't have a PAM stack for telnet specifically, it's just using OTHER.

OTHER doesn't have anything else defined except libpam_unix.so.1, so Kerberos won't ever be checked. (don't change this by the way)

My #1 recommendation would be to stop using telnet and to add the libpam_krb5.so.1 line to the sshd blocks (that should be in there anyway). If you must use telnet, add a "telnet" stack (just cut and paste the "ftp" lines) in the appropriate places.

Good luck.

[Doug G Williams]

:( Still no joy. Tried with ssh, telnet, ftp, dtlogin... What version of Pam Kerberos are you using?

[Jeffrey W Watts]

PAM Kerberos 1.26

[Doug G Williams]

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]

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