Re: [SLUG] LDAP config help sought (long post)

[O Plameras]

Howard Lowndes wrote:



My concern, and my reason for originally seeking the hierarchical 
approach was to limit the level of management access inside the 
directory, eg. I don't want someone who has write access to domain A 
being allowed to have read access to domain B, or even knowing that 
domain B exists.



Fundamentally, Address Directory like OpenLDAP  is hierchical(inverted 
tree structured). Can't be otherwise.


When I  work on OpenLDAP I start with a tree (hierchical) and graphical 
diagram like so:
  dn: dc=example,dc=com  
(can be e.g. dn: dc=slug,dc=org,dc=au or similar)

   |
  
-
  
|  
| |
 dn: ou=People,dc=example,dc=com   dn: 
ou=Computers,dc=example,dc=cometc

   |
 
---
 
|   
||
dn: uid=joeblue,ou=People,dc=example,dc=comdn:  
uid=madamblue,ou=People,dc=example,dc=com   etc.


joeblue can access only his dn and madamblue likewise by combining:
1. /*User authentication, and Access control list (ACL)*/
E.g.: Check output of
ldapsearch -x -D "uid=joeblue,ou=People,dc=example,dc=com" -w password
ldapsearch -x -D "uid=madamblue,ou=People,dc=example,dc=com" -w password

Output only their respective dn's.

slapd.conf has:
..
rootdn   "cn=Manager,dc=example,dc=com"
rootpw   secret
..
#
access to *
 by self write
 by users none
 by anonymous auth
 by * none

after doing following command:
ldapadd -x -D "cn=Manager,dc=example,dc=com" -w secret -f sample.ldif

where contents of sample.ldif:
# Entry : root organization: dn: dc=example,dc=com
dn: dc=example,dc=com
objectClass: dcObject
objectClass: organization
o: example
dc: example

# Entry : ou=People,dc=example,dc=com
dn: ou=People,dc=example,dc=com
objectClass: organizationalUnit
ou: People

# Entry : uid=joeblue,ou=People,dc=example,dc=com
dn: uid=joeblue,ou=People,dc=example,dc=com
cn: joeblue
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
uid: joeblue
homeDirectory: /home/joeblue
loginShell: /bin/false
gecos: Administrator
uidNumber: 1
gidNumber: 548
givenName: System
sn: Administrator
shadowExpire: 21914
shadowLastChange: 12944
displayName: System Administrator - Site A
userPassword: password

# Entry : uid=madamblue,ou=People,dc=example,dc=com
dn: uid=madamblue,ou=People,dc=example,dc=com
objectClass: posixAccount
objectClass: shadowAccount
objectClass: inetOrgPerson
homeDirectory: /home/joeblue
loginShell: /bin/false
gecos: Administrator
uidNumber: 1
gidNumber: 548
givenName: System
sn: Administrator
shadowExpire: 21914
shadowLastChange: 12944
displayName: System Administrator - Site B
userPassword: password

Hope these help.

O Plameras

--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] LDAP config help sought (long post)

[Jeff Waugh]

> I was interested in your comments about bdb -v- ldbm and would be
> interested in an expansion on that if you feel inclined; I have little
> knowledge of the workings or vagaries of the Unix dbs.

The BDB backend uses the very latest in highly scalable and pull your hair
out with a combine harvester Berkeley DB technology. It's very complex,
highly configurable, and requires a lot of babysitting. You end up having to
do database recoveries on a fairly regular basis, and have to know all kinds
of ins and outs to get the best performance out of it. In most cases, it's
just over the top, and the much simpler ldbm backend (which is comparably
stupid and slow) saves time in the long run.

(It would be interesting to look at Tridge's ldb and tdb solutions for samba
in more detail at some stage...)

Interestingly enough, this is why the first releases of Subversion always
looked like an astounding headsmack expressed in elaborate modern folk dance
to me - no way would I put my revision control in the hands of BDB. At least
these days they have fsfs and use it by default.

