Using a custom attribute for RDN.

I'm not allowed to show personally identifiable information to anonymous
users, and the DN needs to be visible for people to bind against it when
using AD's LDAP interface.

This means that the idea of using 'CN' (where CN contains someone's name)
is not an option. Neither is using UID, OU, or along those lines. So
what I do is generate an MD5 hash of some of the person's identifiers and
- after checking for collisions - use that.

Now, I CAN just stuff this MD5 hash into 'CN', but I'd rather keep that as
a very last resort. I'd rather use something like 'dalUUID'.

However, AD is being very, very picky about what I can use as an RDN. With
OpenLDAP, any attribute contained in the entity can be the RDN, so long as
the full RDN is unique.

I've created a 'dalUUID' attribute as a unicode string: 2.5.5.12, and with
an omSyntax of 64. I declared this as 'systemMustContain' in my dalPerson
class, and as 'rdnAttId'. dalPerson is an auxilaryClass, subclass of 'top'.
(I was using eduPerson as a template...)

AD won't let me create any 'dalUUID=<hash>,cn=Users,dc=dal,dc=ca' objects,
with a naming violation. What am I doing wrong?

-------------------------
# Attribute: dalUUID
dn: cn=dalUUID,cn=Schema,cn=Configuration,dc=X
changetype: add
objectClass: attributeSchema
attributeId: 1.3.6.1.4.1.13095.2.1.5.2
ldapDisplayName: dalUUID
attributeSyntax: 2.5.5.12
adminDescription: dal LDAP Unique Identifier
adminDisplayName: dalUUID
# schemaIDGUID: 24bc3585-0220-4c42-af7b-a625d45c6b6c
schemaIDGUID:: hTW8JCACQkyve6Yl1FxrbA==
oMSyntax: 64
searchFlags: 1
isSingleValued: TRUE
systemOnly: FALSE
-------------------------

# Class: dalPerson
dn: cn=dalPerson,cn=Schema,cn=Configuration,dc=X
changetype: add
objectClass: classSchema
governsID: 1.3.6.1.4.1.13095.2.2.1
ldapDisplayName: dalPerson
adminDisplayName: dalPerson
adminDescription:
Consists of a set of data elements or attributes about individuals at Dalhousi
e
# schemaIDGUID: ccd40cdc-dc07-4be7-a78e-79d05a094677
schemaIDGUID:: 3AzUzAfc50unjnnQWglGdw==
objectClassCategory: 3
systemOnly: FALSE
# subclassOf: top
subclassOf: 2.5.6.0
# rdnAttId: dalUUID
rdnAttId: 1.3.6.1.4.1.13095.2.1.5.2
# systemMustContain: dalUUID
systemMustContain: 1.3.6.1.4.1.13095.2.1.5.2
# mayContain: dalBannerID
mayContain: 1.3.6.1.4.1.13095.2.1.0.0
# mayContain: dalBarCode
mayContain: 1.3.6.1.4.1.13095.2.1.0.7
# mayContain: dalChangePasswordCode
mayContain: 1.3.6.1.4.1.13095.2.1.0.1
# mayContain: dalExpiresOn
mayContain: 1.3.6.1.4.1.13095.2.1.0.4
# mayContain: dalLastSeen
mayContain: 1.3.6.1.4.1.13095.2.1.0.2
# mayContain: dalOldUserPassword
mayContain: 1.3.6.1.4.1.13095.2.1.0.9
# mayContain: dalPasswordExpiresOn
mayContain: 1.3.6.1.4.1.13095.2.1.0.3
# mayContain: dalPersonEmergencySMSNumber
mayContain: 1.3.6.1.4.1.13095.2.1.1.8
# mayContain: dalPersonEmployeeTypeClass
mayContain: 1.3.6.1.4.1.13095.2.1.1.9
# mayContain: dalPersonExpiredAffiliation
mayContain: 1.3.6.1.4.1.13095.2.1.1.6
# mayContain: dalPersonInternationalNumber
mayContain: 1.3.6.1.4.1.13095.2.1.1.7
# mayContain: dalPublish
mayContain: 1.3.6.1.4.1.13095.2.1.0.5
# possSuperiors: container
possSuperiors: 1.2.840.113556.1.3.23
# possSuperiors: domainDNS
possSuperiors: 1.2.840.113556.1.5.67
# possSuperiors: organizationalUnit
possSuperiors: 2.5.6.5
# defaultObjectCategory: dalPerson
defaultObjectCategory: cn=dalPerson,cn=Schema,cn=Configuration,dc=X

-------------------------

--
Brandon Hume - hume -> BOFH.Ca, http://WWW.BOFH.Ca/

wrote:
> dn: cn=dalPerson,cn=Schema,cn=Configuration,dc=X
> objectClassCategory: 3

I changed this from auxilary to structural and seem to have fixed this
particular problem. (Yay!)

--
Brandon Hume - hume -> BOFH.Ca, http://WWW.BOFH.Ca/