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