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."
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: (Score:2)
Anyway if you implemented LDAP+Kerberos it would be better then active directory because you would not be suffering from vendor lock. Vendor lock is always bad.
Re: (Score:2)
Not if you're the vendor!
Re: (Score:2)
Re: (Score:3, Informative)
Re: (Score:2)
Re: (Score:2)
No reason to run TLS enabled LDAP on a separate port, and with most LDAP servers (including OpenLDAP) you can restrict the security level required for certain operations (such as bind and update).
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.
Re: (Score:2, Interesting)
Sad, but often true.
NordicEdge AB
Re: (Score:2)
I also had a though meeting after the migration where the CEOs asekd me what the benfit was.
I replied: "Cheaper maintenance". Luckily I started this domain for them so I could also add "enhanced security, privacy" to the mix.
Otherwise I would have gotten into trouble too.
You are probably right. I was just wondering if there are architectural/technical issues I wasnt aware of.
Re:I always wondered... (Score:5, Informative)
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:I always wondered... (Score:4, Informative)
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).
Re: (Score:2)
Re: (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 wit
Re: (Score:2)
Back when I worked in a network shop in the air force, all the people that really didn't know anything and weren't willing to put in the effort to learn were given the task of user account management, since it's easy (at least it was easy on NT4 with Enterprise Administrator). Some of them would get fed up doing the same old boring thing and find out what the more knowledgable people were doing, some wouldn't.
I liked the way it was set up 'cause I
Re:I always wondered... (Score:5, Insightful)
Maybe you have a brain the size of this guy [wikipedia.org]. I don't know. I have tried a few times in the past to set up LDAP and all the documentation is written by space-aliens as far as I can tell. I can't even penetrate the language used, let alone follow the steps prescribed.
This Fine Article is no different. After about the 3rd sentence I have no idea what is being described, because we're already talking about "a replication" but this has not been defined. It's all like that: undefined terms and references, and exhortations to read the ldap man pages if you want to understand what is going on. The man pages are also full of undefined terms and references, except they are presented in highly-compact text blocks with bad grammar.
LDAP is niche because it is so freaking impossible to figure out. That's why.
Re: (Score:2)
Glad to see I'm not alone. I successfully set up Kerberos 5 for single signon on my little home network, complete with master/slave redundant KDCs. I then successfully set up NIS. The next step is to migrate to LDAP, right? Well, this totally mystified me.
Re: (Score:2)
Which is a shame really, because once you know it's quite easy to understand.
It's a tree-based database which may store objects as well as just text.
Because it's tree based, you don't generally search it like you do with an SQL database (SELECT record FROM table WHERE condition). Instead, you already know at least roughly where what you're interested will be, so you say "starting from this point in the tree, find me this type of
Re: (Score:2)
Re: (Score:2)
"RTFM n00b".
thank you.
Other options (Score:3, Informative)
For administration, check out JXplorer. It makes it easy to add/delete/modify users.
Re: (Score:2, Informative)
Re: (Score:2)
Re: (Score:2)
Do you mean previously proprietary? I have a hard time believing that very many LDAP installations are non-commercial.
Re: (Score:2)
No, he/she means commercial. He's referring to the product, Fedora Directory Server, not an installation of said product. That Netscape Directory Server was a proprietary product before becoming FDS is irrelevant to the OPs point. Nor does commercial/non-commercial LDAP installations.
Re: (Score:2)
(Disclaimer: I use OpenLDAP myself. But it is so f
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: (Score:2)
If only more apps used it...
Our wiki Linux LDAP Howto (Score:3, Informative)
I hope you find it useful.
LDAP/Postgres? (Score:3, Insightful)
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 [google.com] 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?
Re: (Score:2)
Re: (Score:2)
If you don't understand how a unified data layer for a network-available query interface is useful, refrain from commenting on it.
Re: (Score:2)
Why would you want to port a hierarchical database to a relational DBMS?
Re: (Score:2)
Re: (Score:2)
SPLAT - Scalable Periodic LDAP Attribute Transmogr (Score:3, Informative)
Authentication with Apache Directory Server? (Score:2)
The article uses OpenLDAP as the LDAP server. Has anyone got this to work using the Apache Directory Server [apache.org]?
Host-based control (Score:2, Informative)
Installing the software never was the problem (Score:2)
Nested groups (Score:3, Interesting)
LDAP is NOT an authentication service (Score:4, Insightful)
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.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Got any good HOWTOs? (Score:2)
Funnily enough I was having a similar conversation with someone at work last week. It seems that our Intranet authenticates via an LDAP bind, and when I found this out I thought "huh?!" and went to talk to the guy responsible. Of course, I didn't really have any better answer for him because although it's very easy to say "Just use Kerberos!", I only really know the basic principles of it and not really the practice.
So, my question to you is... do you have any good pointers to a nice, simple "getting start
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.
Exercise in futility (Score:2)
Far more useful is managing the users locally but authenticating them (i.e. checking their password) via LDAP. For example, in an enterprise
Re: (Score:2)
Re: (Score:2)
If fifty million people say a foolish thing, it is still a foolish thing.
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: (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 legac
Re: (Score:2)
Just make sure there's an enabled root account in your /etc/(passwd|shadow), make sure pam_unix is enabled in your /etc/pam.d/(system.auth|login), and your /etc/nsswitch.conf has a line that says "passwd: files ldap" and you're all set.
Re: (Score:2)
Yep, there is.
make sure pam_unix is enabled in your
Yep, it is. Well, theres lines that say:
auth required pam_unix.so nullok
account required pam_unix.so
session required pam_unix.so
password required pam_unix.so nullok obscure min=4 max=8 md5
and your
It did say this:
passwd: compat ldap
which I've changed to:
passwd:
Re: (Score:3, Informative)
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:
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: (Score:2, Informative)
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
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.
As was already mentioned..... (Score:2, Informative)
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!
Welcome to 1996 (Score:2)
Why is this slashdot material? (Score:2)
NIS gateway (Score:2)
Re: (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 realiz
Re: (Score:2)
Re: (Score:3, Insightful)
Huh? Surely Kerberos is more complex than plain LDAP authentication?
Re: (Score:2)
Deploying Kerberos is likely easier than managing LDAP-over-SSL, if you take into consideration the problems around maintaining the certs. [No, cert maintenance isn't difficult, but the tools are essentially "built in" to Kerberos rather than being a manual process if you're using, say, OpenSSL as your RA.]
Plus, Kerberos gets you SSO and the ability to secure NFS, which using LDAP doesn't.
Comment removed (Score:4, Informative)
Re: (Score:3, Informative)
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
Re:Why would one want to do this? (Score:5, Informative)
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.se]
NordicEdge AB
Re: (Score:2)
Re: (Score:3, Informative)
You can also keep NIS around just for those maps.
Re:Why would one want to do this? (Score:4, Informative)
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: (Score:2)
... except, in the specific case of automount maps, everyone seems to be doing it slightly different. Certain distributions of Linux and older versions of Solaris, for example, tend to require that the automount map have a nisobject object class in addtion to the automount object class. Then you get to Mac OS X. It was bad enough that Apple opted to essentially move the broken NetInfo mounts directory into its equivalent ou=mounts in LDAP. If you want them mounted with AFP, you get the added bonus havin
Re: (Score:3, Informative)
Re: (Score:2)
Re: (Score:3, Insightful)
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.
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: (Score:2)
Re: (Score:2)
Re: (Score:3, Insightful)
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 situati
Re:Why would one want to do this? (Score:4, Insightful)
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?
Re: (Score:2)
Re: (Score:2)
Which is all fine and good as long as you login regularly on that machine as that user. But if you only ever log in as root if you need to fix something (such as LDAP...), you're screwed.
Re: (Score:2)
In any case you can always boot knoppix or whatever to fix any LDAP issues.
Re: (Score:2)
Dare to take a chance once in a while!
Anyway, it's very easy to make a passwd fallback for root.
Point is, since you seldom/never need this fallback password, there is no need to change it.
Been working with Linux for 7 years now, upgrading live servers during office hours. It has never bitten me, although it's not recommended practice either, so please don't call me an idiot. I know what *could* go wro
Re: (Score:2)
Dare to take a chance once in a while!
I can see that you don't look after enterprise systems on which many other peoples livelyhoods depends.
Or if you do, then you bloody well shouldn't.
Re: (Score:2)
Re: (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 adminis
Re: (Score:2)
Re: (Score:2)
We use LDAP authentication as the primary login method but in case LDAP server is down there is a fallback to standard Unix
Additionally, you can configure PAM to parse names like "SCB\Administrator" as "Administrator" in Samba domain "SCB". We use this for winbind authentication.
Re: (Score:2)
Every tried to replicate NIS across a firewall? Or god forbid winhoze authentication?
So if you have 2+ security zones LDAP is your only choice. Good example is developers from your company on your internal LAN and contractors from an outsourcing shop which work in another LAN which has no access to your internal network. The LAN they work on is also connected via a VPN to a LAN on their premises across a firewall configured by an out
Re: (Score:3, Interesting)
Re:Password only (Score:4, Interesting)
Re:Password only (Score:4, Insightful)
Re: (Score:2)
So...what's the difference between this and having only usernames?
Re: (Score:2)
I don't know what bulletin boards have to do with this. I figure you're specifically talking about single-factor authorization. Whether the no-username-password is encrypted or the no-password-username is encrypted (or kept in the clear as with passworded usernames) is irrelevant. One piece of information for login is what you're talking about and it is well-established that this is not as secure as methods involving more elements of information being used to
Re: (Score:3, Insightful)
(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
Re: (Score:2)
Umm you hash one password, then compare 50,000 strings - or
You compare 50,000 strings, and hash one password.
I don't see that making a difference at all, there's a whole lot of other reasons to do it though...
Re: (Score:2)
Re: (Score:2)
I followed this guide: Implementing a Disconnected Authentication and PDC/BDC Relationships Using Samba and OpenLDAP [linsec.ca].
The only problem with it is, and this is only on my laptop (it's supposed to work), is changing passwords has to be done on the master LDAP server. Has something to do with update referrals, maybe PAM_LDAP doesn't follow them, but right now it's not a big issue for me so I haven't really looked into it.
Other than that, it works great (when it works). Replication goes through immedately, and
Re: (Score:2)
Good point, that is just asking for trouble. I have no idea why I thought that was a good idea. The only other alternative I can think of is to expose you LDAP server's SSL port to the Internet and require verified client certificates. Even if somebody gets a hold of your client certificate, all they can do is start trying to brute force. Of course, as far as I know, there's no way to lock an account if they try LDAP auth directly. Guess it's time to start believing the truth: LDAP isn't an authentication p