daniel@ncsu.edu wrote:

Note that I have not changed anything to add the ou's as a group and the ncsuCurriculumCode's as a group, but from what I understood, this should work fine for openldap, even if it may or may not be truly legit based off the RFCs. And again, I have not changed anything in this code and have been adding things like this for the past 2 years with OpenLDAP 2.2 and earlier. I mean sure I can go edit my code to add those ou's and ncsucurriculumcodes in the correct order (ie, bunched together), but if you are saying openldap should be able to handle this, I'd like to stick with it and see it resolved instead of letting it be a dangling difference behavior since 2.2. If you want to make an official-like statement that what I'm doing there is not proper and not supported, then so be it, I'll take that as golden and adjust my code. =) (in other words, would you rather it be that this is flat out not supported? .. of course if it's not supported it would be nicer if openldap yelled about it instead of accepting it and just being mad afterwards)

It is supposed to work. On my tests it does work. I have no idea what's happening on your side.

Here's a snippet from running slapadd with -d -1 for the entry I tested with. Since I didn't have your NCSU schema I substituted some other attributetypes instead, but it should be equivalent. Note that I used "ou:" and "Ou:" which would have triggered the error before. The fact that "ou" only turns up once in the oc_check_allowed messages indicates that it correctly parsed them into a single attribute.

Please send your corresponding debug output for this operation.

slapadd startup: initiated. backend_startup_one: starting "dc=example,dc=com" bdb_db_open: dc=example,dc=com bdb_db_open: Warning - No DB_CONFIG file found in directory ./testrun/db.1.a: (2) Expect poor performance for suffix dc=example,dc=com. bdb_db_open: dbenv_open(./testrun/db.1.a) => str2entry: "dn: uid=XXX,ou=people,dc=example,dc=com objectClass: person objectClass: inetOrgPerson objectClass: openldapperson uid: XXX cn: XXX sn: XXX title: Senior description: XXX organizationalStatus: registered o: NC State University gn: XXX initials: XXX displayName: XXX personalTitle: XXX departmentNumber: XXX destinationIndicator: SR Ou: Physics businessCategory: PY ou: B S - Philosophy businessCategory: LSL mail: XXX@unity.ncsu.edu labeleduri: XXX@unity.ncsu.edu registeredAddress: XXX postalAddress: XXX telephoneNumber: XXX l: Raleigh st: NC postalCode: 27603 employeeType: staff "

...

...

dnPrettyNormal: <uid=XXX,ou=people,dc=example,dc=com>

<<< dnPrettyNormal: <uid=XXX,ou=people,dc=example,dc=com>, <uid=xxx,ou=people,dc=example,dc=com> <= str2entry(uid=XXX,ou=people,dc=example,dc=com) -> 0x7734f0 oc_check_required entry (uid=XXX,ou=people,dc=example,dc=com), objectClass "OpenLDAPperson" oc_check_allowed type "objectClass" oc_check_allowed type "uid" oc_check_allowed type "cn" oc_check_allowed type "sn" oc_check_allowed type "title" oc_check_allowed type "description" oc_check_allowed type "organizationalStatus" oc_check_allowed type "o" oc_check_allowed type "givenName" oc_check_allowed type "initials" oc_check_allowed type "displayName" oc_check_allowed type "personalTitle" oc_check_allowed type "departmentNumber" oc_check_allowed type "destinationIndicator" oc_check_allowed type "ou" oc_check_allowed type "businessCategory" oc_check_allowed type "mail" oc_check_allowed type "labeledURI" oc_check_allowed type "registeredAddress" oc_check_allowed type "postalAddress" oc_check_allowed type "telephoneNumber" oc_check_allowed type "l" oc_check_allowed type "st" oc_check_allowed type "postalCode" oc_check_allowed type "employeeType" oc_check_allowed type "structuralObjectClass" => bdb_tool_entry_put( -1, "uid=XXX,ou=people,dc=example,dc=com" )