Chris Shenton chris.shenton@nasa.gov writes:

I'm running 2.3.39 and using ppolicy to enforce our password policy. Got an LDIF file:

dn: cn=npg2810,ou=policies,dc=nasascience,dc=nasa,dc=gov cn: npg2810 objectClass: top objectClass: pwdPolicy objectClass: organizationalRole objectClass: pwdPolicyChecker description: OpenLDAP ppolicy to implement NPG2810-like restrictions pwdAttribute: userPassword

pwdAttribute value should contain the OID of attribute type userpassword, which is 2.5.4.35

-Dieter

Chris Shenton skrev, on 22-02-2008 23:53:

I'm running 2.3.39 and using ppolicy to enforce our password policy. Got an LDIF file:

I run ppolicy too at my sites.

dn: cn=npg2810,ou=policies,dc=nasascience,dc=nasa,dc=gov cn: npg2810 objectClass: top objectClass: pwdPolicy objectClass: organizationalRole objectClass: pwdPolicyChecker description: OpenLDAP ppolicy to implement NPG2810-like restrictions pwdAttribute: userPassword

When I try to slapadd it, I get an error indicating it doesn't like "userPassword":

sudo sbin/slapadd -l ldifs/6_policies.ldif str2entry: invalid value for attributeType pwdAttribute #0 (syntax 1.3.6.1.4.1.1466.115.121.1.38) slapadd: could not parse entry (line=51)

I had this on my FC6 test machine the first time I ever tried out ppolicy. But I'd run the tests in the build directory after building Buchan's srpm and all tests had passed, including test022-ppolicy. Running that test again populated $BUILD_DIR/{testdata,testrun} with data for that test and I noticed that the ldif used for the test used the OID 2.5.4.35 for userPassword, rather than the string. So I put that in my ldif and it worked.

If you notice, you also get 1.3.6.1.4.1.1466.115.121.1.38 for the syntax. According to my present OL 2.4.8 setup, using gq, the correct syntax is 1.3.6.1.4.1.1466.115.121.1.40{128} (with length).

I've never had it since, have no idea why it ever occurred in the first place.

The ppolicy.schema file says:

#5.2.1 pwdAttribute # # This holds the name of the attribute to which the password policy is # applied. For example, the password policy may be applied to the # userPassword attribute.

attributetype ( 1.3.6.1.4.1.42.2.27.8.1.1 NAME 'pwdAttribute' EQUALITY objectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )

Ah. This is interesting, read on ...

And my slapd.conf includes ppolicy.schema in addition to core.schema, cosine.schema, and inetorgperson.schema.

Oddly, replacing the "userPassword" value with a random number, like "42" or "3.14159" causes no error.

I cannot find userPassword defined in any of the schemas, tho it is commented out in core.schema. If I uncomment it from core.schema it complains that it's a dupe:

sbin/slapadd -l ldifs/6_policies.ldif schema/core.schema: line 244: Duplicate attributeType: "2.5.4.35" slapadd: bad configuration file!

This is because it's built into slapd as a hard-coded entry in $BUILD_DIR/servers/slapd/schema_prep.c. There it is defined as:

{ "userPassword", "( 2.5.4.35 NAME 'userPassword' " "DESC 'RFC4519/2307: password of user' " "EQUALITY octetStringMatch " "SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128} )"

Notice the syntax? How it differs from the schema definition?

What am I missing?

That would have to be 1: experience and 2: inventiveness.

FWIW I read draft-behera thoroughly and through the whole draft it stresses that user password MUST be a single value attribute, while the above stanza makes it into a multi-value attribute. In accord with the IETF definition. I filed an ITS about this to which Howard replied words to the effect of "Probably ...". I'd noticed that if a user had access to a GUI such as phpldapAdmin or gq he could give himself whatever extra passwords he wanted and all would work. That is not what I, as admin, want. So I now patch schema_prep.c for all my builds, thus:

{ "userPassword", "( 2.5.4.35 NAME 'userPassword' " "DESC 'RFC4519/2307 adapted for draft behera: password of user' " "EQUALITY octetStringMatch " "SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128} SINGLE-VALUE )"

On the one hand IETF decrees that userPassword MUST be multi-value and on the other single-valued, go figure: "let not thy left hand know what thy right hand doeth".

Best,

--Tonni