To use LDAP or not?

[WSS]

Hi everyone,

I have a set up of 4 Unix servers, all running HP-UX 11i and I am toying with the idea of using LDAP to allow the users to change their passwords once/create accounts once, and be populated and accessed by all 4 servers. Thefore only one change needed on one server, but to take effect on all 4 servers.

As I don't know much about LDAP, can I get some advice on whether this is a good a valid option for 4 servers.

We looked into NIS initially, but we are converting to a Trusted System, and you can't use NIS within a Trusted System.

So the other option is perhaps LDAP, or is there anything else out there that can do the job? Or with only 4 servers, is copying the /etc/passwd file etc to the other servers after making a change the best option?

Thanks in advance...
Trev

[A. Clay Stephenson]

Your other option is NIS+ which is secure and works with Trusted systems but is of limited lifetime. LDAP is your better choice. The major "gotcha" is that while most UNIX applications will work with NIS(+), some applications (especially legacy applications) may not work under LDAP. Note that simply copying /etc/passwd entries among your 4 servers is not sufficint; you must also copy the /tcb/files/auth entries because that is where the password hashes are actually stored. You can use rdist, for example, to move the /tcb entries from your "master" server to the other but this approach is really Mickey Mouse compared to
LDAP or NIS+. You should learn to use LDAP as you are going to see more and more of it as time goes on but make sure that your existing applications get along and play well with LDAP.

[WSS]

Why does the other Apps need to get on and play well with LDAP? All I want to do is have one point of reference when changing a password or creating an account.. Wouldn't this just affect a number of hpux files?

[Jeff Schussele]

Hi Trev,

IF you're going trusted then my advice would be to flat out forget about LDAP.
We literally tried for months to make it work, but due to the way the PAM stack needs to be ordered, you'll never get it to work in a fashion that would satisfy a SOX audit - PERIOD.
And when SSH gets into the mix....well it only brings in other shortcomings.
HP *needs* to seriously deal with this.
Until then LDAP is *only* OK for non-trusted systems.
Fix your PAM stack HP!!!

Rgds,
Jeff Sorry to vent - but I'm tired of trying to make that mess work

[Darrel Louis]

Hi Trev,

If you just want to have the same passwd on all 4 servers, just copying the /etc/passwd and /tcb/files/auth* to the other three servers would be sufficient.

Create a script to sync all.

We've LDAP running with more than 200 client-servers, all is running well.
But the LDAP-server is running on a Sun Solaris-10 server. Untill now we don't have any problems.


Darrel

[Jeff Schussele]

I should expand on that...
Trusted in and of itself will pass SOX audits.
What happens when you throw LDAP into it is that IF you have SSH kys in play one will get in EVEN if you're LDAP PW is expired.
Also we found that if your PW expired you don't get the opportunity to reset it you're just denied - I could go into further detail but I just don't have the energy.
Just take my word for it - LDAP/trusted/SSH just don't play well together.

Rgds,
Jeff

[A. Clay Stephenson]

Why does the other Apps need to get on and play well with LDAP? All I want to do is have one point of reference when changing a password or creating an account.. Wouldn't this just affect a number of hpux files?

In an ideal world, yes -- but many, many applications use the funcions getpwnam(), getpwuid(),getgrgid(),getgrnam(), and all their cousins. Now these functions should be smart enough to look at /etc/passwd and /etc/group if using traditional UNIX security and to supplement with NIS(+) entries if those are in use -- and to read the /tcb entries if Trusted --- and should also consult LDAP tables for the equivalent values --- all invisibly to your application. However (and especially with a very unUNIX concept like LDAP) many implementations of these function don't behave properly (possibly because when your code was linked, LDAP was not even a gleam in its Daddy's eye). So the only way to know is to test.

Now I haven't had all the horror stories related above with LDAP but I had a very long time in a Sandbox to get all of this working and it did involve custom libPAM functions but LDAP is not for the feint of heart.

[Jeff Schussele]

Well Clay, if you've been able to overcome my "horror stories" I could sure use a knowledge injection. I'm sure you see the nature of the problems we're having.
We're under tremendous pressure to strictly comply to SOX standards & we can't get past the SSH-key/LDAP free-bie problem. Couple that with the damn Sun-One's LDAP server's knack of setting expired PWs to epoch past expiration such that you can't normally reset (you can do it w/LDAP commands) it is just killing (well essentially killed) our project.
What type LDAP server are you using & have you beat these demons?
And if a layman such as me could see what PAM miracles you've spawned - well I'd be eternally grateful.

Best Rgds,
Jeff

[WSS]

"Note that simply copying /etc/passwd entries among your 4 servers is not sufficint; you must also copy the /tcb/files/auth entries because that is where the password hashes are actually stored."

Clay, notice I put "etc" in my original post, I realise that there is more than just the /etc/passwd file that needs to be copied over to sync everything up :-)

Hmm, LDAP is sounding like more of a headache than needed for just syncing up 4 boxes.

Can anyone tell me what sort of lifespan NIS+ has? Someone mentioned it has a "limited lifetime".....

[Michael Kalisz]

Why not use just use shadow password support.
(to secure against password cracking)

and have a cronjobb to securely copy /etc/passwd and /etc/shadow between the machines.

Just my 2 cents,

Michael

[Steven Protter]

Shalom,

I think LDAP is a good choice.

Its possible to do single sign on so that a Windows user id is good on Unix and vice versa.

I think trusted system is a must, though the only two I work with right now are in my apartment due to our current reliance on NIS. Windows 2003 Server has a tool that permits integration with NIS if you have a legacy NIS environment.

