Here is the catch (at least for some people.)
This can break NFS stuff. On my PDC I made a similar change. Home
directories are not on the PDC. This fixed the problem of people
getting login failures when logging into windows if they had more than
16 groups. But if a user tries to ssh into the PDC, and he is in more
than 16 groups, his login will fail because the home directory can not
be mounted. But if your samba server is not functioning as an nfs
client then it shouldn't be an issue.
My PDC is samba 3.4.x. The BDC's are 3.0.x. Samba 3.0.x domain
controllers didn't check if your Windows groups exceeded the system
group max. You could login- you might not have all the access to
directories you thought you should since your effective group list was
still getting truncated.
With Samba 3.4.x, samba checks to see how may groups you are in, and if
the exceeds the ngroups_max it aborts your login. I don't know why.
It isn't like it is fixing a security hole. It just gets people mad at me.
On 07/14/2010 07:39 AM, Marcis Lielturks wrote:
Hi!
Running OpenSolaris snv_134 with Samba 3.0.37. Samba is successfully
joined to AD domain. AD user "user1" is member in 17 AD groups
including "group1", but he cannot access Samba share which have read
permissions for "group1". If user account is modified and "group1"
becomes users primary group, then he can access shares. If user is
member of only 16 groups, then permissions work as expected regardless
of users primary group.
Operating systems "ngroups_max" is set to 1024. I tested with local
user and was able to add user to 1024 local groups.
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba