Bug 11299 - NT_STATUS_ACCESS_DENIED returned when combining username map with uidNumber entries
Summary: NT_STATUS_ACCESS_DENIED returned when combining username map with uidNumber e...
Status: NEW
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: File services (show other bugs)
Version: 4.2.1
Hardware: All All
: P5 normal (vote)
Target Milestone: ---
Assignee: Samba QA Contact
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-05-28 20:13 UTC by pspencer
Modified: 2015-05-28 20:13 UTC (History)
0 users

See Also:


Attachments
Patch to allow mapped user connections to retain necessary domain SID credentials (2.93 KB, patch)
2015-05-28 20:13 UTC, pspencer
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description pspencer 2015-05-28 20:13:02 UTC
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.