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

Comments

fuuuck all you hoes

[Anonymous Coward]

fuuuuuck all you hoes

Re:fuuuck all you hoes

[Anonymous Coward]

Sorry, but I'm not into gardening tool sex.

Faux Scotsman unwittingly flashes gay hike group!

[Anonymous Coward]

Should have stuck with the standard "nothing but socks and shoes" answer...

Why would one want to do this?

[penix1]

Besides geek points, why would one want to do this? There is an old saying....If it ain't broke, don't fix it.

B.

Re:Why would one want to do this?

[Timesprout]

Because you might like to gain penetration in enterprise environments.

Re:Why would one want to do this?

[penix1]

So in essence, you are say for the geek points....

B.

Re:Why would one want to do this?

[Anonymous Coward]

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

Re:Why would one want to do this?

[Anonymous Coward]

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.

Re:Why would one want to do this?

[antlope]

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

/Anthony Whitehead
http://www.nordicedge.se/
NordicEdge AB

Re:Why would one want to do this?

[charlesnw]

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.

Re:Why would one want to do this?

[fm6]

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?

[MrResistor]

Maybe you have multiple computers in your house, and maybe you have multiple users as well. Wouldn't it be nice if any given user could log on to any given computer and have their environment be the same without having to go through the pain of configuring it on every machine, and have access to all their files without having to remember which machine those files are stored on?

Re:Why would one want to do this?

[mojinoman]

Are you insinuating that you need some other motivation apart from the "geek points" in order to consider this interesting enough? This is Slashdot, for god's sake! Geek points is a necessary and sufficient condition.

Re:Why would one want to do this?

[whoever57]

If one replaces NIS with LDAP, what about the other maps: for example: how do you distribute auto-mount maps?

Re:Why would one want to do this?

[LinuxDon]

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!

Re:Why would one want to do this?

[Anonymous Coward]

It is broke' when it comes to managing a work group. With a proper LDAP setup, you can go to any workstation on the network and login as though you were sitting at your desktop machine (requires exporting the home directories from a server). I have that setup in my lab and it is a huge improvement over NIS or password-file-per-machine. In fact, I would like to see LDAP become the default account mechanism (at least in my preferred distro). Slapd is relatively lightweight so even standalone installations would not notice a big hit. Most users would not even know they were using LDAP. Now add a nice friendly "share user accounts" setup menu and viola, instant work group. (Nice if it was also configured to work out-of-the-box with SAMBA!)

Re:Why would one want to do this?

[ximenes]

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.

Re:Why would one want to do this?

[antlope]

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

Re:Why would one want to do this?

[Anonymous Coward]

Listen, I am a sufferer of someone who did this to a large scale Linux/Solaris environment. Performance TANKED. Don't do this unless you really know what you're doing.

Re:Why would one want to do this?

[tek.net-ium]

Try changing your root password on 10 different servers on a regular basis.

Using LDAP to set root passwords is a horrible idea. Often, you need to login to a machine as root when something bad is happening, and that often entails network access being unavailable. This is an undesired dependency in most environments.

Re:Why would one want to do this?

[Anonymous Coward]

change Wouldn't it be nice if... to i have a dream that ;]

Re:Why would one want to do this?

[Anonymous Coward]

Let me give you a real-world example.

I run a small school, and we provide some computer resources to our students.

We have a back end server that hosts our NFS and SAMBA shared directories, our SQL server and our LDAP server. On this server we also run our student database (billing, scheduling, etc). Everyone gets a username and password in our LDAP system, allowing students to log in to our website (apache+php, both with ldap support) to sign up for or pay for classes. Each year students may also choose to sign up for "computer services for students". When they sign up for this service, their LDAP username and password gives them access to our on-site wifi, access to any public terminal at our site (XP machines and K12LTSP workstations. We may add some full linux terminals this winter), a POP3 email account (can also access via HORD with LDAP), access to our wiki (Mediawiki with LDAP), access to select usenet newsgroups (NNTP) and email lists, access to our online textbooks, and access to 2 other off-site databases. Teachers get all the same services kids do, plus they get to reserve rooms, sign in and out for payroll (onsite only), order textbooks, order other equipment, and other such things.

Other LDAP services we are looking at adding include Moodle (online classrooms), various library services, even room access controls (new locks that are controled via swipe cards).

All with a single click of a button. Geekpoints aside, if I had to do this by logging on to each system, or each program, I wouln't be able to offer these services to my students cost effectivly, or even at all.

Re:Why would one want to do this?

[rmallico]

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

Re:Why would one want to do this?

[ScriptedReplay]

If all you need is authentication, LDAP is overkill - just use kerberos. If you want directory services though, LDAP is your friend (or enemy)

Re:Why would one want to do this?

[arivanov]

This is the only sensible way to propagate authentication across firewalls.

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 outsourcing firewall admin (anyone who had to suffer explaining some of these will know what I mean). LDAP is the only sensible method to maintain uids, credentials and authentication across a scenario like this which is not that uncommon nowdays. In fact what I am describing is a fairly typical scenario.

The howto as such is not bad, but it has missed all the fine points for the people who really need it. If you can get alone on this howto alone I have some serious doubts that you needed to use LDAP auth and nss in first place.

Re:Why would one want to do this?

[Anonymous Coward]

Not having read the article, I can't really say that this is true for this setup. For the setup we use at my place of work, when LDAP isn't accessible, you still authenticate against the shadow file. I'm sure there's a security leak in there somewhere, but at the very least you won't be locked out of your system if LDAP crashes and burns.

Re:Why would one want to do this?

[jgrahn]

If all you need is authentication, LDAP is overkill - just use kerberos.

Huh? Surely Kerberos is more complex than plain LDAP authentication?

Re:Why would one want to do this?

[allenw]

... 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 having to make sure the entries are in a XML format.

This is one place where some agreement amongst vendors would be a good thing. Luckily, they do seem to be converging, but this is definitely an area where enterprise folks need to be on the lookout.

Re:Why would one want to do this?

[PlusFiveTroll]

On my windows box I can login as Administator\NETWORK or Administrator\LOCAL, it seems likely you can have a fallback on your unix box too.

Re:Why would one want to do this?

[allenw]

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.

Re:Why would one want to do this?

[Anonymous Coward]

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.

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 /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).

Re:Why would one want to do this?

[ChrisA90278]

Why, Lets say you have a building full of computers they run Windows, Mac OSX and Linux. Now you want to add a user to the system. Ideally he should have an account on all or some subset of the machines and his data should live on some server, so his folders and data are available no matter which machine he logs into. I think this is what users expect no days. OK so where do YOU keep his username and password. Do you go to each machine in the building and make an account for him? Likely not. So yu need some kind of database the Windows, Mac OS, Linux, Solaris and so on know how to querry. Gosh wouldn't it be need if the e-mail user directory and the company phone book could use the same data? LDAP will do all this.

