[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Alternative to OpenLDAP

You might want to look into using Mac OS X Server. Its directory services are actually based on Open LDAP/bdb in the soon to come next release 10.3 (according to apple). They also tie Samba 3 and (if you so desire an MIT KDC) into the same user database, so PCs and *NIX/OSX clients are working from the same central user/password store. From my experience it plays pretty well with Kerberos, so AD integration is a possibility.

What does this buy you, you say? Well, I am not intimately familiar with what you have had trouble getting to work, but if the issue is that you would like to use an open source LDAP solution, but you are having a difficult time getting it up and running, Apple traditionally puts a lot of time and effort into making sure things "just work". In the case of Mac OS X Server, they are using OpenLDAP as the engine underneath and doing a lot of the legwork to getting it working for you out of the box. They also provide some GUI management/setup tools that make things easier.

Like I said, it depends on your situation, but its something to look into.


On Oct 6, 2003, at 9:51 AM, Yelich, Scott D. wrote:

I'd like to followup in case there is a misunderstanding of my email.

My question was not that I had OpenLDAP working and I wanted to
replace it, my issue is that after 2 years I *can't* get OpenLDAP to work
and my supervisor has decided he wants a central password database
working *yesterday* ... with the arguments along the lines of
"windows has it" and "others must be doing it" ... so why can't/aren't we?

So what was just a light investigation off and on (thank you for the help here,
and those individuals who responded to me privately) has now turned into a
long overdue critically important core enterprise bet-the-company issue...
or so it seems like it.

From the feedback I've received here, it appears the main choices would be
OpenLDAP and iplanet. Of course, I'd favor OpenLDAP, provided it would be
made to work - and there appear to be some paths to reach this end.

However, my position now is that I want to try to avoid a poor decision from
being made - that is, just because I had issues with OpenLDAP, it doesn't
mean that it's still not the correct choice.

Wish me luck!


-----Original Message-----
From: Quanah Gibson-Mount [mailto:quanah@stanford.edu]
Sent: Saturday, October 04, 2003 3:40 PM
To: openldap-software@OpenLDAP.org
Cc: jonlists
Subject: Re: Alternative to OpenLDAP

--On Saturday, October 04, 2003 8:11 PM +0200 Tony Earnshaw <tonni@billy.demon.nl> wrote:

jonlists wrote:

Not to be rude, but your comparison doesn't state much about NDS -
version release of eDirectory you examined....

Did you truly evaluate the Novell offerings, or did you just fill in the

Also not to be rude, but Quanah's evaluation seemed more of a
justification than the former. The point was, IMHO, that if "the others
didn't have the necessary, then they were rejected".

The comparison/evaluation was done in 2001. It was based completely on
what literature we could find online and whatever comment we could get from
the sales reps, which often wasn't very knowledgeable. I believe Scott's
own message refers to the troubles he's had in that area. The matrix is
very specifically constructed along the needs that Stanford has, as Tony
points out above. Any client that could not support K5 authentication was
dropped, as that was an inflexible requirement. I've currently put it on
my plate to start updating that document, so if you have any information
for the places there are ?'s, I'd be more than happy to update.


Quanah Gibson-Mount
Principal Software Developer
ITSS/TSS/Computing Systems
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

_______________________________________________________________________ _
This email has been scanned for all viruses by the MessageLabs Email Security System.
_______________________________________________________________________ _

This mail message originated outside Commerzbank via the Internet. As a result, the sender's address is not verifiable.

This communication is confidential and is intended only for the person to whom it is addressed. If you are not that person you are not permitted to make use of the information and you are requested to notify Commerzbank Aktiengesellschaft, New York Branch immediately that you have received it and then to destroy the copy in your possession. Views expressed in this e-mail do not necessarily reflect the views of Commerzbank AG.