Trying to add a local user account on AIX, to a Unix enabled Active Directory (AD) group, using VAS, and its group-override file does not work. After adding a local user account to the AD group, through the group-override file, different commands will return conflicting information as to whether the local user is actually a member of the AD group.
Running 'lsgroup' on the AD group will show the local user as a member, while trying to use 'newgrp', as the local user, to change the user's 'real' group to the AD group, will not work. Finally, the local user will not have access to system resources requiring membership in the AD group.
This issue is due to a limitation of how AIX and LAM function. AIX works very hard at trying to keep both the local and alternate pluggable authentication modules, including VAS, independent of each other. Thus when VAS is asked by LAM who is a member of an AD group, because VAS will use its group-override file, it will return the local user as a member. When a command, such as 'newgrp', tries to determine which groups the local user is a member of, by performing a getgrent() or getgrset() libc call, it will only ask the local registry. So it follows, that the group membership information will differ, depending on which registry LAM is using to get the information, when mixing information from the local and alternate registries, such as VAS.
WORKAROUND1:
Create a local group which matches the name and GID of the AD group you are trying add the local user to, then add the local user account to both the local group, through /etc/groups, and the AD group, through the group-override file. The system will act as though they are the same group, when returning group struct calls. This way, AD users and local users can be members of the same AD group.
There is, however, one caveat when using this setup; if an AD user has their primary GID set to an AD group, which has the matching local group, they will be unable to login through SSH. This is because SSH, on AIX, calls the setauthdb function, which restricts the search order for loadable authentication modules. This means that when the AD user is logging in, setauthdb will be set to use the VAS registry (as it the registry the returned user information to LAM), except when it tries to resolve the user's primary GID through the VAS registry. VAS will see that there is a local group with the same GID, and by design, VAS will not return any information on the group (normally, this is to ensure AD account information does not clobber local account information). AIX does not allow authentication for any user without a valid primary GID, so it will deny access to the AD user. This will not be an issue, as long as for the groups, which are being setup in the aforementioned way, do not have any AD users using that group as their primary GID.
WORKAROUND2:
1 Install VASYPD
2 Edit the following line in # /etc/rc.d/init.d/vasypd
VAS_NIS_DOMAINNAME="yourdomain.com"
3. Follow these steps to create the required directories and files
# cd /var/yp
# mkdir binding
# cd binding
# mkdir yourdomain.com
(as entered in the VAS_NIS_DOMAINNAME)
# cd yourdomain.com
# touch ypservers
3 Start vasypd
# /etc/rc.d/init.d/vasypd start
4 Verify /etc/security user is VAS OR compat and not VAS OR files in the default stanza for the SYSTEM setting.
5 Verify /usr/lib/security/methods.cfg has NIS entries.
6 Add '+:::' to the end of the groups file.
7 Add the local usernames to the group-override file in the groups they need to be shown as being a member of e.g.
# /etc/opt/quest/vas/group-override
adgroup1:::aixlocal1
8 Check that the information is being provided
# id aixlocal1
You should see the active directory group being provided to the local user.
If response times are slow check /etc/netsvc.conf
There should be an entry as follows
hosts = files, bind4
© ALL RIGHTS RESERVED. Terms of Use Privacy Cookie Preference Center