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

Tree layout / functionality confusion



All,

I need a little help and some ideas on tree layout.. I seem to have run
across a mental block that I haven't been able to work through on my
own... I have a feeling that I'm simply not comprehending a vital aspect
of the functionality that LDAP provides... I'm new to LDAP, and have
been doing A LOT of reading.. Unfortunately, not much is available (that
I have found) on implementing a directory layout... please excuse my
long winded  explanation...

I am looking to provide single sign on for services on several
servers... Including httpd, pure ftpd, qmail-ldap, ssh, and several
custom web applications... In addition, we obviously want to use the
info as an address book for mail clients, and possibly at some point,
build a custom directory application on the web... In the future, we may
integrate LDAP with bind for DNS (or some other DNS server), and
possibly for SAMBA... but as of right now I'm concentrating the most on
pure-ftpd, qmail-ldap, and ssh....

We are trying to keep our schema as 'vanilla' as possible – and not
extend it with custom objectclasses and attributes.. As of right now, I
have slapd.conf configured with the following schemas...

include         /etc/openldap/schema/core.schema
include         /etc/openldap/schema/cosine.schema
include         /etc/openldap/schema/inetorgperson.schema
include         /etc/openldap/schema/nis.schema
include         /etc/openldap/schema/eduOrg.schema
include         /etc/openldap/schema/eduPerson.schema
include         /etc/openldap/schema/qmail.schema

As I understand it, the generally wise way to setup a tree is to have a
branch for people and a branch for groups... I can do that no problem...
and have.. Within the unit people, I then have a few test entries with
an RDN of:
 uid=user,ou=people,dc=mydomain,dc=edu
Each of these 'people' entries are entitled to attributes in...
inetOrgPerson, organizationalPerson, person, posixAccount, eduPerson,
and of course top...

All of that seems to be no problem.. I can fill the attributes with
values.. but herein lies the problem I am having... I have two servers
(ftp server – not ldap servers).. on one I have a home directory of
/home/neil and on the other I have a home directory of /detox/home/neil –
the nis schema only provides for a single homeDirectory per RDN... but I
have two possible values.. Depending upon which FTP server I log into, I
want to have the correct home directory passed back during the
authentication process. 

One thought that I have was to create another branch called 'nis' and
pushing all of the account information into that branch.. but (and this
is where I think I'm missing something) doesn't that effectively negate
the single sign on.... for example.. If my tree looked something like
this...




| dc=domain,dc=edu
-| ou=people
  --| uid=somebody,ou=people,dc=domain,dc=edu
-| ou=groups
-| ou=nis
  --| ou=servers
     --| ou=box1
        --| uid=somebody,ou=box1,ou=servers,ou=nis,dc=domain,dc=edu
     --| ou=box2
        --| uid=somebody,ou=box2,ou=servers,ou=nis,dc=domain,dc=edu

Then I have a userPassword in three different locations... and that's
not what I want...

Another thought that I haven't played around with much is extending down
below the uid=somebody,ou=people,dc=domain,dc=edu tree for each ftp
box... which to me, seems like it would have some advantages in that
when the entry was removed it would remove everything below it... but
I'm not sure it would solve the problem of having multiple passwords...
and I'm also not sure I can (or want to take the performance hit to)
tune the permissions to make the info as secure as possible...

What I'm wanting.. is for certain attributes to be 'inherited' from
other parts of the directory tree... and for some reason.. I can't see
how... Any help is greatly appreciated!!

Thanks,
ns