You should probably get a LDAP book or read a few online
tutorials. That said, the approach depends on whether you use groups or
roles.
groups-
Do a filter on
(&(objectClass=groupOfNames)(cn=TEAM-NAME)) and grab all the member
attributes. Then you have to scan through each member in a second pass.
roles-
Just do a filter on the role itself and you get the
members in the first pass.
On a side note, while there may be
some disagreement on this list about the use of groupOfUniqueNames, the
fact is it's used almost interchangeably with groupOfNames these days (I
do it) and you should always be ready to support it.
You
can do that by writing the appropriate filters:
(&(|(objectClass=groupOfNames)(objectClass=groupOfUniqueNames))(cn=TEAM-NAME))
And then determining how to read the entry (member vs.
uniqueMember) or have a configuration file that specifies the filter and
attribute to look at.
> Hello Dustin,
>
>
thanks for answering.
> Nice to hear that I do not have to modify
a lot :-)
>
> But there's one answer left. How can I
search for all members of a
> certain team.
> e.g.: I
want to have a list of sn,mail,phone of all members of team a
>
> I have no idea how to create this type of search ?
>
> any help appreciated.....GERD.....
>
>
>
> Am 22.10.2008 um 17:27 schrieb Dustin Puryear:
>
>>
>>
>>
>> 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/
>>
>>
>
>
>
> --
>
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/
