In the objectclass schema definition you must have one of MAY or MUST, otherwise there are no attributes considered legal by adding your supplimentary objectclass to an object, it wont affect what attributes are considered valid (valid attributes in your case are determined by the superset attributes which are allowed by the other objectclass values).

The MAY attribute you commented out does not look valid, IMHO.. from the shipped schemas :

objectclass ( 2.16.840.1.113730.3.2.2 NAME 'inetOrgPerson' DESC 'RFC2798: Internet Organizational Person' SUP organizationalPerson STRUCTURAL MAY ( audio $ businessCategory $ carLicense $ departmentNumber $ displayName $ employeeNumber $ employeeType $ givenName $ homePhone $ homePostalAddress $ initials $ jpegPhoto $ labeledURI $ mail $ manager $ mobile $ o $ pager $ photo $ roomNumber $ secretary $ uid $ userCertificate $ x500uniqueIdentifier $ preferredLanguage $ userSMIMECertificate $ userPKCS12 ) )

The first character after MAY should be "(" with a dollar delimited list of allowed attribute names, with a closing ")"

Cheers Brett

On Wed, Oct 5, 2011 at 2:52 AM, Bryce Powell Bryce.Powell@telus.com wrote:

Hi,

I need an attribute to store password expiry date for the inetOrgPerson objectClass entries in my directory. Since I could not find this or similar attribute in the existing set of schemas (including the ppolicy schema), I have tried to implemented an extension in a custom local.schema:

objectclass ( 1.3.6.1.4.1.22280.1021.4.1 NAME 'x-sdids-enPortal' DESC 'Indicates that this entry has additional attributes used by enPortal.' AUXILIARY ) # The “MAY” directive below prevents slapd form starting, and is therefore commented out. # MAY 1.3.6.1.4.1.22280.1021.3.1 )

attributeType ( 1.3.6.1.4.1.22280.1021.3.1 NAME 'x-sdids-passwordExpirationTime' DESC 'TELUS defined password policy attribute type used by enPortal.' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE userApplications )

I figured the best bet would be an auxiliary objectClass. After including the new local.schema file in the slapd.conf, and restarting slapd, I get an error when trying to add the new attribute value to an existing or new inetOrgPerson entry:

Oct 4 10:37:43 vmsdildap04 slapd[31176]: conn=1 op=22 MOD dn="uid= john@abc.com,ou=CUSTOMER,ou=Users,dc=private,dc=sdi" Oct 4 10:37:43 vmsdildap04 slapd[31176]: conn=1 op=22 MOD attr=x-sdids-passwordExpirationTime Oct 4 10:37:43 vmsdildap04 slapd[31176]: Entry (uid= john@abc.com,ou=CUSTOMER,ou=Users,dc=private,dc=sdi), attribute 'x-sdids-passwordExpirationTime' not allowed Oct 4 10:37:43 vmsdildap04 slapd[31176]: entry failed schema check: attribute 'x-sdids-passwordExpirationTime' not allowed Oct 4 10:37:43 vmsdildap04 slapd[31176]: conn=1 op=22 RESULT tag=103 err=65 text=attribute 'x-sdids-passwordExpirationTime' not allowed

I believe this error 65, as per the OpenLDAP docs, is: H.35. objectClassViolation (65) Indicates that the entry violates object class restrictions. The value I am specifying for the attribute is 20111004164129Z

I have also tried to first add an objectClass attribute value to an existing entry with value ‘x-sdids-enPortal’, and then add the ‘x-sdids-passwordExpirationTime’ attribute value, with the same outcome.

Thanks, Bryce Powell