What you are trying to do is just create a set of users and teams
(groups of users). You can use LDAP groups or roles for the team
implementation. Let's just use groups.
root
- users
-- uid=bob (inetOrgPerson)
-- uid=frank
(inetOrgPerson)
- groups
-- cn=teama (groupOfNames or
groupOfUniqueNames)
-- cn=teamb (groupOfNames or
groupOfUniqueNames)
To make bob a member of teama, then add
uniqueMember=uid=bob,... to cn=teama. Ditto for teamb. To remove
bob from
teama, remove their uniqueMember=uid=bob,... from cn=teama.
This is essentially what you did. It works and it's how most of us do
it.
With roles, you would actually edit the user entry instead
and add a role attribute. Also, if you are using an LDAP server that
supports dynamic roles, you can probably maintain groups and get the
benefit of having roles (which are read directly from the user entry).
Hello,
I'm going to create a ldap
directory for the company to have a central
place for user
administration.
I've started with an example found in the web.
First of all I created
the top level dc=example,dc=com and the
manager
(cn=manager,dc=example,dc=com).
Afterwards I
created 2 organizational units:
ou=persons
ou=teams
and filled them with content (see at bottom of the email).
I'm in doubt if this is the correct way to build the
directory and
"connect" each user to its team. I only
set the "ou=" property of each
person to its
teamname, and added one "member=" entry for each person to
the team-object. I'm not happy with such setting.
What if a person changes the team, do I have to update the person's
"ou=" and the "member=" section of the
teams ??
Is this really the way to implement such a
company->team->person hierarchy
?
any help appreciated....GERD....
dn: cn=Tinky
Winky,ou=people,dc=example,dc=com
objectclass: inetOrgPerson
sn: Tinky
cn: Tinky Winky
uid: twinky
userpassword: twinky
ou: support
dn:
cn=Dipsy,ou=people,dc=example,dc=com
objectclass: inetOrgPerson
sn: Dipsy
cn: Dipsy
uid: dipsy
userpassword: dipsy
ou: support
dn: cn=Laa
Laa,ou=people,dc=example,dc=com
objectclass: inetOrgPerson
sn: Laa
cn: Laa Laa
uid: laa
userpassword: laa
ou: marketing
## team MARKETING
dn: cn=marketing,ou=teams,dc=transporeon,dc=nil
objectclass: groupofnames
cn: marketing
description:
team marketing
member: cn=Laa
Laa,ou=people,dc=transporeon,dc=nil
## team SUPPORT
dn: cn=support,ou=teams,dc=transporeon,dc=nil
objectclass:
groupofnames
cn: support
description: team support
member: cn=Tinky Winky,ou=people,dc=transporeon,dc=nil
member: cn=Dipsy,ou=people,dc=transporeon,dc=nil
--
This message was
scanned by ESVA and is believed to be clean.
Click here to
report this message as spam.
http://esva.puryear-it.com/cgi-bin/learn-msg.cgi?id=
--
Dustin Puryear
President and
Sr. Consultant
Puryear Information Technology, LLC
225-706-8414 x112
http://www.puryear-it.com
Author,
"Best Practices for Managing Linux and UNIX Servers"
http://www.puryear-it.com/pubs/linux-unix-best-practices/
