Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

LDAP Authentication in Linux

ScuttleMonkey posted about 8 years ago | from the roadmaps dept.

189

hausmasta writes "HowtoForge has published a walkthrough to show you how to store your users in LDAP and authenticate some of the services against it. It will not show how to install particular packages, as it is distribution/system dependent, instead it will focus on pure configuration of all components needed to have LDAP authentication/storage of users. The howto assumes that you are migrating from a regular passwd/shadow authentication, but it is also suitable for people who do it from scratch."

cancel ×

189 comments

Sorry! There are no comments related to the filter you selected.

fuuuck all you hoes (-1, Troll)

Anonymous Coward | about 8 years ago | (#16033743)

fuuuuuck all you hoes

Re:fuuuck all you hoes (-1, Offtopic)

Anonymous Coward | about 8 years ago | (#16033763)

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

Faux Scotsman unwittingly flashes gay hike group! (-1, Offtopic)

Anonymous Coward | about 8 years ago | (#16033754)

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

Why would one want to do this? (-1)

penix1 (722987) | about 8 years ago | (#16033756)

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? (1)

Timesprout (579035) | about 8 years ago | (#16033769)

Because you might like to gain penetration in enterprise environments.

Re:Why would one want to do this? (0, Flamebait)

penix1 (722987) | about 8 years ago | (#16033777)

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

B.

Re:Why would one want to do this? (0)

Anonymous Coward | about 8 years ago | (#16033983)

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.

So speaks (0, Flamebait)

Colin Smith (2679) | about 8 years ago | (#16033772)

A "power" user. *sigh*

 

Re:Why would one want to do this? (3, Interesting)

Anonymous Coward | about 8 years ago | (#16033789)

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? (1)

ScriptedReplay (908196) | about 8 years ago | (#16034073)

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? (2, Insightful)

jgrahn (181062) | about 8 years ago | (#16034193)

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? (1)

allenw (33234) | about 8 years ago | (#16034205)

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? (1, Insightful)

Anonymous Coward | about 8 years ago | (#16034222)

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? (3, Informative)

Anonymous Coward | about 8 years ago | (#16033813)

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? (5, Informative)

antlope (926281) | about 8 years ago | (#16033819)

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.se]
NordicEdge AB

Re:Why would one want to do this? (1)

whoever57 (658626) | about 8 years ago | (#16033913)

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? (2, Informative)

ximenes (10) | about 8 years ago | (#16033933)

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? (4, Informative)

antlope (926281) | about 8 years ago | (#16033945)

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 [linuxjournal.com]
There are many other sources of information on this out there.

Anthony Whitehead
NordicEdge AB

Re:Why would one want to do this? (1)

allenw (33234) | about 8 years ago | (#16034197)

... 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? (3, Informative)

charlesnw (843045) | about 8 years ago | (#16033824)

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? (2, Insightful)

fm6 (162816) | about 8 years ago | (#16033841)

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? (4, Interesting)

rmallico (831443) | about 8 years ago | (#16034066)

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 [quest.com] or http://www.centrify.com/ [centrify.com] for some good info on two companies that are doing this for the *nix world now...

 

Re:Why would one want to do this? (1)

finkployd (12902) | about 8 years ago | (#16034419)

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? (1)

MrResistor (120588) | about 8 years ago | (#16033891)

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? (0)

Anonymous Coward | about 8 years ago | (#16034019)

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

Re:Why would one want to do this? (1)

mojinoman (674418) | about 8 years ago | (#16033894)

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? (2, Insightful)

LinuxDon (925232) | about 8 years ago | (#16033927)

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? (1)

tek.net-ium (841449) | about 8 years ago | (#16033995)

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? (0)

Anonymous Coward | about 8 years ago | (#16034167)

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? (1)

PlusFiveTroll (754249) | about 8 years ago | (#16034198)

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? (2, Interesting)

Schraegstrichpunkt (931443) | about 8 years ago | (#16034370)

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? (3, Insightful)

myowntrueself (607117) | about 8 years ago | (#16034357)

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? (1, Interesting)

Anonymous Coward | about 8 years ago | (#16033929)

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? (0)

Anonymous Coward | about 8 years ago | (#16034024)

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? (1)

arivanov (12034) | about 8 years ago | (#16034162)

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? (0, Redundant)

ChrisA90278 (905188) | about 8 years ago | (#16034346)

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? (0)

Anonymous Coward | about 8 years ago | (#16034544)

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

A question only slashdotters can answer (-1, Troll)

Anonymous Coward | about 8 years ago | (#16033780)

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

Re:A question only slashdotters can answer (1)

LiquidCoooled (634315) | about 8 years ago | (#16033898)

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

Re:A question only slashdotters can answer (1)

cdcarter (822001) | about 8 years ago | (#16034065)

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 (0)

Anonymous Coward | about 8 years ago | (#16034431)

What's the first sign of AIDS?

A pounding sensation in the ass.

Proofreading (0, Offtopic)

Vlad_the_Inhaler (32958) | about 8 years ago | (#16033797)

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

Password only (1)

Cybert4 (994278) | about 8 years ago | (#16033810)

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 (4, Interesting)

Imagix (695350) | about 8 years ago | (#16033852)

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 (1)

antlope (926281) | about 8 years ago | (#16033856)

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 (3, Insightful)

legoburner (702695) | about 8 years ago | (#16033861)

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 (1)

rhizome (115711) | about 8 years ago | (#16033882)

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 (1)

Cybert4 (994278) | about 8 years ago | (#16033899)

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

Re:Password only (1)

dotgain (630123) | about 8 years ago | (#16034118)

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

Re:Password only (1)

rhizome (115711) | about 8 years ago | (#16034178)

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 (2, Insightful)

David McBride (183571) | about 8 years ago | (#16033896)

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 (0)

Anonymous Coward | about 8 years ago | (#16033910)

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

Comments to all (1)

Cybert4 (994278) | about 8 years ago | (#16033940)

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.

Re:Password only (1)

VGPowerlord (621254) | about 8 years ago | (#16034260)

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

Ldap on its own is not enough (3, Interesting)

Anonymous Coward | about 8 years ago | (#16033842)

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 (1)

bitflusher (853768) | about 8 years ago | (#16034000)

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

Re:Ldap on its own is not enough (1)

killjoe (766577) | about 8 years ago | (#16034136)

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 (1)

Schraegstrichpunkt (931443) | about 8 years ago | (#16034380)

Vendor lock is always bad.

Not if you're the vendor!

Re:Ldap on its own is not enough (1)

killjoe (766577) | about 8 years ago | (#16034420)

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

Re:Ldap on its own is not enough (2, Informative)

finkployd (12902) | about 8 years ago | (#16034447)

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

I always wondered... (4, Interesting)

Lispy (136512) | about 8 years ago | (#16033878)

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... (2, Interesting)

antlope (926281) | about 8 years ago | (#16033911)

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

Lispy (136512) | about 8 years ago | (#16033928)

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... (4, Informative)

guruevi (827432) | about 8 years ago | (#16033978)

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... (3, Informative)

spauldo (118058) | about 8 years ago | (#16034304)

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 [wikipedia.org] for more info. Microsoft was more or less copying Novell, not any of the UNIX vendors (who were mostly still using NIS and friends when active directory came out).

Re:I always wondered... (2, Interesting)

93 Escort Wagon (326346) | about 8 years ago | (#16034124)

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

spauldo (118058) | about 8 years ago | (#16034327)

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... (4, Insightful)

Wylfing (144940) | about 8 years ago | (#16034140)

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

Maybe you have a brain the size of this guy [wikipedia.org] . I don't know. I have tried a few times in the past to set up LDAP and all the documentation is written by space-aliens as far as I can tell. I can't even penetrate the language used, let alone follow the steps prescribed.

This Fine Article is no different. After about the 3rd sentence I have no idea what is being described, because we're already talking about "a replication" but this has not been defined. It's all like that: undefined terms and references, and exhortations to read the ldap man pages if you want to understand what is going on. The man pages are also full of undefined terms and references, except they are presented in highly-compact text blocks with bad grammar.

LDAP is niche because it is so freaking impossible to figure out. That's why.

Re:I always wondered... (1)

19thNervousBreakdown (768619) | about 8 years ago | (#16034453)

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.

Other options (2, Informative)

digitalhermit (113459) | about 8 years ago | (#16033879)

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 (2, Informative)

hethopus (806708) | about 8 years ago | (#16033999)

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

Re:Other options (1)

thanasakis (225405) | about 8 years ago | (#16034021)

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

Re:Other options (0)

Anonymous Coward | about 8 years ago | (#16034033)

For GNOME users, there is LAT [mmgsecurity.com] (LDAP Administration Tool)

Re:Other options (1)

Schraegstrichpunkt (931443) | about 8 years ago | (#16034397)

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

LDAP for everything (4, Interesting)

linuxkrn (635044) | about 8 years ago | (#16033909)

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

Our wiki Linux LDAP Howto (3, Informative)

Anonymous Coward | about 8 years ago | (#16033931)

I figured this was as good time as any to point out our relatively complete Linux LDAP HOWTO [freaks-unidos.net] , 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.

LDAP/Postgres? (2, Insightful)

Doc Ruby (173196) | about 8 years ago | (#16033960)

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 [google.com] seem inconclusive, untested. And some of the commercial products that advertise the feature don't even respond to emails to sales departments asking about the cutover.

As long as Slashdot is staring down "LDAP Auth in Linux", how about taking it to (and over) the Postgres wall?

Re:LDAP/Postgres? (1)

Erik Hollensbe (808) | about 8 years ago | (#16034057)

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? (1)

Doc Ruby (173196) | about 8 years ago | (#16034186)

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? (1)

Schraegstrichpunkt (931443) | about 8 years ago | (#16034404)

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?

Great - I already use - BUT.... (0)

Anonymous Coward | about 8 years ago | (#16033989)

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

19thNervousBreakdown (768619) | about 8 years ago | (#16034106)

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

The only problem with it is, and this is only on my laptop (it's supposed to work), is changing passwords has to be done on the master LDAP server. Has something to do with update referrals, maybe PAM_LDAP doesn't follow them, but right now it's not a big issue for me so I haven't really looked into it.

Other than that, it works great (when it works). Replication goes through immedately, and 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.... (0)

Anonymous Coward | about 8 years ago | (#16034286)

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

19thNervousBreakdown (768619) | about 8 years ago | (#16034322)

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 (3, Informative)

lizthegrey (991606) | about 8 years ago | (#16034005)

https://dpw.threerings.net/projects/splat/ [threerings.net] (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? (1)

Kunta Kinte (323399) | about 8 years ago | (#16034040)

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

Host-based control (2, Informative)

sparr0w (902739) | about 8 years ago | (#16034045)

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 (1)

wertarbyte (811674) | about 8 years ago | (#16034051)

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?

Nested groups (3, Interesting)

Yag (537766) | about 8 years ago | (#16034053)

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 (3, Insightful)

KidSock (150684) | about 8 years ago | (#16034141)

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 (1)

Watson Ladd (955755) | about 8 years ago | (#16034203)

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 (1)

finkployd (12902) | about 8 years ago | (#16034428)

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

I pride myself ... (4, Interesting)

Zombie Ryushu (803103) | about 8 years ago | (#16034161)

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

Anonymous Coward | about 8 years ago | (#16034475)

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?

You Fail It (-1, Flamebait)

Anonymous Coward | about 8 years ago | (#16034204)

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

Exercise in futility (1)

Spazmania (174582) | about 8 years ago | (#16034236)

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 [herrin.us]

Reliability (2, Interesting)

Gaima (174551) | about 8 years ago | (#16034279)

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 [padl.com] (I don't know if there are any other alternatives, nor do I know if that actually work, sounds like they do though).

Re:Reliability (2, Interesting)

myowntrueself (607117) | about 8 years ago | (#16034319)

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 (1)

19thNervousBreakdown (768619) | about 8 years ago | (#16034469)

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.

LDAP is a pain in the arse (2, Interesting)

SnapperHead (178050) | about 8 years ago | (#16034336)

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.
 
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>