> My concern, and my reason for originally seeking the hierarchical approach
> was to limit the level of management access inside the directory, eg. I
> don't want someone who has write access to domain A being allowed to have
> read access to domain B, or even knowing that domain B exists.

Aha, good reason. :-) Though you could achieve that through other ends, such
as putting all of that smarts in your management tools.

> I have installed phpldapadmin and using that has proved insightful as 
> well as seemingly being a good management tool.

It has improved leaps and bounds since I last looked at it - definitely one
of the more successful FOSS LDAP tools thus far. I'm really looking forward
to how things change with the Fedora Directory Server release, and what the
tools are like once they're Freed. :-)

- Jeff

-- 
OSCON 2005: August 1st-5th http://conferences.oreillynet.com/os2005/
 
 GDK (acronym): GNU's Not Unix Image Manipulation Program Tool-Kit
Drawing-Kit.
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] LDAP config help sought (long post)

[Howard Lowndes]

Flat earth here :)

Tks Jeff, that is probably one of the most insightful responses I have 
seen in a long while, and really does clear some things up for me.


I was interested in your comments about bdb -v- ldbm and would be 
interested in an expansion on that if you feel inclined; I have little 
knowledge of the workings or vagaries of the Unix dbs.


My concern, and my reason for originally seeking the hierarchical 
approach was to limit the level of management access inside the 
directory, eg. I don't want someone who has write access to domain A 
being allowed to have read access to domain B, or even knowing that 
domain B exists.


I have installed phpldapadmin and using that has proved insightful as 
well as seemingly being a good management tool.


Anyway, thanks for you comments.

Jeff Waugh wrote:



Now, let us consider setting up my database more like the examples.  The 
questions here are:


1: Can I have more than 1 "database bdb" entry, say 1 for each of 
several disparate domains?


2. If I can have more than 1 "database bdb" entry, can they all co-exist 
in the same directory path "/var/lib/ldap" or do they need separate 
directory paths "/var/lib/ldap/firstdomain", "/var/lib/seconddomain", etc?


3. Do the rootdn's have to match each dc= for its suffix or can it be 
quite different, and can I have a common rootdn for all domains?


4. I understand that multiple "database bdb" entries are permissible and 
apparently multiple suffix entries are permissible.  Are 
multiple/multiples permissible?


5. If multiple suffixes are permissible under any "database bdb" entry, 
then how is the following considered:

suffix "dc=example,dc=com"
suffix "dc=sitea"
suffix "dc=siteb"
Is the third line a subset of the second or of the first?



Gus gave you great technical answers to your questions - I'm going to focus
more on the "Zen of LDAP" side of things. :-) Sorry that this email is so
long, I hope it's worthy of more than a quick skim.

Your examples and questions suggest you want to "host multiple domains" in
your LDAP directory, and that you're conflating this goal with the structure
of your directory - ie. the generic DN, the multiple db files, domains as dc
elements under the generic DN, etc.

This is not the way to go with LDAP, and it's usually learned the hard way,
because there seems to be a vacuum of written documentation about LDAP best
practices. So hopefully this will help a little bit.

Firstly, try to keep thinking about LDAP as a directory, not a database. It
changes the way you perceive problems, and lets you see past some of the
things we assume from database land.

You'll often read about LDAP explained in terms of phone books, because they
are physical directories. It's handy to use this metaphor, and think about
its differences in the digital domain, when dealing with LDAP. For example,
a) why do we have separate phone books, and b) why are there different sets
for residential and business entries?

(a) is easy: it'd be a fucking expensive and unwieldy to produce such a huge
book. In the digital domain, we talk about management and scalability.

(b) because that's the easiest way to structure the information for humans,
particularly that crucial first categorisation step (when you want to get as
rid of as much irrelevant information as cheaply as possible), but it'd be
pretty hopeless and arbitrary for a computer to deal with, right?