If you only had one machine at home, yes this would be pointless unless then goal was to learn about LDAP.

Re:Why would one want to do this?

[myowntrueself]

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?

Re:Why would one want to do this?

[Schraegstrichpunkt]

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.

Re:Why would one want to do this?

[finkployd]

Or if you know what you are doing, Kerberos for authentication and LDAP for authorization (groups and user attributes). Using LDAP for authentication makes Baby Jesus cry.

Finkployd

Re:Why would one want to do this?

[Anonymous Coward]

you mean you see no advantage to centralized authentication? you're a tool of product pride.

Re:Why would one want to do this?

[mvdw]

I have only a couple of computers on my home network, and still am going to implement this. I just setup a computer for the kids yesterday and now lament having to setup accounts on that machine - the magic of LDAP means I won't have to (although I will have to migrate login/share data).

Re:Why would one want to do this?

[mvdw]

I'm not an expert by any means, but the limited reading I've done indicates that there is some degree of caching of passwd data on the local machine. Is this not true? I'd like to know because I'm about to implement LDAP on my home network.

Re:Why would one want to do this?

[finkployd]

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

Re:Why would one want to do this?

[shayne321]

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.

Re:Why would one want to do this?

[mdhoover]

Performance tanked in a linux/solaris environment? You obviously did something wrong.

Here's a question, is your passwd backend in /etc/nsswitch.conf setup to run in nis compat mode? Using netgroups?
If so there is your problem. If you must use netgroups, use pam_access under linux and for solaris either port pam_access (I can put this up somewhere for interested folk) or use pam_netgroups (available from OpenSolaris, just fix the malloc() without free() in it).

No point loading up the naming service layer for getpw* calls (and the ldap backend due to the large increase in lookups) when you really only need to evaluate during account checks during login.

Re:Why would one want to do this?

[mdhoover]

Plus, Kerberos gets you SSO and the ability to secure NFS, which using LDAP doesn't.

You'll get SSO for kerborized services sure, but for those services that aren't...

A combination of both is best, LDAP as a naming service backend (authorisation), kerberos for authentication.
Even better if (using OpenLDAP) you backend the LDAP server for user passwords via saslauthd to kerberos so at least for non-kerborized services that understand ldap, or even for those that dont using pam w pam_ldap, you at least get "Single Password" and a centralised authentication store.

Re:Why would one want to do this?

[Anonymous Coward]

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

Why can't you just say "Especially for things like the Payment Card Industry compliance that require it" and save yourself and all of us, the extra redundant garbage?

No offense, it just impresses me how people use acronyms (which help make things shorter) and actually spend a lot more time and space explaining it.

Re:Why would one want to do this?

[spongman]

It's a nice way to hose a Windows install.

hey, why go to all that trouble? del /f /s c:\ works fine for me...

Re:Why would one want to do this?

[ArsenneLupin]

but the limited reading I've done indicates that there is some degree of caching of passwd data on the local machine.

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:Why would one want to do this?

[mvdw]

Fair enough; I use ubuntu now so I don't have root accounts (my user account is in the sudoers list). Not so secure, but it's only my home network...

In any case you can always boot knoppix or whatever to fix any LDAP issues.

Re:Why would one want to do this?

[LinuxDon]

Who cares, I could always throw knoppix in the CD drive, chroot and change the password and PAM settings.

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 wrong, but usually doesn't. :)
And it beats having to go back to work in the weekends, which I never need to do this way! Weekends are for fun stuff!

Re:Why would one want to do this?

[myowntrueself]

Who cares, I could always throw knoppix in the CD drive, chroot and change the password and PAM settings.

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:Why would one want to do this?

[Cyberax]

Actually, you can implement something like 'domain' prompt.

We use LDAP authentication as the primary login method but in case LDAP server is down there is a fallback to standard Unix /etc/shadow authentication. It's just a simple line "auth sufficient pam_unix.so nullok_secure" in PAM configuration.

Additionally, you can configure PAM to parse names like "SCB\Administrator" as "Administrator" in Samba domain "SCB". We use this for winbind authentication.

Re:Why would one want to do this?

[macshome]

Hmmm... All that sounds suspiciously like Mac OS X Server. OpenLDAP for the directory, Kerb for auth, and a SASL blackbox Password Server for things that don't know kerb.

The difference is that Mac OS X Server is a one mouse click setup. :)

Re:Why would one want to do this?

[giantsfan89]

I don't know about Windows 2000, but you can login with a disabled Administrator account in safe mode in Windows XP.

So speaks

[Colin Smith]

A "power" user. *sigh*

A question only slashdotters can answer

[Anonymous Coward]

My neighbour is a Mac owner and heavily into RoR, is teh gay contagious?

Re:A question only slashdotters can answer

[LiquidCoooled]

Yes it is - its passed by mutual exchange of bodily fluids.

Re:A question only slashdotters can answer

[cdcarter]

I didn't know you lived next door. I will bring you a muffin basket. I heard your kind is into that kinda thing.

Re:A question only slashdotters can answer

[Anonymous Coward]

What's the first sign of AIDS?

A pounding sensation in the ass.

Proofreading

[Vlad_the_Inhaler]

Someone needs to clean up the typos there, they detract from 'the message'.

Password only

[Cybert4]

Seems like a good place to ask. In a recent job I asked why we stick to login/password? Why not have just passwords? Yes you'll have to reject taken passwords, but that's good policy anyway.

Re:Password only

[Imagix]

Because if you reject a "taken password", you now know another user's password. You can then use it to login as them.

Re:Password only

[antlope]

