Bug 11185 - 'force user' does not work with winbind default domain user
Summary: 'force user' does not work with winbind default domain user
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: File services (show other bugs)
Version: 4.2.0
Hardware: All All
: P5 normal (vote)
Target Milestone: ---
Assignee: Karolin Seeger
QA Contact: Samba QA Contact
Depends on:
Reported: 2015-03-31 16:15 UTC by Andreas Schneider
Modified: 2015-10-26 10:29 UTC (History)
4 users (show)

See Also:

patch for master (1.40 KB, patch)
2015-03-31 16:20 UTC, Andreas Schneider
no flags Details
patch for 4.2 (1.51 KB, patch)
2015-04-01 09:04 UTC, Andreas Schneider
jra: review+
patch for 4.1 (1.51 KB, patch)
2015-04-01 09:05 UTC, Andreas Schneider
jra: review+
patch for 3.6 (1.51 KB, patch)
2015-04-01 09:06 UTC, Andreas Schneider
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Schneider 2015-03-31 16:15:35 UTC
When using 'winbind use default domain = yes' in combination with a domain user for the 'force user' setting, access to the share will fail with NT_STATUS_INVALID_SID. The domain user ends up being resolved to a "Unix User" domain instead.
Comment 1 Andreas Schneider 2015-03-31 16:19:55 UTC
        workgroup = DISCWORLD
        realm = DISCWORLD.SITE
        security = ads

        # Winbind domain idmap
        idmap config DISCWORLD : backend = rid
        idmap config DISCWORLD : range = 100000000-199999999

        # Winbind auth
        client use spnego = yes
        client ldap sasl wrapping = seal
        create krb5 conf = no

        # Winbind generic
        template shell = /bin/bash
        winbind cache time = 300
        winbind enum users = true
        winbind enum groups = true
        winbind offline logon = false
        winbind normalize names = false
        winbind refresh tickets = true
        winbind use default domain = true
        winbind separator = +
        comment = Test directory
        path = /srv/samba/test
        valid users = +testforcegroup
        force user = testforceuser
        force group = testforcegroup
        read only = No
        create mask = 0660
        directory mask = 0770

testforceuser is a domain user and testforcegroup is a domain group. Due to 'winbind use default domain = true' it should be possible to specify them without a domain name.
Comment 2 Andreas Schneider 2015-03-31 16:20:22 UTC
Created attachment 10923 [details]
patch for master
Comment 3 Andreas Schneider 2015-04-01 09:04:05 UTC
Created attachment 10927 [details]
patch for 4.2
Comment 4 Andreas Schneider 2015-04-01 09:05:17 UTC
Created attachment 10928 [details]
patch for 4.1
Comment 5 Andreas Schneider 2015-04-01 09:06:01 UTC
Created attachment 10929 [details]
patch for 3.6
Comment 6 Jeremy Allison 2015-04-01 17:08:16 UTC
Comment on attachment 10927 [details]
patch for 4.2

Comment 7 Jeremy Allison 2015-04-01 17:08:27 UTC
Comment on attachment 10928 [details]
patch for 4.1

Comment 8 Jeremy Allison 2015-04-01 17:08:51 UTC
Karolin, please push to 4.2.next, 4.1.next.

Thanks !

Comment 9 Karolin Seeger 2015-04-08 19:19:25 UTC
(In reply to Jeremy Allison from comment #8)
Pushed to autobuild-v4-[1|2]-test.
Comment 10 Karolin Seeger 2015-04-09 19:24:34 UTC
(In reply to Karolin Seeger from comment #9)
Pushed to both branches.
Closing out bug report.

Comment 11 Justin Maggard 2015-10-13 20:06:19 UTC
This change causes a regression if "winbind use default domain = yes", but "security = user".  Would it make sense to add something like this around it?

if (lp_security() > SEC_USER)
Comment 12 Jeremy Allison 2015-10-13 20:10:40 UTC
(In reply to Justin Maggard from comment #11)

Can you give me a debug 10 log + smb.conf showing the problem ?
Comment 13 Justin Maggard 2015-10-13 21:12:33 UTC
OK, so upon further review, it's not as simple as that.  My local group is named "Users", so eventually lookup_name() matches at "6. Builtin aliases"; thus we never get to the fallback check for local accounts.
Comment 14 Jeremy Allison 2015-10-13 23:52:13 UTC
On 10/13/2015 03:22 PM, Jeremy Allison wrote:
> On Tue, Oct 13, 2015 at 02:58:45PM -0700, Justin Maggard wrote:
>> Looks like Windows doesn't return anything for WORKGROUP\Users... :-)
>> Not sure where that leaves us now though -- Feel free to just tell me to
>> go away if you prefer.  I'll get our config settings fixed either way.
>> C:\Users\justin> wmic group where (name='Users' and domain='Justin-PC')
>> get sid
>> SID
>> S-1-5-32-545
>> C:\Users\justin> wmic group where (name='Users' and domain='WORKGROUP')
>> get sid
>> No Instance(s) Available.
> So the bug is in standalone server mode WORKGROUP\Users should not
> return a BUILTIN. Only BUILTIN\Users or DOMAIN\Users (where 'domain'
> here is the machine name of the server).

Yep.  I'm probably being dense here, but I still don't understand why
calls to lookup_name_smbconf() from token_contains_name() should even be
checking for builtins though.

token_contains_name() is only called from token_contains_name_in_list().
 And from what I can see, token_contains_name_in_list() is only called
to look up accounts for the following smb.conf parameters:

1) invalid users
2) valid users
3) only user + username
4) read list
5) write list
6) admin users

When would any of those parameters have a builtin user in the list?
What would that even accomplish?
Comment 15 Volker Lendecke 2015-10-14 05:53:22 UTC
(In reply to Jeremy Allison from comment #14)
> When would any of those parameters have a builtin user in the list?
> What would that even accomplish?

Nested group memberships would give domain users access via those parameters
Comment 16 Jeremy Allison 2015-10-14 17:03:53 UTC
(In reply to Volker Lendecke from comment #15)

Ah, just to be clear - that was me cutting and pasting Justin's email for the record, not my own query :-). I know we have to have BUILTIN groups. However, on a standalone system with "security = user" WORKGROUP\Users shouldn't match a builtin group - but MACHINENAME\Users should (as on a standalone Windows box).
Comment 17 Jeremy Allison 2015-10-14 17:17:38 UTC
OH ! I see the bug:

The LsaLookupNames algorithm is here:


Note it says:

Translation of isolated names introduces the possibility of name collisions because the same name may be used in multiple domains. The LsaLookupNames function uses the following algorithm to translate isolated names
To translate isolated names

where isolated names are defined as names with no DOMAIN\ component.

We're getting this wrong in lookup_name(). We have:

        if ((domain[0] == '\0') && (!(flags & LOOKUP_NAME_ISOLATED))) {
                return false;

but lookup_name() *has* been given an explicit domain component, so we shouldn't blunder into the rest of this code in this case. Let me code a change and test it..
Comment 18 Jeremy Allison 2015-10-14 17:24:00 UTC
Ok, I'm pretty sure that clause should be:

        if ((domain[0] != '\0') || (!(flags & LOOKUP_NAME_ISOLATED))) {
                return false;

as otherwise, even when given an explicit DOMAIN\ component, we blunder into the LOOKUP_NAME_ISOLATED no domain component name lookup code.
Comment 19 Jeremy Allison 2015-10-14 17:44:23 UTC
Opened a new bug:


to track this. Closing this one out again.