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...
Is it possible to apply the ppolicy on SASL binds?
--On Friday, September 07, 2007 5:22 PM +0200 Turbo Fredriksson turbo@bayour.com wrote:
Is it possible to apply the ppolicy on SASL binds?
I suggest you sit down and really think about this for a little bit. SASL/GSSAPI binds already know that the user has authenticated, all that is happening when talking to LDAP is the authorization part. If you want the same sort of restrictions password wise when dealing with SASL/GSSAPI, then fix your policies at the KDC. There is no way ppolicy can know how to deal with KDC password policies, since the password request *doesn't go through the LDAP server at a protocol level*.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
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.TLDBut 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.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
Quoting Pierangelo Masarati ando@sys-net.it:
that slapo-ppolicy(5) enforces a single value for the password attribute, even though such constraint is not present in the specification of userPassword.
That was not the issue, the issue was that I was authenticated with my SASL (Krb5 key) _even though I did not have {SASL} in userPassword_.
On Saturday 08 September 2007 20:18:01 Turbo Fredriksson wrote:
Quoting Pierangelo Masarati ando@sys-net.it:
that slapo-ppolicy(5) enforces a single value for the password attribute, even though such constraint is not present in the specification of userPassword.
That was not the issue, the issue was that I was authenticated with my SASL (Krb5 key) _even though I did not have {SASL} in userPassword_.
No, you were *authorized* by your sasl-regexp. You were *authenticated* by your Kerberos server.
With GSSAPI, the LDAP server doesn't do authentication.
As such, the LDAP server wasn't even consulted about whether it knows anything about your account, only that it should map your SASL identity to a DN (that need not exist in the directory).
Regards, Buchan
"Buchan" == Buchan Milne bgmilne@staff.telkomsa.net writes:
Buchan> As such, the LDAP server wasn't even consulted about Buchan> whether it knows anything about your account, only that it Buchan> should map your SASL identity to a DN (that need not exist Buchan> in the directory).
So what's the point of having {SASL} in the userPassword then?
And if it wasn't the sasl regexp, shouldn't my auth req DN be:
uid=turbo,cn=REALM,cn=sasl,cn=auth
And that DN don't have any special access, so how come I got full access to the object(s), and not the anonymous read access that I expected?
'only that it should map your SASL identity to a DN'... That's translated into a 'correct' DN by the sasl regexp - which worked... ?
Turbo Fredriksson wrote:
"Buchan" == Buchan Milne bgmilne@staff.telkomsa.net writes:
Buchan> As such, the LDAP server wasn't even consulted about Buchan> whether it knows anything about your account, only that it Buchan> should map your SASL identity to a DN (that need not exist Buchan> in the directory).So what's the point of having {SASL} in the userPassword then?
No one ever said there was any point to it. Why are you using it if you don't understand what it's for?
And if it wasn't the sasl regexp, shouldn't my auth req DN be:
uid=turbo,cn=REALM,cn=sasl,cn=authAnd that DN don't have any special access, so how come I got full access to the object(s), and not the anonymous read access that I expected?
'only that it should map your SASL identity to a DN'... That's translated into a 'correct' DN by the sasl regexp - which worked... ?
From the sound of it, yes, the SASL regexp worked as it should.
"Howard" == Howard Chu hyc@symas.com writes:
>> So what's the point of having {SASL} in the userPassword then?
Howard> No one ever said there was any point to it. Why are you Howard> using it if you don't understand what it's for?
I have no idea. It's been YEARS since I was 'taught' (?) to use it... I sat up 1.3.something-low (or was even earlier than that!?) and I haven't read a manual/doc about this in years... I've just taken my old db/config and did the absolutly nessesary changes to get it to work...
Was {KERBEROS} required in userPassword?
Howard> From the sound of it, yes, the SASL regexp worked as it Howard> should.
Oki, that looked reasonble and the only conclution I could draw from my experience..
But I'd _really_ like an explanation of the {SASL} 'thingie'...
Turbo Fredriksson wrote:
"Howard" == Howard Chu hyc@symas.com writes:
>> So what's the point of having {SASL} in the userPassword then? Howard> No one ever said there was any point to it. Why are you Howard> using it if you don't understand what it's for?I have no idea. It's been YEARS since I was 'taught' (?) to use it... I sat up 1.3.something-low (or was even earlier than that!?) and I haven't read a manual/doc about this in years... I've just taken my old db/config and did the absolutly nessesary changes to get it to work...
I don't know what planet you've been living on, but the last 1.x release of OpenLDAP was 1.2, there was no 1.3. And between 1.x and 2.3 huge volumes of new documentation have been written. You can operate with obsolete knowledge if you like, but it's smarter to read the docs that match the software revision you're working with.
Was {KERBEROS} required in userPassword?
Nothing is ever *required* in userPassword. Different things *may* be set in userPassword depending on what you want to accomplish.
Pretty sure I explained this to you several years ago. I won't bother to go thru it again.
http://www.openldap.org/lists/openldap-software/200206/msg00334.html
Howard> From the sound of it, yes, the SASL regexp worked as it Howard> should.Oki, that looked reasonble and the only conclution I could draw from my experience..
But I'd _really_ like an explanation of the {SASL} 'thingie'...
Quoting Howard Chu hyc@symas.com:
Pretty sure I explained this to you several years ago. I won't bother to go thru it again.
http://www.openldap.org/lists/openldap-software/200206/msg00334.html
Fine, I stand corrected. The 'Simple Bind' part escaped me at the time.
openldap-software@openldap.org
-
Buchan Milne -
Howard Chu -
Pierangelo Masarati -
Quanah Gibson-Mount -
Turbo Fredriksson