Red Hat Appears to Ignore Secondary Groups for LDAP Users

[Tim P. Starrin]

This is bizarre, now it's working for the first time ever.  I am not 
running nscd either and I did not change a thing.  Yesterday I even 
called Red Hat support and reported the problem.  They were baffled too.

While on the phone yesterday, we confirmed the following...

    Selinux is permissive
    no acls
    no attr
    The gid is above 500 (we tested another file with a gid over 1,000
    just in case)
    no nscd service running
    id while the ldap user is logged in shows secondary ldap groups.
    Getent passwd and getent group show ldap users and groups


Any ideas what happened here?  I do not want to run into this problem 
again when I add a few hundred users to the system and place it in 
production.

Thanks

Nigel Wade wrote:
> Tim P. Starrin wrote:
>> On Red Hat Enterprise Linux (RHEL) 4 Update 6 with the latest patches
>>
>> Given the LDAP user "t-bone" with the following group set...
>>
>>    % id
>>    uid=9066(t-bone) gid=121(a00121) groups=121(a00121),144(a00144) \
>>        context=user_u:system_r:unconfined_t
>>
>>    % groups
>>    a00121 a00144
>>
>>
>> The following operations that should work on a Linux ext3 file system,
>> fail...
>>
>>    % ls -la
>>    drwxr-x---  2 root   a00144 4096 Mar 19 13:29 a00144
>>    -r--r-----  1 root   a00144   29 Feb 27 18:34 date
>>
>>    % ls a00144
>>    ls: a00144: Permission denied
>>
>>    % cat date
>>    cat: date: Permission denied
>>
>>
>> Note that file and directory access via the primary group, 
>> gid=121(a00121),
>> works fine.
>>
>> Did I setup something wrong or is this a real bug?
>>
>> Thanks.
>>
>
> That should work, it works here with groups supplied by LDAP.
> What are the permissions on the entire path leading to the directory 
> containing a00144 and date?
>
> What do you get if you use getent to display the group a00144?
>
> # getent group a00144
>
>