Subject: Re: [ldapext] Interaction of <draft-behera-ldap-password-policy> with authentication applications

From: Andrew Bartlett <[email-masked]>
Date: Mon, 02 Jan 2006 17:23:38 +1100

On Tue, 2005-12-27 at 13:58 +0100, Pierangelo Masarati wrote:
> Dear all,
> 
> Howard Chu and I, of the OpenLDAP Project, and Alexey Melnikov of Cyrus
> SASL have been chatting about the issues of making password-based SASL
> mechs aware and respectful of any Password Policy mechanism implemented
> at the DSA that contains the passwords, and used by the SASL mechanisms
> by way of auxprop lookup.  I'll briefly summarize the private discussion
> we had, and then expose my suggestions for a possible evolution of
> draft-behera-ldap-password-policy.

> This message should be considered a notification of the problem we're
> addressing; we're open to suggestions for different solutions.  We think
> it would be important to include this further lookup-based mechanism
> into those accounted for by the LDAP password policy I.D., because it
> would broaden its application to authentication mechanisms that are
> closely related to those currently addressed.

I'm very interested in this space, due to the poor history that Samba
has achieved in solving exactly these problems in the past.  As I
develop Samba4 and it's LDAP server, I would like to move to better and
more standards-based solutions.

In particular, I have an aim that Samba4 (an implementation of many of
the AD protocols for windows domain control, amongst other things) may
back onto an arbitrary LDAP server.  This places Samba4 in the same
situation as Cyrus-SASL above.  Similarly, Samba3 is already in that
situation, and performs poorly in this area.

Firstly, I fail to see the distinction between directory authentication
and application authentication, in a well-managed solution.  This will
show in the remainder of my response.

As a history:  Traditionally, Samba3 used LDAP simply as a data store,
with no reference to it for password policy, or even synchronisation.  

Before the Samba3 release, I added support to set passwords into LDAP
using the openldap password set exop (but would only read it's own
password values).  Samba3 eventually gained support for reading the
Novell eDirectory universal password, and this is where the hacks really
started:

The password is obtained with a custom exop, and to perform the second
stage (the notification of the authentication results), a *simple bind*
was returned to the server.  The bind would be with the plaintext
password to indicate success (and the result checked to indicate if the
policy would allow the login), or with a random password to indicate
failure.

While I don't expect changes in this area for Samba3 (however anything
is possible), I would really like to see a better and standards-based
way to handle this over LDAP in Samba4.  I would like Cyrus-SASL (and
RADIUS servers etc) to operate in a Samba4 environment, and correctly
honour our password policy, in a standard manner.  A standard policy
here would also simplify the creation of alternate KDC implementations
(which would back onto Samba4 via LDAP).  

I would also like Samba4 to use the directory policy, when it is simply
a front-end to the larger directory.

So, I'm glad to hear that this area is being thought about by others.
One particular comment I have is that for a password change, I need to
be able to trigger what is considered by the directory to be a 'user
change' operation, but with administrative credentials.  This is because
we do not get the old plaintext in the kpassswd and NTLM password change
systems.  I also need to be able to return the following values
(samr.idl in samba4):

	/* password properties flags */
	const uint32 DOMAIN_PASSWORD_COMPLEX         = 0x00000001;
	const uint32 DOMAIN_PASSWORD_NO_ANON_CHANGE  = 0x00000002;
	const uint32 DOMAIN_PASSWORD_NO_CLEAR_CHANGE = 0x00000004;
	const uint32 DOMAIN_PASSWORD_STORE_CLEARTEXT = 0x00000010;
	const uint32 DOMAIN_REFUSE_PASSWORD_CHANGE   = 0x00000020;

	typedef struct {
		uint16 min_password_length;
		uint16 password_history_length;
		uint32 password_properties;

		/* yes, these are signed. They are in negative 100ns */
		dlong  max_password_age;
		dlong  min_password_age;
	} samr_DomInfo1;

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Student Network Administrator, Hawker College  http://hawkerc.net
_______________________________________________
Ldapext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext

---

From: Pierangelo Masarati <[email-masked]>
Date: Mon, 02 Jan 2006 09:03:20 +0100

Andrew,

without getting too much into the details of your message, what you
describe sounds quite close to what I mean.  The point is that the
draft-behera-ldap-password-policy is essentially intended for a simple

	client <-> server

relationship, and there seems to be no intention to broaden it to
generic password policy (which I understand, because if it needs to
account for all the different needs it could become obfuscate and nearly
unusable).

When speaking about application authentication, I mean something like

	client <-> { application <-> DSA }

