> I have also had to tackle the problem of disambiguating entries in a large
> corporate directory. I think the solution I used works but is illegal (or at
> least immoral). We have unique Employee Id Numbers and I constructed entries
> looking like:
>
> dn: cn=Joe Soap (123456), o=BT plc, c=gb (1)
> cn: Joe Soap
> ein: 123456
> objectclass: BTperson
>
> The number at the right is for reference and is not part of the dn. It seems
> I should have actually used a dn like:
>
> dn: cn=Joe Soap+ein=123456, o=BT plc, c=gb (2)
>
> However, given that dns only exist to uniquely label entries then the
> following would suffice:
>
> dn: ein=123456, o=BT plc, c=gb (3)
>
> My questions/comments are:
Others have given good answers - I'd just like add that if your DSA will
be connected to the outside world, it is nice (but not mandatory) if your
DNs use standard X.500 attributes rather than internal ones. For example,
if you use the 1988 "serialNumber" attribute to hold the employee ID then
you can browse and view your DIT with any X.500-88 compliant user agent.
My vote would be for form #2 unless you expect to *NEVER* display DNs to
users. Even then it would probably make your life easier if you could see
the more meaningful DNs in your logs rather than just "ein=123456, o=BT
plc, c=gb".
Eric
---------------------------------------------------------------------
Eric Rosenquist, Strata Software Limited http://www.strataware.com/
Email: rosenqui@strataware.com Tel: 613-591-1922 Fax: 613-591-3485
Quote: He had very thin English skin and very thick alcoholic blood.
-- David St. Hubbins of Spinal Tap
---------------------------------------------------------------------