Several reasons, but the one I'd be most inclined to rate highest is the inability to protect against brute force attacks. Since you can't (or don't want to) stop all logins then the only way to stop brute force attacks is to disable the account that is under attack after a few incorrect guesses.
If you have only passwords then an attacker can use a distributed botnet to attack you with as many random passwords as he sees fit.
Given that most users pick godawful passwords it shouldn't take long to stumble upon a password that is valid for some user in your site, and not asking for a username just makes this a whole lot simpler.
/Anthony Whitehead NordicEdge AB

Re:Password only

[legoburner]

er because when you reject a taken password, the user has all they need to know to get into somebody else's account!?

Re:Password only

[rhizome]

In a recent job I asked why we stick to login/password? Why not have just passwords?

So...what's the difference between this and having only usernames?

Re:Password only

[David McBride]

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.

Re:Password only

[Cybert4]

Usernames are public (say it's a bulletin board).

Re:Password only

[Anonymous Coward]

...You're kidding, right? That's insane! How the hell would you be able to actually _identify_ your users? Assign rights to them, run stats on their activity, that sort of things? And gods, the security aspect would be a nightmare.

If you say "The system will know which user it is, according to the password", then I really hope you're not in any position of authority.

Re:Password only

[dotgain]

Doesn't saying "'banana' is taken, choose another" not make the passwords public?

Re:Password only

[rhizome]

Usernames are public (say it's a bulletin board).

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 identify the user.

Re:Password only

[VGPowerlord]

A score of 1? Hordes of people pointing out stupid that is? I guess people aren't catching on that you're joking.

Re:Password only

[Kjella]

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.

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:Password only

[Anonymous Coward]

His response to other posters, which appears just your post, clearly indicates that he was not, in fact, joking.

And people wonder how so many sites get hacked...

Re:Password only

[Anonymous Coward]

> Umm you hash one password, then compare 50,000 strings

Ever heard of salting? Look it up. And that's assuming a local password file and not a remote system, since a remote box can do challenge/response with as much salt as it wants that changes every time.

Testing against "taken" passwords is still criminally stupid.

Re:Password only

[Cybert4]

I'm no longer in a place to implement such a thing (changed jobs), but I still think it has its place (for non-important sites like bulletin boards). Supposedly bright people sometimes get so caught up in what's just "always been done". See decimal, archaic measurements, or QWERTY.

Ldap on its own is not enough

[Anonymous Coward]

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.

Re:Ldap on its own is not enough

[bitflusher]

you mean recreate the ms windows for mix authentication called activedirectory on a unix enviroment?

Re:Ldap on its own is not enough

[killjoe]

Are you under some impression that MS invented LDAP+Kerberos?

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:Ldap on its own is not enough

[Schraegstrichpunkt]

Vendor lock is always bad.

Not if you're the vendor!

Re:Ldap on its own is not enough

[killjoe]

True, rape is usually good for the rapist and bad for the rapee.

Re:Ldap on its own is not enough

[finkployd]

Haha

Active Directory, you mean recreate DCE (Distributed computing environment) using Kerberos for authentication and an x.500 derived directory for storing services and user groups and attributes?

Microsoft did nothing original with AD except to use LDAP instead of CDS (good move CDS sucks) and try to stuff service registration and discovery into DNS (yuck, LDAP would be much better for that). That said, DCE was way too complicated for most sites to set up, so it is good that MS brought it to the masses in the form of AD. But don't for a second think they invented any of it.

Finkployd

Re:Ldap on its own is not enough

[shootmeagain]

not much better than NIS? if it was exactly the same as NIS but with encryption, it would already be far better than NIS. assuming of course that deployments use ldaps:/// and forbid ldap:/// (why would anybody use ldap:/// aside from debugging?)

Re:Ldap on its own is not enough

[MaoTse]

It's actually sad how many people in here find the AD based solution to
be either "the best possible deal" or neglect the whole idea completely
(based on a notion it is "a MS thing").

At some point LDAP on Unices had potential to sweep AD black boxes out of the
market but unfortunately Microsoft was quicker. And now people can be proud of
being able to hook up sambas and perhaps linux boxes to AD.

It is like a hidden secret that the basic deployment could be made in an other
way: hooking up Windows machines to Unix LDAP. It is much more secure and
manageable. But also too cumbersome for most people.

Interesting things happen in this area (like Fedora Directory Server or Sun
OpenDS). Deployments of these type are however much more prevalent in large
java-based web apps environments - not in company wide identity soulutions.

AD won.

Re:Ldap on its own is not enough

[Christopher Cashell]

StartTLS.

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

Re:Ldap on its own is not enough

[finkployd]

AD does nothing that DCE has not been doing on Unix for over a decade. However DCE is basically dead (not due to any shortcomings, it was just complicated as all get out to get running, only the largest sites did).

PSU's identify management solution (I'm most familiar with this having worked there for 7 years, most of the time with it) is Kerberos for authentication and LDAP for all attribute and group information. This allows for very nice (and secure) single sign on as well as robust authorization and workflow control. AD's KDC is a slave (one way trust) to the production MIT Kerberos KDC so Microsoft has no control of authentication. We have also developed/integrated solutions to obtain credentials in any other format necessary for special or external applications. Need an x.509 certificate for a government application? we have a short term cert generator that signs certificates when presented with the user's kerberos credentials (basically an authentication token converter). Need a SAML assertion for federated offsite application? We have that in the form of Shibboleth ( http://shibboleth.internet2.edu/ ), but it still all backends to our Kerberos authentication and LDAP user registry.

The best solutions let you add on functionality as needed, without compromising your core workflow and authentication setup. As you say, there are open solutions out there which do it a lot better than AD. The only valid reasons to use AD are (1) you are a complete MS shop and never intend to require functionality that MS doesn't provide, (2) you don't know what you are doing and need a wizard setup to set up your identity management infrastructure or (3) management dictated it, technical reasons be damned. In all cases, I feel a twinge of sorrow for for the admin ;)

Finkployd

Re:Ldap on its own is not enough

[jimicus]

One thing I still don't understand is what does LDAP+Kerberos give me that LDAP+SSL or LDAP+SASL doesn't already offer?

Re:Ldap on its own is not enough

[mverwijs]

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

NIS can handle more than just a passwd or shadow. We've still got NIS distributing automount scripts, for example.

I always wondered...

[Lispy]

Ever since I rolled out an LDAPed Samba domain for a customer I was wondering why this is not beeing used for more stuff?
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. :) Been there...

Re:I always wondered...

[antlope]

Because the sites that could most benifit already run NIS or similar for Unix, and have working AD systems for windows. With a larger site (100+ servers) the admin groups are usually hard presses for time anyway and have to justify this kind of switch to a manager who most of the time doesn't fully see the advantage of spending all those man hours switching systems.

Sad, but often true.

/Anthony Whitehead
NordicEdge AB

Re:I always wondered...

[Lispy]

Ah! Not that you mention it.
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...

[guruevi]

It is otherwise widely used hidden under proprietary MS code: Active Directory is a pure Kerberos + LDAPv3 implementation except that for synching and logging in (the essential outside communications that other platforms would like to use) is proprietary and they changed some things to the standard scheme too (SID etc.) which makes it useless for anybody but MS.

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

[93 Escort Wagon]

Ah, I was about to ask this same question...

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?

Re:I always wondered...

[Wylfing]

Who can enlighten me why this is still rather a niche?

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.

Re:I always wondered...

[spauldo]

recently even Novell and lots of companies use it for different purposes in one or another way

Novell's been using it longer than pretty much anyone. Check out NDS 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:I always wondered...

[spauldo]

Account management is boring and detracts from "real" work.

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 could worry about other things than user support and train people who were actually interested in learning.

Re:I always wondered...

[19thNervousBreakdown]

I know! It's like they expect you to know LDAP in order to set up LDAP authentication! The nerve!

If you don't even know what replication is in the context of LDAP, you probably should do some reading before you try to set it up.

Re:I always wondered...

[GreenBugsBunny]

I highly recommend O'Reilly's LDAP System Administration. That's where I started when I was interested in setting up LDAP. When I started, I knew nothing. By the time I was through the book, I had a working LDAP directory with TLS encryption and master-slave duplication, and I actually understood what how I got there.

Re:I always wondered...

[Icyfire0573]

I think the main problem with it is that it can be hell to setup. When I got a brand new computer at home (to be my file/web/myth/SQL server) I decided to use LDAP and make all 5 of my computers use it. There is a lot to say for having a great frontend (Active Directory). I haven't read this article yet, but I sure as hell plan on doing so because I went through 3 or 4 days of hell trying to get the whole thing configured right and I never really did understand if the tree came out right or not. In the end I was using Debian Testing on that machine and a aptitude dist-upgrade ended up destroying its ability to work so everyone go moved back to the standard passwd/shadow method.

Re:I always wondered...

[finkployd]

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

No, they copied DCE, which was in use by a lot of Unix people at really large sites. (PSU, National Labs, Merck, etc.)

Active directory is effectivly OSF/DCE only easier to set up and intentionally crippled to be non-interoperable. Oh, and it uses LDAP instead of CDS (both x.500 derived directories)

Finkployd

Re:I always wondered...

[Anonymous Coward]

Wow, I found it to be soooo easy, but then again, I just used this script to do it.

Re:I always wondered...

[Anonymous Coward]

May be you'll find this introductory document useful:

http://wiki.freaks-unidos.net/ldap-intro

Re:I always wondered...

[glitch23]

Just so people are aware, all companies who make a directory server change little things here and there and so they all fall outside the standards in one way or another. Despite the public being used to MS doing that, at least in the LDAP world, it is fairly common and thus no surprise that MS did it for AD. They actually don't use standard kerberos tickets but their own flavor of them however standard tickets can be turned on by setting a registry setting (which is required if you have a Java app that you want to authenticate to ADS by using the kerberos ticket). The standard schema (not scheme) is very minimal and MS had to add a lot of things to it in order to support the functionality that MS provides (such as using SIDs for ACLs instead of just usernames). Exchange Server 2003 adds around 1000 new object classes on its own which extends the schema once again but the LDAP schema is meant to be extended so this isn't so bad.

By the way, one company you missed in your list is Oracle. They have their own implementation of LDAP called Oracle Internet Directory which is used by their Collaboration Suite and many other applications. They also provide a sync feature that can synchronize OID to ADS in both directions (although I could get the sync'ing working I couldn't ever get an ADS user to authenticate to OID).

One thing people should realize and that I should emphasize is that MS did not change the standard schema, they added to it. There is no SID in the standard LDAP schema. And you can't fault MS for adding it by saying it is useless for anybody but MS because it already was useless(no one else uses the SID anyway) so why would it matter,from an outside perspective, whether they added it or not? By that logic, the fact that the attribute "jpegPhoto" is in the standard schema must mean it is proprietary because it is useless for anyone other than whose who doesn't want to store employee photos in their directory.

I believe if any one LDAP implementation is closest to the standard it is OpenLDAP.

Re:I always wondered...

[Yeechang Lee]

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.

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:I always wondered...

[Anonymous Coward]

I think a lot of people have no idea what LDAP even is. Those that do often find themselves contrained by the default schemas, and don't know how to extend LDAP to meet their particular requirements. Also, I think a lot of folks aren't quite sure how to interface LDAP with their institutional data repositories. I.E. - how do you keep LDAP syncronized with data coming from disparate systems like HR, the school registrar, your systems group, etc.

Re:I always wondered...

[afd8856]

Haven't read the article, but I had my share of LDAP learning Basically, ldap is a sort of object-oriented database, with customizable schemas for the objects. That's all there is to it, and is especially easy to comprehend for anyone familiar with zope / Archetypes.

Re:I always wondered...

[jimicus]

The main reason for that is that nothing really tries to explain what LDAP is.

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 record with this value".

TBH, it's easier to explain in person with a whiteboard than it is to write - which is probably why so much of the documentation is so lousy ;) However, if you can stomach it, this seems to be as good an introduction as any - though it's still pretty hairy:

http://www.zytrax.com/books/ldap/ch2/

Re:I always wondered...

[gbjbaanb]

If I may rephrase that comment in terms the average slashdotter will be more comfortable with,

"RTFM n00b".

thank you.

Re:I always wondered...

[spauldo]

I don't see that. Their biggest competitor for file/print services was Novell, which works pretty much the same. They might have used DCE for implementation details, but I'm willing to bet it was Novell they copied the basic ideas from.

Now Novell might have copied DCE... I have no idea. I'm just saying that Microsoft had their mind on copying the directory features of NDS, not an obscure UNIX setup.

Re:I always wondered...

[renoX]

Agreed, and to add insult to the injury the LDAP ugly & weird syntax 'dn,cn,dc,etc' is *never* explained..
And when it is the explanation is incomprehensible.

If we'd classify tools by their elegance, LDAP would be well down the bottom :-( , too bad as it is supposed to be the replacement of NIS..

Other options

[digitalhermit]

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.

Re:Other options

[hethopus]

Best one I've used is Luma -- http://luma.sourceforge.net/

Re:Other options

[thanasakis]

For large installations (read: hundreds of thousands of users) one might also want to take a look at the Sun Java System DS (former iPlanet), which is a very trustworthy and feature rich solution from what I've been told.

Re:Other options

[Anonymous Coward]

For GNOME users, there is LAT (LDAP Administration Tool)

Re:Other options

[Schraegstrichpunkt]

... Fedora Directory Server, which is based on a previously commercial product.

Do you mean previously proprietary? I have a hard time believing that very many LDAP installations are non-commercial.

Re:Other options

[PygmySurfer]

Do you mean previously proprietary? I have a hard time believing that very many LDAP installations are non-commercial.

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:Other options

[mdhoover]

Indeed, and with JES 6 there will be no limit on the amount of master replicas allowed to replicate.
Should be out end of this year.

Re:Other options

[WaffleMonster]

The Netscape directory server (NDS) became the iplanet directory server which then became the Sun directory something or other after sun axed the partnership taking NMS and NDS with it.

Sun also had their own directory and mail server (SIMS) both really sucked. Their LDAP server was based almost entirly on the unmodified University of Michigan codebase and was as slow and unrealiable as a directory server could possibly get. It wasn't long until it was abandonded in favor of stealing netscapes messaging and directory server which are both excellent products.

Now somehow redhat managed to get their grubby little hands on the same directory server.. I don't know exactly what miracle happened there but it put a big grin on my face when I heard the news.. NDS rocks.. everyone should use it.

Re:Other options

[jimicus]

OpenLDAP is great except that its support for a number of (admittedly optional) plugins is lousy, like most LDAP implementations the ASN.1 used for the schema definitions is subtly different to everyone elses, it doesn't support multi-master replication, it has this awkward tendency to leave the most appallingly unintelligible logs, its single-master replication support isn't exactly stellar and its mailing lists can be downright hostile to the uninitiated.

(Disclaimer: I use OpenLDAP myself. But it is so far behind almost every other directory server out there in terms of polish that it would be a downright lie to describe it as "great". The main points in its favour are it's free and most other free software which supports LDAP supplies schemas suitable for, and is tested against OpenLDAP.)

Re:Other options

[mrroach]

I'll take this opportunity once again to self-promote. I wrote EDSAdmin. A user and group management tool for LDAP servers (including LDAP+Kerberos and Samba) that focuses on doing its one task simply without bothering the user with DNs or CNs or general LDAP specific terminology. Check it out and let me know what you think.

-Mark

Re:Other options

[tbuskey]

From what I understand, NDS was for sale when AOL/Sun split up Netscape.

Sun's JDS is NDS with all the years of Sun's coding added to it.
Redhat bought the NDS code base and open sourced it. So it has a few less years of development then JDS.

Oh, and they all started w/ Umich's original code base.

I'm sure someone will fill in details/correct mistakes I might have, but that's the jist of it.

LDAP for everything

[linuxkrn]

I use LDAP at work for everything and life is so much better now.

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 /home/username. Public drives are mapped as well.

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:LDAP for everything

[gbjbaanb]

This is the thing I'd love to see - more apps integrating with a LDAP user db. I hink it would enhance a lot of applications (and I'm thinking all those PHP web-based things) if they all used a single-signon sourced from a LDAP directory instead of rolling their own user login system every time.

If only more apps used it...

Our wiki Linux LDAP Howto

[Anonymous Coward]

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.

Re:Our wiki Linux LDAP Howto

[necio_online]

Hey! Good to see fuwiki in Slashdot. I'll follow this howto, I really want to learn how to:

* Set up an LDAP server with replication and use it.
* Set up spamassasin (very well).

I will learn this year.

Rock on :)

