On Howard's suggestion I tried using the userPassword OID instead and
got another error message:

stran@educ236:~$ ldapmodify -vv -x -W -D
"uid=stran,ou=people,dc=example,dc=com" -H ldap://localhost -f
passwd_cn.ldif 
ldap_initialize( ldap://localhost )
Enter LDAP Password: 
replace cn:
        password
replace objectClass:
        organizationalRole
        pwdPolicy
replace pwdattribute:
        2.5.4.35
modifying entry "cn=password,ou=Policies,dc=example,dc=com"
modify complete
ldap_modify: No such object (32)
        matched DN: ou=Policies,dc=example,dc=com

Using the numeric OID actually worked. I wrongly used ldapmodify instead
of ldapadd. However using the name 'userPassword' still does not work.

Sam

changed notes
changed state Open to Test
moved from Incoming to Software Bugs

stran@amnh.org wrote:
> Full_Name: Samuel Tran
> Version: 2.3.7
> OS: Debian Linux Sarge
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (66.114.85.133)
>
>
> I am trying to implement the password policy overlay.
>
> When I try to create a dn that would hold the password policy, I get the
> following error:
>
> stran@educ236:~$ ldapmodify -vv -x -W -D
> "uid=stran,ou=people,dc=example,dc=com" -H ldap://localhost -f
> passwd_cn.ldif 
> ldap_initialize( ldap://localhost )
> Enter LDAP Password: 
> replace cn:
>         password
> replace objectClass:
>         organizationalRole
>         pwdPolicy
> replace pwdattribute:
>         userpassword
> modifying entry "cn=password,ou=Policies,dc=example,dc=com"
> modify complete
> ldap_modify: Invalid syntax (21)
>         additional info: pwdattribute: value #0 invalid per syntax
>
>
>   
The ppolicy overlay code in HEAD has been patched to allow descriptions 
in addition to numeric OIDs.

-- 
  -- 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/

On Tue, 2005-09-27 at 07:30 -0700, Howard Chu wrote:
> stran@amnh.org wrote:
> > Full_Name: Samuel Tran
> > Version: 2.3.7
> > OS: Debian Linux Sarge
> > URL: ftp://ftp.openldap.org/incoming/
> > Submission from: (NULL) (66.114.85.133)
> >
> >
> > I am trying to implement the password policy overlay.
> >
> > When I try to create a dn that would hold the password policy, I get the
> > following error:
> >
> > stran@educ236:~$ ldapmodify -vv -x -W -D
> > "uid=stran,ou=people,dc=example,dc=com" -H ldap://localhost -f
> > passwd_cn.ldif 
> > ldap_initialize( ldap://localhost )
> > Enter LDAP Password: 
> > replace cn:
> >         password
> > replace objectClass:
> >         organizationalRole
> >         pwdPolicy
> > replace pwdattribute:
> >         userpassword
> > modifying entry "cn=password,ou=Policies,dc=example,dc=com"
> > modify complete
> > ldap_modify: Invalid syntax (21)
> >         additional info: pwdattribute: value #0 invalid per syntax
> >
> >
> >   
> The ppolicy overlay code in HEAD has been patched to allow descriptions 
> in addition to numeric OIDs.
> 

Howard,

I just compiled the latest CVS and tried to use the description instead
of the numeric OIDs. Unfortuantely same result:

stran@info-ldap-001:/etc/openldap_REL_ENG_2_3/schema$ ldapmodify -vv -x
-W -D "cn=manager,dc=example,dc=com"
ldap_initialize( <DEFAULT> )
Enter LDAP Password: 
dn: cn=PsynchPwd,ou=Policies,dc=example,dc=com
changetype: modify
replace: pwdAttribute
pwdAttribute: userPassword

replace pwdAttribute:
        userPassword
modifying entry "cn=PsynchPwd,ou=Policies,dc=example,dc=com"
modify complete
ldap_modify: Invalid syntax (21)
        additional info: pwdAttribute: value #0 invalid per syntax


Sam

stran@amnh.org wrote:
> Howard,
>
> I just compiled the latest CVS and tried to use the description instead
> of the numeric OIDs. Unfortuantely same result:
>   

Are you sure you got the latest version (ppolicy.c 1.66)? Are you sure 
you installed it after rebuilding? It works for me.
> stran@info-ldap-001:/etc/openldap_REL_ENG_2_3/schema$ ldapmodify -vv -x
> -W -D "cn=manager,dc=example,dc=com"
> ldap_initialize( <DEFAULT> )
> Enter LDAP Password: 
> dn: cn=PsynchPwd,ou=Policies,dc=example,dc=com
> changetype: modify
> replace: pwdAttribute
> pwdAttribute: userPassword
>
> replace pwdAttribute:
>         userPassword
> modifying entry "cn=PsynchPwd,ou=Policies,dc=example,dc=com"
> modify complete
> ldap_modify: Invalid syntax (21)
>         additional info: pwdAttribute: value #0 invalid per syntax
>
>
> Sam
>
>
>   


-- 
  -- 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/

On Tue, 2005-09-27 at 18:06 -0700, Howard Chu wrote:
> stran@amnh.org wrote:
> > Howard,
> >
> > I just compiled the latest CVS and tried to use the description instead
> > of the numeric OIDs. Unfortuantely same result:
> >   
> 
> Are you sure you got the latest version (ppolicy.c 1.66)? Are you sure 
> you installed it after rebuilding? It works for me.

Howard,

I first compiled and installed OL 2.3.7 with ppolicy 1.66 from CVS. It
didn't work.

I then checked out CVS 2005-09-27, compiled it and installed it. Same
result.

Today I checked out CVS (2005-09-28), compiled it and installed it. Same
result.

When I use the numeric OID instead, it works.
Is there something else I should pay attention to? I am still using the
slapd.conf file and not the new slapd.d format.

Sam

Samuel Tran wrote:
> On Wed, 2005-09-28 at 08:25 -0700, Howard Chu wrote: 
>   
>> I think it may help to see your slapd.conf at this point.
>
> Howard,
>
> My apologies, I have several test servers and I forgot to add the
> following lines to my slapd.conf on the test server I am working on:
> overlay ppolicy
> ppolicy_default "cn=StdPwd,ou=Policies,dc=amnh,dc=org"
> ppolicy_use_lockout
>
> Now it is working as expected.
>
> Why is it required to specify the overlay in slapd.conf in order to use
> the pwdPolicy objectClass?
>
>   
You can use the objectClass in general, just by loading the schema file. 
But the code patch that changes the behavior of the pwdAttribute 
attributeType resides in the ppolicy overlay. If you don't use the 
overlay, the patch does not take effect. It wasn't clear to me that it 
was a good idea to change the objectIdentifier syntax behavior for all 
of slapd, so the patch is specific to the pwdAttribute attributeType. It 
may be a topic for discussion on -devel, whether a global change is more 
appropriate.

-- 
  -- 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/

On Wed, 2005-09-28 at 09:00 -0700, Howard Chu wrote:
> Samuel Tran wrote:
> > On Wed, 2005-09-28 at 08:25 -0700, Howard Chu wrote: 
> >   
> >> I think it may help to see your slapd.conf at this point.
> >
> > Howard,
> >
> > My apologies, I have several test servers and I forgot to add the
> > following lines to my slapd.conf on the test server I am working on:
> > overlay ppolicy
> > ppolicy_default "cn=StdPwd,ou=Policies,dc=amnh,dc=org"
> > ppolicy_use_lockout
> >
> > Now it is working as expected.
> >
> > Why is it required to specify the overlay in slapd.conf in order to use
> > the pwdPolicy objectClass?
> >
> >   
> You can use the objectClass in general, just by loading the schema file. 
> But the code patch that changes the behavior of the pwdAttribute 
> attributeType resides in the ppolicy overlay. If you don't use the 
> overlay, the patch does not take effect. It wasn't clear to me that it 
> was a good idea to change the objectIdentifier syntax behavior for all 
> of slapd, so the patch is specific to the pwdAttribute attributeType. It 
> may be a topic for discussion on -devel, whether a global change is more 
> appropriate.
> 

I saw the new functions you added in your patch.
IMHO the EQUALITY objectIdentifierMatch should be satisfied regardless
of whether the ppolicy is specified or not.

In core.schema there is that attribute 'supportedApplicationContext'
that uses the same equality constraint. I haven't used it. Does it mean
that it won't understand description?

Thanks a lot!

Sam

changed notes
changed state Test to Release

Samuel Tran wrote:
>> You can use the objectClass in general, just by loading the schema file.
>> But the code patch that changes the behavior of the pwdAttribute 
>> attributeType resides in the ppolicy overlay. If you don't use the 
>> overlay, the patch does not take effect. It wasn't clear to me that it 
>> was a good idea to change the objectIdentifier syntax behavior for all 
>> of slapd, so the patch is specific to the pwdAttribute attributeType. It 
>> may be a topic for discussion on -devel, whether a global change is more 
>> appropriate.
>>
>>     
>
> I saw the new functions you added in your patch.
> IMHO the EQUALITY objectIdentifierMatch should be satisfied regardless
> of whether the ppolicy is specified or not.
>
> In core.schema there is that attribute 'supportedApplicationContext'
> that uses the same equality constraint. I haven't used it. Does it mean
> that it won't understand description?
>   
Correct.

The larger issue here is that OIDs are not maintained in a single table 
in slapd. OIDs for AttributeTypes are recorded separately from OIDs for 
ObjectClasses, Syntaxes, Matching Rules, or any other protocol elements 
that have OIDs. While there is conceptually a single OID namespace, it 
is not implemented as a single namespace inside slapd. So a generic OID 
validator that accepts descriptors would need to look in many tables to 
validate a name.

The other issue is that descriptors aren't guaranteed to be unique. 
E.g., it's possible to have both an AttributeType and an ObjectClass 
with the same name. X.500/ASN.1 doesn't care about descriptor clashes as 
long as OIDs are unique, but this is a problem for LDAP.

The ppolicy patch works because I know that pwdAttribute will only be 
used with OIDs of AttributeTypes. In the general case, we can't make any 
such assumptions, and just searching for the first matching descriptor 
in a variety of tables may yield the wrong numeric OID. For your example 
'supportedApplicationContext' slapd doesn't have any notion of the 
namespace in which ApplicationContext descriptors are registered, so in 
that case the lookup would be futile anyway.

-- 
  -- 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/

At 09:00 AM 9/28/2005, hyc@symas.com wrote:
>It wasn't clear to me that it 
>was a good idea to change the objectIdentifier syntax behavior for all 
>of slapd, so the patch is specific to the pwdAttribute attributeType. 

It's clear to me that descriptor matching must be specific
to the attribute type, as one must know what kind of descriptor
is involved in order to do matching as descriptors are only
unique within a particular kind (attributetype, objectclass,
matchingrule, etc.).

Hence, descriptor matching can only be provided in objectIdentifierMatch
for built-in attributetypes.  There really should be
objectClassMatch, attributeTypeMatch, MatchingRuleMatch, etc.

Kurt 

At 09:41 AM 9/28/2005, hyc@symas.com wrote:
>While there is conceptually a single OID namespace, it 
>is not implemented as a single namespace inside slapd. 

This is because there is not a single descriptor name
space.  One can have a 'foo' objectClass and a 'foo'
attributeType, both referring to different OIDs.
IIRC, there is even a case of duplicate descriptor use
in the LDAP RFCs...

Kurt 

changed state Release to Closed

moved from Software Bugs to Archive.Software Bugs

fixed in HEAD/re23