[prev in list] [next in list] [prev in thread] [next in thread]
List: kolab-devel
Subject: [Kolab-devel] A few LDAP comments.
From: "Mike" <Mike () hurn ! ca>
Date: 2003-05-18 5:34:11
Message-ID: 002e01c31cff$200d8120$19c8a8c0 () vs ! shawcable ! net
[Download RAW message or body]
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@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)
[Attachment #3 (text/html)]
<!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>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic