Slashdot Mirror
Where are the 'Modern' Directory Services?
MarcQuadra asks: "I've been a Linux user since 1998, and I admin Mac OS X machines at work, but I have yet to find a distribution that comes out-of-the-box with modern directory services. Sure, there are guides to kerberize and set up OpenLDAP, but before I can start pushing Linux as an alternative at work I'll need a few things. Are there any distributions out there that can auto-mount SMB shares as home directories without heavy modification? How about a distro that's based on OpenLDAP and can easily be configured with LDAP-enabled SAMBA and Kerberos? Am I missing something, or is this not a priority with the community at-large?"
Any word on when Redhat will make the Netscape Directory server availible? That would be your solution or look at: http://imc.sourceforge.net/index.html
I believe SUSE Enterprise Server (and SUSE Open Exchange server too) has a yast module to setup LDAP easily.
I might be wrong though - I'm still waiting for my copy...
sigaar
Solaris automounts my home directory just fine. Just point the machine to the NIS domain and it works
"Are there any distributions out there that can auto-mount SMB shares as home directories without heavy modification?"
It takes 3 shellcommands and inserting your favorite validation-server to hook up an osx-client on an AD-server, SMB-shares included (not DFS though, as far as I know)
All those moments will be lost in time, like tears in rain. Time to die.
There's this company called Novell that has this product called, variously, "NetWare Directory Services", "Novell Directory Services", "eDirectory", and "Nsure/exteNd/Nterprise/Ngage".
Okay, so maybe their marketing department has sucked big donkey dongs for like the last ten years and that's why you've never heard of them.
But rumor has it they purchased this outfit called SuSE, and that all their stuff has been ported to the Linux kernel, and they also purchased this other outfit, called Ximian, so that all their stuff would play nice with .NET, and...
Well, you get the picture.
LDAP/Samba/Kerbros on Suse works real well out of the box in the latest Suse Server offerings. I don't play with many distros so I can't recommend it against others.
But for professional use on networks of any real size, I really try to push my customers to NDS. Say what you want about Novell, but I have yet to find a beter DS that Novell's.
So why not use it? It's a full featured directory service based on OpenLDAP with Kerberized AFP and SMB built in, so why use a Linux server and "roll your own" with everything, and do all the extra work?
I have to be missing something here.
I mount NFS home directories with automount on Red Hat 9.
/etc/auto.master, or NIS to get the auto.master. No biggy -- isn't updating /etc/auto.master easy enough (assuming you don't push it with NIS)?
So, I push an auto.master using NIS. Works peachy. I've never tried it -- but I think that using an SMB share as a home directory would be as simple as changing the automount specification? This doesn't work?
As to NIS: its what I use, and RH9 is happy with it.
However, RH9 does offer "NIS", "LDAP", "Kerberos 5", "SMB" authentication schemes on installation.
Note that autofs uses
What are you trying to do?
Ratboy
Just another "Cubible(sic) Joe" 2 17 3061
and/or PAM and winbind with Samba3, at least on the client. All available via aptitude on debian sarge, and rather not difficult to configure.
(I'm not using users' domain homedirs on the box I've got that setup on, as my primary desire was to use Apache basic auth to the existing AD infrastructure, but other than that it works rather well so far.)
One of the things that has always annoyed me is how bad the administration tools for LDAP are. My preferred method for quite a while was to keep an LDIF laying around that I would edit and import with slapadd. Not a beautiful solution.
:-)
I have since created an LDAP admin tool that doesn't have a strange obsession with DN's, doesn't make you specify UIDNumbers, and generally tries not to suck.
It is also (to my knowledge) the only LDAP admin tool that will manage your Kerberos principals alongside your LDAP users (if you're into that sort of thing). Anyhow, enough of my blathering, check it out: (http://edsadmin.sf.net).
The next step of my Grand Vision is EDSRealmAssistant, which currently auto-configures samba+ldap, and will in the future do the whole LDAP+SAMBA+KRB5+DNS+DHCP shebang that everyone wants but is too lazy to set up
-Mark
i'm guessing the difference is that setting up AD server and AD-based single-sign-on doesn't make you want to gouge out your eyes with a shrimp fork (compared to linux at least).
i say i'm guessing because i'm 100% linux at home and work, and i'll never lay a hand on a windows box if i can avoid it; but the theme of this Ask /. is dead-on.
Linux needs *easy*, *default*, *out of the box* ldap-based authentication. i should be able to install a distro, select "ldap auth", and then have everything automagically authenticate against it - shell, apache, samba, IMAP, etc etc etc. same on workstations - select "ldap auth", specify the ldap server, and you're done.
i don't know any distros that offer this ease of use - correct me if i'm wrong. (i run debian sarge and sid).
pr0n - keeping monitor glass spotless since 1981.
Actually, there was plenty of free software available in 1992.
...) have been augmented as new requirements have been encountered and are still relatively simple (to understand, to implement, to debug, to use, ...) today.
At about that time I was writing X.500 based applications using ISODE.
In my estimation, X.500 failed to take off for five reasons. The first was that it was overly complex. The protocol was certainly complex. While ISODE made things easier, building applications was still too complicated.
The second is that X.500 was a resource pig, both on the client and the server.
The third is that there were too many optional features in the protocol. No vendor could practically support all of the options and no two vendors could agree on a reasonably common subset of features. Interoperability was a nightmare.
The fourth is that due to its complex data model and binary data encoding, debugging X.500 sessions was extremely difficult using a packet sniffer or other protocol capturing tool. It also meant that writing scripts to do reasonably interesting X.500 things was not going to happen.
The fifth was that once LDAP was fielded, the practical need for X.500 disappeared. The first 3 reasons above created LDAP and once it existed, X.500 was an answer in search of a question.
One might say that there was no mission critical need to directory services. We had DNS for host to address mapping. Directory services was a "would be nice to have" not a "must have".
In addition, because it was originally conceived to be operated by the PTTs of the world, there was an organizational element with regard to who ran what servers and served what branches of the X.500 name space. That never really came together.
Many thought that company employee directories would be on-line for the world to browse. Except nobody checked with the companies to see if they thought that that was a good idea. It wasn't.
Reasons 1 through 4 above apply to many if not most if not all ISO (or OSI) protocols. We used to say that ISO protocols were designed to solve all problems for all people for all time. It turns out that because the protocols were too complex and too resource hungry, and the implementations didn't interoperate, that in the end they solved few problems, for few people, for a very short time. And that was on a particularly good day.
Designing protocols to solve every problem and provide every feature that we will ever need lost out to designing protocols that were the simplest things that would serve the desired purpose and solve the current problem. And these simple protocols (FTP, HTTP, NNTP, SMTP, POP3, TFTP,
LDAP, however, is not one of these simple protocols. LDAP was a compromise, like SNMP, and like SNMP, LDAP has paid for not being what it could have been: small, simple, and elegant. Both protocols use the ISO data model (ASN.1) and the ISO encoding model (BER,DER,...). In fact, both protocols were designed to be transitional protocols to get things going until their ISO replacements (X.500 and CMOT (CMIP over TCP)) were ready to be deployed.
The funny thing is that once LDAP and SNMP were fielded, X.500 and CMOT were no longer needed. And funnier yet, the authors of the LDAP and SNMP protocols secretly knew that LDAP and SNMP would not be replaced by X.500 and CMOT, but they had to make the design compromise to ease the transition that they knew would never occur in order to keep the peace while they pulled the rug from beneath the X.500 and CMOT proponents. Of course this was back in the day when most people believed that X.400 would be replacing SMTP in no time at all. But some knew better.
Windows and Active Directory are a proprietary ripoff of LDAP and kerberos with some gui tools
Well I guess if you never used it, you would probably think this.
AD goes so far beyond a type of LDAP or authenication system it would be like saying Linux is nothing more than a rip off of 1969 *nix and doesn't do anymore.
(And no I don't believe that about Linux.)
Geesh...
I just have to make some advertisement:
During the last two years, I've been hacking on a generalized system for managing an LDAPized system, including all sysadmin tasks like home-dir-creation etc, for my employer. The system is GPL:ed and available from http://grimoire.takeit.se (the webdemo doesn't work ATM, sorry).
The aim of the system is to carry out any sysadmin task on any host in the system, and combine those tasks into more complex ones, even if executed on different machines, and then control access to tasks in a very fine-grained way (a bit similar to Novell:s trustees, in that you have inheritance down the tree).
ATM, the system can handle users, groups (it can let users create their own groups in a controllable fashion), machine accounts and printer ques interacting with Samba, OpenLDAP, Courier, Postfix, CUPS, pam/nss-ldap and some other tools. It is however in beta-stage...
--The knowledge that you are an idiot, is what distinguishes you from one.