Re: Going LDAP #2

[Hallvard B Furuseth <h.b.furuseth%usit.uio.no@localhost>]

Anders Magnusson writes:
> So, here's my idea about how the LDAP/Kerberos stuff should be used in
> the NetBSD system.  Comments wanted :-)

I've just browsed the recent LDAP discussions.  I don't know NetBSD, but
anyway: One possibility I haven't seen mentioned here is to provide LDAP
as an access protocol to your current db files.  Or from LDAP-server
point of view, write a backend to the LDAP server which uses the current
db files as its data store.  Then you could administer most of the data
with your current tools on the master host.  In addition I presume you
need to support at least write operations for passwords over LDAP,
so the passwd program will work.

I don't know if the server may keep your files permanently open while
other programs modify them?  This idea might not scale too well if it
has to close them between each operation.  Unless the admin tools write
via LDAP too...  (That might be simple for updates limited to a single
LDAP entry, but would need LDAP transactions as an extension if a
"logical" update must update several LDAP entries.)

BTW, this could offer users an entirely new way to hose themselves if
it's designed wrongly - nsswitch.conf referring to ldap which refers
back to nss...

> (...) I therefore read some RFC's and wrote an embryo to a simple
> [ldap server] implementation just to test it out, and it wasn't
> especially difficult.

Time will tell how correct it is though.  If you want a small LDAP
server, you might start with TinyLDAP which has already received some
devel and testing.  I haven't looked at it myself though.  Doesn't
support writes yet I think.

> Basics:
> - Only root credentials have the possibility to change something.

s/root/ldap admin/ I presume.  So a host must store the ldap admin
credentials somewhere for e.g. the passwd program to work?

> - Auth both simple and SASL (GSSAPI).

And TLS to protect the auth.  Some auth methods are safe without TLS,
but most are not.

> (...)
> - Only a few attribute types; directorystring, integermatch etc.
> - No OIDs or other similar stuff.

Note that these points make it a subset-of-LDAP server.  In valid LDAP,
a search requesting attribute 0.9.2342.19200300.100.1.1 will receive
attribute uid (which has that OID).

-- 
Hallvard