[Samba] Domain users are loosing there groups after some time.

[Benedikt Schindler]

Am 02.03.2012 19:59, schrieb Dale Schroeder:
> On 03/02/2012 5:39 AM, Benedikt Schindler wrote:
>> Samba version : 3.6.3
>> Filesystem :    BTRFS
>> Clients :       XP, Win7
>> Log Level :     5
>>
>>
>> When we start our samba server everything works fine.
>> After a few days, some of our users are not allowed to connect to shares
>> anymore. When we restart the clients they can connect for a short time
>> and then say have the same problem again.
>>
>> When we restart the server everything works fine for a few days again.
>> We set the "winbind offline logon = yes" and it slowed down the process,
>> but didn't stop it.
>>
>> After a long search i think i found the problem.
>>
>> The user has "401217" as mapped ID,
>> and should be in the groups
>>    400513
>>    401612
>>    401609
>>    401611
>>
>> But samba just put him into
>>    400513
>>    401612
>>    401611
>>
>> So samba lost one group. And thats the reason the user is not allowed to
>> connect to the share, because only the group 401609 has a read permisson.
>>
>> Any ideas how that could happen?
>>
>>
>> Here is a log of a "failed" login:
>>
>>
>> [2012/03/02 11:37:52.842978,  5]
>> ../libcli/security/security_token.c:63(security_token_debug)
>>    Security token SIDs (15):
>>      SID[  0]: S-1-5-21-1004336348-920026266-682003330-1217
>>      SID[  1]: S-1-5-21-1004336348-920026266-682003330-513
>>      SID[  2]: S-1-5-21-1004336348-920026266-682003330-1612
>>      SID[  3]: S-1-5-21-1004336348-920026266-682003330-1609
>>      SID[  4]: S-1-5-21-1004336348-920026266-682003330-1611
>>      SID[  5]: S-1-1-0
>>      SID[  6]: S-1-5-2
>>      SID[  7]: S-1-5-11
>>      SID[  8]: S-1-22-1-401217
>>      SID[  9]: S-1-22-2-400513
>>      SID[ 10]: S-1-22-2-401612
>>      SID[ 11]: S-1-22-2-401611
>>      SID[ 12]: S-1-22-2-70000
>>      SID[ 13]: S-1-22-2-70002
>>      SID[ 14]: S-1-22-2-70011
>>     Privileges (0x               0):
>>     Rights (0x               0):
>> [2012/03/02 11:37:52.843247,  5]
>> auth/token_util.c:527(debug_unix_user_token)
>>    UNIX token of user 401217
>>    Primary group is 400513 and contains 6 supplementary groups
>>    Group[  0]: 400513
>>    Group[  1]: 401612
>>    Group[  2]: 401611
>>    Group[  3]: 70000
>>    Group[  4]: 70002
>>    Group[  5]: 70011
>> [2012/03/02 11:37:52.843372,  5] smbd/uid.c:317(change_to_user_internal)
>>    Impersonated user: uid=(0,401217), gid=(0,400513)
>> [2012/03/02 11:37:52.843408,  4] smbd/vfs.c:780(vfs_ChDir)
>>    vfs_ChDir to /home/data
>> [2012/03/02 11:37:52.843443,  4] smbd/vfs.c:780(vfs_ChDir)
>>    vfs_ChDir to /home/data
>> [2012/03/02 11:37:52.843476,  3] smbd/service.c:190(set_current_service)
>>    chdir (/home/data) failed, reason: Keine Berechtigung
>> [2012/03/02 11:37:52.843509,  3] smbd/error.c:81(error_packet_set)
>>    error packet at smbd/process.c(1558) cmd=50 (SMBtrans2)
>> NT_STATUS_ACCESS_DENIED
>>
>>
>>
>>
>> Configuration parts that are maybe interresting:
>> smb.conf:
>>
>>
>> security = ADS
>>
>> socket options = SO_KEEPALIVE IPTOS_LOWDELAY TCP_NODELAY
>> nt acl support = yes
>> vfs objects = acl_xattr
>>
>> winbind enum users = yes
>>          winbind enum groups = yes
>>          winbind offline logon = yes
>>          allow trusted domains = yes
>>
>>          idmap config * : backend     = rid
>>          idmap config * : range       = 70000-99999
>>          idmap config * : base_rid    = 0
>>
>>          idmap config A : backend     = rid
>>          idmap config A : range       = 400000-499999
>>          idmap config A : base_rid    = 0
>>
>>          idmap config B : backend  = rid
>>          idmap config B : range    = 300000-399999
>>          idmap config B : base_rid = 0
> 
> Benedikt,
> 
> Check this bug - https://bugzilla.samba.org/show_bug.cgi?id=8676 - to
> see if any of these symptoms match those of your systems when the group
> loss happens.
> 
> Dale
> 
> 


Hello Dale,

none of these symptoms exists on our server.

And it's more like the existing connection is loosing the group.

The windows client is connected to "\\server.domain.tld\data" and this
connection broke after some time. (Because of the group)
You could open a second connection from the same computer to the same
server by using "\\server\data" with no problems. And it's not about
FQDN or not. It also appears the other way arround.

If you restart the client, the client could connect without any problems
... until it looses the group again.

best regards
Benedikt