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."
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.
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
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.
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!
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
Maybe you have a brain the size of this guy. 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.
Our intelligent designer has never created an animal that we couldn't improve by strapping a bomb to it.
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.
Huh? Surely Kerberos is more complex than plain LDAP authentication?
Kerberos is also very nice to use with SSH (no password typing:)), on systems that support it (SLC3 has patched sshd for example), but most I encountered don't.
/etc/passwd data (e.g. home directory, UIDs for uidusername matching...). You may also want to do automounting of user's home directory over NFS, for that you either have to store a copy of auto.home on each machine, or you can instruct automounter to use ldap and have central place with that information (though some distros' automounter versions support only one of two ldap dedicated schemes floating around, or even none at all).
Of course, you can use kerberos auth with default unix pam/nss setup, but then you don't have central administration of users. Just kerberos isn't enough for that because You CAN'T migrate
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.