LDAP Authentication in Linux

hausmasta writes "HowtoForge has published a walkthrough to show you how to store your users in LDAP and authenticate some of the services against it. It will not show how to install particular packages, as it is distribution/system dependent, instead it will focus on pure configuration of all components needed to have LDAP authentication/storage of users. The howto assumes that you are migrating from a regular passwd/shadow authentication, but it is also suitable for people who do it from scratch."

Re:Why would one want to do this?

[Anonymous Coward]

You might have more than one machine to string together, and/or a very large number of users, and/or primary account administration happens somewhere else (like Active Directory, let's say) and account enablement/disablement, password resets, etc., should carry over across both environments.

Put together pam_ldap and pam_krb5 and you can do a lot of nifty stuff. You probably wouldn't care about hardly any of it for a standalone computer, but for a true multiuser system in a multisystem environment... almost anything else is scandalously silly.

Re:Why would one want to do this?

[antlope]

For the same reasons as one would use NIS in the past, to allow central control and a single point of administration for your users.
With some decent admin tools you can even share your users between variants of Unix and Windows environments.
There are some advantages of LDAP over NIS which are worth mentioning. LDAP can be made more secure than NIS (NIS+ is better in this respect, but oh so much more of a pain to administer) through the use of SSL or better authentication methods. LDAP will usually scale better for many thousands of users than plain NIS. NIS is limited as to what data may be stored for a user, which is ok if all you want your user database for is authentication and basic authorization, but LDAP is much more flexible if you need to store other user information and would rather have a single user store.
There are some sites that even use Unix LDAP clients to authenticate to an Active Directory service running on windows platforms. This can be done much more transparantly with LDAP than many other authentication methods.

/Anthony Whitehead
http://www.nordicedge.se/ [nordicedge.se]
NordicEdge AB

Re:Why would one want to do this?

[charlesnw]

Well not all of us live in our parents basement and have less then 10 systems. Some of use work in enterprise environments with 1000+ servers and would like a central way to manage logins/passwords/auditing. Especially for things like PCI compliance that require it. And no I don't mean PCI as in the system bus interface. I mean payment card industry.

Other options

[digitalhermit]

OpenLDAP is great and does a good job. You may also want to look at Fedora Directory Server, which is based on a previously commercial product. Both are ridiculously easy to configure for basic authentication. Another option for OpenLDAP is to grab the VMWare OpenLDAP appliance. It's an easy way to get LDAP working.

For administration, check out JXplorer. It makes it easy to add/delete/modify users.

Our wiki Linux LDAP Howto

[Anonymous Coward]

I figured this was as good time as any to point out our relatively complete Linux LDAP HOWTO [freaks-unidos.net], which covers quite a few LDAP servers (MS AD, Novell eDir, OpenLDAP) and the security implications of different setups (eg. using PAM_LDAP vs just using NSS_LDAP). The article lives in a wiki so any improvements are welcome. :-)

I hope you find it useful.

Re:Why would one want to do this?

[ximenes]

It is possible to distribute those kinds of maps over LDAP as well, if you have control over adding data to your LDAP server.

You can also keep NIS around just for those maps.

Re:Why would one want to do this?

[antlope]

Most of the common maps, including the auto-mount maps have schema and attributes in LDAP. So its just a simple matter of using a migration tool (or doing it by hand) to build your LDAP version of the auto-mount map.

A quick google and here is a link you might like to look at:

http://www.linuxjournal.com/article/6266 [linuxjournal.com]
There are many other sources of information on this out there.

Anthony Whitehead
NordicEdge AB

Re:I always wondered...

[guruevi]

It is otherwise widely used hidden under proprietary MS code: Active Directory is a pure Kerberos + LDAPv3 implementation except that for synching and logging in (the essential outside communications that other platforms would like to use) is proprietary and they changed some things to the standard scheme too (SID etc.) which makes it useless for anybody but MS.

OpenDirectory by Apple is also an LDAPv3 implementation be it more pure than MS's implementation. You can combine both AD and OD on Mac to get a unified Windows-compatible login capabilities in the network that also get the benefits of using OD (force preferences and security settings on users/computers) without schema changes on either side.

RedHat also relies on LDAP for network-wide authentication in their products as does IBM and recently even Novell and lots of companies use it for different purposes in one or another way.

Re:Other options

[hethopus]

Best one I've used is Luma -- http://luma.sourceforge.net/ [sourceforge.net]

