Slashdot Mirror
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 could now have several machines authenticating against one machine(although I know there are other ways).
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).
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
It's amazing how many Slashdotters think that the only computers are those used by individuals. In serious organization, you have hundreds or thousands of people using your systems, and maintaining a separate password file for each one is just unthinkable. So you have a central authentication facility, such as Active Directory, NIS, or LDAP.
Really, you need to add kerberos to the mix, especially the heimdall kerberos implementation is attractive, since it allows you to store its settings inside the ldap tree, providing a true centralised secure single signon enviroment.
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.
Because if you reject a "taken password", you now know another user's password. You can then use it to login as them.
er because when you reject a taken password, the user has all they need to know to get into somebody else's account!?
Warhammer forums
Ever since I rolled out an LDAPed Samba domain for a customer I was wondering why this is not beeing used for more stuff?
:) Been there...
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.
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.
If you have a system which has 50,000 users, then logging in would require that the system check the input passphrase against every single stored password hash until it hit the right one. This is expensive, and doesn't scale.
(Unless, of course, you speed up the backend by storing each end-user's passphrase in clear -- but that's very bad, as a successful attack on one of the authentication servers could immediately reveal the plaintext passphrase of every user.)
So we make users type in their username first. They need to have a username on the system anyway, and it's generally something that's easy to remember and changes infrequently, if at all.
I use LDAP at work for everything and life is so much better now.
/home/username. Public drives are mapped as well.
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. =)
Quote: "Besides geek points, why would one want to do this? There is an old saying....If it ain't broke, don't fix it."
Try changing your root password on 10 different servers on a regular basis.
Then issue accounts for 55 people on a combination of those servers, depending on which kind of job they do.
Also, each of those servers run different services, which some people need to have access to.
This leads to the situation where it is very common for people to have 6 different passwords, and this is the situation I find myself in right now.
The situation also leads to a lot of support calls with requests to reset a password, since people find it hard to keep track of their passwords.
I've actually been looking for a solution that is described in the article, but I've failed to find it all out myself within a reasonable timeframe.
It's best to start out with a step-by-step tutorial like the article, and then expand the solution yourself over time.
So I am very happy with this article!
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
LDAP authentication is cool, but LDAP is just an interface. Unfortunately, it usually comes bundled monolithically with a dedicated datastore, the BerkeleyDB. Which is neat and fast, working well for "standalone LDAP". But it ghettoizes ID info away from other apps which don't already have an LDAP interface. Some of which need relational access for their app logic, or just higher performance than massive volumes of LDAP queries will permit. The OpenLDAP server is stuck this way. Its basic features are really good, but that's as far as it goes.
So where's the HOWTO for porting OpenLDAP to Postgres for its datastore? There's some HOWTOs for porting it to MySQL, but MySQL doesn't scale as well as Postgres, and existing Postgres installs are out of luck. The few existing LDAP/Postgres HOWTOs seem inconclusive, untested. And some of the commercial products that advertise the feature don't even respond to emails to sales departments asking about the cutover.
As long as Slashdot is staring down "LDAP Auth in Linux", how about taking it to (and over) the Postgres wall?
--
make install -not war
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....
The big problem with ldap is that most of autentication plugins (apache, pam and the others) matches only first level group members, not nested groups, normally used, expecially, in big micro$oft directories. This creates a lot of "difficul to mantain" groups containing very big lists of accounts. I know that filters or organizational units can be used to group them, but most of the times this is not enaugh. For this reason i usually prefer radius which integrates well *nix and m$ worlds (even if i still use ldap for apache cause radius mod for apache is not so customizable).
i work for a company that handles large enterprises single sign on and user id consolidation needs... (as well as small/medium ones as well)
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 or http://www.centrify.com/ for some good info on two companies that are doing this for the *nix world now...
sig goes here!
This tutorial should have some major security warnings plastered all over and I see nothing to that effect so here's a suppliment.
First, LDAP is NOT an authentication service. I cringe a little whenever someone mentions using "LDAP authentication" for anything other than LDAP clients. Some of these tools use LDAP as a make-shift "pass-through" style authentication service. This is like passing credentials to an SSH server to authenticate web clients (only SSH would be more secure since it enforces confidentiality and integrity).
Second, if you are going to use LDAP like this, make sure the bind is being conducted over SSL. Using SASL would be even better but that's a little harder for a long lived service account and somewhat pointless if you already have Kerberos setup. With a plain bind you're sending passwords in clear text. Do not ever do that or someone will eventually come to your cube asking funny questions.
Finally, using LDAP as an authentication service does not provide Single Sign-On (SSO). You basically have to store some kind of token in the user's HTTP session which means someone could get your session ID and impersonate you (e.g. inadvertantly send a link with a session ID in it).
In general I don't recommend using LDAP as a make-shift authentication service as it is very easy for it to be insecure. Use Kerberos through and through people. It's the correct way to do things, it scales well and it's portable across both UNIX and Microsoft.
I believe I have one of the most advanced LDAP/Kerberos/Samba/Bind "Open Directory" setups. I have two Samba 3 Domain Controllers, both Kerberos and Bind Enabled. with OpenLDAP and MIT Kerberos. I have no need for NFS.
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.
Huh? Surely Kerberos is more complex than plain LDAP authentication?
Yep centralised user management, great, no doubt.
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 (I don't know if there are any other alternatives, nor do I know if that actually work, sounds like they do though).
Few years ago, this was a common setup I would put in place. When I had a number of users accessing all different types of devices or services, I would setup an LDAP server and have everything auth against it. It worked well, but has 2 major flaws.
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.
until (succeed) try { again(); }
Try changing your root password on 10 different servers on a regular basis.
You aren't thinking of putting your root login under LDAP are you?
Not meaning to be rude, but please, don't be such an idiot.
What happens when the LDAP server falls over and you are at the console and you try to login as root... and it can't authenticate root because the LDAP subsystem is down? Reboot and pray that LDAP starts up ok?
In the free world the media isn't government run; the government is media run.
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.
http://outcampaign.org/
We switched to ldap authentication on our UNIX systems about a year ago, and basically it rocks. Providing single-sign-on between all of your device of varying operating systems and utility (i.e. servers, routers, switches, terminal/console servers, a lot of applications, and even kvm's) is great when you have a multi-teared support organization, and even if you don't you can still save yourself a lot of useradd / usermod /userdel commands if you centralize.
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.
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!
Amen.. This is such a no-brainer to me. I implemented a similar service at a previous employer back before AD was even heard of (1997 or so). Basically I wrote a web UI which the helpdesk could access to add/change/delete accounts, which only updated entries in a mysql database (the web app never talks directly to individual servers, for security reasons). Each server in turn queries the DB once an hour and updates the local passwd, shadow, smbpasswd, sasldb, group, etc files as accounts are added/changed/removed. The only drawback is it takes up to an hour for a change to fully propogate though all servers. The good thing though is that to the apps the authentication is local (they just use the local files), so if the DB server poops its pants those services (samba, dovecot, sendmail, etc) are still available. Plus, the apps don't need to have intelligence about the DB, LDAP, NIS, etc.. They just use their local files like always. I rounded this out with freeradius with an sql module (for wireless, vpn, and dial up), and mod_auth_mysql for apache for the intranet. This allowed us to offer ONE username/password for every possible service on the network, and fine grained control via the web UI of each user's access to each service. Through the web UI we could enforce strong passwords, auto-generate the user's login, etc, etc. I *never* had to touch servers for accounts (other than root, which was never handled from the db), and the helpdesk really liked having an easy to use UI rather than being forced to ssh or telnet directly to servers (which would have been a nightmare). The only issue with this setup is each server needs to be able to talk directly to your SQL server, but as long as you manage this correctly (restricted permissions, etc) it's workable.
Today I didn't even have to use my AK; I got to say it was a good day -- Icecube