Subject: immutable, permanent DNs @ Stanford

From: [email-masked]
Date: Fri, 09 Jan 1998 01:43:16 -0800

I have a test directory up that folks are welcome to poke at...

  ldap://director.stanford.edu:389/

For example, you can point Netscape Communicator 4.X's "Search Directory" tool 
(available from the Edit menu) at it (by editing Edit:Preferences:Mail & 
Groups:Directory and adding info about ldap://director.stanford.edu:389/, with 
a search root of "dc=stanford,dc=edu").

You should then be able to get at the test entries by setting the "Search 
Directory" tool to..

  search for items in 'director' where the 'name' 'contains' 'entry'

An "ldapsearch" command that returns similar results is..

  ldapsearch -h director.stanford.edu -b dc=stanford,dc=edu objectclass=\* dn

  (this command assumes a standard cshell command-line interface)

You'll get four entries back, without having to know anything about their DNs, 
or specifically the attribute used to construct the entries' RDNs.

You can now double-click on each of these entries to get a detailed view 
(which will expose the entry's DN as a side-effect). Also, you can get the 
Stanford University entry by setting the "Search Directory" tool to..

  search for items in 'director' where the 'organization' 'contains' 'SU'

An "ldapsearch" command that returns the same results is..

  ldapsearch -h director.stanford.edu -b dc=stanford,dc=edu -s base 
objectclass=\*

  (this command also assumes a standard cshell command-line interface)

So, about the DNs, they (presently) look like this...

 regid=3000169d-b824-21d1-8300-ab400e0baa77, ou=People, dc=Stanford, dc=edu

"regid" is short for "Registry ID". The ID presently used is a dce-uuid-based 
id. It could, and we're planning that it will be, a guaranteed-unique, 
non-resuable number generated by our Person Registry [1].

Also, all person entries are contained in the ou=People flat space. 
Organizational information will be contained in attributes in the person 
entries themselves. Should we decide that its useful for our directory to 
provide a browseable organizational representation, we'll likely implement 
that in a subtree parallel to ou=People, and utilize aliases/references to 
point back to the person entries.

Some folks will claim "the DNs aren't easily human-consummable." And, they are 
nominally correct. We're confident though, that as more applications vendors 
(and our own in-house staff) become more educated about LDAP/X.500-based 
directory technology, they'll create tools that shelter users from DN 
intricities, and instead focus on using well-known "naming attributes" (I'm 
not using "naming" in the strict X.500 sense here).
  
A very good example of this trend is NS Communicator's directory 
functionality. Notice how, in the examples above, the user doesn't interact 
directly with DNs, but rather with focused attributes (such as cn), that serve 
as user-perceivable names for the entries for search purposes. Once the 
entries are read, then the app can cache the DN and use it as a "key" for 
base-object *lookups*.

Additionally, Communicator is highly configurable -- see...

 http://developer.netscape.com/library/documentation/communicator/custom.htm

 (note that there may be newer documentation available (pls lemme know if so))

..for the details on how. Note that they allow one to configure how attributes 
are used in these fashions..

  * the displayed name of attributes
  * the set of attributes available for use in search specifications
  * which attributes and how they are used "under the hood" in search filters 
  * object classes used "under the hood" in search filters

I believe that we need to encourage vendors in general to provide similar 
levels of configurability in their directory-based wares, rather than the IETF 
trying to produce standards-track docs such that they can figure out what 
attributes to hard code into their dialogs.

Thanks,

Jeff
----

[1] The Registries Project pages...

  http://www.stanford.edu/group/itss-ccs/project/registry

---

From: Alexis Bor <[email-masked]>
Date: Fri, 9 Jan 1998 09:15:35 -0800

Jeff,
After many efforts at various different DN naming approaches between
1990 and 1995, I ended up with the same conclusion - that the DN is just
a unique pointer to an entry and nothing else.  This really makes life
much simpler.  Back in 1995, it was almost impossible to get anyone to
agree or even consider this.  

I am now seeing many large companies finding that this is the only way
to do it.  The only challenge is what to use for the unique permanent
value.  Your choice is just as good as any.  Many companies are using
employee badge numbers or generating unique numbers within the directory
service.  Some are also trying to coordinate the values with their HR
systems (often PeopleSoft or SAP).

Thanks for your input - I am hoping that more and more people consider
such an approach.

-- Alexis

Alexis Bor
Directory Works, Inc.
16312 194th Avenue NE
Woodinville, WA  98072
425-788-7647
425-844-2375 (FAX)
[email-masked]
http://www.directoryworks.com 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, January 09, 1998 1:43 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: immutable, permanent DNs @ Stanford
> 
> 

> Additionally, Communicator is highly configurable -- see...
 
http://developer.netscape.com/library/documentation/communicator/custom.
htm

 (note that there may be newer documentation available (pls lemme know
if so))

..for the details on how. Note that they allow one to configure how
attributes 
are used in these fashions..

  * the displayed name of attributes
  * the set of attributes available for use in search specifications
  * which attributes and how they are used "under the hood" in search
filters 
  * object classes used "under the hood" in search filters

I believe that we need to encourage vendors in general to provide
similar 
levels of configurability in their directory-based wares, rather than
the IETF 
trying to produce standards-track docs such that they can figure out
what 
attributes to hard code into their dialogs.

Thanks,

Jeff
----

 <<Alexis Bor (E-mail).vcf>>

---

From: Alexis Bor <[email-masked]>
Date: Fri, 9 Jan 1998 15:09:13 -0800

In the example you reference the documentatoin on modifying the Netscape
Communicator for LDAP.  

Has anyone come across similar instructions for Microsoft products, such
as Outlook 98 or Outlook Express, as well as Internet Explorer?

-- Alexis

Alexis Bor
Directory Works, Inc.
16312 194th Avenue NE
Woodinville, WA  98072
425-788-7647
425-844-2375 (FAX)

 

Thanks,

Jeff
----

---

From: [email-masked]
Date: Fri, 09 Jan 1998 16:05:07 -0800

> as Outlook 98 or Outlook Express, as well as Internet Explorer?

I spent about .5 hr yesterday evening pokin' about IE 4.0 (actually: 4.72.2106.8) et al, and even though Outlook Express's help indicates that one can configure in LDAP-based directory services other than those it is shipped with, I couln't find it. 

so, they claim some minimal level of configuration. Dunno about the level Communicator has.

Jeff

---

From: Jeff Hodges <[email-masked]>
Date: Tue, 13 Jan 1998 23:13:33 -0800

Peter,

Hm, not sure what's going on in terms of it not working for you. I
haven't looked at my logs to see what IE is doing. 

Yes, the cn attribute is present in our entries, "in spades"  ;-)

