RE: NIS to LDAP: a better way?

[Luke Howard <lukeh@PADL.COM>]

>Sure, use back-passwd directly instead of back-ldbm. It will need some patching
>to make it conform to RFC2307, but that's pretty trivial. Then
>get nis_ldap from www.padl.com to make NIS read directly from LDAP and you'll
>have no more synchronization problems whatsoever; you won't even need to run
>ypmake any more (or whatever the equivalent command for running the NIS
>makefile...).

Thanks for the plug, the product is called "ypldapd" BTW :-)

>I might also point out that Symas' Connexitor product includes a full-featured
>UnixAuth module for slapd that securely provides full read-write access to
>/etc/passwd, /etc/shadow, whatever. It's not RFC2307 compliant either, but
>that's because we also support AIX's security database, and we also can deal
>with the SecureWare attributes that HPUX and SCO use. (I think it's a shame
>that RFC2307 defined the "posixAccount" objectclass but only implemented Sun's
>limited view of such...) (Yes, we support authenticated Binds, but that's not
>really what we intended it for. It's meant to be a remote admin tool; it just
>so happens that it can serve equally well as an LDAP authentication target and,
>with a bit of tweaking, as a nis_ldap provider.)

posixAccount maps closely to the POSIX specification, with the exception of the
userPassword field, which was a Netscape-ism we inherited (primarily to convince
Netscape to use the schema -- when I started drafting RFC 2307 in December 1996,
no one was interested in using LDAP as a replacement for NIS).

The comments you make are perhaps more appropriately addressed at "shadowAccount"
which is very much a Solaris-ism, and should be fixed. But I think these days
people are using directory server-enforced policies for access control and
it is becoming more and more outside the scope of RFC 2307 (bis).

regards,

-- Luke

--
Luke Howard | lukehoward.com
PADL Software | www.padl.com