Comments to all

[Cybert4]

Well, you all make good points. But still, for a just-for-fun bulletin board, it may be OK. Hashing is not a problem with few users and a fast system.

LDAP/Postgres?

[Doc Ruby]

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?

Re:LDAP/Postgres?

[Erik Hollensbe]

If you don't understand why a unified interface to something like a network-available user database is useful, refrain from commenting on it.

Re:LDAP/Postgres?

[Doc Ruby]

I said LDAP was cool, and said how useful I think it is. Then I detailed how much more useful it would be with an integrated datastore open to the rest of the apps.

If you don't understand how a unified data layer for a network-available query interface is useful, refrain from commenting on it.

Re:LDAP/Postgres?

[Schraegstrichpunkt]

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.

Why would you want to port a hierarchical database to a relational DBMS?

Re:LDAP/Postgres?

[T-Ranger]

Its all linear store, somewhere.

Re:LDAP/Postgres?

[Doc Ruby]

Because I want the hierarchical ID data easily accessible to joins against other, more relational data. And I don't want the dependency on multiple DBs that might require more skills or even extra DBAs. While getting all the management features (replication, clustering, transactions) of an RDBMS.

Re:LDAP/Postgres?

[Schraegstrichpunkt]

Ah. Makes sense.

Re:LDAP/Postgres?