I've included the test entries below.

thanks,

Jeff
----

ldapsearch -h director.stanford.edu -b dc=stanford,dc=edu objectclass=\*

dc=Stanford, dc=edu
dc=Stanford
o=Stanford University
o=SU
o=Stanford University
o=Stanford Univ
o=Stanford U
objectclass=top
objectclass=organization
objectclass=domainRelatedObject
objectclass=quipuObject
objectclass=quipuNonLeafObject
objectclass=labeledURLObject
physicaldeliveryofficename=Stanford
telephonenumber=+1 415-723-2300
associateddomain=Stanford.EDU
description=Stanford University, Home of the Cardinal. PLEASE NOTE: This
directo
ry service is EXPERIMENTAL and PILOT. Please send email to
"Jeff.Hodges@Stanford
.edu" if you have questions about it. Thanks.
l=Palo Alto
streetaddress=Pine Hall, 241 Panama Street
postaladdress=Stanford
st=California
postalcode=94305-4122
c=US
labeleduri=http://www.stanford.edu/ Stanford University Home Page

ou=People, dc=Stanford, dc=edu
ou=People
objectclass=top
objectclass=organizationalUnit
objectclass=quipuObject
objectclass=quipuNonLeafObject
objectclass=labeledURLObject
description=This portion of Stanford's directory presently contains a
flat listi
ng of people in the "SUNetID" system.

regid=0000169d-b824-21d1-8300-ab400e0baa77, ou=People, dc=Stanford,
dc=edu
regid=0000169d-b824-21d1-8300-ab400e0baa77
cn=Test RegID Entry 0
cn=Test RegID Entry
cn=Test.RegID.Entry.0
cn=testregidentry
cn=testregidentry0
cn=T.RegID.Entry.0
cn=tregidentry
objectclass=top
objectclass=person
objectclass=organizationalPerson
objectclass=pilotObject
objectclass=newPilotPerson
objectclass=labeledURIObject
objectclass=stanfordPerson
sn=Entry
title=a lowly test entry
telephonenumber=650 123 1234
facsimiletelephonenumber=650 234 2345
homephone=650 345 3456
classstanding=graduate
stanfordorg=University
facultystaffdept=itss-ccs
streetaddress=Pine Hall
homepostaladdress=99 homely street
uid=testrid0
maildrop=[email-masked]
mail=[email-masked]
generalid=Test.Regid.Entry.0
generalid=testregidentry0
generalid=T.Regid.Entry.0
generalid=tregidentry0
mailacceptinggeneralid=testregidentry0
mailacceptinggeneralid=tregidentry0
preferredgeneralid=Test.Regid.Entry.0
dceuuid=00000000-b821-21d0-8300-000000000000
suunivid=00000000
privilegegroup=Stanford

