[Date Prev][Date Next]
Re: DN question?
-----BEGIN PGP SIGNED MESSAGE-----
When I started with ldap I was totally NOT understanding the concept of a tree
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:
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
(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
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
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
> <email@example.com> 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
> > question.
> 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)
-----END PGP SIGNATURE-----