[Samba] vfs_ChDir fails, even though the share is read-write for that user

[Nathan VanHoudnos]

I've verified that it is an ngroups_max issue. As it stands, Solaris
cannot integrate with Active Directory if there exist users who are
members of more then 32 groups. Worse, the number of groups is
calculated by Samba by taking the number of groups a user is properly a
member of PLUS the number of groups inside of Active Directory that
include Domain Users as a member. (At least that's what it seems like, I
could be wrong.) For my site, that means any user is a member of at
least 17 groups, and I cannot change this. 

I missed it originally, so I thought I'd post this to the list for the
benefit of others who are struggling with Solaris and Samba integration.

At least on my site, there is a discrepancy between what "wbinfo -r
DOMAIN+user" returns and what AD says a user is a member of. If you're
using bash, you can use this one liner to see this more easily: 

  for x in `wbinfo -r UIUC+vanhoudn`; do y=`wbinfo -G \
  $x`; wbinfo -s $y; done

the output will report the user as a member of all the groups that AD
says, plus any groups that have "Domain Users" as a member. My site has
many OU's, and several OU admins have set groups with "Domain Users" as
members. For my site, any user created with AD, is a member of at least
17 groups because of spurious "Domain Users" memberships. Unfortunately,
that is strictly greater then the default ngroups_max setting of 16. So
that explains why even my test users who I thought were members of only
one group were failing. They were in fact members of 17 groups as far as
Samba was concerned. 

Since I don't have the special powers to reconfigure different OU's, I
tested this by changing /etc/system to have 
  set ngroups_max = 32 
and rebooting. 

I then  created a test user called fherbert. Initially, 
  wbinfo -r UIUC+fherbert | wc - l
returned 17. Surprisingly, fherbert was able to access groups for which
AD did not report as his primary group. Things were working as
expected. 

I then created 15 fake groups and added fherbert to them one by one.
Things continued to work beautifully until I added fherbert to his 33rd
group. That caused him to lose access to shares that were owned by his
supplementary groups. He still could access shares that belonged to his
the group that AD reported as being his primary group. In short, that
was the same error I've been having all along. 

I tried setting /etc/system to nmax_groups > 32, (I tried 100 and 64)
but after reboot,
  getconf NGROUPS_MAX
just returns the default of 16. Bummer. 

I'm in touch with Sun about it. If I get a fix I'll let you guys know.
Thanks so much for your help.

Cheers,

Nathan VanHoudnos


On Thu, 2007-12-13 at 10:05 -0600, Nathan VanHoudnos wrote:
> (Forgot to copy the list.) 
> 
> Thanks for the info. 
> 
> I've opened a ticket with Sun to get a workaround resolved. I'll report
> back to the list with whatever I hear back.
> 
> Thanks,
> 
> Nathan
> 
> On Thu, 2007-12-13 at 11:01 +0000, James R Grinter wrote:
> > On Wed, Dec 12, 2007 at 02:15:45PM -0800, Jeremy Allison wrote:
> > > No, sorry. You need to find out if the smbd server has the
> > > correct groups associated with it's token when it's representing
> > > the user.
> > > 
> > > Not sure how to get ps to display this info.
> > 
> > pcred(1) will show all process credentials, on Solaris (8, 9, 10)
> > 
> > http://blogs.sun.com/peteh/date/20050614 has a discussion of the issues
> > with changing it in future Solaris releases.
> > 
> > NGROUPS_UMAX (a constant built into the Solaris kernel) caps the
> > tuneable ngroups_max to a maximum 32.
> > 
> > Using file ACLs is the only other approach, currently, for Solaris
> > (which is a pain, obviously, as maintaining individual entries for
> > users on ACLs is far more awkward than putting allowed users into a
> > group!)
> > 
> > James.
>