SPLAT - Scalable Periodic LDAP Attribute Transmogr

[lizthegrey]

https://dpw.threerings.net/projects/splat/ [threerings.net] (written by the wonderful people I work with and BSD-licensed) hooks into LDAP, allowing for the storage of public keys for SSH access and other niftiness. We use it for managing passwordless SSH-key based access to the two dozen or so servers here with great success.

Host-based control

[sparr0w]

The author failed to point out one of (IMHO) the neatest parts of doing PAM/NSS/LDAP authentication against your server: controlling by host. The LDAP authentication set includes the ability to dictate (using the "host" attribute) which users are allowed on which servers. From an enterprise POV, that helps limit the systems users have access to (controlling which servers your UNIX gurus have access to). You can also tie LDAP into Samba, and using some scripts emulate an active directory. We've been playing with this whole idea for awhile now where I work, to essentially create a mixed environment where Linux/UNIX and Windows can play (somewhat) nicely together. Hopefully this article will bring some more people on board with LDAP authentication for servers....

Re:I always wondered...

[spauldo]

recently even Novell and lots of companies use it for different purposes in one or another way

Novell's been using it longer than pretty much anyone. Check out NDS [wikipedia.org] for more info. Microsoft was more or less copying Novell, not any of the UNIX vendors (who were mostly still using NIS and friends when active directory came out).

Comment removed

[account_deleted]

Comment removed based on user account deletion

Comment removed

[account_deleted]

Comment removed based on user account deletion

As was already mentioned.....

[FlyingGuy]

Just use Novell Directory Services, or EDirectory as it is now named.

Nope it aint free, nope it aint open source. But it DOES rock the house!

Scales to over a billion objects. Easy administration and setup.

Runs on practicaly everything Form Linux, Unix, Solaris, Windows, Copiers, Printers to Toasters and Web Servers.

Why yes I am a Novell Fan Boy. Whats your fucking point!

Re:Reliability

[19thNervousBreakdown]

I'd change it back, or if you're not using NIS, give just "passwd: files ldap" a shot, both files and compat are redundant at best. Whichever PAM file you have there is odd, auth should fail if a "required" module doesn't succeed. Here's mine:

auth required pam_env.so
auth sufficient pam_unix.so likeauth nullok
auth sufficient pam_ldap.so use_first_pass
auth required pam_deny.so

account sufficient pam_unix.so
account sufficient pam_ldap.so
account required pam_deny.so

password required pam_cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2 retry=3
password sufficient pam_unix.so nullok md5 shadow use_authtok
password sufficient pam_ldap.so use_authtok
password required pam_deny.so

session required pam_limits.so
session required pam_unix.so
session required pam_mkhomedir.so skel=/etc/skel umask=0077
session optional pam_ldap.so

Basically, make sure that pam_unix is before pam_ldap, that they are both "sufficient", and put a required pam_deny.so at the end, and your passwd should override any ldap. Also make sure to check both /etc/pam.d/* and /etc/pam.conf. pam.d should override pam.conf, but it doesn't hurt to check. The pam.d dir will probably have different files for different services, so make sure to check ssh if you're having a problem with that, login if it's with console logins, and so on. They might include other files, but whoever edited them might have changed stuff. HTH.

Re:LDAP is a pain in the arse

[unsigned integer]

Yeah, no kidding. Total pain in the ass.

I tried to take a NIS domain, mixed linux/solaris clients and convert into a single LDAP auth'ing environment, plus LDAP auth for our webservers ... thus giving me finally a SSO environment where I didn't have to maintain numerous passwd files, etc. I went from knowing nothing about LDAP, to at least being able to set it all up. Even with the PADL tools things took a while. Setting up all the SSL certs ... self-signing etc. Incorrect examples and docs from people online. Yeah, then try to make Solaris play well with OpenLDAP ... all sorts of little hacks involved in that. Then enjoy the fun of getting Apache up and running and properly using LDAP. Lots of little things that can go wrong there, unless you follow things to a T. It was like two steps forward, 1 step back all the friggen time. Would have been probably 10x easier had I just been a pure linux shop ...

I must say, despite all the pain, it was absolutely beautiful when it was working. I even managed to get all the auto mount maps working as well ... the only thing I didn't get a chance (before I left) was to get our NetApp using LDAP. Another thing that "should have just worked" but didn't. Much like everything else along the road of LDAP.