LDAP is a bit complex for a 4 server environment unless you want to do Windows Integration. I worked with NIS+ once, in the HP Education center. Everything worked out, but the administration seemed somewhat onerous to me.

There is of course the mickey mouse option, which involves copying /etc/passwd and other configuration files around. I've been forced to do that at one location. I don't like it, but it does work.

SEP

[Chan 007]

Mark "0" for this..:-(

Steven, I can't beleive that you lost you green ring...where you so hungry and ate those greens to be POPEYE ....:-)

Chan

[Don Mallory]

Wow, this is quite the conversation, and one I have may have a few insights into.

We've just migrated our first few systems from a home-grown system that transfers around the /etc/passwd, /etc/group, /etc/auto.direct and /etc/auto.home files. Yes, don't forget to copy your group as well as passwd, shadow, etc. files if you go that way.. to LDAP / Kerberos to a Windows Active Directory.

So.. where to start.

Why not to copy around the files. If your /etc/passwd or shadow files get corrupted, and / is full, you no longer can log in. Shut down, go to single user mode and hope you aren't using the boot authenticator

The biggest problem is latency and determining if your files have been copied securely to the other system, then determining if it's safe to copy them in place.

Next problem. Do you want different root passwords per server? And, are ALL your users allowed to log into ALL the servers? if you are using /etc/passwd copied between, they are all the same. If not, you need to blank out the password or user somehow, or add pam_authz into the mix and mess around with netgroups or other strangeness.

ssh / pam / ldap, etc. question (Jeff.. this is for you).. Use Kerberos. Yup, I really said that. You enable GSSAPIAuthentication in your ssh_config and a few other settings. (I can dig them up if you like). and whamo-bammo, your authentication, even with authorized_keys files comes against the KDC. In my case, the Active Directory, which is also where all of the LDAP data resides. It's pretty slick when you get it working.

The problems with Windows AD and LDAP are pretty simple:

- You need Kerberos to authenticate. LDAP provides info, not authentication.

- You need LDAP to list the user and group data on the host.
- you can also host rpc, services, hosts data, but not automount maps, netgroups or printers.

- Seriously think about SSL. Otherwise, lots of data is clear text.

- If you use SSL, you will need a Certificate Authority installed on your Domain Controller & Global Catalog & AD (makes it LDAP), which is also your KDC (all DC's are a KDC).

- Do NOT put your KDC on the same server as your DNS server. Leaves you open to strange slowness in a failover state. - best option is system 1 is your primary KDC/LDAP/CA & secondary DNS, system 2 is your secondary KDC/LDAP/CA & primary DNS.

- the PreferredServerList is a direct failover list, not a load balanced one. The DefaultServerList is exactly the same. Don't bother with it.

- DES is your ONLY option for passwords in the AD. On the other hand, since you are authenticating with Kerberos against the AD, you can use 127 character passphrases with the who gambit of account policies from the AD group policy.

- You will need either Windows 2003 RC2 installed on your AD server (includes NIS services, RFC2307 compliant POSIX entries, User Name Mapping), or you will need Services for UNIX for Windows version 3.5 installed (which includes the same thing.) As of today, it's harder to find it on Microsoft's web site, but it's still free. You don't need the services turned on, however you DO need the RFC2307 compliant Active Directory Schema extensions to put your LDAP POSIX account data in the AD. It also adds a neat little tab called "UNIX Attributes" to the user, group and host entries.

- Use the MemberOf tab in windows for group membership and then re-map the group memberuid attribute to member, instead of msSFU30PosixMember (otherwise, it tries to use full display names instead of usernames as your group membership..)

- You will need a Proxy User in the AD. You can't ever change the password.

- LDAP provides user and group info. Kerberos provides authentication (who you are). If you are in the AD, and authenticated, you can log into any host..

- pam_authz provides Authorization, that you are allowed. Use the /etc/opt/ldapux/pam_authz.policy file to set up a group with authorized users. This group can be local or in the AD, remember, if you add this, this is for ALL users on the system, including root, so include a local group that is also allowed with root as a member.

- Automounter files will need to be manually updated. I wrote script that parses the output of a "showmount -e $filesever" and builds my automounter maps for me. Enhanced AutoFS is useful for this.

- Still need ShadowPasswords app if you aren't using trusted mode. Easy to add.

List of packages.. (all post QPK Sept 2005):

ENHAUTOFS B.11.11.03 Enhanced AutoFS for better performance and functionality
J4269AA B.04.00.02 LDAP-UX Integration
J5849AA B.11.11.13 PAM-Kerberos and Kerberos Support
KRB5CLIENT C.1.3.5.03 Kerberos V5 Client Version 1.3.5.03
PHCO_28605 1.0 libnss_files cumulative patch
PHCO_30913 1.0 libsec cumulative patch
PHCO_31923 1.0 libc cumulative header file patch
PHCO_33205 1.0 mountall, Dev IDs enabler, iSCSI support
PHCO_33711 1.0 libc cumulative patch
PHKL_33258 1.0 VxFS cumulative patch ;ml_flag race
PHNE_29445 1.0 libnss_dns DNS backend patch
PHSS_33384 1.0 KRB5-Client Version 1.0 cumulative patch
PHCO_28830 1.0 Security man page cumulative.
PHSS_33325 1.0 CDE Base Periodic Patch
ShadowPassword B.11.11.03 HP-UX 11.11 Shadow Password Bundle

Kerberos Doc reference:

A Basic Step-by-Step Summary of Kerberos v.51 Setup on HPUX DocId: PAMKKBAN00000983 Updated: 20050127

This is a wonderful document. The author, Don Isler is a genius and has been of no ending help.

Good luck,
Don