[SOLVED] Retrieve group names for user in OpenLDAP
Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
I want to get the name of groups to which users belongs in OpenLDAP. I can get the list of group-members by passing group-name to ldapsearch command.However I want to get group names by passing uid/username to ldapsearch command.
Currently I am getting below result,
[root@Test ~]# ldapsearch -h 127.0.0.1 -x -b "dc=test,dc=com" "(uid=skimeer)"
# extended LDIF
# base <dc=test,dc=com> with scope subtree
# filter: (uid=skimeer)
# requesting: ALL
From the ldapsearch output above, looks like there are no attributes in a user's DN that hold the groups a user belongs to.
So if in any group DN, there are as attributes the group members (users), you can use the following command to find the groups a user belongs to:
That's not wrong, per se, but that form does indicate that the value is base64 encoded. For attribute syntaxes other than octetString, that only happens when one or more characters in the value are unprintable. How did it get in there? Did you put it there? Probably not. Also, the syntax for memberUid is IA5String, which specifies 7-bit characters, and NO extended characters. So one or more characters in that value are outside the legal range for that syntax. I also note that in your earlier tests not all the members of your group printed out. In fact, test123, which is the one just before the base64-encoded value, is the last one displayed.
One thing I see a lot during learning cycles is dirty databases. Unprintable characters in attribute values that normally contain only printable characters is an indicator that something hinky happened and your database may have problems.
I suggest the following:
Run a backup of the database using slapcat. Something like:
slapcat -b "dc=test,dc=com" > backup.ldif
would do it. While you're at it, review the contents of the LDIF file you just produced, paying special attention to the attribute values in your group object. Remove any (besides userPassword) that are base64 encoded (they have double-colon as the separator instead of a single-colon).
Now, edit slapd.conf and change the database directory value for the dc=test,dc=com backend to something else. Create that new directory in the file system with the mkdir command and re-create the database using slapadd. Something like:
slapadd < backup.ldif
will do it.
Now restart slapd and run your test search again. In particular, the one looking for "(memberUID=skimeer)" I'll bet the search works fine.
One other thing: It's safer and more efficient to search for specific attribute values rather than a wildcard and the other attribute value that you want. To show you an example,
Instead of using this filter:
use this one:
The reason this is safer is that it's just possible that an LDAP database somewhere that your application gets used ends up with some other type of objectClass that just happens to have a cn attribute and a memberUid you're searching for, but is not a group. Best to be safe and filter based on specific values instead of wildcards whenever possible.
The reason this is more efficient is that the "(objectClass=posixGroup)" section of the filter results in only those entries containing "objectClass=posixGroup" being selected and then a subsequent lookup is performed within that set of entries with "memberUid=skimeer". "objectClass=posixGroup" is almost always going to be a smaller set than "cn=*". Setting eq indexes on objectClass and memberUid further accelerates the lookups. Don't forget to stop slapd and run slapindex if you're adding indexes to an existing database.
Contrast this to (cn=*), which will cause all entries in the database that contain any value of cn to be selected. That's going to be a much larger set than in the "objectClass=posixGroup" example above. Then all those entries will then need to be searched for "memberUid=skimeer". Adding appropriate indexes will speed things up a bit (i.e., pres for cn, eq for memberUid), but the resulting sets that need to be searched are quite a bit larger in this case than in the previous one, so slapd spends more time searching.