[thelist] LDAP v. Database

[Aredridel]

> Actually, LDAP is a protocol, not a database.
> 
> Incidentally, on the semantics: SQL is a language, not a database :)

Oh, poo! <grin>

> 
> > The advantage is in the protocol, and mostly for a large organization --
> 
> The more data that you need to put into a directory context, the more
> useful LDAP becomes.  The whole idea of a directory service is to cut down
> on redundant data stored in many different places throughout an
> organization.  In other words, if HR already has a database of employees,
> and IT has a database of those employee's email accounts, and you need to
> create a web authentication scheme for those same employees... in that
> case, LDAP could be leveraged as a repository for all this information.

I have to agree here -- that's why I need LDAP (though I haven't done it
yet, since I'm lazy)

> I would recommend against considering LDAP for web authentication, unless
> you already have an LDAP service in production, or plan to deploy one for
> other purposes.  It would be too much learning curve, and too much effort
> to create and maintain an LDAP service for the sole purpose of doing web
> authentication (unless the scale was grand enough, there are always
> exceptional circumstances).

Yeah -- one other thing that it's nice for is playing nice with the
system and also not having to be root to check authentication. That's my
main reason: I have unprivileged processes that need to authenticate, on
several machines, and I want the same auth info used for system logon.

> > It's also cross-platform: Windows' "Active Directory" is LDAP.  If you
> > want to authenticate off of a windows domain, you're doing LDAP.
> 
> Try getting it to play nicely with other LDAP servers.
> It's called FUD.  I got yer MS 'standards compliance' RIGHT here!

It's getting there, it's getting there. It's mostly MS's implementation
of Kerberos that's hard to handle.  Anyway, it can be done.

Ari