So some decisions are based on human management, some are based on computer
scalability and application of the data. In the case of hosting multiple
domains, your brain *really* wants to conflate all the information about a
single domain into a nicely identifiable ball of stuff, whereas the computer
(and its software) just has a bunch of unrelated configuration data that
happen to work together.

WARNING: Do not think of "LDAP" in general as a management tool, think of it
as a directory-optimised data storage and retrieval tool. Management tools
are built on top of LDAP, and some are really very cool, like eDirectory and
Active Directory. But though they have LDAP at their heart, most of what you
see is the management infrastructure. When you're working with OpenLDAP, you
are dealing with the storage infrastructure, and usually custom management
tools, because we are cheap and dirty and haven't solved many of those hard
problems in FOSS land yet. *cough*

So, go flat. Put all of the entries for people under ou=People. Their mail
attributes will identify them. Put all of the hosts under ou=Hosts. Their
DNS attributes will identify them. This will make it easier to configure
your applications, and manage changes to your directory in future. You won't
need to worry about having separate bdb files until you're really pushing
scalability limits - it is transparent and has nothing to do with management
of the directory. *Do* think about using one of the simpler backends, such
as ldbm. bdb is a pain in the arse to manage, and doesn't give you enough
bang 

Re: [SLUG] LDAP config help sought (long post)

[Jeff Waugh]

> Now, let us consider setting up my database more like the examples.  The 
> questions here are:
> 
> 1: Can I have more than 1 "database bdb" entry, say 1 for each of 
> several disparate domains?
> 
> 2. If I can have more than 1 "database bdb" entry, can they all co-exist 
> in the same directory path "/var/lib/ldap" or do they need separate 
> directory paths "/var/lib/ldap/firstdomain", "/var/lib/seconddomain", etc?
> 
> 3. Do the rootdn's have to match each dc= for its suffix or can it be 
> quite different, and can I have a common rootdn for all domains?
> 
> 4. I understand that multiple "database bdb" entries are permissible and 
> apparently multiple suffix entries are permissible.  Are 
> multiple/multiples permissible?
> 
> 5. If multiple suffixes are permissible under any "database bdb" entry, 
> then how is the following considered:
> suffix "dc=example,dc=com"
> suffix "dc=sitea"
> suffix "dc=siteb"
> Is the third line a subset of the second or of the first?

Gus gave you great technical answers to your questions - I'm going to focus
more on the "Zen of LDAP" side of things. :-) Sorry that this email is so
long, I hope it's worthy of more than a quick skim.

Your examples and questions suggest you want to "host multiple domains" in
your LDAP directory, and that you're conflating this goal with the structure
of your directory - ie. the generic DN, the multiple db files, domains as dc
elements under the generic DN, etc.

This is not the way to go with LDAP, and it's usually learned the hard way,
because there seems to be a vacuum of written documentation about LDAP best
practices. So hopefully this will help a little bit.

Firstly, try to keep thinking about LDAP as a directory, not a database. It
changes the way you perceive problems, and lets you see past some of the
things we assume from database land.

You'll often read about LDAP explained in terms of phone books, because they
are physical directories. It's handy to use this metaphor, and think about
its differences in the digital domain, when dealing with LDAP. For example,
a) why do we have separate phone books, and b) why are there different sets
for residential and business entries?

(a) is easy: it'd be a fucking expensive and unwieldy to produce such a huge
book. In the digital domain, we talk about management and scalability.

(b) because that's the easiest way to structure the information for humans,
particularly that crucial first categorisation step (when you want to get as
rid of as much irrelevant information as cheaply as possible), but it'd be
pretty hopeless and arbitrary for a computer to deal with, right?

So some decisions are based on human management, some are based on computer
scalability and application of the data. In the case of hosting multiple
domains, your brain *really* wants to conflate all the information about a
single domain into a nicely identifiable ball of stuff, whereas the computer
(and its software) just has a bunch of unrelated configuration data that
happen to work together.

