In a Security=ADS enviornment, shares level acl's can be set with Windows Server Manager. If the acls are set with a indivdual's account (not a group), the user will not be able to connect to the share. They get prompted for a username and password. The Samba machine log for the connecting computer will show access denied. This appears to be the result of Samba not fully resolving all of the users domain sid's. As shown here, the local server sid and the user's UID is taken to be the users first sid rather than the users domain sid. The sid does not match any of the ACE's in the Share ACL so access is denied. Note that the users groups are resoved into the account's domain sid list (in this case only Domain Users). [2004/06/24 13:53:50, 3] lib/util_seaccess.c:se_access_check(252) se_access_check: user sid is S-1-5-21-3834728434-493093361-1801336039-21004 se_access_check: also S-1-5-21-3834728434-493093361-1801336039-21001 se_access_check: also S-1-1-0 se_access_check: also S-1-5-2 se_access_check: also S-1-5-11 se_access_check: also S-1-5-21-1935655697-854245398-839522115-513 se_access_check: ACE 0: type 0, flags = 0x00, SID = S-1-5-21-1935655697-854245 398-839522115-512 mask = 1f01ff, current desired = 1 se_access_check: ACE 1: type 0, flags = 0x00, SID = S-1-5-21-1935655697-854245 398-839522115-1133 mask = 1301bf, current desired = 1 [2004/06/24 13:53:50, 5] lib/util_seaccess.c:se_access_check(315) se_access_check: access (1) denied. This was tested in a Windows 2000 ADS environment with Samba 3.0.2a, 3.0.4, & 3.0.5pre1. All have the same result.
Known issue. When getting a kerberos ticket, the primary user and group sids are always chosen algorithmic. Sorry for leaving this in while being known, time pressure with other things :-( Volker
volker, is this still an issue ?
this is fixed.