[global]
        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 = +
[test]
        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.

Created attachment 10923 [details]
patch for master

Created attachment 10927 [details]
patch for 4.2

Created attachment 10928 [details]
patch for 4.1

Created attachment 10929 [details]
patch for 3.6

Comment on attachment 10927 [details]
patch for 4.2

LGTM.

Comment on attachment 10928 [details]
patch for 4.1

LGTM.

Karolin, please push to 4.2.next, 4.1.next.

Thanks !

Jeremy.

(In reply to Jeremy Allison from comment #8)
Pushed to autobuild-v4-[1|2]-test.

(In reply to Karolin Seeger from comment #9)
Pushed to both branches.
Closing out bug report.

Thanks!

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)

(In reply to Justin Maggard from comment #11)

Can you give me a debug 10 log + smb.conf showing the problem ?

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.

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?

(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

(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).

OH ! I see the bug:

The LsaLookupNames algorithm is here:

https://msdn.microsoft.com/en-us/library/windows/desktop/ms721797(v=vs.85).aspx

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))) {
                TALLOC_FREE(tmp_ctx);
                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..

Ok, I'm pretty sure that clause should be:

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

as otherwise, even when given an explicit DOMAIN\ component, we blunder into the LOOKUP_NAME_ISOLATED no domain component name lookup code.

Opened a new bug:

https://bugzilla.samba.org/show_bug.cgi?id=11555

to track this. Closing this one out again.