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."
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
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.
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.