How Linux Beats Windows in ID Management Ease
Amy Kucharik writes "Fed up with Windows systems management? A Linux conversion may be your ticket away from the daily hassles of managing and licensing domain controllers and related software devices. In this tip, Paul Murphy discusses the evolution of LDAP and how using it, along with Linux, can make an administrator's job easier."
... was an embarassment because OpenLDAP is a pile of junk compared to the quality of flagship OSS products like the LAMP stack.
Thankfully, Redhat's new Directory Server (based off iPlanet's) should be much easier to use and deploy.
Go somewhere random
Sure, Linux is one way.
However, I'm very impressed by Novell NSure.
Do not overlook this product if you're looking for a solid LDAP based Identity Management solution.
There's nothing better in ID management the eDirectory, either running on Linux, NetWare, or yes.... even Windows. MS always promises that the *next* Active Directory version will have the features that eDirectory had 15 years ago. True container based security and delegation, partitioning, replication, all with the greatest of use. Yes, it's more expensive that OpenLDAP, but WAY better.
please excuse my apathy
LDAP, is a directory service, or database, that also has the ability to verify ID/Pass pairs, which is the most basic form of authentication.
For stronger authentication, using tickets for further authorization, use Kerberos. With LDAP, you must punch in your password repeatedly. Yes, it is the same password, but it must still be entered multiple times. In a properly Kerberized environment, you enter the PW once, and that's it. And, if desired, you can do some neat P
And, to head off some arguments -- Kerberos is pretty easy to setup. It is, at least, no harder than OpenLDAP to set up.
Try Kerberos -- you'll like it.
10b||~10b -- aah, what a question!
He's talking about managin IDs on networked systems. Not standalone.
I worked at a facility when they implemented Active Directory, and re-implemented Active Directory, and re-re-implemented Active directory, and re-re-re-implemented Active Directory. Eventually some contractors came around to each system that was dorqued and fixed it, sort of. They had to get help from both us contractors, and the local systems guy.
I just hope they aren't using any of Excel's statistical functions. Or if they are, I hope they don't care about accuracy. There are so many problems with Excel's statistical functions (even the latest-and-greatest version) that it has been repeatedly ruled "unsuitable for serious statistical analysis". That's fine if "a large majority of people in my area need Excel to function" just be aware of its shortcomings (which are many). Gnumeric (and I think KSpread and StarCalc) is significantly better than Excel in this area (and many others, but I digress).
Of course, both this post, the parent and the parent's parent are "-1 Off Topic".
Currently Windows Update Services is out which allows for very good, grandular control of software updates and management, should more control be needed, there is always SMS2003. No it's not just for Windows. The newer releases of Update Services update all supported software detected on the system, this will include 3rd party applications as well. If applications follow standard Microsoft development "rules" one would not have to clean up anything, but as usual, people take the shortest and quickest path possible and leave crap all around. Is it perfect? Nope. But it works well when used properly.
The article incorrectly states that PAM (Pluggable Authentication Modules) came out of Project Athena.
However, it was actually invented by Sun, and was eventually adopted as RFC 86.0 by the Open Software Foundation in 1995.
Swoosh.
Since it isn't possible for one article to explain how to configure identification, authentication, and authorization for all systems, the article contained links to more information.
That's because you often have to learn about things in order to do them. With flexibility comes a price, and that price is work. Luckily, they pay you for that, if you do it well enough.
Or maybe he should have published a GUI along with the article? Sorry for being flippant, but I think you're expecting too much hand-holding.
Raise your children as if you were teaching them to raise your grandchildren, because you are.
I know for a fact that OS X 10.3 (Panther) Server included OpenLDAP, not sure if it was there earlier. The whole package, with OpenLDAP, Kerberos, the GUI admin and such, is called Open Directory.
More info here.
NetInfo is now pretty much relegated to storing info for the local machine only.
Since the article didn't really say anything about managing LDAP or playing with OpenLDAP, I thought I would share a useful utility my team has recently started using for LDAP management and administration.
Have a look at JXplorer (or alternate Sourceforge link).
It's a really nice open source LDAP administration and management utility that not only lets you do the easy entry editing stuff but a lot of the more complex tree management operations. It also has some really nice search building interfaces. I'm in no way connected with this project but it has replaced a number of free and commercial utilities we used to use.
It also lets you play with populating an OpenLDAP installation so you can begin to understand some of its real power and tuning potential.
NetInfo is still used for the local accounts, and LDAP is one of the methods available for remote authentication (along with ActiveDirectory, Kerberos, etc...). This is all part of the OpenDirectory system, and there is no real sign that anything major is going to change.
MacOS X Server uses LDAP as one method to store user information, and also NetInfo (as "local users" that can still be vended out).
PS... this works very well, and is easy to admin. I don't see any reason to change things.
PPS... the documentation on how to create NetInfo directory master/client trees has disappeared, and I don't know if this is still possible.
A friend and I tried the same thing and got the same results.
One is free, but needs a lot of implementation to get it to work.
One costs, but it's damn easy to use.
Personally, for mucking around improving skills I'd use the Linux/LDAP but as soon as you hit a corporate environment, Group Policy wins hands down for speed, integration and ease of use.
How many people can read hex if only you and dead people can read hex?
Ok, I give. LDAP is initially hard to understand (objectclasses, schemes, replica's, DNs), but once you do, it's a snap.
Here is my real world setup.
1. RedHat Enterprise server
2. OpenLDAP
3. Postfix (SMTP auth, Spamassassin, TLS, Postgrey)
4. Cyrus Imap Server
5. Samba File server
6. Apache WebDav
Right now I have a master copy of LDAP on the internal file server. Then two other servers (on the DMZ) are replicas. Samba pulls info from LDAP, Cyrus, Postfix, WebDAV as well. Not using Kerberos at this time, but all passwords for Logging onto the computer, email, outgoing email, are same username/password.
Very nice. Some of the configuration and stuff I have documented no my wiki
http://www.spydorweb.com/wiki/
This space available for rent.
Our intelligent designer has never created an animal that we couldn't improve by strapping a bomb to it.
Not only is the article light on content, but it is rather meaningless to argue that LDAP is better than Active Directory, since AD is an implementation of LDAP (featuring Kerberos authentication and the LDAP data stored in a multimaster replicated database).
Of course, it has taken MS a while to catch up with the features Novell's NDIS directory offerings, but they are finally getting it right with 2003, and it is arguably the easiest to manage enterprise-scale LDAP implementation around. It isn't perfect mind you (we dig up plenty of bugs), but does seem to be the best thing going. Furthermore, Group Policy Objects are a seriously kick-butt feature. Besides, nothing else can properly issue authorization tokens (SID keychains) for Windows clients.
Now if only they would fix the huge heaping piles of Exchange integration bugs in Entourage...
(No, I'm not a MS apologist. They piss me off on a regular basis, both in terms of product quality, or lack thereof in many cases, and in terms of business practices; however, folks are barking up the wrong tree where these criticisms of AD are concerned. In a short time it has matured into a quality product.)
*** Quantum Mechanics: The Dreams of Which Stuff is Made ***
I've looked into using Linux with OpenLDAP, SAMBA and Kerberos before and in it's current state it simply isn't going to work as a replacement Windows domain controller.
All the key components exist, but none of them are well enough integrated to provide a convincing solution. Notably, Windows machines that log onto a domain use a microsofti[sz]ed version of the LDAP standard, CLDAP (Connectionless LDAP) which from my understanding OpenLDAP doesn't want to support because it's non-standard. This makes it's unsuitable for a Linux-based domain controller but suitable for most other tasks. Also, SAMBA 3 doesn't support Kerberos as an authentication backend, and so password synchronisation and single signon is difficult in a mixed windows and *nix environment.
The up and coming SAMBA 4 is promising to fix these shortfalls, with an inbuilt implementation of CLDAP, support for Kerberos authentication, etc. Until this happens, SAMBA and LDAP aren't going to meet the requirements of most medium size businesses as a replacement domain controller.
The lesson I learnt from my research is that a Windows server currently makes more sense for a Windows environment for things other than relatively simple implementations that a Linux one.
Graham
For something more complex (like specifying unix UIDs, login shells, home directories, etc) you need to look at Microsoft Services for Unix (to extend the AD schema)
Which (in my experience) just tanks your AD server.
I've tried it twice, and both times turned my AD server into a doorstop - the AD service locks hard, and there's no way to bring it back.. which makes the entire machine useless (as you can't log in without AD running) - a reinstall was required to fix it.
And apparently I'm not the only one this has happened to.
Is that open source?
Yes
The page makes it look like it isn't.
You're correct, RH's page is pretty misleading (maybe because they want you to buy a support contract from them?) - I had to hunt around for quite awhile before I found the source.
Is this the reincarnation of Netscape Directory Server?
Yes, although it's now known as "Fedora Directory Server"
They have a wiki for the project here
A couple different places....
samba.org has had its guides updated for more modern deployment. There are several places, but one of the better guides is listed with the same people who make the samba-ldap tools.
Active Directory is a nightmware because a lot of what happens is done for you in a windows environment. Which is funny... a great deal of what goes on with normal samba is automated and you get to feel a whole lot more of that when you goto ldap. I'm sure someone has made some progress.
Anyhow, once it's done, you basically get a samba pdc + ldap auth source. It integrates nicely with linux, but becareful of setting up too many accounts on ldap (because it can of course go offline).
I've been using openldap + smba pdc for several months. It wasn't that bad and there were a few too many oddities involved, but it works nicely now.
"You should always go to other people's funerals; otherwise, they won't come to yours." -- Yogi Berra
Winbind, part of Samba.
OR for apache use: auth_kerb_module
OR for authentication only (manually add dummy users) use pam_krb5.conf
Its all fairly easy and you don't need to touch the unix services toolkit.
Jason.
correction, one is free and not so difficult to setup (openldap), but when that hurdle is behind, man!, you can use it for *anything* and there are enough tools out there to make the task of using it a breeze.
.htaccess directories in the intranet server (management, sysadmins), centralized addresbook, ..., for over 15 different offices. So we can work on the important stuff :-) (no, reading slashdot happens at home).
You need to know very little to use phpldapadmin or jxplorer. It just *works*. I just trained my windows colleague to use jxplorer at work for user management, no sweat. He knows nothing of the theory of how directories work, he just uses it. The same login for windows users, email (postfix),
In SUSE, use Yast2 --> Software --> Online Update.