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."
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.
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.
/Anthony Whitehead
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.
http://www.nordicedge.se/
NordicEdge AB
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.
Charles Wyble System Engineer
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.
I figured this was as good time as any to point out our relatively complete Linux LDAP HOWTO, 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.
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.
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
There are many other sources of information on this out there.
Anthony Whitehead
NordicEdge AB
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.
Custom electronics and digital signage for your business: www.evcircuits.com
https://dpw.threerings.net/projects/splat/ (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.
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....
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 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).
Those who can't do, teach. Those who can't teach either, do tech support.
Haha
Active Directory, you mean recreate DCE (Distributed computing environment) using Kerberos for authentication and an x.500 derived directory for storing services and user groups and attributes?
Microsoft did nothing original with AD except to use LDAP instead of CDS (good move CDS sucks) and try to stuff service registration and discovery into DNS (yuck, LDAP would be much better for that). That said, DCE was way too complicated for most sites to set up, so it is good that MS brought it to the masses in the form of AD. But don't for a second think they invented any of it.
Finkployd
Huh? Surely Kerberos is more complex than plain LDAP authentication?
And a HELL of a lot less secure. You would be better off doing nothing than doing plain LDAP authentication.
And for large insitutions, Kerberos gives you a credential that can be used multiple places. NFS, AFS, websites (with SPEGNO goodness), may services such as SSH, IMAP, etc.
Unless this is for a 192.168 network in your basement, there is NEVER a good reason to do LDAP authenticaion. That is not what it was designed for, and certainly not something it is good at.
Finkployd
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!
Hey KID! Yeah you, get the fuck off my lawn!
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:
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.
<xml><I><am><so><damn>Web 2.0</damn></so></am></I></xml>
Yeah, no kidding. Total pain in the ass.
... 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 ...
... 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.
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
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