where the application authenticates the client using services stored on
the DSA server, including the password and the password policy.  The
policy could still apply if you see the whole from the client's
perspective, but now the server doesn't get a simple bind but rather an
auxprop lookup, as in general we cannot turn generic password-based
authentications into simple binds.  So if we still want to apply the
password policy, using the facilities provided by the DSA,  the
responsibility has to move to the application.  Technically, this has to
result in a code duplication which, IMHO, could be eliminated by
providing some cooperation means between the application and the server.
With OpenLDAP, for example, we can circumvent this by moving password
policy enforcement into the app (in this case Cyrus SASL, but I guess it
would be essentially the same with Samba 3, as far as I know of it).
Then, the administrative operations related to storing policy info into
the DSA would be performed as regular modify, with a privileged
identity, and with the manageDIT control (undocumented, I know; it's a
work in progress) to circumvent the NO-USER-MODIFICATION constraint.

Currently, I'm working at the Cyrus SASL side to allow backpropgtion of
errors during auxprop lookup; next step will be full (well, as much as
possible) password policy awareness in OpenLDAP internal and ldapdb
external auxprop lookup functionalities.

p.

> 		/* yes, these are signed. They are in negative 100ns */

Ing. Pierangelo Masarati

Responsabile Open Solution

OpenLDAP Core Team

SysNet s.n.c.

Via Dossi, 8 - 27100 Pavia - ITALIA

http://www.sys-net.it

------------------------------------------

Office:   +39.02.23998309          

Mobile:   +39.333.4963172

Email:    [email-masked]

------------------------------------------

---

From: Andrew Bartlett <[email-masked]>
Date: Mon, 02 Jan 2006 23:46:29 +1100

On Mon, 2006-01-02 at 09:03 +0100, Pierangelo Masarati wrote:
> authentications into simple binds.  

The other reason we should consider this area as closely tied  to the
client <-> server exchange is the number of applications that still do
'ldap authentication' by simple binds...

> So if we still want to apply the

I'm unclear why we are doing modifies here.  While a complete hack, the
Novell eDirectory with Samba3 approach is I believe instructive.  I just
want a standards-based way to do it.

For logins: 
 The password should be fetched, and a password compare done.  

 A message should be sent to the server indicating: 
  - success/failure
  - source IP
  - other details (such as the NTLM 'workstation name')

 The server should handle all the modifies, I think.

For password changes:
 The existing password change exop, but with clear info on failures.
This should set all hash types etc.

I don't actually see where the manageDIT modify would come into it.  The
other point to consider is that any change should easily hook into the
code for the server-only policy

> external auxprop lookup functionalities.

If the hooks do look like what I suggest above, then we might even get
Samba3 along for this, because the internal APIs already exist for the
eDirectory case.

Andrew Bartlett

---

From: Pierangelo Masarati <[email-masked]>
Date: Mon, 02 Jan 2006 14:29:00 +0100

>  The password should be fetched, and a password compare done.  

^^^ you assume every authentication can be turned in a value compare;
for those cases, draft-behera is just fine, because it already accounts
for compare on the pwdAttribute as an authentication method.  However,
there are other password-based methods that need the value, not just a
yes/no.  This is what I'm discussing, and that's why I need separate
"lookup" and "done" methods; that's also why my needs are currently out
of the scope of draft-behera, requiring me to (re-)implement its logics
in the authentication application, using hacks to update the
authentication state info in the DSA.

>  The existing password change exop, but with clear info on failures.

All you need to use is the password policy control as described in the
draft; OpenLDAP already implements the server-side of ppolicy in an
overlay, and the client side in the library: get libldap 2.3 and that's
all.

> This should set all hash types etc.

Yes.

> code for the server-only policy

See above.

> Samba3 along for this, because the internal APIs already exist for the

Well, if you're fine with LDAP compare, yes: you can definitely have it
working in Samba 3, as far as I can tell.

p.

Ing. Pierangelo Masarati

OpenLDAP Core Team

SysNet s.n.c.

http://www.sys-net.it

Office:   +39.02.23998309          

Mobile:   +39.333.4963172

---

From: Howard Chu <[email-masked]>
Date: Mon, 02 Jan 2006 05:39:35 -0800

> authentication state info in the DSA.

As suggested, you could use a regular Bind operation to update the 
authentication state in the auxprop "done" method. As long as the done 
method is called in all cases, the lookup method doesn't need to trigger 
any updates, and the only extension we need is to define the ppolicy 
control behavior when accompanying a Search. I think this is a 
relatively benign change and ought to be rolled into draft-behera; it is 
at least as relevant as the current support for Compare operations.

-- 
   -- Howard Chu
   Chief Architect, Symas Corp.  http://www.symas.com
   Director, Highland Sun        http://highlandsun.com/hyc
   OpenLDAP Core Team            http://www.openldap.org/project/

---

From: Pierangelo Masarati <[email-masked]>
Date: Mon, 02 Jan 2006 14:53:42 +0100

> at least as relevant as the current support for Compare operations.

My point is: what if we lookup auxprops non in cleartext?  But I fear
the answer would be: use a Compare instead of a Bind...

p.

Ing. Pierangelo Masarati

OpenLDAP Core Team

SysNet s.n.c.

http://www.sys-net.it

Office:   +39.02.23998309          

Mobile:   +39.333.4963172

---