WARNING: Do not think of "LDAP" in general as a management tool, think of it
as a directory-optimised data storage and retrieval tool. Management tools
are built on top of LDAP, and some are really very cool, like eDirectory and
Active Directory. But though they have LDAP at their heart, most of what you
see is the management infrastructure. When you're working with OpenLDAP, you
are dealing with the storage infrastructure, and usually custom management
tools, because we are cheap and dirty and haven't solved many of those hard
problems in FOSS land yet. *cough*

So, go flat. Put all of the entries for people under ou=People. Their mail
attributes will identify them. Put all of the hosts under ou=Hosts. Their
DNS attributes will identify them. This will make it easier to configure
your applications, and manage changes to your directory in future. You won't
need to worry about having separate bdb files until you're really pushing
scalability limits - it is transparent and has nothing to do with management
of the directory. *Do* think about using one of the simpler backends, such
as ldbm. bdb is a pain in the arse to manage, and doesn't give you enough
bang for your buck to be worth bothering about (again, until scalability or
performance are massive concerns - I was running a very busy 80,000+ account
mail server on ldbm). Experiment with your applications and policies before
mucking around too much with the details of LDAP. That's *hugely* important,
because you can spend a lot of time working around your assumptions if you
don't think about your applications before you put your directory together.

Finally, go flat. Yes, it's great that LDAP is hierarchical, but it's too
easy to abuse and tie yourself up in knots. It's not a benefit, it's a
feature. :-)

And to finish off... go flat! :-)

- Jeff

-- 
GNOME Summit 2005: October 8th-10th http://live.gnome.org/Boston2005
 
   "I think hot Chinese girls who kick ass are

Re: [SLUG] LDAP config help sought (long post)

[Angus Lees]

At Thu, 14 Jul 2005 12:28:56 +1000, Howard Lowndes wrote:
> I'm trying to get somewhere with setting up an LDAP database.

> The problem I am encountering is that all the examples that I can find
> assume the the top level has a dn: of the form dc=example,dc=com
> My problem is that I want a different top level, and I want my
> slapd.conf file to look like [o=myhosting example]

The DN is supposed to be *globally* unique.  Hence everyone using some
sort of DNS name as the root of the data stored in their LDAP server.
(The older convention was o=Company Name,c=AU - but DNS names are
better in an internet age)

I really think you should rethink your base DN.  Note that the DN has
very little to do with the actual data stored in that entry (or below
that point in the tree) - it just has to be unique.

> Thus far my layout works just fine, but when I come to add dcObjects I
> start to run into problems.  An LDIF of:
> 
> dn: dc=example,dc=com,o=myhosting
> objectClass: dcObject
> dc: example
> 
> returns the following error:
> # ldapadd -x -D 'cn=manager,o=myhosting' -W -f myhosting.ldif
> adding new entry "dc=example,dc=com,o=myhosting"
> ldap_add: Object class violation (65)
>  additional info: no structural object class provided

Thats because your objectclasses (only dcObject) are only "auxiliary"
classes that augment other "structural" objectclasses.  You need at
least one structural objectclass for each LDAP entry.  You might want
to consider using objectClass "domain" for these entries
(RFC1274/cosine).

> If I then expand this LDIF file to:
> 
> dn: dc=example,dc=com,o=myhosting
> objectClass: dcObject
> dc: example
> objectClass: organizationalUnit
> ou: My Hosting
> 
> I now get this error:
> # ldapadd -x -D 'cn=manager,o=myhosting' -W -f myhosting.ldif
> adding new entry "dc=example,dc=com,o=myhosting"
> ldap_add: No such object (32)
>  matched DN: o=myhosting
> The question at this point is: What am I doing wrong here?

I think that error means you have to create dc=com,o=myhosting first.

> Now, let us consider setting up my database more like the examples.
> The questions here are:
> 
> 1: Can I have more than 1 "database bdb" entry, say 1 for each of
> several disparate domains?

Yes, if you want.  There isn't much reason to actually store the
separate domains in separate files however.  I wouldn't do it unless I
had some technical reason to do so (large databases that want
different indexing or different backend implementations, for example).

