I create DN's using cn, and dceUuid. DCE UUID's are unique 128-bit
values, in the database, I represent them in string form. i.e.
dn: cn=James Robert Doyle, dceuuid=861a5b31-8d7e-101f-8ec7-080069089ac6, \
o=Boston University, c=US
If you are using and/or considering DCE to provide the various things
that people at Universities use it for (DFS, Kerberos V5, single-signon,
apps, etc). Then you already have DCE uuids generated for every principal
in the DCE RGY.
My choice for using dce uuids is that they provide a unique-ifer
to the DN, they are attributes that are useful and meaningful to
other components of our distributed computing environment and
they are provide no other additional information about the entity
(i.e. direct or implicit personal information). They are the best
kind of uniquefier - because there is only (or should be) only one
UUID of its kind in the entire world.... And there will never be
another one quite like it. :)
I figure that most users will not directly operate with full DN's,
but rather, will use a lookup applications that returns to them a
number of X.500 entries which they will choose from, and then the
application will use the DN internally... Seems like a legit argument
in this age of GUI applications.
> Obviously, searching for Tran Nguyen will return 50 hits no matter how
> fully you specify the search. That's a problem, but so is asking 411 for
> the phone number of John Lee in San Francisco. You don't get a usable
> result, but you don't break the system, either. Will duplicate DNs break an
> LDAP system, or will they just return multiple hits?
There cant be duplicate DN's.
> Option 3 would also be easy to implement and it would assure unique DNs,
> but it seems rather antithetical to the whole concept of X.500-style
> naming. It's also very cumbersome, since most people here at Davis don't
> even know what their own handle is, let alone people from outside searching
> our database. I'm not sure how useful the resulting database would be. It
> would also make it difficult or impossible to join our database with a more
> global server, since our DNs would not follow a standard hierarchy for
> query resolution.
There are standard schemas with standard attribute names... You can
extend them with local attributes relevant to your organization
(i.e. student status, major, YOG, etc ).
FYI- I am using SLAPD (BSD 4.4 BTree) with 51,000 entries.. Its a limited
pilot right now, but so far its working out for us very well.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Jim Doyle Boston University Information Technology
Systems Analyst/Programmer Distributed Systems Group tel: 617-353-8248
"UNIX for a stronger America" email: jrd@bu.edu fax: 617-353-6260
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++--+-+-+-+-+-+-