From: alex@milivojevic.org
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@ieee.org
Quoting "Bryan J. Smith b.j.smith@ieee.org" thebs413@earthlink.net:
The SASL capability can interface with any GSSAPI solution IIRC. I _know_ that includes a _real_ KDC.
I'm not talking about LDAP server supporting SASL GSSAPI here. This is completely different. I'm talking about LDAP server talking to saslauthd to perform the authentication, passing it the string from userPassword attribute as username/realm part.
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.
As I said above, it's not how they have been doing it.
They are using SASL GSSAPI. I'm not. My clients are not capable of it. Actually, they are not capable of SASL anything. I'm lucky they are capable of SSL/TLS so passwords do not fly around in cleartext.
What happens in my case is:
1) user joe connects to IMAP server (for example, or some other service), and uses plaintext LOGIN to authenticate with his username (joe) and password (sex, easy to remember and fast to type)
2) IMAP server is configured to check username/password against LDAP server, so it attempts to perform simple bind as uid=joe,ou=smurfs,dc=myorg,dc=com
3) LDAP server finds that blah=joe,ou=smurfs,dc=myorg,dc=com has userPassword attribute with value {SASL}joe.the.big.guy@BLUE.MYORG.COM. The {SASL} at the begining of the string triggers it to connect to saslauthd and passes joe.the.big.guy@BLUE.MYORG.COM and user supplied password
4) saslauthd (configured to use kerberos5 backend) checks password against joe.the.big.guy@BLUE.MYORG.COM principal in BLUE.MYORG.COM Kerberos domain and returns "go" or "no go".
In this example, the LDAP server simply holds the mapping between user's username on mail server and his Kerberos principal name (it holds other stuff too, I haven't installed it just to get simple authentication working). As I said, there are multiple domains, so IMAP server can't simply slap @REALM to the end of user supplied username and do the check directly. For historical reasons, IMAP server uses flat userspace (while in reality it is more tree-like). And nope, having users type the @REALM part during login is not acceptable solution (most of them don't even know what @REALM should be, nor should they be bothered with such details).
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
-
alex＠milivojevic.org -
Bryan J. Smith <b.j.smith＠ieee.org>