[Anonymous Coward]

LDAP and relational databases serve different purposes. LDAP is a hierarichal databases; few relational databases, including PostgreSQL, are. The impedance mismatch makes calculating the responses to LDAP queries in a relational database inefficient. I'm a huge PostgreSQL fan myself, but it's just not the right tool for this job. There's some possibility that recent work on tree structures using GIST would help PostgreSQL in this regard. Compiling LDAP with SQL support (including PostgreSQL) is an option (the fact that you don't know this makes me wonder if you've ever used LDAP at all), so why don't you just give it a shot, and let everyone know what you learn.

Re:LDAP/Postgres?

[Doc Ruby]

Actually I'm using LDAP all day long, as a user of an installation that runs against BDB, as I mentioned. The discussions of porting to MySQL didn't inform me much, as I've waited for (and encouraged) better experts to get it working on Postgres, which I prefer. Nor did the Postgres compile option inform much, because there isn't enough doc on the Web describing its tested use against a real Postgres. That's the point at which I use options: when there's a community of people which has already reported common errors and solutions.

The fact that there is a Pg option and many HOWTOs for MySQL LDAP datastores shows that relational and hierarchical databases are complementary, or at least compatible, systems for LDAP. The GIST tree structures you mention are only the latest in many schemas which map hierarchical to relational. As I mentioned, BDB is faster in the purely hierarchical operations than Pg, but of course all the relational ops I need find BDB performing at "0%". And the other connectivity/management benefits of my existing Pg operations of course also require connection.

I'm going to pull this off, at least once I'm not the first pioneer facing the arrows. Hopefully next time someone else asks about it on Slashdot I'll have more answers than questions.

Re:LDAP/Postgres?

[Skjellifetti]

If you don't understand why a unified backend datastore of user info with multiple interfaces for accessing it is useful, please refrain from commenting on it.

Re:LDAP/Postgres?

[Erik Hollensbe]

Actually, I don't. That's what a "bridge" is for, although commonly I'll just use an application that is more robust.

Of course, if you prefer to use clients that use a proprietary communication protocol as opposed to something that's well documented and fairly standardized, just make sure the gun is loaded when you aim down and fire.

Re:LDAP/Postgres?

[Skjellifetti]

A user datastore is just one small part of many applications. While LDAP is quite useful for accessing the user (and other similar) info, often that user info becomes even more useful when it can be directly and easily tied to other data. SQL statements that bypass the LDAP protocol entirely are one example of a well documented interface that has a well documented standard syntax. For some purposes, you want to access the data through an LDAP interface (e.g. authentication) while for others (e.g. report generation) the SQL interface may be superior. One user datastore with multiple interfaces for multiple purposes can be better than demanding that all accesses to that datastore go through a single interface that may not have anticipated all possible application requirements.

Re:LDAP/Postgres?

[Erik Hollensbe]

As long as you have shelled out copious amounts of cash for UnixODBC or all your applications support SQL-network-protocol-flavor-of-the-month. Please read posts before replying.

Re:LDAP/Postgres?

[Skjellifetti]

For SQL, the underlying network protocol is usually irrelevent. Swapping one JDBC/Perl/C lib for a given RDBMS vs another is usually trivial. But that problem is overrated since I have yet to see any of the Fortune 100 firms I've worked for actually decide to drop Oracle for DB2 or verse visa.

