[Kolab-devel] A few LDAP comments.

[Mike]

The LDAP server for Kolab can also form the key component for a Single Sign On & Identity Management system. A few suggestions from my previous work with Netscape/iPlanet directory server technology.

The two main linux versions that I use (Red Hat and SuSE) as well as Sun use a common DN structure for the people that are known to the company namely:

    dn: ou=people, dc=domain, dc=tld
 
    dn: uid=michur01, ou=people, dc=domain, dc=tld

I have suggested using uid instead of cn as each dn needs to be unique. When you use cn what do you do when you get more than one "John Smith" or "Hans Hermann"? I therefore recommend that the uid is automatically generated, in my example above I have used the first three letters of my givenName (Michael), the first three letters of my last name and a number.

Can you please use a Kolab specific schema along with the standard schema files that come with OpenLDAP and the other components? With such a directory setup it is a simple task add attributes for NIS+, RADIUS and Windows/Samba authentication. I believe that Red Hat and SuSE are using open source code from www.padl.com to enable linux logon authentication via an OpenLDAP server. To give an example when you install RH9 you get options to configure NIS+, LDAP or Samba servers for authentication.

I would let the users set the first part of the displayName as if it was a firstName attribute to act as the preferred name to be used when displaying entries. The second part should be from the sn attribute.

In the Netscape directory that I setup to show what can be achieved. The manager and secretary attributes were given access controls to allow the manager to change some of the attributes values of there direct reports. With the secretary (departmental administrator) having a compatible set of access controls as the manager. This is very useful when staff changed departments. In this case the secretary from the old department would add the secretary for the new department. The new secretary will then make the amendments and remove the old secretaries details from the entry.

Make users with extra privileges members of a common group.

dn: cn=Kolab Maintainer, ou=Groups, dc=domain, dc=tld
objectclass: top
objectclass: groupOfUniqueNames
cn: Kolab Maintainer
description: none
uniquemember: uid=michur01, ou=People, dc=domain, dc=tld
uniquemember: cn=Kolab Administrator, ou=Groups, dc=domain, dc=tld

dn: cn=Kolab Administrator, ou=Groups, dc=domain, dc=tld
objectclass: top
objectclass: groupOfUniqueNames
cn: Kolab Administrator
description: Main Kolab Admin Group
uniquemember: uid=markon01, ou=People, dc=domain, dc=tld
uniquemember: uid=stebuy01, ou=People, dc=domain, dc=tld

Adding an index on uniquemember and an access control directive and not only can you control who has access to what parts of the directory. You can also control who can book a meeting room, who can login to what systems etc. Form the above groups you can see that I also recommend that every Administrator and Maintainer is also a standard user.


I would recommend putting the entry/structure for the Kolab server under a common group/unit.

    dn: ou=servers, dc=domain, dc=tld
 
    dn: cn=kolab, ou=servers, dc=domain, dc=tld
 
Other developers will then be able to add their information under ou=servers, dc=domain, dc=tld.

I hope that the above information is of some use.

Regards
 
Mike.


Michael E Hurn, Mike at Hurn.ca, www.hurn.ca
11036 Swan Crescent, Surrey, British Columbia, V3R 5B6, Canada
Phone:1 604 585 HURN (4876) Cell:1 604 780 HURN (4876)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kolab.org/pipermail/devel/attachments/20030517/0b23ae74/attachment.html>