LDAP Server Schema Validation

[regenrek]

Hi

I try to setup the InMemoryDirectorySevicer with a custom Schema. After Server startup the server fails with some error and I can't really find the issue here.

I guess its more likely a LDAP Schema issue but is there any hint how I can get some more to debug this error.

InMemoryListenerConfig dsListener = new InMemoryListenerConfig(name, addr, port, null, null, null);
config.setSchema(Schema.getSchema(new ClassPathResource("/schema.ldif").getFile()));
InMemoryDirectoryServer ds = new InMemoryDirectoryServer(config);
// importLDIF data ...
ds.startListening();

Error

Caused by: com.unboundid.ldap.sdk.LDAPException: Unable to add entry 'uid=ID_100,dc=example,dc=com' because it violates the provided schema:  The entry contains object class com-customview which is not defined in the schema.  The entry contains attribute cn which is not allowed by its object classes and/or DIT content rule.  The entry contains attribute customField which is not defined in the schema. The entry contains attribute street which is not allowed by its object classes and/or DIT content rule. The entry contains attribute l which is not allowed by its object classes and/or DIT content rule.The entry contains attribute uid which is not allowed by its object classes and/or DIT content rule.  The entry's RDN contains attribute uid which is not allowed to be included in the entry.

Since this is a dumped schema from another ldap it should work and the entries are all here. I can post some snippet of the schema here

dn: cn=schema
objectClass: top
objectClass: ldapSubEntry
objectClass: subschema
cn: schema
objectClasses: ( 1.2.6.1.4.1.17031.0.3.2 NAME 'com-customview' DESC '' STRUCTUR
 AL MAY  (givenName $ sn $ street $ l  $ st $ displayName $ customField
  title $ organization $ otherName $) MUST (uid $ personalEntry $ cn) )
attributeTypes: ( 1.2.6.1.4.1.17031.0.5.3.1 NAME 'customField' DESC '' EQUALITY case
 IgnoreMatch ORDERING caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 USAGE userApplications )

I can turn the schema validation off but then aliases like st -> stateOrProvinceName aren't working correctly...

[dirmgr]

There are a few issues with the portions of the schema that you provided. They include:

• Both of the elements include DESC '' as part of their definition. This is not allowed because schema elements cannot contain empty quoted strings. RFC 4512 section 4.1.1 states that the DESC element for an object class definition has a type of qdstring, and section 4.1.2 does the same for attribute type definitions. The 4.1 section states that qdstring is a dstring surrounded by single quotes, and that dstring is one or more characters from an escaped UTF-8 string. Since empty quoted strings are not allowed, the LDAP SDK can't parse those definitions. You can work around this by just removing the DESC '' portion of the definitions, or by putting something between the quotes.

• In addition to the empty quoted string , the object class definition has an issue with misplaced dollar signs. The list of MAY attribute types is missing a dollar sign between the customField and title types, and it has an illegal trailing dollar sign just before the closing parenthesis. Also note that technically as per RFC 4512 section 4.1.1, the MUST elements must come before the MAY elements, but the LDAP SDK isn't too picky about that.

• The object class definition is missing the SUP element that indicates its superclass. Assuming that it's not intended to inherit from any other object class, you should include SUP top before the STRUCTURAL component of the object class definition. The specification actually isn't all that clear about whether this is actually a problem. The top object class doesn't have a superior class and as such the specification has to permit at least the definition for the top object class to omit the superior class, but it doesn't say how to handle other object classes without a superior. The LDAP SDK doesn't like it, but I could probably relax the parsing to assume that an object class other than top that doesn't have a superior is assumed to have a superior class of top.

• The sample that you offered doesn't include a definition for the nonstandard personalEntry attribute type. It's entirely possible that your full schema has it but you just omitted it in this example.

The first two of these would have been caught by the LDAP SDK if you had used the Schema.getSchema(File, boolean) method instead of just Schema.getSchema(File). That second boolean argument tells the schema parser to throw an exception if it encounters an unparsable schema element rather than just silently ignoring it. The error message that is returned may not have specifically told you that the DESC element was the problem, but it would have said that the definition could not be parsed because it contained an empty quoted string, and that probably would have let you figure out that the DESC element was the problem. And once you got past that, then it would have failed because of the dollar sign problems in the MAY list.

Unfortunately, the other two issues are something that isn't as easy to spot using what the LDAP SDK currently provides. Once it was able to parse all of the schema elements, it wouldn't have complained about the undefined personalEntry attribute. I'll look into updating the schema to add a method to validate the schema and ensure that it doesn't include undefined references.