The Samba-Bugzilla – Bug 77
ADS auth does not work with all groups
Last modified: 2005-11-14 09:26:13 UTC
I've set up a samba fileserver which authenticates its users by using Winbind
against a Active Directory.
It seems that there is a bug with this. It looks like Samba sometimes has
problems with authenticating users from groups.
User1 is a member of Group1
If i set Valid user = @"Group1" ... Now i log in as User1 ... and then i
doesn't work. But if i make Group1 a member of Group2 and set Valid user =
@"Group 2" ... That means i am using group2 like a kind of proxy group.... and
then it works... Isn't this wierd?
Log from attempt to connect to a share which i am 100% sure that i should have
Also when i tried to set up another fileserver. Then Valid user = @"Group 2"
didn't work (while it still works on the first server) ... but now Group1 works
And ... If i fail authenticate to one share (even though i am authorized by the
AD and samba to access this...) .. and then try to access one of the other
shares that i were able to access before. It fails here to until i restart
Log from attemt to access the share that now fails:
At this very moment i have 3 servers with Samba3.0 working and running with
about 500 users. I have managed to work around this bug, but it makes no sense
to me at all. Hope it will be fixed sometime =o)
Mads / Denmark
Very interesting...I'm not sure quite what it is yet, but I was able to get the
nested group working just like this. Then, I delted the user from the nested
group and readded back to the same group (group1 in this case), and it no longer
works. It no longer finds the nested groups. Something being cached, maybe?
Ok, I found my issues to be about the winbind cache time parameter. It's now
defaulting to 5 minutes, and so updates take that long. If I reduce it to just
a few seconds, everything works fine for me. I can include a group directly, or
use a nested group, as described, and the user gets access properly.
If you're still having trouble, please include your smb.conf and perhaps a more
detailed debug log. Also I'd suggest running some wbinfo commands on the SIDs,
group names, or gid's involved, and the wbinfo -r userid command.
originally reported against 3.0alpha23. Bugzilla spring cleaning.