Re: Cyrus SASL w/GSSAPI

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 05:20 PM 1/12/01 -0700, Brent Dunlock wrote:

>I have 2.0.7 running with Cyrus SASL w/GSSAPI on Solaris 7 and it works great as long as the user kinit's with Kerberos first.  It looks like this:
>
># ldapmodify -I -f ./modify.ldif 
>SASL/GSSAPI authentication started 
>SASL Interaction 
>Please enter your authorization name: sysgod 

This is technically an invalid authorization identity.
In LDAP, authorization identities have form:
        u:<username>
        dn:<distinguishedName>

or empty.  Empty causes the server to derive the authorization
identity from the authentication identity.  Unless you intend
to assert an authorization identity different from the one
derived from the authentication identity, you should leave
the authorization identity field empty.

In OpenLDAP 2.0, there is no "proxy policy" support.  That is,
you are expected to leave the authorization identity field
empty.

The reason why your authorization succeed is that OpenLDAP
2.0 treats an authorization identity which is the same as
the authentication identity the same as if the authorization
identity is empty.  This is done for historical reasons and
is deprecated.  I suggest you don't make a habit of using this.


>SASL username: sysgod 
>SASL SSF: 56 
>SASL installing layers 
>modifying entry "uid=sysgod,ou=People,dc=asu,dc=edu" 
>
>But now I don't know what client the users might have - they may not have the nice client that OpenLdap provides, so we need to also authenticate via simple and hop for the same result... but it seems to ignore the "userPassword: {SASL}usename" entry:

This uses whatever password check method Cyrus SASL is configured
to use (which can be per application).  The default is SASLdb.
The latest version of Cyrus SASL doesn't support Kerberos 5 check
directly (thought it would be trivial to add), but you can do
it via PAM.  However, you could just use the "{KERBEROS}principal"
scheme instead.  Note: simple authentication should only be used
when there is adequate privacy protections.


># ldapsearch  -W -x -D "uid=sysgod,ou=People,dc=asu,dc=edu" -f ./modify.ldif 
>Enter LDAP Password: 
>ldap_bind: Invalid credentials 
>
>As I understand it this should look at the userPassword entry for uid=sysgod and authenticate as such. 

It will use the userPassword values of the bind name
<uid=sysgod,ou=People,dc=asu,dc=edu>.   Invalid credentials is a generic failure,
you need to look at the server logs to determine why the
credentials were deemed invalid.

>That user is valid in our KDC, so I'm not sure what's happening here.  My ACL's look like this:
>
># Access for SASL authenticated users 
>access to dn="uid=([^,]+),ou=People,dc=asu,dc=edu" 
>        by dn="uid=$1\@ASU\.EDU" write 
>        by dn="uid=$1" write 
>        by * read 
>
># Access for simple authenticated users 
>access to * 
>        by self write 
>        by dn="cn=Manager,dc=asu,dc=edu" write 
>        by * read 
>
>Do I need to have one big butt-ugly access statment to handle both situations?  Or, am I missing something else? 

Note that second access does not apply to any entry matching
dn="uid=([^,]+),ou=People,dc=asu,dc=edu".