Fedora directory users - Jun 2005 - support for non-localy stored passwords?

Hi,

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@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@REALM" and whatever password user
supplied).  I''ve
read that FDS supports SASL, but does it support this feautre too?

Thanks,
Aleksandar Milivojevic

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

alex@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@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@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.

David Boreham wrote:
> alex@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@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@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.
>
>
>
>
>
>
> -- 
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users

>
> 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.
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.

Rich Megginson wrote:
> David Boreham wrote:
> 
>> alex@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@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@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@REALM" feature.

David Boreham wrote:
> 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.
What I have are users that effectively belong to several Kerberos 
domains (this way or the other).

User types in only the "username" part.  What Kerberos domain it
belongs
to is stored in LDAP database.  For simple PAM solution to work, user 
would need to type "username@REALM" (since there is more than one
REALM
involved), which is not acceptable solution in my case.

Basically, I started with the similar ideas as you and Rich sugested 
when solving problem with OpenLDAP.  And the things always broke at the 
multiple Kerberos domains used and the fact that user''s were not 
supplying the domain portion as part of their login.  At the end, using 
{SASL}username@REALM was the solution suggested on SASL and OpenLDAP 
mailing lists, and it worked great so far.

Quoting David Boreham <david_list@boreham.org>:
> Is this a currently supported OpenLDAP feature ?
The {SASL}username@REALM works on all OpenLDAP versions shipped with 
Red Hat 7.3
(probably earlier too) up to FC3 and RHEL4.  I haven''t checked OpenLDAP
shipped
with FC4, but my guess is that it should work on FC4 too.  It is also 
mentioned
in many HOWTOs dealing with non-trivial authentication configurations.  While
probably not very widespread (most people have only one Kerberos domain, or
some other password store, and even more people simply have passwords stored
inside LDAP database), I guess there are many OpenLDAP installations that take
advantage of it.

Anyhow, if something like this is not possible with current version of FDS,
posibility to use saslauthd and to create mappings between LDAP objects and
external entities (against which passwords should be checked) would be 
nice and
usefull features to have in FDS.

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

> -----Original Message-----
> From: fedora-directory-users-bounces@redhat.com 
> [mailto:fedora-directory-users-bounces@redhat.com] On Behalf 
> Of Aleksandar Milivojevic
> Sent: Tuesday, June 28, 2005 8:19 PM
> To: david_list@boreham.org; General discussion list for the 
> Fedora Directory server project.
> Subject: Re: [Fedora-directory-users] support for non-localy 
> stored passwords?
> 
> Basically, I started with the similar ideas as you and Rich 
> sugested when solving problem with OpenLDAP.  And the things 
> always broke at the multiple Kerberos domains used and the 
> fact that user''s were not supplying the domain portion as 
> part of their login.  At the end, using {SASL}username@REALM 
> was the solution suggested on SASL and OpenLDAP mailing 
> lists, and it worked great so far.
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 :)

Quoting Pete Rowley <pete@openrowley.com>:
> 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 :)
Hmmm...  Somehow I have a feeling that it would take less coding to add 
support
for ''{SASL}'' stuff in FDS password verification code ;-)

(haven''t seen the actual code, so just a wild guess)

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.