LDAP Authentication in Linux 189
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? (Score:3, Interesting)
You can also have all your software that is LDAP aware authenticating against the same username/password (assuming they don't already support the stuff like PAM or the like).
If you really want to, you can also setup samba to use it and you can have XP machines join the domain, get the users in the domain all that fun stuff. (Was going to do this in a small lab I help at, ended up not because I realized it wasn't necessary for anything we did down there).
Ldap on its own is not enough (Score:3, Interesting)
Using ldap itself is really not much better than using NIS, aside from the fact that it can contain much more than just the user database.
Re:Password only (Score:4, Interesting)
I always wondered... (Score:5, Interesting)
Its relatively eay to setup and quite stable. This in combination with PAM should be the once and for all way of authentication.
If you have a directory like this you can add virtually everything to it, be it intranet pages, mailserver authentication, hell even an inhouse Jabber client for employees. This should be unified and used much more often.
The management is a blast with the ability to choose whatever LDAP-Frontend you might wanna use and worstcase you can go back to browserbased or console. Its really flexible, elegant and in a Unix style a tool for the job.
Who can enlighten me why this is still rather a niche? are Unixadmins simply too used to the passwd/shadow style auth?
Oh yeah: In case you are going to set it up stay the hell away from BerkeleyDB 4.3.
It can have some nasty surprises.
LDAP for everything (Score:5, Interesting)
Windows Desktops (Samba PDC and BDC -> LDAP)
Linux pam_ldap + nss -> LDAP and NFS shares
You can log into either a windows desktop or linux box and have the same file shares open. Windows has H: and Linux is
Then for email, postfix + dovecot -> ldap. You can store not only use the same username password as for linux, but you can add unlimited number of real-time mail aliases to each user. Also supports virtual domains.
Directory services for phone numbers, room locations, etc. in ldap. Mapped to email clients search/contact lists.
squid + ldap and apache + ldap, secure login to website.
Squirrelmail/horde both use ldap as well. Auth is done via imap, but horde can do much more with ldap. Both can use it for directory services.
Admin can be done either via CLI smbldap-tools, php ldap admin, gq (ldap tree browser), or ldapmodify if you're hard core. Plus with sync'ing data to other sites they have a copy of the data for their BDC/etc. If I need to add/modify a user there is only one place that needs to be modified. And I can do it from home. =)
Re:I always wondered... (Score:2, Interesting)
Sad, but often true.
NordicEdge AB
Re:Why would one want to do this? (Score:1, Interesting)
Nested groups (Score:3, Interesting)
Re:Why would one want to do this? (Score:4, Interesting)
you are right on... when it comes to compliance and SOX requirements, getting all of your machines authenticating against one directory (AD or otherwise) makes perfect sense. I am sure there are a few sys admins here who have been asked for login failure and share access permissions across all of their network machines. adding more 'directories' makes it even more fun to gather these reports, comb through logs, look for changes across all the flavors of *nix and then the msft event logs, even network syslog...
There are a few companies out there who have built product lines that allow unix machines to authenticate against AD, their machine accounts can have Windows Group Polices and managed under one single console, they have the ability to appear in SMS as any other machine for reporting and hardware inventory and also to send their performance metrics over to MSFT MOM...
Why in the HELL would anyone want to authenticate against AD? well, it is simple really.. MSFT DID do the LDAP/Kerberos thing right and have been doing it right for a long time. They also have the whole pass-through, single id thing going and it works just fine in AD (when its an all windows network)... and its EVERYWHERE... how many LARGE companies are using whitepages/ldap type directories for authentication and how many are using AD? its a valid question to ask and what is happening is that most ARE already on AD or are moving to AD and they ARE using Exchange and this put AD into a space of being one of the main components of an enterprise. So why not just toss the unix machines in there as well?
yes, it empowers windows AD... but the first solution below (from quest) does not take anything out of the unix guys bag of tricks... in fact it allows for the unix guy to actually do things against AD that before was a pain to setup/admin...
anyway... sunday, should be out walking the dog and playing frisbee with the kids or working on my short game... check out http://www.quest.com/landing/?ID=531 [quest.com] or http://www.centrify.com/ [centrify.com] for some good info on two companies that are doing this for the *nix world now...
Re:I always wondered... (Score:3, Interesting)
One of our former (and rather forward-looking) sysadmins moved our servers over to a centralized Kerberos+LDAP (via PAM) authentication and authorization system. He left for greener pastures; and since then I've seen a series of (mostly pretty young) sysadmins that just have this innate dislike for any sort of centralized management. It usually starts with complaints about OpenLDAP; but pretty soon you realize it's not the app, since they view any replacements with equal disdain - it's the whole concept that they don't like.
I see the same sort of thing when it comes to centralized server maintenance/management systems. A lot of guys seem to prefer to just configure and run each server totally independently, even though it takes a rediculous chunk of time compared to a distributed management system. It's obviously inefficient, and the end result often is out of date kernels and/or other packages. So why this fascination with trying to run your workplace servers as if they're no different than the hobby servers in your basement?
I pride myself ... (Score:4, Interesting)
My OpenLDAP stores:
POSIX User Attributes
Samba User Attributes
Radius User Attributes
eGroupware User Attributes (Egroupware accounts.)
DNS Information for our internal DNS Server
DHCP Lease information.
I use Kerberos with ssh-agent to distribute software RPMS for Mandriva Linux to mass distibute RPMs with a single command.
I have Samba Kerberos enabled so that Samba will not repeatedly ask for usernames and passwords, and requires zero configuration.
I have had the code to Egroupware modified so that eGroupware, and Nagios can use Apache's mod_auth_kerb addon to authenticate eGroupware users with a single click instead of a whole second login process.
I'm currently workong on creating a Samba Authenticated gateway with NTLM-SPNEGO support so that kerberos will handle Squid too.
All I need now is for someone to make the modifications nesessary to eGroupware's XMLRPC so that Kontact could use Kerberos and I would have the "Exchange Killer" I always wanted.
All of my users use Samba for network browsing under KDE's Konqueror, with Kerberos and LDAP, it just works.
I consider this my shining accomplishment.
I like to have myself believe that I accomplished "Active Direrctory" under Linux now. I don't use Windows at all in this network, so keep that in mind. The eGroupware people can attest to what a past I am. bugging them to include Kerberos detection in session management. But it all works.
Reliability (Score:3, Interesting)
But, what happens when the LDAP service isn't available?
I say service to not distinguish between a physical server, a cluster of servers, a crashed openLDAP process, broken network link, yadda, yadda, yadda.
With AD if a PDC isn't there, you can still login if you've logged on before.
The article really should have mentioned nss_updatedb and pam_ccreds from PADL [padl.com] (I don't know if there are any other alternatives, nor do I know if that actually work, sounds like they do though).
Re:Reliability (Score:3, Interesting)
Indeed...
Where I work one of my 'genius' predecessors set up a Linux fileserver with LDAP 'authentication' (nice euphemism that). LDAP is only used for samba fileshares... and for login.
The LDAP server runs on the fileserver itself, so at least it doesn't have to connect to a remote LDAP server.
He did a lovely piece of work, hacking it into place on a debian woody system, butchering the PAM config to make it appear to work.
He is long gone but his legacy remains; if the LDAP system falls over you can't log onto the server at all.
Not as root, not on the console, not remotely, not even via a remote logon with ssh keys.
Fantastic. What a genius.
The best one can do is reboot it and hope that the LDAP system does come back up.
I'd fix it but its so hacked together and my LDAP knowledge is limited (as, evidently, was his) and the server is no longer mission critical (I'm about to strip it for parts).
I would never, *ever* use LDAP for logon 'authentication'. Maybe for samba but I'd be very careful about getting LDAP involved with a console logon.
LDAP is a pain in the arse (Score:3, Interesting)
Total pain in the ass to setup
Total pain in the ass to maintain
Now, I am using radius for the same thing. It works a lot better, because lets face it. PostgreSQL or MySQL is a hell of a lot easier to work with then LDAP.
LDAP does have its place. If you are looking to tie more then just auth into a profile, then LDAP is the choice. If you just want auth, use something Radius.
Of course, if you are a total LDAP guru, you are gonna recommend LDAP. But for average admins, or quick setups. LDAP isn't the way to go.
Re:Why would one want to do this? (Score:3, Interesting)
Unix login doesn't have separate "username" and "domain" prompts like WinNT does. So here's what you do: Make "root" always a local user, and if you need an centralized "administrator" user, you create another user and add it to the "wheel" group or to /etc/sudoers or whatever, and that user can run "su" or "sudo -s" to get a root shell when necessary.
Funny story: A few years ago, we were testing Active Directory on some Win2K boxes. One of the security policies you can set is "disable the local administrator account". This can be set on the domain controller and propagated to all the clients. The problem with this is that, if you take a Windows workstation, and have it join a domain with this setting enabled, then almost immediately have it leave the domain, the "disable the local administrator account" will stay set. If you log out, you won't be able to log in again, and without logging in as an administrator, you can't re-join the domain.
It's a nice way to hose a Windows install.
This rocks (Score:4, Interesting)
Why does it rock so much? LDAP seems unique that, unlike almost every other authentication method under the sun (NIS, NIS+ radius) it can be used on a number of devices. Additionally LDAP tends to be a great back-end for other authentication protocols (i.e. radius) can use an LDAP backend.
Practically speaking, often times all someone needs to do is have read access to a device to find out if an interface is up but many system admins give up if they don't have the ability to centralize and allow the company to become altogether too dependent on them. LDAP basically gets rid of this hassle and the administration is minimal. This means that the system admin gets paged less and more people can get work done with better efficiency.
Re:Why would one want to do this? (Score:3, Interesting)