<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=windows-1252">
<META content="MSHTML 6.00.2800.1170" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face="Courier New" size=2></FONT> </DIV>
<DIV><FONT face="Courier New" size=2>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.</FONT></DIV>
<DIV><FONT face="Courier New" size=2></FONT> </DIV>
<DIV><FONT face="Courier New" size=2>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:</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face="Courier New" size=2>    dn: ou=people, 
dc=domain, dc=tld<BR> <BR>    dn: uid=michur01, ou=people, 
dc=domain, dc=tld</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face="Courier New" size=2>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.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face="Courier New" size=2>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 <A href="http://www.padl.com">www.padl.com</A> 
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.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face="Courier New" size=2>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.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face="Courier New" size=2>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.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face="Courier New" size=2>Make users with extra privileges members of 
a common group.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face="Courier New" size=2>dn: cn=Kolab Maintainer, ou=Groups, 
dc=domain, dc=tld<BR>objectclass: top<BR>objectclass: groupOfUniqueNames<BR>cn: 
Kolab Maintainer<BR>description: none<BR>uniquemember: uid=michur01, ou=People, 
dc=domain, dc=tld<BR>uniquemember: cn=Kolab Administrator, ou=Groups, dc=domain, 
dc=tld</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face="Courier New" size=2>dn: cn=Kolab Administrator, ou=Groups, 
dc=domain, dc=tld<BR>objectclass: top<BR>objectclass: groupOfUniqueNames<BR>cn: 
Kolab Administrator<BR>description: Main Kolab Admin Group<BR>uniquemember: 
uid=markon01, ou=People, dc=domain, dc=tld<BR>uniquemember: uid=stebuy01, 
ou=People, dc=domain, dc=tld</FONT></DIV>
<DIV><FONT face="Courier New" size=2></FONT> </DIV>
<DIV><FONT face="Courier New" size=2>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.</FONT></DIV>
<DIV><FONT face="Courier New" size=2></FONT> </DIV><FONT face="Courier New" 
size=2>
<DIV><BR>I would recommend putting the entry/structure for the Kolab server 
under a common group/unit.</DIV>
<DIV> </DIV>
<DIV>    dn: ou=servers, dc=domain, 
dc=tld<BR> <BR>    dn: cn=kolab, ou=servers, dc=domain, 
dc=tld<BR> <BR>Other developers will then be able to add their information 
under ou=servers, dc=domain, dc=tld.</DIV>
<DIV> </DIV>
<DIV>I hope that the above information is of some use.</DIV>
<DIV> </DIV>
<DIV>Regards<BR> <BR>Mike.</DIV>
<DIV> </DIV>
<DIV></FONT><FONT face="Courier New" size=2><BR>Michael E Hurn, <A 
href="mailto:Mike@Hurn.ca">Mike@Hurn.ca</A>, <A 
href="http://www.hurn.ca">www.hurn.ca</A><BR>11036 Swan Crescent, Surrey, 
British Columbia, V3R 5B6, Canada<BR>Phone:1 604 585 HURN (4876) Cell:1 604 780 
HURN (4876)</FONT></DIV></BODY></HTML>