From: Andrew Bartlett <[email-masked]>
Date: Tue, 03 Jan 2006 08:58:21 +1100

> ^^^ you assume every authentication can be turned in a value compare;

Oh, I was a bit sloppy with my language.  I meant a comparison of the
challenge-response result in Samba, not an LDAP compare operation.

Andrew Bartlett

---

From: Andrew Bartlett <[email-masked]>
Date: Wed, 04 Jan 2006 23:59:51 +1100

> at least as relevant as the current support for Compare operations.

But how should this be handled if we don't store the plaintext.  I
realise this isn't where Cyrus-SASL is heading, but Samba traditionally
only stores the NT and LM hashes.  For the Samba4 work, storage of what
windows calls the 'reversibly encrypted password' is optional, and I
would hate for LDAP-based password policy to rely on it.

Also, how could I attach (to the bind operation for updating/validation
of the policy) the IP the user authenticated from (and other such
details)? 

Andrew Bartlett

---

From: Howard Chu <[email-masked]>
Date: Wed, 04 Jan 2006 19:50:53 -0800

> would hate for LDAP-based password policy to rely on it.

The enforcement of password policy works regardless of the method/hash 
used to store passwords in the directory. However, for Cyrus SASL 
secret-based mechs, obviously we need plaintext, and password 
modifications must be sent to the server in plaintext.

> of the policy) the IP the user authenticated from (and other such

These are clearly application-specific issues, and it's just this sort 
of thing I'm sure Kurt was trying to avoid dragging into the picture. It 
is right and proper that draft-behera only address features and 
behaviors relevant to an LDAP client authenticating to an LDAP server. 
When the LDAP client is itself an application authenticating on behalf 
of some other client, you've really got a proxy situation, and that 
deserves its own separate consideration.

Where the two situations overlap, it makes sense to me to unify them. I 
think there is sufficient overlap in the Cyrus SASL case. Where the two 
situations differ, it makes sense to isolate the differences. The 
password policy specification only talks about password management. A 
user's IP address may figure into authentication policy or more 
generally into access control, but that's outside the scope of a 
password discussion.

---

From: Andrew Bartlett <[email-masked]>
Date: Sat, 07 Jan 2006 08:09:56 +1100

> generally into access control, but that's outside the scope of a 

I've been looking at the spec again, from the password management angle.
I understand the intent to limit the scope here.

What I'm worried about is again an application proxy issue, but more
limited:  Strictly within the password management space, I want to
communicate to the back end the difference between:

 - user changes their password 
 - administrator changes a user's password (but must follow some
restrictions)
 - big hammer (I am going to set 'cat' and you shouldn't stop me...)

I need that in Samba4 (and indeed the first 2 in Samba3), if we are to
have the directory enforce the password policies.  However, in all cases
the bind occurs as an administrative user, as we never get the user's
cleartext in these protocols.

I presume the big hammer matches up with ManageDIT?  Could we add a
control to advise the backend of the other details?
 
Andrew Bartlett

---

From: John McMeeking <[email-masked]>
Date: Mon, 9 Jan 2006 09:00:15 -0600

Setting aside the question of what draft
might address this, it looks like there are two things (at least) to address:

1.  Proxied binds, where the server
provides a password but doesn't receive a bind request (or even compare).
An application performs authentication after using search to retreive
the password.

2.  Proxied password changes, where
the server stores the password but an application changes the password
on behalf of a user.

I assume the password is shared with
other applications or LDAP clients, otherwise there's really no need to
have LDAP password policy at all; you just need a schema.

For the proxied bind case, I think an
extended request would be appropriate.  There was some mention of
changes to search.  Unless I missed the point, it seems like that
would require two searches - one to retrieve the password and account status,
a second to somehow indicate bind success or failure.  That seems
like inappropiate use of a search control.  The extended request value
could contain an entry DN and an indication of whether the bind was successful
or not.  The server would update the password policy state accordingly.
I agree that items like clients IP address would be outside the scope
of this discussion.

For the proxied password change, I think
you'd want a control attached to the modify request (or the password change
extended request).  As I read it, the existing password policy acknowledges
a two kinds of password changes:

1.  changing your own password

2.  changing someone else's password

As you suggested, one could define a
control to cover the first case. I don't think the control needs any value,
just the presence of the control to tell the server to act like this is
a password change from the client.  At that, the LDAP Proxied Authorization
Control (draft-weltman-ldapv3-proxy-xx) might also work, though it carries
a lot more function with it unless the server implementation is restricted
to just this use.

For the second case, I don't think we
need to define anything extra.  It seems to me this falls cleanly
into the category of changing someone else's password and should be covered
by the password policy draft.  Your note suggests there might be some
holes in password policy draft - different flavors of administrative password
changes - and I don't know if the existing draft meets your needs there.

John  McMeeking

[email-masked] wrote on 01/06/2006 03:09:56

> Andrew Bartlett
http://samba.org/~abartlet/

> [attachment "signature.asc" deleted by John McMeeking/Rochester/IBM]