[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: DN question?

Ace Suares wrote:

Hash: SHA1

Hi there,

When I started with ldap I was totally NOT understanding the concept of a tree (in ldap).

I started out with the example, which at that time was something like


I understood that in the greater scheme of things, the last part


was of some importance - X.500 directories, where LDAP is a 'lite' form of, where meant to connect directories world wide and so I figured if I would ever want to fit in, I'd better use


since I was based in the netherlands.

But soon I found out, that there was no real central registry as with domain names, so no one prevented me from using


which could well be used for the University in Amsterdam.

Anyway, I was using

	o= Ace Suares,c=NL

which was very unlikely to give conflicts.

Then my application was to manage email in qmail-ldap, and that is pretty much domain-based, so I proceeded with

	cn=suares.nl,o= Ace Suares,c=NL
	cn=suares.com,o= Ace Suares,c=NL
	cn=suares.net,o= Ace Suares,c=NL

and so on. It worked, so far so good.

After a couple of years, the 'dc' (domain component) stuff came flying at me throught the various mailinglists.


is probably the most seen suffix.

But I had one problem. I wanted the domain *as a whole* in the DN, so I could do lot's of funny stuff.


	<? $domain = $_SERVER['HTTP_HOST']
	     $dn = 'foo=bar,domain=$domain,c=NL' ?>

(This is sort of PHP code, using the built-in variable that denotes the hostname this webpage has been requested with).

With rewrite rules (interesting apache technique) I could have just one php script file, that would serve all virtual hosts!

So, the dc=,dc=,dc= stuff didn't work for me.
Especially with subdomains, consider:


is very hard to write generic ACL's for !

So, then I started thinking another way:

1. the c=NL 'toplevel' has no significance for me.
2. the dc model has no benefit for me.

Then, I named my application 'qwido'.
I requested an OID (see earlier discussion on this list), and started inventing my own schema.

So, now my tree looks like:

	qwidoManager=Ace Suares,qRole=qwidoManager,qApp=qwido
	qwidoManager=Brian Bruce,qRole=qwidoManager,qApp=qwido

I agree these are very long dn's, and I am not sure if all those 'qRole' containers are really needed, but when 'browsing' with GQ it does look much nicer. Also, writing ACL's is quite a daunting task, but once the structure is clear, the qRole's simplify ACL management considerably.

Also, later I might write another application, which 'toplevel' is



and then later I still might integrate all these trees in something bigger, maybe sufficing everything with

	o=Ace Suares,c=NL

(just a joke).

Which is to say, don't let yourself get dragged into the 'dc' scheme, the 'c=XX' scheme, or any scheme that uses ou, o, cn, uid, and such.

Just make something up that really translates what YOU want to achieve.

If you have some branch that handles addressbooks, and some other branch that handles boomarks, and you think of these branches as 'utilities', then simply name them


You might have to twiddle with YOUR OWN SCHEMA to make this possible!

Unless you want compatibility or interoperability with a specific existing tree/aplication, you can use anything that fits.

The longer names like 'utility' instead of 'o' or 'ispManDomain' instead of 'ou' might have some speed penalties, but that shouldn't have to be like that. It might be that you notice this on a P4 2 Ghz, but then again, on a Dual Xeon 3.7 Ghz machine the difference might be too small to measure. I don't know.

This is what I think - it might be wrong, I'd like to hear from someone who has good arguments to think elsewise!


--On Friday, November 14, 2003 3:35 PM -0500 Raj Balasubramanian

<r0x61j@comcast.net> wrote:

Hello All
Wanted to get an idea of what is the thought process out there in
deciding on a DN? I am specifically curious about DN of format
uid=<id>,ou=users,o=abc (flater) vs. uid=<id>,ou=<mydept>,o=abc (with one
or more flexible OUs).
I have seen the flatter kind more so than the latter, as there are less
dependcies on keeping DN sync with various application storing the DN for
authorization. I also like the idea of having atleast one OU specific to
a grouping of users (division/.dept etc.) so the ACL can be generically
set (if apps support wildcards..
What are some of the common working DN implementations out there?
Thanks in advance and please accept my apoloies if this is a repeat

In relation to this, I'm curious about ou/o vs. dc.  We use uid=x,
cn=accounts,dc=stanford,dc=edu for example, rather than uid=x,
??=accounts,ou=stanford,o=edu.  What are the pros/cons?  Is there a
particular reason to use one syntax over the other?


Quanah Gibson-Mount
Principal Software Developer
ITSS/TSS/Computing Systems
ITSS/TSS/Infrastructure Operations
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

- -- Ace Suares' Internet Consultancy
NIEUW ADRES: Postbus 2599, 4800 CN Breda
telefoon: 06-244 33 608
fax en voicemail: 0848-707 705
website: http://www.suares.nl * http://www.qwikzite.nl
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)


Thanks much for all the awesome responses...This list rocks!!