Created attachment 11102 [details] Patch to allow mapped user connections to retain necessary domain SID credentials When a domain user is mapped to a different local username on a samba domain member file server (via a "unixuser = DOMAIN\domainusername" entry in a "username map" file), it may also be desirable to have files that owned by / accessible to unixuser appear to Windows clients as being owned by / accessible to DOMAIN\domainusername instead of the foreign "Unix User\unixuser" SID. This is indeed possible, by setting the appropriate uidNumber attribute on the domain account. However, when you do this, attempting to connect to the samba server as DOMAIN\domainusername and access a file which is only accessible to unixuser results in NT_STATUS_ACCESS_DENIED, even though the samba process is successfully authenticated and operating as unixuser. And, from the Windows client point of view, we are connecting as "DOMAIN\domainusername" and attempting to access a file whose ACL allows access by "DOMAIN\domainusername", so NT_STATUS_ACCESS_DENIED is clearly unexpected. The source of the issue is that, when username mapping is in effect, all domain information about the user, such as the SID for DOMAIN\domainusername, is ignored when building the security token held by the samba process. All it has is the SID for Unix User\unixuser. However, ACL entries involving unixuser are mapped to the domain SID before the access control check, so access gets denied because the domain SID is not held by the token. The cause is the following code in the file source3/auth/auth_util.c (this is from 4.2.1; have not had time to look at newer snapshots, sorry!): /* * If winbind is not around, we can not make much use of the SIDs the * domain controller provided us with. Likewise if the user name was * mapped to some local unix user. */ if (((lp_server_role() == ROLE_DOMAIN_MEMBER) && !winbind_ping()) || (server_info->nss_token)) { ... status = create_token_from_username(...) ... } else { status = create_local_nt_token_from_info3(...) } Although I'm not familiar with samba's inner workings, I suspect that the correct behaviour for the case where samba is a domain member and nss_token is set is to first try create_local_nt_token_from_info3 (provided winbind is available, of course) and see if it produces a satisfactory token with a unix id number matching that of the mapped username, only falling back to create_token_from_username if it does not. We are using the attached patch which does the above. It seems to work well for us, though somebody more familiar with SAMBA internals should make sure it doesn't break anything else.