From: alex@xxxxxxxxxxxxxxx
> Hm, sounds interesting alternative to OpenLDAP.
Actually, OpenLDAP started as a GPL alternative to NsDS as far as
I am concerned. @-p
> It says it supports SASL authentication and MD5 password hashes.
> Does it also support placing a pointer for SASL where to check the
> password into password attribute (instead of placing actual password
> in it)?
The SASL capability can interface with any GSSAPI solution IIRC.
I _know_ that includes a _real_ KDC.
> What I'm talking about is putting something like "{SASL}user@REALM"
> intopassword attribute. OpenLDAP would than use saslauthd to check
> the password(passing it user@REALM and whatever user entered as
> password). In my case saslauthd is configured to check passwords
> using kerberos5 backend.
> Basically, directory server does not store any passwords, passwords
> are stored in Kerberos database
That's _exactly_ how most enterprise have been running NsDS since the
'90s, using Kerberos as the authentication end.
> (and I have users spread across several distinctive Kerberos realms
> (some Unix based, some Windows AD), to make things even more
> interesting).
The Florida Institute of Technology created a Windows side service called
"acctsync" so a segmented ADS tree could pull/push password and other,
basic meta-data changes. This was because more and more ADS-only
Windows applications were being implemented, but they still wanted to
keep NsDS as their "root" tree (where _all_ users were _always_ created/
removed first).
Translation: FIT's AcctSync turned ADS into NsDS' bitch.
This was _before_ MS Kerberos was even published, let alone any such
interoperability, hence FIT's need and eventual solution. It doesn't use
network services and protocols, but is a service that runs on the Windows
DCs themselves. The Windows DCs pull/push from/to the NsDS LDAP
stores.
http://acctsync.sourceforge.net/
[ Side Note: FIT actually didn't use SASL to Kerberos for their password
store, but hashes in the directory. But it would have worked for the
SASL/Kerberos options too IIRC. ]
> (having that functionality is "must-have" for me, before even thinking
> about downloading FDS to try it out).
Trust me, NsDS has been supporting these details for a _long_ time.
Some of it has been with 3rd party software, but others have been BSD,
GPL and other projects built around NsDS, even if it wasn't GPL before
Red Hat.
--
Bryan J. Smith mailto:b.j.smith@xxxxxxxx
