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.
