How does AIX determine primary and secondary group membership for LDAP users?
How AIX Determines Group Membership for LDAP Users
This document will explain how AIX determines primary and secondary group membership for LDAP users. Specific examples will be shown as well as debug and testcase collection information.
1) LDAP users must belong to LDAP groups
AIX has a requirement that LDAP users MUST belong to LDAP groups. In other words, all the possible groups that an LDAP user is a member of must be defined on LDAP. An LDAP user cannot be a member of a local group.
This LDAP group requirement is by design, as noted by a quote from development below:
“AIX has strict checks to maintain user/group integrity. It is designed that each domain works as a separate entity and there is no mix between users/groups from multiple domains.”
2) Configuration files that affect group membership lookup
There are three files that controls how AIX determines group membership:
- user map
- group map
To determine the exact user and group map file name, look at the userattrmappath and groupattrmappath options in the ldap.cfg file.
The ldap.cfg file provides the following information:
- groupbasedn - specifies where group entries reside on LDAP server
- userattrmappath - user map file
- groupattrmappath - group map file
- groupclasses - objectclass(es) associated with group entry
user map file
The user map file provides the primary group mapping.
In the 2307aixuser.map file, this entry is present:
pgrp SEC_CHAR gidnumber …
A similar entry is present in the sfur2user.map file:
pgrp SEC_CHAR gidNumber …
For both schemas, AIX will get the value of the gidnumber attribute for the LDAP user and map it to the primary group AIX user attribute. This gidnumber is the numeric value of the primary group name.
group map file
The group map file provides the following default mapping:
groupname SEC_CHAR cn ...
id SEC_INT gidnumber ...
users SEC_LIST memberuid …
3) How primary group membership is determined
Primary group membership for an LDAP user is obtained as follows (based on above configuration files):
- Get the user’s gidnumber from the LDAP user entry
- Search under groupbasedn for a posixgroup entry that has a matching gidnumber
- The value of the ‘cn’ attribute in the found group entry will be displayed as primary group name for the LDAP user
Note: The specific group objectclass to search for is based on the schema being used. “posixgroup” is typical for an rfc2307 schema while “group” is common in Windows SFUR2 environment. The ldap.cfg and map files will determine which group objectclass to search for.
Here’s a partial output of an LDAP user entry (from ldapsearch):
Here are two sample LDAP group entries:
ldap.cfg file contains the following:
Given the above configuration and LDAP entries, here is the primary group membership for the “marie” user:
# lsuser -a pgrp marie
4) How secondary group membership is determined
Secondary group membership for an LDAP user is obtained as follows (based on above configuration files):
- Search under groupbasedn for all posixgroup entries that have “memberuid=<userDN>” or “memberuid=<username>”; <userDN> is the DN of the LDAP user entry; <username> is the AIX login name
- The value of the “cn” attribute for each group found will comprise the secondary group list for the LDAP user
Using configuration and sample user and group entries above, the secondary group search filter would look like this:
The search would find the “group2” entry, with “cn=group2”.
And ‘lsuser’ will show the following group membership:
# lsuser -a pgrp groups marie
marie pgrp=group1 groups=group1,group2
Note: The “groups” list is actually a concatenation of the primary and secondary groups.
5) Debugging group membership problems
Here are items to consider:
- Review and understand the explanation above
- Review the relevant parameters in the ldap.cfg, user and group map files mentioned above
- Ensure that the LDAP user and group entries matches up with the configuration and map files
- Check for known defects, specifically check later levels of bos.rte.security fileset
The two most common issues regarding LDAP group membership are:
1) Customer wants LDAP users to belong to local groups. This is not possible and is addressed in section 1 of this document.
2) Secondary group membership is not working. Check the LDAP group entry that corresponds to the secondary group of a user. Make sure that the memberuid -- or whatever attribute the group map has the “users” attribute mapped to -- is defined correctly in the group entry.
6) Collecting and submitting a testcase
Use the instructions below to collect and submit an initial testcase.
- Create a testcase directory, ie:
# mkdir /tmp/tc
- Get a snap
# snap -gtnfkSLNd /tmp/tc/snap
- Get lsuser and lsldap data
Note: Replace <username> with LDAP user name
# cd /tmp/tc
# lsuser <username> > lsuser.out
# lsldap -a passwd <username> > lsldap.user.out
# lsldap -a group > lsldap.group.out
- Package testcase
# cd /tmp/tc
Note: If your PMR number is 12345,700,000, then <pmr.branch.country> would be 12345.700.000 (country is always 000 for USA)
# tar -cvf./<pmr.branch.country>.tar *
# gzip <pmr.branch.country>.tar
- Upload the /tmp/tc/<pmr.branch.country>.tar.gz file to IBM via the URL below: