LDAP Discussions: AD, OpenLDAP, Samba, NDS, PAM, NSS, RADIUS, Kerberos, etc.

This page has discussions about LDAP and related technologies, collected from Slashdot, Reddit and other forums. Some of these discussions have been excerpted and lightly edited for clarity.
LDAP is really just a database-access protocol, with security and distributed-system features built in. I believe RFC 3377 is the most recent relevant standard. Most LDAP directories are used to keep track of people; therefore there is an InternetOrgPerson type which (if I remember rightly) has the following attributes by default: However, LDAP types are extensible, so you could create a new type to represent employees, inventory, or even projects, or you could extend an existing type. For instance, you might want to add some of the following to InternetOrgPerson (if they're not already there): It's even possible to use an SQL or legacy-system database as a backend for OpenLDAP with some custom coding, although I'm sure a lot of people who use it don't bother. So that's what's in the directory. You might still ask, "what is it used for?" Firstly, Windows, Netware, Solaris and Linux can all be told to get their login information from an LDAP directory. This means that (if it works) someone only needs one account in an organization, that their Windows password is automatically the same as their Unix password, etc. It does not mean that they need to use the same home directory on all systems; but home directories can be automatically created by login scripts. NIS+ was a Unix-only way to distribute just the information found in /etc/passwd; LDAP is cross-platform. Secondly, some E-mail clients (specifically Netscape, its derivatives, and Outlook; I don't have experience to speak for others) can treat an LDAP directory as an extension of the address-book. That sure beats running down the hall and referring to a printed list every time you want to e-mail someone or call them on the phone and only remember their name.
Orignal poster wrote: If this is a serious LDAP deployment, don't even bother with OpenLDAP. Seriously. Heh, I've been coming to this conclusion lately as well. Anyone have any suggestions for an LDAP server I can expect to work, and will handle replication without falling on it's ***?
Book Reviews: Deploying OpenLDAP Overall, I would say that I left this book with little new information. People that are just now installing OpenLDAP may find the book beneficial, but I really didn't see any material that stood out. My personal belief is that this "Deploying OpenLDAP" needs to provide far more troubleshooting and example deployment scenarios and less regurgitation of manpages and HOWTOs
> Novell eDirectory (formerly NDS) is a technically brilliant tour de force. It's a really amazing package; multimaster replication; multimaster schema changes; extremely efficient over slow links, unbelieveably secure (and has some really sophisicated extensible authentication systems), works on every platform under the sun, the APIs & developer tools are extremely mature, scales like crazy and runs super-fast, and like the previous poster said, it's CHEAP. Anything else, to me, is a weak imitation--but I guess as long as your directory speaks LDAP all is well. Unless it's Active Directory--which is really just a set of "nested" domains with automated trust relationships. And that part makes it a huge pain in the ass to maintain. (The trick to this is to throw an AD domain into eDirectory and have eDirectory manage the whole thing - it is so flexible it can manage _other directories._)
> In many ways eDirectory is far more sophisticated. It is more close to a true X500 directory and it has some very sophisticated tools for data replication and management. The admin console is streets ahead of the old Netscape Java Console for starters and the APIs are very well developed. It is very easy do do operations such as prune and graft on the Novell Directory than on the typical standalone LDAP directories (Open LDAP, SUN ONE) where you have to essentially delete and recreate the entry rather than just modify the base DN. One key differentiator is replication strategy. eDirectory and Microsoft AD are genuine multi-master directories, you can configure them to accept updates anywhere and the data then replicates among the cloud of replicated servers. Open LDAP and Netscape's LDAP are have pyramid structure replication, you update a master, it updates slaves and these can update further consumer servers. This approach can have some advantages if you want to secure updates and be able to take a consistent snapshot of your data at a particular point in time.
IBM has licensed its enterprise-class LDAP directory server software free of charge for over 5 years now. It's currently under the Tivoli brand, going as the IBM Tivoli Directory Server v6.0. Not only does it pack all the bells and whistles of other enterprise LDAP directories, such as multimaster and cascaded replication models, but instead of flat files it *includes* IBM DB2 UDB enterprise edition database (also licensed free of charge) for its data storage. I've seen the comparative test results, and nothing touches this solution for performance and scalability. It runs on just about anything, too...including Linux on non-x86 hardware.
Honestly, I cannot imagine why anyone would want to run a FOSS equivalent Active Directory. After having spent months in setting up a full mixed Windows/Linux environment (OpenLDAP, Kerberos, Samba, the works), I can say that setting up AD is a breeze: for me, it is a prime example where Microsoft took existing technologies (LDAP, DNS, Kerberos) and actually turned it into something useful without the typically associated configuration nightmares. And it works very stable indeed. And please, cost is not a reason for not going with Active Directory. The cost of a single Windows Server license is absolutely peanuts compared to what *you* cost your employer. The operational costs are what matter in long term and I am pretty confident that Microsoft's AD will do much better than that for the years to come.
The costs for AD/Exchange, etc. pale in comparison to the administrative salary costs associated with supporting an IT infrastructure and the lost productivity costs of down time. I've found Samba in a Domain environment to be kind of flaky, and while it's useful for accessing the file system on a Linux server (though I prefer scp) there's no way I would look at replacing any Windows file server that had an SLA with a Samba server. The licensing costs for a Windows server (especially virtualized) are negligible. On the other hand, there's still no great solution for something similar to AD on Linux. NIS+ is old and sucks. Going through the whole LDAP rigmarole only gets you part of the way and requires a hell of a lot of upkeep depending on the server. Winbind against AD isn't bad though again it's flaky and requires way too much work to setup. I supposed there's the tried and true method of rsync-ing passwd, group and shadow files around. The combo of AD and Group Policy is pretty killer, It would be really nice to see something similar for Linux, or at the very least improved AD integration would be awesome.
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.
The prob­lem is that LDAP (like all hier­ar­chi­cal direc­to­ries) is a bro­ken way to orga­nize infor­ma­tion. Information, like every­thing else, is rarely strictly hier­ar­chi­cal. Often the user may wish to sort their data into dif­fer­ent cat­e­go­riza­tions. Basically, there may be broad hier­arhical ten­den­cies within infor­ma­tion, but at some level of detail, par­tic­u­larly the level which LDAP oper­ates at, it makes next to zero sense. For exam­ple, it’d be nice to keep all the infor­ma­tion about a par­tic­u­lar com­puter in one place. It’d be nice to have MAC address, IP address, war­ranty infor­ma­tion, ser­ial num­ber, etc. all grouped together. Unfortunately the only way to do that in LDAP is to cre­ate whole tree for each item, and then add the extra stuff which uses dif­fer­ent object­Classes to sub-items, often with over­lap­ping infor­ma­tion. Comment 1: There shouldn’t be any need to split your LDAP objects up like that. You should be able to put all the required object Classes into just “dc=somehost.yoursite.org,ou=Hosts,dc=yoursite,dc=org”. A single dis­tin guished name in LDAP can have multiple object Classes. So instead of adding extra object Classes as subitems, just add those object Classes to the item itself and fill in the values with data, and you’re home free. Comment 2: With regards to ‘links’ - LDAP supports alias objects and deref­er enc ing on either server or client side (well, not sure if openldap sup­ports either type ... eDirectory can do it transparently).
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. ... Oh yeah: In case you are going to set it up stay the hell away from BerkeleyDB 4.3.
> 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. =)
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 microsoft 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 time this is not enaugh. For this reason I usually prefer RADIUS which integrates well (unix and microsoft worlds), even if i still use LDAP for Apache because RADIUS mod for apache is not so customizable.
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.
Few years ago, LDAP 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 to setup, total pain 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.
I have spent the last few months up to my eyeballs in LDAP. While I am still hopeful of what LDAP can bring to the table I am admittedly disappointed in the tools, support and documentation surrounding the standard. I have been successful at creating and populating an LDAP directory and even authenticating against it, however I cannot find decent replacements for useradd, userdel, usermod, passwd, etc. Nor have I found any decent LDAP editors or browsers (preferably console or web-based). ... Are there any LDAP veterans out there who can reccommend any tools? What is the best way to maintain system account synchronization with an LDAP directory? Or perhaps, is there a more attractive alternative to LDAP?
Evey big client I've worked with had a LDAP server. Or Active Directory, basically same thing. I've had to integrate applications with their LDAPs more times than I care to count. It was always painful. No two corporate LDAPs I've ever seen were alike (different class schemas, different ways of storing user-roles, different ways of differentiating organizational units), which means every single time, we had to do tweaking to get that LDAP integration working. Also, LDAP lives in its own world and the "impedance mismatch" with object-oriented code is almost as bad as with database access.
Even if setting up a simple LDAP server is easy, that's not where all the pain comes from. See, it's not such a straightforward problem as you think. LDAP is basically a repository of user data; you can use that data to check user credentials in order to allow or disallow access to a user (authentication); and you can use it to decide if a user has enough clearance level to perform some action or access some part of the application (authorization). It's not as easy as giving people ftp access; you could use it to manage access to an enterprise portal, so that only managers could access to manager-level dashboards and financial reporting, and only network engineers could access the web GUI to manage the routers, and even more, you could make it so that only a specific group of network engineers could access the GUI to manage a couple of very critical routers. So the user information in the server has to reflect the corporate structure, to some extent. But every corporation has a very different structure; even more, when dealing with user authorization, some corps like to differentiate users depending on their department; some, depending on their geographical location; some, depending on their roles in the company. Even worse, some corporations like their users to have some profiles for a certain app, and different roles for a different app, with those sets of roles only partially overlaping (you may have role "A" for some app, and your pal also has role "A" for that app; but even if your pal has role "B" in a different app, it doesn't mean you have role "B" in that app; you can only be sure asking the LDAP server). So, as you see, it's a complex problem, and one that has a different solution for each company. Worse, it may change from time to time, because changes in corporate structure often happen each year. To be able to adapt to every scenario, LDAP is flexible. .... You can map user roles in LDAP as user attributes. Or as branches in the directory tree. Or as user groups. Or you can extend the default class schema adding whatever attributes you feel like to your users, groups, organizational units and the like (to be frank, extending the schema is usually the first thing an unexperienced LDAP admin does, and it's rarely worth the headaches it causes down the road). You can do whatever you like with an LDAP repository to adapt it to your environment. So of course people do whatever they like, and for whatever reason there is very little information out there about good practices when modelling your repository. The end result is that no two directories look the same, and the semantical meaning of attributes is not necessarily the same from repository to repository. So picture yourself in this situation: you just sold a new piece of software to a customer, and of course he wants it integrated with his LDAP server, so that he can continue managing user accounts in a centralized location (the LDAP server). Thing is, you can't know beforehand how that LDAP is structured. You WILL have to make an ad-hoc development to adapt your piece of software to that LDAP. You will have to do it for every customer that buys it. And every time it will be different, and every time there will be small nuances and hidden traps waiting for you. That's not mentioning the real possibility that the LDAP directory may not have the information you need for your application; what happens if your app distinguishes between "senior" and "junior" users, but there is no attribute in the directory that gives you that information?
What happens when:
  • Companyname Inc is bought and becomes Acme-Companyname Ltd, and the legal department wants the name updated?
  • Jane Smith decides to convert religions andd changes her name to Kwa-Jane Smitharama?
Both of these could be solved simply -- the company name one by the fact that there need not necessarily be any connection between something like a DC and a DNS FQDN; same for a CN and the user's name -- so you make something up (nonsense DC name and something like an employee serial number) and use a friendly name or something similar for the actual field value.
You can use another LDAP attribute as the username, but then you can't simply check credentials with a bind call. You have to use a "system account" to search for a directory entry with an attribute value that matches the username entered by the user. Then you have to read the attribute in that entry that stores the user's password (because you can't do a bind, you can't delegate the password check to the LDAP server, you have to do it yourself). Then you have to be aware of the algorithm in which the password is hashed or encrypted (because you don't store passwords in plain text in LDAP, do you?). If it's encrypted, you have to know the encryption key. When you have all this, you encrypt or hash the password entered by the user, and only then you can see if the password matches or not. Reply:
  1. Use a system account to search for the UN. Capture the DN, which is your UUID.
  2. Rebind to the server with the DN/user supplied password.
OP: Ok, yes, you're right. That works too, and it's easier. Kudos :)

What's Next?

blog comments powered by Disqus