regid=1000169d-b824-21d1-8300-ab400e0baa77, ou=People, dc=Stanford,
dc=edu
regid=1000169d-b824-21d1-8300-ab400e0baa77
cn=Test RegID Entry 1
cn=Test RegID Entry
cn=Test.RegID.Entry.1
cn=testregidentry
cn=testregidentry1
cn=T.RegID.Entry.1
cn=tregidentry1
objectclass=top
objectclass=person
objectclass=organizationalPerson
objectclass=pilotObject
objectclass=newPilotPerson
objectclass=labeledURIObject
objectclass=stanfordPerson
sn=Entry
title=a lowly test entry
telephonenumber=650 123 1234
facsimiletelephonenumber=650 234 2345
homephone=650 345 3456
classstanding=graduate
stanfordorg=University
facultystaffdept=itss-ccs
studentdept=Computer Science
streetaddress=Pine Hall
homepostaladdress=1234 home street
uid=testrid1
maildrop=[email-masked]
mail=[email-masked]
generalid=Test.Regid.Entry.1
generalid=testregidentry1
generalid=T.Regid.Entry1
generalid=tregidentry1
mailacceptinggeneralid=testregidentry1
mailacceptinggeneralid=tregidentry1
preferredgeneralid=Test.Regid.Entry.1
dceuuid=11111111-b821-21d0-8300-000000000000
suunivid=11111111
privilegegroup=Stanford
privilegegroup=LelandFull
privilegegroup=Academic

regid=2000169d-b824-21d1-8300-ab400e0baa77, ou=People, dc=Stanford,
dc=edu
regid=2000169d-b824-21d1-8300-ab400e0baa77
cn=Test RegID Entry 2
cn=Test RegID Entry
cn=Test.RegID.Entry.2
cn=T.RegID.Entry.2
cn=testregidentry
cn=testregidentry2
cn=tregidentry2
objectclass=top
objectclass=person
objectclass=organizationalPerson
objectclass=pilotObject
objectclass=newPilotPerson
objectclass=labeledURIObject
objectclass=stanfordPerson
sn=Entry
title=aanother lowly test entry
telephonenumber=650 123 1234
facsimiletelephonenumber=650 234 2345
homephone=650 345 3456
stanfordorg=University
facultystaffdept=Facilities
streetaddress=Redwood Hall
homepostaladdress=5678 another home street
uid=testrid2
maildrop=[email-masked]
mail=[email-masked]
generalid=Test.Regid.Entry.2
generalid=testregidentry2
generalid=T.Regid.Entry.2
generalid=tregidentry2
mailacceptinggeneralid=testregidentry2
mailacceptinggeneralid=tregidentry2
preferredgeneralid=Test.Regid.Entry.2
dceuuid=22222222-b821-21d0-8300-000000000000
suunivid=22222222
privilegegroup=Academic
privilegegroup=LelandFull

regid=3000169d-b824-21d1-8300-ab400e0baa77, ou=People, dc=Stanford,
dc=edu
regid=3000169d-b824-21d1-8300-ab400e0baa
cn=Test RegID Entry 3
cn=Test RegID Entry
cn=Test.RegID.Entry.3
cn=T.RegID.Entry.3
cn=testregidentry
cn=testregidentry3
cn=tregidentry3
objectclass=top
objectclass=person
objectclass=organizationalPerson
objectclass=pilotObject
objectclass=newPilotPerson
objectclass=labeledURIObject
objectclass=stanfordPerson
sn=Entry
title=aanother lowly test entry
telephonenumber=650 123 1234
facsimiletelephonenumber=650 234 2345
homephone=650 345 3456
classstanding=junior
stanfordorg=University
studentdept=Economics
streetaddress=Polya Hall
homepostaladdress=4321 yet another home street
uid=testrid3
maildrop=[email-masked]
mail=[email-masked]
generalid=Test.Regid.Entry.3
generalid=testregidentry3
generalid=T.Regid.Entry.3
generalid=tregidentry3
mailacceptinggeneralid=testregidentry3
mailacceptinggeneralid=tregidentry3
preferredgeneralid=Test.Regid.Entry.3
dceuuid=33333333-b821-21d0-8300-000000000000
suunivid=33333333
privilegegroup=Stanford
privilegegroup=Routing

-- 
Jeff Hodges                              [email-masked]
Principal, Kings Mountain Systems         Voice & Fax: +1 650 369 6376

            Directory Services and Public Key Infrastructure
              Consulting, Systems Architecture, and Design
                     http://www.KingsMountain.com

See also:	   http://www.stanford.edu/~hodges/