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/ 



Reply via email to