Stop thinking of LDAP as a wire protocol. Think of it as a DBMS view. LDAP provides one small slice of corporate data. I want to be able to trivially integrate that slice with other corporate data for which the LDAP interface may be too inefficient or incomplete.

Please understand requirements before replying.

Great - I already use - BUT....

[Anonymous Coward]

Where is easy to follow details to get your mobile clients working with disconnected logins ?

To have nice Windows replacements, log on when connected to the network, and then go away on the road, and log-on with that cached user-name and password...

Pam-ccreds apparently does it, but no-where that I can find either a nice how-to, or something where I don't have to manually configure the files EVERY bloody laptop install.

Easy, out-of-the box Disconected logins is a killer "MUST" for Linux/BSD to overcome relience on Windows laptops.

AM

Re:Great - I already use - BUT....

[19thNervousBreakdown]

I followed this guide: Implementing a Disconnected Authentication and PDC/BDC Relationships Using Samba and OpenLDAP.

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 any changes made when disconnected are pushed through as soon as the connection is re-established. It should be fairly easy to make up a script that copies over the configuration to a laptop, the hard part will be bringing down the LDAP server to add the slave. Your best bet is probably to have a slave server that does nothing but replicate to other slaves, that way you don't hang half the network an crash the other half.

I've been running LDAP auth at home for a couple years, and just set up the disconnected auth recently, so I don't know much about that specifically, but if you're going to set up LDAP auth in general, be prepared to do a lot of "crunch" work. An update will frequently change something that screws up authentication, and sometimes it's an hour or more before I can find the solution. Don't put root on it, and have a "machine" account that can su if you have SSH locked to not allow root logins. I can't imagine doing that in a production environment, which means testing, which means work (less than fucking something up though), and your test eventually won't catch something anyway (more work). Hopefully someday this stuff will be stable, NIS is a joke, and I don't know of any other distributed auth for Linux that includes groups.

One more thing, with the newer NSS_LDAP, make sure to set your bind_policy to "soft". I can't figure out why in the hell they changed that, but if you don't your machine will more than likely hang on boot (waits for the LDAP server before network is up. Stupid.)

Re:Great - I already use - BUT....

[Anonymous Coward]

nice documentation...

'cept why the bloody hell would I want to have every laptop in my organisation being an LDAP slave server ?

so every time my users take their laptops on a conference, they have the entire LDAP directory on their laptops .....

that is just ludicrous, surely to goodness there is a "better" option, like cache the users that have logged onto that machine, and if no ldap server is about to talk to, use the cached credentials, in the same/similar way to Windoze. (try logging onto a Windows machine, off the network, with an account that has never been used on that machine, it will fail, and that is "A Good Thing")

Re:Great - I already use - BUT....

[19thNervousBreakdown]

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 protocol. But hey, it works for me at home.

SPLAT - Scalable Periodic LDAP Attribute Transmogr

[lizthegrey]

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.

Authentication with Apache Directory Server?

[Kunta Kinte]

The article uses OpenLDAP as the LDAP server. Has anyone got this to work using the Apache Directory Server?

Host-based control

[sparr0w]

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

Installing the software never was the problem

[wertarbyte]

I tried to migrate an existing file and NIS based system to LDAP - I had no problem with setting up PAM and openldap, however I did not find a replacement for the Debian adduser program, so I would have to hack my own user management tools. Does anyone know an alternative to this?

Re:Installing the software never was the problem

[Anonymous Coward]

It's called "cpu" in Debian.

Re:Installing the software never was the problem

[Anonymous Coward]