> 2. If I can have more than 1 "database bdb" entry, can they all
> co-exist in the same directory path "/var/lib/ldap" or do they need
> separate directory paths "/var/lib/ldap/firstdomain",
> "/var/lib/seconddomain", etc?

It looks like it has to be separate directories.

> 3. Do the rootdn's have to match each dc= for its suffix or can it be
> quite different, and can I have a common rootdn for all domains?

You may specify a rootdn for each database.  According to
slapd.conf(5), if the rootdn is outside the suffix ("namingContext"),
then the "rootpw" directive won't work.

The rootdn in OpenLDAP is like an LDAP superuser account.  The most
secure way to use openldap is to never use the superuser account.  You
can use openldap without specifying rootdn at all and enjoy finer
grained access controls.

> 4. I understand that multiple "database bdb" entries are permissible
> and apparently multiple suffix entries are permissible.  Are
> multiple/multiples permissible?

yes (assuming I understand your question).

> 5. If multiple suffixes are permissible under any "database bdb"
> entry, then how is the following considered:
> suffix "dc=example,dc=com"
> suffix "dc=sitea"
> suffix "dc=siteb"
> Is the third line a subset of the second or of the first?

Neither is a subset of another in this example.

-- 
 - Gus

-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] LDAP config help sought (long post)

[O Plameras]

Howard Lowndes wrote:


I'm trying to get somewhere with setting up an LDAP database.

The problem I am encountering is that all the examples that I can find 
assume the the top level has a dn: of the form dc=example,dc=com such 
that slapd.conf looks like:

...
database bdb
suffix "cd=example,dc=com"
rootdn "cn=manager,dc=example,dc=com"
rootpw secret
directory /var/lib/ldap
...

and the top level LDIF file looks like:
...
dn: dc=example,dc=com
objectClass: dcObject
dc: example
objectClass: organization
o: Example Company
...

My problem is that I want a different top level, and I want my 
slapd.conf file to look like:

...
database bdb
suffix "o=myhosting"
rootdn "cn=manager,o=myhosting"
rootpw secret
directory /var/lib/ldap
...

and the top level LDIF file looks like:

dn: o=myhosting
objectClass: organisation
o: My Hosting

Thus far my layout works just fine, but when I come to add dcObjects I 
start to run into problems.  An LDIF of:


dn: dc=example,dc=com,o=myhosting
objectClass: dcObject
dc: example

returns the following error:
# ldapadd -x -D 'cn=manager,o=myhosting' -W -f myhosting.ldif
adding new entry "dc=example,dc=com,o=myhosting"
ldap_add: Object class violation (65)
additional info: no structural object class provided

If I then expand this LDIF file to:

dn: dc=example,dc=com,o=myhosting
objectClass: dcObject
dc: example
objectClass: organizationalUnit
ou: My Hosting



Perhaps you want this ldif:

dn: dc=example,dc=com,o=myhosting,
objectClass: dcObject
objectClass: organization
o: My Hosting
dc: example

Then, you may create 'ou's after that.



I now get this error:
# ldapadd -x -D 'cn=manager,o=myhosting' -W -f myhosting.ldif
adding new entry "dc=example,dc=com,o=myhosting"
ldap_add: No such object (32)
matched DN: o=myhosting

or alternatively expand it to:

dn: dc=example,dc=com,o=myhosting
objectClass: dcObject
dc: example
objectClass: organization
o: My Hosting

then I still get the same error message.

The question at this point is: What am I doing wrong here?


Now, let us consider setting up my database more like the examples.  
The questions here are:


1: Can I have more than 1 "database bdb" entry, say 1 for each of 
several disparate domains?


2. If I can have more than 1 "database bdb" entry, can they all 
co-exist in the same directory path "/var/lib/ldap" or do they need 
separate directory paths "/var/lib/ldap/firstdomain", 
"/var/lib/seconddomain", etc?


3. Do the rootdn's have to match each dc= for its suffix or can it be 
quite different, and can I have a common rootdn for all domains?


