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

Re: DN question?



-----BEGIN PGP SIGNED MESSAGE-----
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

	o=Princeton,c=US

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

	c=US

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 

	c=NL

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

	o=VU,c=NL

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.

	dc=example,dc=com

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.

Consider:

	<? $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:

	ou=users,dc=suares,dc=com
	ou=users,dc=intranet,dc=suares,dc=com

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:

	qApp=qwido
	qRole=qwidoManager,qApp=qwido
	qwidoManager=Ace Suares,qRole=qwidoManager,qApp=qwido
	qwidoManager=Brian Bruce,qRole=qwidoManager,qApp=qwido
	qRole=qISP,qApp=qwido
	qISP=XS4ALL,qRole=qISP,qApp=qwido
	qISP=XS4SOME,qRole=qISP,qApp=qwido
	qISP=XS4NOTHING,qRole=qISP,qApp=qwido
	qRole=qDomain,qISP=XS4NOTHING,qRole=qISP,qApp=qwido
	qDomain=suares.com,qRole=qDomain,qISP=XS4NOTHING,qRole=qISP,qApp=qwido
qService=qMail,qDomain=suares.com,qRole=qDomain,qISP=XS4NOTHING,qRole=qISP,qApp=qwido
qRole=qUser,qService=qMail,qDomain=suares.com,qRole=qDomain,qISP=XS4NOTHING,qRole=qISP,qApp=qwido
qUser=BabsJensen@suares.com,qRole=qUser,qService=qMail,qDomain=suares.com,qRole=qDomain,qISP=XS4NOTHING,qRole=qISP,qApp=qwido
qUser=JensJensen@suares.com,qRole=qUser,qService=qMail,qDomain=suares.com,qRole=qDomain,qISP=XS4NOTHING,qRole=qISP,qApp=qwido
qUser=Kurt@suares.com,qRole=qUser,qService=qMail,qDomain=suares.com,qRole=qDomain,qISP=XS4NOTHING,qRole=qISP,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 

	qApp=qwiText

or
	qApp=qwikZite

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

	utility=bookmarks,whateversuffix
	utility=addressbooks,whateversuffix

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!

Cheers,
ace





> --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
> > 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
>
>
> --
> 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)

iD8DBQE/tWhTy7boE8xtIjURAvdgAJ4/VdYQGVQmBxBIYC3hAj8DNbqTOwCgigZZ
R93Yl+vZXR+GCSmy0kCzioc=
=SMbX
-----END PGP SIGNATURE-----