[Fedora-directory-users] support for non-localy stored passwords?

[Aleksandar Milivojevic]

Rich Megginson wrote:
> David Boreham wrote:
> 
>> alex at milivojevic.org wrote:
>>
>>> I don't have Fedora Directory Server installed (yet).  However, 
>>> there's one
>>> feature from OpenLDAP that is must-have before even attempting to 
>>> play with
>>> FDS.
>>>
>>> In OpenLDAP, if I use string like "{SASL}username at REALM" as a value for
>>> userPassword attribute, and have "pwcheck_method: saslauthd" in
>>> /usr/lib/sasl2/slapd.conf, then OpenLDAP will use saslauthd to 
>>> authenticate the
>>> user (passing it "username at REALM" and whatever password user 
>>> supplied).  I've
>>> read that FDS supports SASL, but does it support this feautre too?
>>>  
>>>
>> 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.
> 
> 
> What problem are you trying to solve?  Are you trying to authenticate 
> apps that cannot use LDAP SASL and must use LDAP Simple BIND, and use 
> your Kerberos password?  Fedora DS has a pam_passthru plugin that might 
> help you with that.  You can tell FDS to use PAM to authenticate the 
> user, and you can configure PAM to authenticate against Kerberos.

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 at REALM" feature.