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
It has to be mentioned. There will be a 100+ open source solutions proposed but none will come close to either of the two.
I know this is a different issue, but why push for Linux if you're already using OS X at work?
"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.
Sounds like you want Windows and Active Directory.
WTF is so wrong with something that's easy to use and administer?
Does it threaten your manhood or something?
Why _SHOULDN'T_ an opensource directory system make the hard things easy and the impossible things routine? The fact that OpenLDAP can be a bear to build and maintain is a usability bug that needs redress.
Listen, if you want to live in a MS world, keep expecting more from people than they give a damn about living up to. That's _REALLY_ productive.
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
I've a similar question myself: Is there a Linux distro which, upon installation, aids in the setup of a Directory Services server, a network filesystem for storing user data (possibly including $HOME directories) and installation of client workstations which use those services?
...
I'm talking of the same installation disks, but at the very onset, instead of just asking (or perhaps more than just asking) if I want a Desktop, Server or workstation install, it include sub-options like:
Server:
[] Directory Services Server
[] Network File Server
[] User $HOME directory (or some other friendly name)
[] Print Services Server
Workstation:
In other words, the very things one would need and in the order one would install for a small- to medium-sized enterprise.
Admittedly, it's easy to get that "flat" feeling if all you do is use the GUIs. That's how it's presented. But there is indeed exposable depth to Active Directory and it's worth it to go digging around under the hood.
I'm a Windows admin. I won't pretend to know enough about OpenLDAP or Apple's OpenDirectory to comment on either. That said, Active Directory has done everything I've ever wanted it to do since rolling it out in August 2001. 36,000 users, about 3,000 computers, hundreds of facilities, security groups, user rights, DNS, site topology, delegated containers, lots more. And 100% uptime period.
I appreciate the value of and the need for open source software, and I do love to hate Micro$oft. But with regards to Active Directory, I'm sorry to say they appear to have gotten something right.
Hey! AD is cool! I loved in in Netware 4.11. We just called it NDS, though.
AD isn't special. It, like so many other "innovations" from MS, is simply a rip-off off LDAP and NDS. OH, but you get the added bonus of having to have twice as many servers to implement it.
... and there is Luma for point and clickness. Macs also love OpenSLP. I suppose an enterprising techie could put together a collection of LDAPpy binaries, call it Linux Directory Services and sell it for thousands. But doesn't O'Reilly have a good LDAP book?
"Only in their dreams can men truly be free 'twas always thus, and always thus will be."
--Tom Schulman
OpenLDAP, as an implimentation of LDAP v3 right now, is lightyears beyond Active directory in functional sophistication. Its not OpenLDAP that sucks.
Its the fact that Configuration is too hard because the nessessary interfaces aren't there. The only thing that comes close is "Directory Administrator"
OpenLDAP is a superb LDAP implimentation from a technical standpoint. Far outpacing ADS. ADS just has ease of use, that Open LDAP needs.
Linux needs OpenLDAP replacements for things like useradd, usermod, and passwd, or some way of modulizing them.
Yeah, thats great, but what does it DO.
Seriously. What the hell is in this "directory" that makes it more magic than just having samba alone, aside from just being a list of users?
If I have been able to see further than others, it is because I bought a pair of binoculars.
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.)
Apache is inclubating a new unified directory service that promises to be the cat's meow.
Luma is still too complex for day-to-day needs (well, then so is LDAP, but the UI should really simplify that).
He wants to have it magically setup out of the box without him having to learn anything. Windows doesn't do this either, you still have to learn AD.
Not with Windows Server 2003, we don't. We don't have to learn nuffin'! All dem wizards can get you set up with a complete, albeit poorly functioning and insecure, AD system within minutes. The learning comes from the error logs and debugging of erronious AD behaviour. I was so glad to find the online help system was unfinished when I got into dire straits during install of services, and at the time technet had pretty much zero info on Server 2003.
this sounds like windows users whining about mountpoints. yeah, docs are lacking, but all the components are there, some twice over. just glue it all together with a little bash. done -- probably even with lower TCO.
Don't thank God, thank a doctor!
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.
It's widely known what the contents of that extra packet is these days, actually. Luke Howard's XAD takes advantage of it, and the Samba guys are coding with it as well.
- jon
Ganymede, a GPL'ed metadirectory for UNIX
What would be the default realm? What is the LDAP domain?
ask me during setup.
Will the root user be stored in the LDAP directory or not? What kerberos principles will be created by default? Will your mail alias information be stored in LDAP or not? What do you do if the LDAP server can not be contacted? How will you handle applications that do not talk to LDAP, PAM or Kerberos? Do you really want a DNS server running on every host you install this distro on?
*i don't care*. pick some sensible least-dangerous defaults and make ldap auth work for me out of the box. i'll discover the other functionality as i need it.
when i installed my first linux box i didn't know dick about PAM, passwd or shadow. but i could log into the fucking thing.
pr0n - keeping monitor glass spotless since 1981.
That's because LDAP sucks, hardcore. I don't mean that the developers of things like OpenLDAP suck, what I mean is that the specification and the protocols and whatnot suck. LDAP shares with it's predecessor X.500 the very serious flaw of over-generalization. They picked a very broad design that attempts to do everything for everyone, which means every little thing in LDAP has to be subclassable, extensible, flexible, etc. Then you have all these schemas that try to tie down common usages, but different vendors use different schema variations. Then you have the hacks to bring the varying schemas into synch on a single dataset....
What most people want, and get, out of LDAP is a relatively simple thing, and LDAP's complexity is a huge cost for the simple results most seek. Wintel integration is really the only advantage it has going for it. Within a pure *nix world, what would be better than LDAP would be something with the essential structure and data complexity of NIS, but with a more modern and secure design. I actually got about 33% through writing such a thing, and it isn't that hard. Secure, flexible, interoperates between *nixes (well, Linux and Solaris was all I was coding for, but modern AIX looked like it had the right hooks for it, so did HPUX), hooks into PAM and NSS, doesn't hang lookups with the servers are down/unreachable, etc. I'm sure there are 10,000 other coders out there who could do the same. Someone just needs to make an official standard based on the idea.
And once we have that working, someone can always write a drop-in DLL for Wintel boxes to do auth/directory services against it or something.
11*43+456^2
I've been setting up RedHat boxes for years using authconfig. If you want the home directories automounted, guess what... use automount! It's amazing, really... the things that have been working and people just did not pay attention to them. Mind you, I'm not sure what the app is called these days, I've been using OS X on my desktop for a while now, and my last home network RH install was so long ago, I can't remember what it was then! lol
I guess my point is, it's there, just take a look at the documentation. It is there, in the handbook. You can get it at redhat.com easily.
Cheers!
Mind you, setting up an Authentication Server can be something else altogether... in that case, grab a copy of OS X Server... the Apple implementation of OpenLDAP is superb, used it several times.
err. And how is this different to SMB? You might like to hear what Andrew Tridgell (the original Samba author) has to say about this. I quote from an article he wrote for Groklaw (http://www.groklaw.net/article.php?story=20050205 010415933&query=Samba)
"The protocol that Samba implements was first invented by Barry Feigenbaum at IBM in early 1983. He initially called it the "BAF" protocol after his initials, but changed the name to "SMB" before the first official release. You may note that the name "Samba" contains the letters "SMB", and that is not a coincidence.
The term "CIFS" or "Common Internet File System" was coined by Microsoft in 1996 as a marketing exercise in an attempt to combat a perceived threat from Sun Microsystems after their WebNFS announcement. The term caught on, and now the SMB protocol is often called CIFS. The two names refer to the same protocol, as is easily demonstrated by connecting a current Microsoft "CIFS" client to a Samba "SMB" server from 1992."
However, for those who know little or nothing of X.500 and are just looking for simple directory services, this makes the LDAP documentation pretty much worthless or extremely annoying, depending on just how tenacious you are.
I don't mean to pick on the various LDAP projects. This kind of thing happens all over the place with free enterprise software.
Red Hat acquired the Netscape/iPlanet directory server (LDAP) code from AOL, along with the original team working on it (i.e. its not open source and dump software). Its about 1.8 million lines of code, and RH is releasing it as free / open source software ASAP. Chris Blizzard of mozilla fame had a great presentation at the Fedora Conference (FUDcon ;-) today about their progress. Very cool stuff.
Blizzard wants to learn from Mozilla and not release the code until a standard build system (such as autoconf) is in place... You can imagine with that much code its going to take a little time to work through in a new build system, but his current estimate is they'll release the first functional useful code "on the order of weeks". There are some smaller chunks that are going to have to be rewritten owing to dependencies on external proprietary code we did not acquire, but it looks like nothing really bad, and the core should be coming along quickly.
This codebase is one of the major commercial directory servers in use, is supposed to scale to giant enterprise loads, and is (according to some RH hackers who just got their hands on it internally) much easier to setup than OpenLDAP. It comes with a nice GUI config interface, etc. Naturally, it'll be integrated into Fedora pretty quickly, and hopefully Debian, Gentoo, SuSE and other distributions too.
-Seth
The problem is that each flavor/vendor uses its own brand of automount schema. OS X uses that awful 'mounts' mapping with its equally awful automounter. Solaris has its own brand. Then there is amd. Etc. Until someone RFCs a decent LDAP schema for automounting and everyone follows along, I suspect this is going to remain a dream.
In the meantime, if you work in a heterogeneous environment, expect to do some work (and in some cases, quite a bit) to build shims between flavors.... and thats before you get to things like Kerberized NFS and/or NFSv4.
In most other respects, everything else is fairly standard. RFC2307b gets you almost all the way via LDAP and Kerberos lets you do it all in an SSO'd environment.
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...
Flat is seldom the answer unless your domain will be very small.
Domains form security boundaries. Unless you want everybody who is in domain admins or who may need domain admins the ability to completely screwup your schema and enterprise configuration then you should have as a minimum a place-holder root.
A placeholder root also allows different security policies for different users. This is the most annoying weakness of AD: user accounts get the security policy of the domain controllers, and not of the user container. So separate domains for separate requirements.
Mergers/de-mergers/acquistions all benefit substatially from being able to spin domains in and out of a forest. You don't need a forest for this, but it helps.
Internal politics also may mandate separate domains - many companies are loosely allied fiefdoms, and there is no way they will agree to monolithic centralised IT. So give them a bone - here, your very own domain. They will not realise that there is no effective difference if you control the root.
Other reasons are said to include control of replication, but I've never really bought this. AD replication is pretty minor compared to other traffic. I know that in 2000 there is a problem with groups (membership is replicated, not membership deltas - changed in 2003) that might suggest it's a good idea, but if you are doing a 2003 roll out - nah.
Oh yeah - as seems de rigour in this thread I was also once involved in one of the largest AD roll outs in the entire world - headquarters (one of them) opposite Waterloo station in London.
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.