Where i work, newbie tech support guys use phpldapadmin, the more "advanced" techies use home made scripts. Creating such scripts is not hard (i don't have access to them right now), all you have to do is create a file where user's dn and attributes are described and call ldapadd.

Re:Installing the software never was the problem

[wertarbyte]

Sure, but by creating a homebrew script, I would have to reinvent useradd - search for a free UID, search for a free GID, do some sanity checks, create the home directory - kind of annoying if the only thing I wish to do is keeping useradd from editing /etc/(passwd|group|shadow) and instead accessing the LDAP directory.

Nested groups

[Yag]

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

LDAP is NOT an authentication service

[KidSock]

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.

Re:LDAP is NOT an authentication service

[Watson Ladd]

They are using a SASL bind so Kerberos is being used. While it isn't an authentication service, it does let you make machines and user enviroments orthogonal. Every user has the same enviroment on whatever machine they pick that day.

Re:LDAP is NOT an authentication service

[finkployd]

It is so refreshing to hear someone else say this, the number of admins who seem to think LDAP stands for Lightwight Directory Authentication Protocol is scary. LDAP absolutely sucks for authN. Authenticate with something real like Kerberos and then set up your services to use LDAP to get their group/attribute information to authorization purposes.

Finkployd

Re:LDAP is NOT an authentication service

[Anonymous Coward]

In my opinion there is little point in LDAP outside of authentication and basic user registries as you need lots of extensions to support any serious data. Compared to a modern RDBMS it's a lightweight joke which happens to have several very useful nich applications.

What on earth is wrong with using SASL/GSSAPI for authentication? I'd really like to know? :)

Re:LDAP is NOT an authentication service

[finkployd]

What on earth is wrong with using SASL/GSSAPI for authentication? I'd really like to know? :)

Straight Kerberos is a lot easier (if you do SASL right-you are doing a lot of PKI setup and management), and far more secure (password never leaves the client, encrypted or not).

LDAP is ideal as a user registry, just let the applications call it to get user attributes and groups after validating the kerberos credentials presented to them. Then you have the added benefit of not needing to so strongly secure LDAP (which is not trivial, and pretty much an afterthought hack anyway)

Finkployd

Re:LDAP is NOT an authentication service

[jimicus]

Second, if you are going to use LDAP like this, make sure the bind is being conducted over SSL

You've missed something. If you're using LDAP as the backend authentication mechanism for anything, you also need to ensure that the services that are using LDAP as their authentication mechanism communicate on a secure connection as well, or you're back to square one.

and somewhat pointless if you already have Kerberos setup

What does Kerberos get you over and above LDAP+SASL?

Re:LDAP is NOT an authentication service

[KidSock]

What does Kerberos get you over and above LDAP+SASL?

SASL just allows you to negotiate an authentication mechanism and confidentiality / integrity options. LDAP uses SASL to negotiate either Kerberos, digest, NTLM, plain, etc. There are many possible mechanims. So SASL by itself gives you nothing. If you're negtiating Kerberos then you're ok. But if you have Kerberos then there's no point in using LDAP+Kerberos as an authentication service since you can use Kerberos directly (e.g. mod_kerb_auth module for Apache uses GSSAPI w/ Kerberos for web clients).

Re:LDAP is NOT an authentication service

[jimicus]

I'm coming from the other direction. I've already got LDAP, and a bunch of services which use it over SSL as an authentication backend.

I'm therefore not too concerned about the LDAP connection being sniffed, but there's not a lot of point in securing the LDAP connection if you then use the data exchanged in the SSL-secured connection to authenticate over an unencrypted channel (eg. plain IMAP).

Seems to me that in my case, I'd be better off dedicating my time to dropping support for any services which use LDAP as the authentication backend but are themselves unencrypted.

I pride myself ...

[Zombie Ryushu]

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.

Re:I pride myself ...

[Anonymous Coward]

Ok, I really really want to know... how did you get Samba3 to use Kerberos. I'm down to two sets of Passwords. Windows logins (stored in LDAP), and Kerberos (Everything else - mail, Unix logins, CVS, SSH, etc).

Also, I'm curious, what connectors did you use to tie in DNS and DHCP?

Re:I pride myself ...

[JohnsonWax]

I think with the exception of eGroupware and RADIUS, Apple's OpenDirectory supports all of that out-of-the box. RADIUS is coming in 10.5.

Not trying to minimize your effort, but there are others with the same mindset is all.

You Fail It

[Anonymous Coward]

wa"lk up to a play Usenet posts. aNd abroad for

Exercise in futility

[Spazmania]

In all but the largest unix/linux installations, managing the users in LDAP is an exercise in futility. When you're all done you have something that's still more difficult to manage than adduser/deluser on the individual machines. Worse, its now brittle: the LDAP server breaks and now every unix box in the system fails at every task that requires a UID to user mapping.

Far more useful is managing the users locally but authenticating them (i.e. checking their password) via LDAP. For example, in an enterprise you might want to piggyback the Windows Active Directory passwords or the IBM/Lotus Domino passwords. This turns out to be trivial to do via a PAM module but the LDAP connectors don't seem to exist. They all want to pull the crypt or MD5 password from LDAP and then compute it instead of binding against LDAP with the given credentials. Every time I want to do this I find myself having to write another PAM module like http://bill.herrin.us/freebies/notesldap.tar.gz

Re:Exercise in futility

[Tweekster]

It seems that every other post is quite to the contrary...

Re:Exercise in futility

[Spazmania]

Meh. If Linux LDAP becomes widely accepted in the enterprise I'm sure I'll find the grace to be embarrassed. 'Till then there's a saying that fits:

If fifty million people say a foolish thing, it is still a foolish thing.

Reliability

[Gaima]

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

Re:Reliability

[myowntrueself]

But, what happens when the LDAP service isn't available?

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.

Re:Reliability

[19thNervousBreakdown]

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:Reliability

[myowntrueself]

Just make sure there's an enabled root account in your /etc/(passwd|shadow),

Yep, there is.

make sure pam_unix is enabled in your /etc/pam.d/(system.auth|login),

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 /etc/nsswitch.conf has a line that says "passwd: files ldap"

It did say this:
passwd: compat ldap

which I've changed to:
passwd: files compat ldap

Would that be right?

(and thanks for the pointers)

Re:Reliability

[19thNervousBreakdown]

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:

auth required pam_env.so
auth sufficient pam_unix.so likeauth nullok
auth sufficient pam_ldap.so use_first_pass
auth required pam_deny.so

account sufficient pam_unix.so
account sufficient pam_ldap.so
account required pam_deny.so

password required pam_cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2 retry=3
password sufficient pam_unix.so nullok md5 shadow use_authtok
password sufficient pam_ldap.so use_authtok
password required pam_deny.so

session required pam_limits.so
session required pam_unix.so
session required pam_mkhomedir.so skel=/etc/skel umask=0077
session optional pam_ldap.so

Basically, make sure that pam_unix is before pam_ldap, that they are both "sufficient", and put a required pam_deny.so at the end, and your passwd should override any ldap. Also make sure to check both /etc/pam.d/* and /etc/pam.conf. pam.d should override pam.conf, but it doesn't hurt to check. The pam.d dir will probably have different files for different services, so make sure to check ssh if you're having a problem with that, login if it's with console logins, and so on. They might include other files, but whoever edited them might have changed stuff. HTH.

Re:Reliability

[timbo234]

We used to have this same problem with some RHEL3 machines where even though they had valid local root accounts when the LDAP server went down nothing could login. The console logins would hang for ages before finally timing out. We followed steps which were very similar if not the same as yours on one of the Redhat support pages to fix the issue but it still didn't work.
Upgrading the machines to RHEL4 fixed it. Very strange because it should have worked in 3 too with the correct nsswitch and pam config.

LDAP is a pain in the arse

[SnapperHead]

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.

Re:LDAP is a pain in the arse

[unsigned integer]

Yeah, no kidding. Total pain in the ass.

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 ... thus giving me finally a SSO environment where I didn't have to maintain numerous passwd files, etc. I went from knowing nothing about LDAP, to at least being able to set it all up. Even with the PADL tools things took a while. Setting up all the SSL certs ... self-signing etc. Incorrect examples and docs from people online. Yeah, then try to make Solaris play well with OpenLDAP ... all sorts of little hacks involved in that. Then enjoy the fun of getting Apache up and running and properly using LDAP. Lots of little things that can go wrong there, unless you follow things to a T. It was like two steps forward, 1 step back all the friggen time. Would have been probably 10x easier had I just been a pure linux shop ...

I must say, despite all the pain, it was absolutely beautiful when it was working. I even managed to get all the auto mount maps working as well ... the only thing I didn't get a chance (before I left) was to get our NetApp using LDAP. Another thing that "should have just worked" but didn't. Much like everything else along the road of LDAP.

This rocks

[PenguinX]

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.

You forgot to mention.

[Anonymous Coward]

Samba 4. When it lands you will be able to upgrade without problem and have all the support of LDAP and Equal to 2003 domain controllers everywhere. Samba 4 is even working on Vista domain controls.

Basicly linux is catching up fast.

LDAP and DNS/Bind/Samba

[Zombie Ryushu]

Bind and dhcpd come with their own schemas in OprnLDAP. The Bind-sdb Schema is known as dnszone.schema, and dhcp.schema Then all you do is change the "file" commands in named.conf to say "database" and give them a DN Suffix. ldap-server "localhost"; ldap-port 389; ldap-username "cn=DHCP User, dc=ntelos, dc=net"; ldap-password "blah"; ldap-base-dn "dc=ntelos, dc=net"; ldap-method dynamic; ldap-debug-file "/var/log/dhcp-ldap-startup.log"; This goes in dhcpd.conf, it connects DHCP to LDAP. (Except put your correct DN information in here. Samba with Kerberos is rather simple. Add cifs/ entries for all of your servers attached in the KDC, distribute copies of the new keytab. Then, add 'use kerberos keytab = Yes' to Samba, and realm = MYREALM to smb.conf Assuming everything is peachy, you should be able to test the bind with smbclient -kd 3 //Server/share, and watch the Kerberos SPNEGO take place,.

As was already mentioned.....

[FlyingGuy]

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!

Why LDAP?

[NaCh0]

For small/medium sized shops, are there any benefits of using LDAP over MySQL for authentication tasks?

I'm curious because we're already running mysqld for web apps and postfix maps. Is it worth running another service and all of the administrative overhead? Obviously the answer may be "it depends." What should I consider in making the decision?

Re:Why LDAP?

[DragonTHC]

you should consider the benefits of LDAP being less resource overhead for mysql.

this is good if you've got a lot of robust web apps with intensive reads.

as for integration, apache, mysql and php all have ldap interfaces.

plus ldap can authenticate over SSL and TLS.

with LDAP being used instead of MySQL, there is also less of a chance of your users being comprimised in the event of a cross-site scripting snafu.

Welcome to 1996

[dave562]

See the subject.

we did this in PHP

[Anonymous Coward]

it was like a whole 5 lines of code

Got any good HOWTOs?

[Nurgled]

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 started" HOWTO for doing Kerberos auth both through PAM and from my own software? Also, I was under the impression that under Kerberos you're not supposed to share your password around, but instead present tickets; how does that work in an app that just accepts a username and password? (Like, say, a Jabber server, or login at the Linux console, or when doing HTTP auth.)

Re:Got any good HOWTOs?

[lachlan76]

My understanding is that the username and password is used to get a ticket from a ticket server, which is then presented to the service which is accessed by the user. But then again, I have never put this into practice, so I cannot be sure.

Why is this slashdot material?

[Argon]

The enabling software pam_ldap and nss_ldap have been around for years. I worked on a project in Novell implementing similar functionality using NDS six years back.

NIS gateway

[teg]

Does anyone here have any experience with NIS gateways to LDAP servers, so existing infrastructure can continue to work?

Re:LDAP/Postgres? - It's the throughput.

[chathamhouse]

I have a love/hate relationship with Berkeley DB. This comment applies to OpenLDAP.

It's moody (DB_CONFIG anyone?), it's fast, gets reliable somewhere after many minor releases (started to trust 4.2.52, 4.3.25, ...), and if it gets corrupted, you'd better have a backup.

I agree with your point, in theory - RDBMS datastores could offer a lot of flexibility, and eliminate many data redundancy complications. In small-ish implementations, you may be fine.

The implementations I've seen are a different animal.

1. Berkeley DB is fast. When you're issuing a lot of reads(3000+/sec/replica), across what is already a large farm (20+) of replicas, BDB means less hardware, hence far less cost than any RDBMS datastore.
2. RDBMS backends for OpenLDAP aren't as well tested. This matters when your database drives your email, authentication, authorization, and address books.

But I agree that the RDBMS should be the _authoritative_ data store. It should populate your LDAP directory. Yes, that's easier said than done. The benefits of this are great though - flexible lower throughput data for the applications that can use it, low data redundancy ( if you've designed both your RDBMS and LDAP schemas properly), blazing read speeds, and excellent service availability.

That has nothing to do with root passwords.

[jotaeleemeese]

Caching is a convenience to increase speed and diminish load in the servers.

Caching is not intended as a backup mechanism.

YOur root passwrod should *always* be in the local machine.

Also if you fail to secure access to your name service servers, and then proceed to put your root passwords in the name service, you could as well hand over the root password to a hacker...

NIS is useless....

[jotaeleemeese]

.... al data is transfered in clear text.

I believe LDAP+ Kerberos that is not the case, but I am not familiar with it so I can't comment.

Re:LDAP/Postgres? - It's the throughput.

[Doc Ruby]

I agree. LDAP is a protocol, and interface between ID data and applications. BDB is high performance, optimized for the hierarchical data model of LDAP data. A local hierarchical cache in BDB is the right way to support the high transaction volume in LDAP transactions. So a BDB datamart against an RDBMS datastore is the best compromise for required performance, flexibility, manageability and access to applications outside the LDAP interface.

That means extra HW and complexity. The extra HW cost is worth it if the requirements can't be met by the BDB, as in joins to existing relational data, because it's still the cheapest alternative. The extra complexity of maintaining parallel BDB and RDBMS datasets with bidirectional consistency is a bigger question. I think this architecture won't really be fully worked out until people with expertise in write-thru caches apply their techniques to this device for both performance and integrity, without sacrificing the rest of the features.

Good for OVPN, etc, but questions!

[lawaetf1]

OpenLDAP (or Fedora Directory Server, if you will), is an excellent choice for things like back-ending OpenVPN installations. OpenVPN + customized OpenVPN-Win32-GUI + Fedora DS = no more commercial client VPN.

Questions for the slashdot crowd..

- How do you make multi-master replication useful for clients that only query one server? Like if you choose to use LDAP for linux authentication ("authconfig") how do you deal with having your primary server fail? I know the usual stuff like having a virtual IP, etc, but was wondering if someone had come up with any hacks to have the clients know to try a different LDAP repository.

- How do you approach UID conformity across a spread of organically grown servers? Take your typical startup, for instance, where people having been indiscriminately creating local users via "useradd" with little regard for varying UIDs. Are there any best practices for convergence when moving to LDAP outside of manually logging into a system, booting the user offline, changing the UID, then "find / " throughout the filesystem to chown the files?

There are tons of alternatives

[stikves]

LDAP authentication in Linux is pretty mature now, and there are many alternatives you can choose according to your needs. They've already been discusses above, I'll try to summarize.

If you just want an quick and easy solution with good compatibility, Active Directory is your friend. It stores all the user, machine and configuration information in LDAP, supports authentication via Kerberos and discovery by using DNS. And Windows Server 2003 R2 brought an NIS server, which you can use if you have some old (probably Sun) boxes lying around.

If you do not like Microsoft, you can choose Novell's NDS. They have a very good history in directory space. However NDS does not run (or I could not easily get it to) on "unspported" new Linux releases (like CentOS/RedHat 4.3).

If you want to go open source you may prefer Fedora Directory Server. It's solid, it has many features (4 way multi master replication, GUI administration, live backups, etc), and you can easily migrate your old passwords to it. However if combining with Kerberos, you'll need to sacrifise those passwords (and a lot of time reading kerberos documentation).

You can also choose Sun's directory server (which shares roots with FDS), or Apache DS (which has the most functionality, yet not stable enough).

I'd recommend against OpenLDAP, unless for maintaining legacy systems. Access Control information is store in configuration files as regular expressions. It's both less secure (you may easily make mistakes), and you need to restart the server when changing ACLs. It also has less features than any other alternative. (They had helped the community for a long time, but I guess they've served their purpose).

Any correction is welcome, so I can fix our current system (FDS).