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
[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, is this still an issue ?
this is fixed.