alex(a)milivojevic.org wrote: Nope. Is this a currently supported OpenLDAP feature ? I ask because I vaguely remember some feature like this being dropped on the basis that it was a stop-gap until real SASL support was implemented. But I may well be thinking of some similar but different feature. FDS does support SASL but I think you'd need to do some extra work to get it to work with the saslauthd plugin. GSSAPI and EXTERNAL are the only two 'officially' supported SASL mechanisms.

My guess was that since saslauthd is involved, that he wants to authenticate against an existing cyrus-sasl user database. I think it may be possible to do that via PAM.

It occurs to me that a simple pre-operation bind plugin plus pam would probably solve your problem. The plugin would alter the bind credentials so that the realm is added appropriateley - then it is simply a matter of setting up kerberos correctly for multiple domains and using the kerberos pam plugin. For that matter a simple pam auth plugin could do this too, though slightly less efficiently since it would need to query the DS to get the realm. Of course, this all requires code :)

Rich Megginson wrote: To answer David first. Yes, that is an supported and documented feature, AFAIK. Rich, I'm affraid answer to your question will be much longer ;-) The problem I have is that I need to authenticate users against Active Directory. There are multiple Active Directory domains for managing various user groups, each completely independently managed. Windows uses Kerberos internally for user authentication (basically, every Active Directory domain is also a Kerberos domain). Suprisingly for Microsoft, their Kerberos implementation is relatively standard conformant, and interoperates nicely with Unix Kerberos implementations. What I currently have is something like this. I have one "corporate" Kerberos domain. Hosts and services running on my Unix servers are placed into that domain, as well as several users that don't have accounts in any of Active Directory domains. Then, I have one-way trust relationship between "corporate" domain and Windows Active Directory servers ("corporate" side trusts Windows side to authenticate users). Now, all Unix based "corporate" services authenticate against "corporate" LDAP server (and use it for storing all kind of other needed information). This "corporate" LDAP server will than use saslauthd to check the password. Saslauthd is configured to use kerberos5 backend. It simply checks the password against appropriate Kerberos domain for that user (for most users it will be one of Active Directory servers). Of course, if the user has Kerberos capable client (usually not the case) and he has a valid Kerberos ticket, than that would be sufficient for authentication. Not many client programs on Windows side actually support Kerberos, so basically they will use classic username/password, and the Unix side would than check the password against appropriate Kerberos server as described above. So, the Kerberos here is not used the way it is intended to be used (single sign on, tickets, and stuff). It is just used as convinient way for Unix side to authenticate against Active Directory domains. Basically, it was a simple way of solving the problem of storing user's password in single place that could be used by all possibly imaginable clients and servers running on all imaginable platforms... If I want to replace OpenLDAP with FDS, obviously I first need to solve a problem that user's passwords are not going to be stored in FDS. They are stored in multiple Active Directory domains (the keyword here is "multiple", which complicates things). In FDS, I could place only the pointer where the user can be authenticated. In OpenLDAP this was accomplished by using "{SASL}user@REALM" feature.