4. I understand that multiple "database bdb" entries are permissible 
and apparently multiple suffix entries are permissible.  Are 
multiple/multiples permissible?


5. If multiple suffixes are permissible under any "database bdb" 
entry, then how is the following considered:

suffix "dc=example,dc=com"
suffix "dc=sitea"
suffix "dc=siteb"
Is the third line a subset of the second or of the first?


That'll do for now.  TIA.






--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] LDAP config help sought (long post)

[Matt Hope]

On 7/14/05, Howard Lowndes <[EMAIL PROTECTED]> wrote:
> I'm trying to get somewhere with setting up an LDAP database.

So your root is 'o=myhosting'
If you want to create 'dc=example,dc=com,o=myhosting' I believe you'll
need to create 'dc=com,o=myhosting' first.

Matt
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

[SLUG] LDAP config help sought (long post)

[Howard Lowndes]

I'm trying to get somewhere with setting up an LDAP database.

The problem I am encountering is that all the examples that I can find 
assume the the top level has a dn: of the form dc=example,dc=com such 
that slapd.conf looks like:

...
database bdb
suffix "cd=example,dc=com"
rootdn "cn=manager,dc=example,dc=com"
rootpw secret
directory /var/lib/ldap
...

and the top level LDIF file looks like:
...
dn: dc=example,dc=com
objectClass: dcObject
dc: example
objectClass: organization
o: Example Company
...

My problem is that I want a different top level, and I want my 
slapd.conf file to look like:

...
database bdb
suffix "o=myhosting"
rootdn "cn=manager,o=myhosting"
rootpw secret
directory /var/lib/ldap
...

and the top level LDIF file looks like:

dn: o=myhosting
objectClass: organisation
o: My Hosting

Thus far my layout works just fine, but when I come to add dcObjects I 
start to run into problems.  An LDIF of:


dn: dc=example,dc=com,o=myhosting
objectClass: dcObject
dc: example

returns the following error:
# ldapadd -x -D 'cn=manager,o=myhosting' -W -f myhosting.ldif
adding new entry "dc=example,dc=com,o=myhosting"
ldap_add: Object class violation (65)
additional info: no structural object class provided

If I then expand this LDIF file to:

dn: dc=example,dc=com,o=myhosting
objectClass: dcObject
dc: example
objectClass: organizationalUnit
ou: My Hosting

I now get this error:
# ldapadd -x -D 'cn=manager,o=myhosting' -W -f myhosting.ldif
adding new entry "dc=example,dc=com,o=myhosting"
ldap_add: No such object (32)
matched DN: o=myhosting

or alternatively expand it to:

dn: dc=example,dc=com,o=myhosting
objectClass: dcObject
dc: example
objectClass: organization
o: My Hosting

then I still get the same error message.

The question at this point is: What am I doing wrong here?


Now, let us consider setting up my database more like the examples.  The 
questions here are:


1: Can I have more than 1 "database bdb" entry, say 1 for each of 
several disparate domains?


2. If I can have more than 1 "database bdb" entry, can they all co-exist 
in the same directory path "/var/lib/ldap" or do they need separate 
directory paths "/var/lib/ldap/firstdomain", "/var/lib/seconddomain", etc?


3. Do the rootdn's have to match each dc= for its suffix or can it be 
quite different, and can I have a common rootdn for all domains?


4. I understand that multiple "database bdb" entries are permissible and 
apparently multiple suffix entries are permissible.  Are 
multiple/multiples permissible?


5. If multiple suffixes are permissible under any "database bdb" entry, 
then how is the following considered:

suffix "dc=example,dc=com"
suffix "dc=sitea"
suffix "dc=siteb"
Is the third line a subset of the second or of the first?


That'll do for now.  TIA.



--
Howard.
LANNet Computing Associates - Your Linux people 
--
When you just want a system that works, you choose Linux;
When you want a system that just works, you choose Microsoft.
--
Flatter government, not fatter government;
Get rid of the Australian states.

--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html