OpenLDAP
Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest

Viewing Software Enhancements/6250
Full headers

From: michael@stroeder.com
Subject: Password modify ext.op. - automagically add simpleSecurityObject
Compose comment
Download message
State:
0 replies:
9 followups: 1 2 3 4 5 6 7 8 9

Major security issue: yes  no

Notes:

Notification:


Date: Tue, 11 Aug 2009 18:08:11 +0000
From: michael@stroeder.com
To: openldap-its@OpenLDAP.org
Subject: Password modify ext.op. - automagically add simpleSecurityObject
Full_Name: Michael Str.der
Version: HEAD
OS: openSUSE Linux 11.1
URL: 
Submission from: (NULL) (84.163.50.194)


If one trys to set the userPassword with a Password Modify ext. op. request but
the object classes of the entry does not allow userPassword slapd could add
automagically AUXILIARY object class simpleSecurityObject to the entry.

(I'm doing this in web2ldap since years when changing the userPassword with a
normal modify operation which client-side hashing.)

Followup 1

Download message
Date: Tue, 11 Aug 2009 12:39:28 -0700
From: Howard Chu <hyc@symas.com>
To: michael@stroeder.com
CC: openldap-its@openldap.org
Subject: Re: (ITS#6250) Password modify ext.op. - automagically add	simpleSecurityObject
michael@stroeder.com wrote:
> Full_Name: Michael Str.der
> Version: HEAD
> OS: openSUSE Linux 11.1
> URL:
> Submission from: (NULL) (84.163.50.194)
>
>
> If one trys to set the userPassword with a Password Modify ext. op. request
but
> the object classes of the entry does not allow userPassword slapd could add
> automagically AUXILIARY object class simpleSecurityObject to the entry.
>
> (I'm doing this in web2ldap since years when changing the userPassword with
a
> normal modify operation which client-side hashing.)

This request sounds like a mistake to me. The DSA is supposed to enforce the 
data model, not automagically enable you to bypass the model. What clients do 
is a completely separate matter...

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



Followup 2

Download message
From: Hallvard B Furuseth <h.b.furuseth@usit.uio.no>
Date: Tue, 11 Aug 2009 21:44:30 +0200
To: hyc@symas.com
Cc: openldap-its@openldap.org
Subject: Re: (ITS#6250) Password modify ext.op. - automagically
	add	simpleSecurityObject
hyc@symas.com writes:
> This request sounds like a mistake to me. The DSA is supposed to
> enforce the data model, not automagically enable you to bypass the
> model. What clients do is a completely separate matter...

It makes sense if you add a config parameter with an LDAP URL or
something describing entries which can be so modified (subject to
ordinary access controls).

-- 
Hallvard



Followup 3

Download message
From: Hallvard B Furuseth <h.b.furuseth@usit.uio.no>
Date: Tue, 11 Aug 2009 21:47:39 +0200
To: hyc@symas.com, openldap-its@openldap.org
Subject: Re: (ITS#6250) Password modify ext.op. - automagically
	add	simpleSecurityObject
Sorry, sent too early.
> It makes sense if you add a config parameter with an LDAP URL or
> something describing entries which can be so modified (subject to
> ordinary access controls).

I imagine one would typically filter for objectClass, e.g.
ldap:///???(objectClass=person)



Followup 4

Download message
Date: Tue, 11 Aug 2009 21:53:00 +0200
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <michael@stroeder.com>
To: hyc@symas.com
CC: openldap-its@openldap.org
Subject: Re: (ITS#6250) Password modify ext.op. - automagically	add simpleSecurityObject
hyc@symas.com wrote:
> michael@stroeder.com wrote:
>> Full_Name: Michael Str.der
>> Version: HEAD
>> OS: openSUSE Linux 11.1
>> URL:
>> Submission from: (NULL) (84.163.50.194)
>>
>>
>> If one trys to set the userPassword with a Password Modify ext. op.
request but
>> the object classes of the entry does not allow userPassword slapd could
add
>> automagically AUXILIARY object class simpleSecurityObject to the entry.
>>
>> (I'm doing this in web2ldap since years when changing the userPassword
with a
>> normal modify operation which client-side hashing.)
> 
> This request sounds like a mistake to me. The DSA is supposed to enforce
the 
> data model, not automagically enable you to bypass the model. What clients
do 
> is a completely separate matter...

Let's assume the policy for a deployment is that password changes MUST be
applied by using password modify ext. op. (e.g. because smbk5pwd is used or
similar) and you want to use object class 'account' for user entries. How
could the attribute 'userPassword' be added to the user entry then? It's kind
of a dead-lock situation.

Ciao, Michael.



Followup 5

Download message
Date: Tue, 11 Aug 2009 13:11:44 -0700
From: Howard Chu <hyc@symas.com>
To: =?ISO-8859-1?Q?Michael_Str=F6der?= <michael@stroeder.com>
CC: openldap-its@openldap.org
Subject: Re: (ITS#6250) Password modify ext.op. - automagically	add simpleSecurityObject
Michael Str.der wrote:
> hyc@symas.com wrote:
>> michael@stroeder.com wrote:
>>> Full_Name: Michael Str.der
>>> Version: HEAD
>>> OS: openSUSE Linux 11.1
>>> URL:
>>> Submission from: (NULL) (84.163.50.194)
>>>
>>>
>>> If one trys to set the userPassword with a Password Modify ext. op.
request but
>>> the object classes of the entry does not allow userPassword slapd
could add
>>> automagically AUXILIARY object class simpleSecurityObject to the
entry.
>>>
>>> (I'm doing this in web2ldap since years when changing the
userPassword with a
>>> normal modify operation which client-side hashing.)
>>
>> This request sounds like a mistake to me. The DSA is supposed to
enforce the
>> data model, not automagically enable you to bypass the model. What
clients do
>> is a completely separate matter...
>
> Let's assume the policy for a deployment is that password changes MUST be
> applied by using password modify ext. op. (e.g. because smbk5pwd is used or
> similar) and you want to use object class 'account' for user entries. How
> could the attribute 'userPassword' be added to the user entry then? It's
kind
> of a dead-lock situation.

Then you made a mistake in your data design. You should have chosen an 
objectclass (or set of objectclasses) that supports authentication from the 
outset. To me this is analogous to the usual prohibition against changing an 
object's structural class - you cannot change a car into a pencil. You cannot 
change a non-user into a user.

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



Followup 6

Download message
Date: Tue, 11 Aug 2009 22:16:52 +0200
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <michael@stroeder.com>
To: Howard Chu <hyc@symas.com>
CC: openldap-its@openldap.org
Subject: Re: (ITS#6250) Password modify ext.op. - automagically	add simpleSecurityObject
Howard Chu wrote:
> Michael Str.der wrote:
>> Let's assume the policy for a deployment is that password changes MUST
be
>> applied by using password modify ext. op. (e.g. because smbk5pwd is
>> used or
>> similar) and you want to use object class 'account' for user entries.
How
>> could the attribute 'userPassword' be added to the user entry then?
>> It's kind
>> of a dead-lock situation.
> 
> Then you made a mistake in your data design.

Nope. Since with a modify request I can achieve the goal by adding object
class 'simpleSecurityObject'. IMO password modify ext.op. should result in
userPassword being added. One could view it as a hen-and-egg problem because
'simpleSecurityObject' is mandating 'userPassword'.

> You should have chosen an
> objectclass (or set of objectclasses) that supports authentication from
> the outset. To me this is analogous to the usual prohibition against
> changing an object's structural class - you cannot change a car into a
> pencil. You cannot change a non-user into a user.

Please don't compare apples with pies.

'account' is STRUCTURAL so the user entry represents already a user.
'simpleSecurityObject' is AUXILIARY (not STRUCTURAL) which adds another
attribute. The STRUCTURAL object class of the entry is not altered, so no
magic change from a car into a pencil here.

Ciao, Michael.



Followup 7

Download message
Date: Tue, 11 Aug 2009 22:18:55 +0200
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <michael@stroeder.com>
To: michael@stroeder.com
CC: openldap-its@openldap.org
Subject: Re: (ITS#6250) Password modify ext.op. - automagically add simpleSecurityObject
michael@stroeder.com wrote:
> Howard Chu wrote:
>> Michael Str.der wrote:
>>> Let's assume the policy for a deployment is that password changes
MUST be
>>> applied by using password modify ext. op. (e.g. because smbk5pwd is
>>> used or
>>> similar) and you want to use object class 'account' for user
entries. How
>>> could the attribute 'userPassword' be added to the user entry then?
>>> It's kind
>>> of a dead-lock situation.
>> Then you made a mistake in your data design.
> 
> Nope. Since with a modify request I can achieve the goal by adding object
> class 'simpleSecurityObject'. IMO password modify ext.op. should result in
> userPassword being added. One could view it as a hen-and-egg problem
because
> 'simpleSecurityObject' is mandating 'userPassword'.

I agree with Hallvard that this should be made configurable. So the admin
could specify whether and which AUXILIARY object class is added.

Ciao, Michael.



Followup 8

Download message
Date: Tue, 11 Aug 2009 13:26:56 -0700
From: Howard Chu <hyc@symas.com>
To: michael@stroeder.com
CC: openldap-its@openldap.org
Subject: Re: (ITS#6250) Password modify ext.op. - automagically	add	simpleSecurityObject
michael@stroeder.com wrote:
> Howard Chu wrote:
>> Michael Str.der wrote:
>>> Let's assume the policy for a deployment is that password changes
MUST be
>>> applied by using password modify ext. op. (e.g. because smbk5pwd is
>>> used or
>>> similar) and you want to use object class 'account' for user
entries. How
>>> could the attribute 'userPassword' be added to the user entry then?
>>> It's kind
>>> of a dead-lock situation.
>>
>> Then you made a mistake in your data design.
>
> Nope. Since with a modify request I can achieve the goal by adding object
> class 'simpleSecurityObject'. IMO password modify ext.op. should result in
> userPassword being added. One could view it as a hen-and-egg problem
because
> 'simpleSecurityObject' is mandating 'userPassword'.

Since the ppolicy overlay already provides the facility for hashing plaintext 
passwords on Add and Modify, there's no reason you couldn't have just created 
the objects correctly in the first place.

>> You should have chosen an
>> objectclass (or set of objectclasses) that supports authentication from
>> the outset. To me this is analogous to the usual prohibition against
>> changing an object's structural class - you cannot change a car into a
>> pencil. You cannot change a non-user into a user.
>
> Please don't compare apples with pies.

It was an analogy, not a literal comparison. Don't lose the main point, which 
is that changing a non-user into a user is a significant change in the purpose 
of an object.

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



Followup 9

Download message
Date: Thu, 22 Apr 2010 03:51:20 +0200 (CEST)
Subject: ITS#6250
From: masarati@aero.polimi.it
To: openldap-its@openldap.org
Why is this ITS in software development, and open?  Anyone intends to
develop that feature, despite the discussion?

p.


Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest


The OpenLDAP Issue Tracking System uses a hacked version of JitterBug

______________
© Copyright 2013, OpenLDAP Foundation, info@OpenLDAP.org