[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: krb5PrincipalName and userPassword

Turbo Fredriksson wrote:
> I've just been playing with the ppolicy overlay and noticed
> that I wasn't locked out! Took a while to figure out, but I
> was only locked out if I was using a simple bind!
> I've always used:
>      userPassword: {SASL}turbo@INT.DOMAIN.TLD
>      krb5PrincipalName: turbo@INT.DOMAIN.TLD
> But before testing ppolicy, I changed the userPassword
> to '{MD5}Xr4ilOzQ4PCOq3aQ0qbuaQ==' (=> 'secret').
> I always thought that these two went hand in hand, but
> my tests now shows that they are not. Is this so?!
> Can this have something to do with my sasl-regexp?
> ----- s n i p -----
> sasl-regexp
>         uid=(.*),cn=int.domain.tld,cn=gssapi,cn=auth
>         ldap:///c=SE??sub?krb5PrincipalName=$1@INT.DOMAIN.TLD
> ----- s n i p -----
> So the result of this is that I can have one password
> for simple binds and one for SASL binds... Not a bad
> thing, but still...

Does "playing" imply "reading the man page"?  It clearly states (fourth
paragraph) that slapo-ppolicy(5) enforces a single value for the
password attribute, even though such constraint is not present in the
specification of userPassword.

> Is it possible to apply the ppolicy on SASL binds?

With respect to SASL, it is not clearly written in the man page, I
admit, and the draft might be misleading, but slapo-ppolicy only applies
to simple bind since it's the only bind method that delegates
authentication to the backend(s).  There was an attempt to move SASL
into cooperating with the credentials storage (via SASL auxprops, which
are implemented by slapd and in principle would allow it), but it got
nowhere.  In any case, only SASL with in-directory password storage,
like *MD5, would likely allow to benefit from password policy.


Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
Office:  +39 02 23998309
Mobile:  +39 333 4963172
Email:   pierangelo.masarati@sys-net.it