Bug 11915 - unix groups don't work within 'valid users' when running winbind
unix groups don't work within 'valid users' when running winbind
Status: RESOLVED FIXED
Product: Samba 4.1 and newer
Classification: Unclassified
Component: File services
4.2.10
All All
: P5 normal
: ---
Assigned To: Samba QA Contact
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2016-05-10 20:37 UTC by David Bell
Modified: 2016-06-07 22:24 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Bell 2016-05-10 20:37:38 UTC
Samba version: samba 4.2.10-6.el7_2 (Samba 4.2 on RHEL7 server 64-bit)
Security: 'ads'
Winbind: Enabled, running
nsswitch: NIS
pam: pam_krb5

The badlock fixes to Samba have changed the configuration such that to authenticate users to Samba shares without using kerberos you must run Winbind (smbd itself no longer allows authentication from clients without using kerberos against AD e.g. using NTLMv2). 

Enabling and running winbind fixes this issue, however running winbind then breaks (well, it changes) the 'valid users' parameter on shares when using NIS (or LDAP or whatever). We use unix groups for share access control (via 'valid users') as per the man page:

"A name starting with '+' is interpreted only by looking in the UNIX group database via the NSS getgrnam() interface"

However, when winbind is running samba doesn't behave in the way the man page describes, instead it seems to behave in an undocumented (but perhaps logical) way - now +groupname looks for a group in Active Directory using winbind. Oddly, @netgroup lookups continue to use NIS netgroups (even though AD can support them with RFC2307). So when winbind is turned on Samba won't look up UNIX groups. In fact the error is:

  string_to_sid: SID +groupnamehere is not in a valid format

Even when winbind is running it should be possible to configure with 'valid users' a list of Unix netgroups - just not groups. Perhaps an additional character is needed which means 'unix groups when winbind is running', as reverting the behaviour of 'valid users' when winbind is running to what the man page describes is obviously a backwards-incompatible change that would annoy a lot of users.

Essentially I'd like to be able to use NIS/local unix groups and netgroups even when winbind is running, there is no reason this shouldn't work. If this is not possible please at least alter the man page / documentation to reflect how '(in)valid users' actually works when winbind is running.
Comment 1 Alexander Bokovoy 2016-05-16 08:01:27 UTC
Thanks for the report, David.

When you run as 'security = ads', you are domain member. Domain member case considers only users known to the DCs, so winbindd does the right thing here and was always doing that.

I would say you relied on a path where a client without winbindd would do a fallback to authenticate and resolve users against AD DCs using auth_domain module in case communication with winbindd failed. This is strictly speaking a side effect of a fallback but definitely not an intended behavior.

Winbindd always considers primary group as defined for the user in AD for the domain member case. In your case you seem to have expectation that a user identity comes from a different source than Samba expects, thus a conflict.

Looking at the code that implements 'valid users' / 'invalid users' checks, I can see that we do a lookup of the identity specified in 'valid users' with '+' and then check the type of it (domain group, alias, workstation group). If it is not either of them, we fail the check. If it is one of them we do check of the SID in token against the share. For netgroups we always do user name check in the netgroup.

If group type is not mapped properly, you need to use 'net groupmap' to correct it on this specific machine.
Comment 2 David Bell 2016-05-16 09:19:37 UTC
Many thanks for your reply.

Our requirement is to use Samba to provide file shares to Windows users (on an AD domain) when running on a Linux system using Linux identity management, such as NIS today (or in future, FreeIPA/IDM). We don't want to use Active Directory groups, or SIDs, or anything like that, we just want to map by username between AD users and NIS users (which always map exactly, i.e. username = username). We don't have Unix extensions in our Active Directory and we have a large Linux estate with pre-existing UID/GIDs (thus, idmap isn't really an option).

Am I thus right in thinking if I choose 'security = ads' then I have to use Active Directory fully, rely on AD groups and SIDs and etc? This is a shame as I understood Samba as a way to bridge to AD, not a way to act as a Windows server. We need a way to bridge the two worlds - we don't wish to ditch our existing Linux ID management systems.

Is there no way a future version of Samba can be configured to utilise the local system's identity source -and- also allow Windows clients via AD to authenticate and use Samba shares on Linux?

The 'net groupmap' doesn't really help as I have hundreds of Linux servers where I'd have to run that, and hundreds of groups. Is it not possible to add a new character (like !group or something) to specify that Samba should look the group up via getgr* rather than AD?

p.s. can you change the man page of smb.conf for 'valid users'? It is incorrect and misleading when running 'winbind' which, from your comments, appears to be the recommended and expected behaviour when running Samba. The man page should make it clear that when running winbind that '(in)valid users' behaves in a very different way.
Comment 3 David Bell 2016-05-16 09:23:56 UTC
Alternatively, is there a way to use 'security = user' and allow Kerberos authentication to provide single sign on for Windows desktop clients?
Comment 4 Alexander Bokovoy 2016-05-16 14:12:45 UTC
(In reply to David Bell from comment #2)
> The 'net groupmap' doesn't really help as I have hundreds of Linux servers
> where I'd have to run that, and hundreds of groups. Is it not possible to add
> a new character (like !group or something) to specify that Samba should look 
> the group up via getgr* rather than AD?

'valid users' uses '+' already to look up the group via getgr*() calls. However, that interface does not provide SID. And access control tokens are all built with SIDs, so Samba needs to know a SID of the group that is allowed to access the resource to compare with the list of SIDs that the user who accesses the resource is member of.

Samba is the tool to map between POSIX attributes and Windows attributes, but it needs to get the information to map from some place. getgr*() don't give Samba any means to find out the SIDs.

To do so you need to maintain local database of mappings per server or you need to have all users/groups known to your domain controller.
Comment 5 Alexander Bokovoy 2016-05-16 14:16:56 UTC
You mentioned FreeIPA/IdM. In that setup there is actually a bit more flexibility because a passdb module FreeIPA provides for Samba is capable of handling forest trust. This makes possible to keep Linux hosts separate from Active Directory deployment and use centralized LDAP store to keep all users/groups, while at the same time able to authenticate Windows users using Kerberos over cross-forest trust.

In that setup you would be able to have centralized groups like you want.
Comment 6 David Bell 2016-05-16 15:56:18 UTC
(In reply to Alexander Bokovoy from comment #4)

> And access control tokens are all built with SIDs, so Samba needs to know a SID > of the group that is allowed to access the resource to compare with the list of > SIDs that the user who accesses the resource is member of.

But when winbind is not running Samba works fine and doesn't appear to need SIDs for access control for UNIX groups? Why does winbind running mean Samba requires SIDs for access control tokens? 

I know this is a big ask, but, can you not add a parameter to Samba such like "winbind mode = auth" (vs winbind mode = auto) where winbind is used for the NTLMSSP authentication but it doesn't mean Samba starts behaving in the way it does right now?

Or...can you add a parameter to allow NTLM auth work without winbind running?
Comment 7 Alexander Bokovoy 2016-05-16 16:04:35 UTC
(In reply to David Bell from comment #6)
> (In reply to Alexander Bokovoy from comment #4)
> 
> But when winbind is not running Samba works fine and doesn't appear to need
> SIDs for access control for UNIX groups? Why does winbind running mean Samba
> requires SIDs for access control tokens? 
It does always need them. There are some fallback paths which cause smbd to duplicate work done by winbindd. They are very fragile, though, for some of authentication requests.

We would need to look at what happens with 'valid users' with and without winbindd running. Can you provide anonymized logs with option 'log level = 10' set in [global] section?

Can you also check if using 'net groupmap' actually fixes your problem?

> I know this is a big ask, but, can you not add a parameter to Samba such
> like "winbind mode = auth" (vs winbind mode = auto) where winbind is used
> for the NTLMSSP authentication but it doesn't mean Samba starts behaving in
> the way it does right now?
> 
> Or...can you add a parameter to allow NTLM auth work without winbind running?
Today all identity operations should be done via winbindd already. A fall back is just that -- a fall back and it may fail. Let's concentrate on finding out what exactly fails in your configuration.
Comment 8 David Bell 2016-05-16 18:13:46 UTC
> Can you provide anonymized logs with option 'log level = 10' set in [global] section?

I will get you the debug logs you asked for tomorrow after I've cleaned them.

> Can you also check if using 'net groupmap' actually fixes your problem?

'net groupmap' doesn't make any sense to me - I don't have a group in Active Directory to map to, nor would I want such a group to map to. I simply want to use the group within Samba for access control, why does Samba have to tell the client that the group exists or who is in it or what its SID it has? All I want Samba to do is to check the user accessing the share is within the group with getgr*. 

I cannot go and create hundreds of new groups in Active Directory (to match our NIS groups) and then place our users into them - our PAC is already far too large for most of our users. I fail to see why Samba needs to know the Windows information (SIDS, etc) about a UNIX group!

> Today all identity operations should be done via winbindd already.

Then this should be added to "man 5 smb.conf" and any other documentation. smbd should not start if winbind is not running if the user sets "security = ads" (Or at least print a lot of warnings!).
Comment 9 David Bell 2016-05-16 18:35:48 UTC
The groupmap doesn't appear to work for me:

[root@play01020 ~]# net groupmap add unixgroup=jf ntgroup=jfStaff sid=S-1-5-21-2015846570-11164191-355810188-3152
Successfully added group jfStaff to the mapping db as a domain group

[root@play01020 ~]# net groupmap list
jfStaff (S-1-5-21-2015846570-11164191-355810188-3152) -> jf

[root@play01020 ~]# getent group jf
jf:*:339:

[root@play01020 ~]# wbinfo -Y S-1-5-21-2015846570-11164191-355810188-3152
-1

[root@play01020 ~]# wbinfo --group-info=jfStaff
jfstaff:x:4294967295:

[root@play01020 ~]# wbinfo -G 339
failed to call wbcGidToSid: WBC_ERR_DOMAIN_NOT_FOUND
Could not convert gid 339 to sid

If I try with:

net groupmap add unixgroup=jf sid=S-1-5-21-2015846570-11164191-355810188-3152

It fails in exactly the same way. :(
Comment 10 Jeremy Allison 2016-05-16 20:17:25 UTC
(In reply to David Bell from comment #8)

> I fail to see why Samba needs to know the Windows information (SIDS, etc) about a UNIX group!

Because in modern Samba all access control on ACLs etc. is done by using the Windows ACL evaluation algorithm on Windows ACLs - which by definition include SIDs. There's no way around this, it's part of the functionality of Samba as a Windows -> UNIX bridge.
Comment 11 David Bell 2016-05-17 11:52:17 UTC
(In reply to Jeremy Allison from comment #10)

Many thanks for your reply.

We were hoping we could use netgroups for access control (which I guess don't need to map to SIDs?!) combined with 'force user' and 'force group'. Whilst the netgroups access control works the 'force user' behaviour also changes when running winbind and Samba is unable to get a SID. This is odd because it should be able to just lookup the user in AD and get the SID and lookup the user in NIS and get the UID, but Samba appears to look up the user in AD and then try to map it (without consulting NIS).

We could configure an idmap backend to solve this - but we can't use idmap_ad (i.e. RFC2307 extensions to AD) because our AD doesn't have them and for lots of complicated reasons we can't add them either. We can't use idmap_rid or hash because we already have allocated UIDs and GIDs and data is stored everywhere across hundreds of boxes using these UIDs and GIDs, and we can't just move to nss_winbind/pam_winbind everywhere for this reason either. We were hoping that idmap_nss would work but this doesn't seem to. 

Do you think idmap_ldap would be the best way to solve this problem? Of course, this would not solve our groups problem, but it would at least solve the user mapping issue. Group mapping would be an issue still for us since we don't have groups to map to in AD, and the local 'net groupmap' commands didn't work anyway.

Can you confirm that with 'security = ads' in 'modern samba' smbd looks for everything in AD and needs to get SIDs for everything (and be able to then map those to UIDs/GIDs)? This is fine, but I think this should be clearly documented on samba.org somewhere (and in the man pages).

We have been able to reproduce the 'legacy' and 'fragile' behaviour by switching to 'security = user' and using smbpasswd backend (well, tdb). We could then combine that with ldapsam or ipasam. That way we don't run winbind. However this also still seems to do SID mapping, but works by using "LEGACY" SID stuff:

gid_to_sid: winbind failed to find a sid for gid 339
LEGACY: gid 339 -> sid S-1-22-2-339

Is using security = user and ldapsam a good idea? Or is this legacy too and something we should not use? If so, does that not mean that Samba in the future will only work for file sharing when in an AD domain with either a hash based ID mapping or RFC2307 extensions in AD (something that Microsoft is essentially deprecating now they've killed SFU/IMU!).
Comment 12 Alexander Bokovoy 2016-05-19 07:57:39 UTC
David,

can we see the logs you promised in the comment 8?
Comment 13 Alexander Bokovoy 2016-05-19 08:22:15 UTC
Also, please use the following instructions when generating logs: https://www.samba.org/~asn/reporting_samba_bugs.txt
Comment 14 Alexander Bokovoy 2016-05-19 11:31:53 UTC
(In reply to David Bell from comment #11)
> (In reply to Jeremy Allison from comment #10)
> 
> Many thanks for your reply.
> 
> We were hoping we could use netgroups for access control (which I guess
> don't need to map to SIDs?!) combined with 'force user' and 'force group'.
> Whilst the netgroups access control works the 'force user' behaviour also
> changes when running winbind and Samba is unable to get a SID. This is odd
> because it should be able to just lookup the user in AD and get the SID and
> lookup the user in NIS and get the UID, but Samba appears to look up the
> user in AD and then try to map it (without consulting NIS).
> 
> We could configure an idmap backend to solve this - but we can't use
> idmap_ad (i.e. RFC2307 extensions to AD) because our AD doesn't have them
> and for lots of complicated reasons we can't add them either. We can't use
> idmap_rid or hash because we already have allocated UIDs and GIDs and data
> is stored everywhere across hundreds of boxes using these UIDs and GIDs, and
> we can't just move to nss_winbind/pam_winbind everywhere for this reason
> either. We were hoping that idmap_nss would work but this doesn't seem to. 
> 
> Do you think idmap_ldap would be the best way to solve this problem? Of
> course, this would not solve our groups problem, but it would at least solve
> the user mapping issue. Group mapping would be an issue still for us since
> we don't have groups to map to in AD, and the local 'net groupmap' commands
> didn't work anyway.
You are mistaken by thinking you only need idmap here. Your problem is two-fold.

- Samba needs to know mapping between UID or GID and SID
- Samba needs to know how to map user or group name to SID (and back)

Domain Controller knows about the latter part. Samba handles the former via IDMAP modules.

Any idmap module has certain assumption about the way how SID mapping to ID happens.

In fact, the IDMAP interface only allows to ask for how SID maps to ID or how ID maps 
to SID (there is also ID allocation code but most IDMAP modules don't implement it)
and the modules will have to deal with that information to convert the data.

The way idmap_nss works is:
1. look up ID via getpwuid()/getgrid() to obtain user or group name
2. look up SID based on the user or group name via winbindd

On AD domain member winbindd will do a call to domain controller to resolve user/group name to SID.
If winbindd is not running, this call will fail and therefore, whole look up of ID to SID will fail.

If winbindd is running but domain controller doesn't successfully map 
the user/group name to SID, whole look up of ID to SID will fail.

So your DC has to know about these groups to be able to provide information about their SIDs.

Using idmap_ldap assumes use of a particular LDAP schema to store information about ID mappings.
This information does not exist in your AD anyway.
 
> Can you confirm that with 'security = ads' in 'modern samba' smbd looks for
> everything in AD and needs to get SIDs for everything (and be able to then
> map those to UIDs/GIDs)? This is fine, but I think this should be clearly
> documented on samba.org somewhere (and in the man pages).
It depends on which idmap module is in use because from Samba point of view 
we deal with SID<->UID/GID mapping. Authentication is always done against domain controller.
idmap modules would differ but at least user and group name should be known to AD DC, 
thus assuming that SID for each object is known to them too.

So Samba does consult AD DC for name<->SID mapping and uses idmap modules
to consult for ID<->SID mapping.

In your situation there is no place for storing ID<->SID mapping in NIS and
idmap_nss doesn't help with that, so Samba talks to AD DC after it finds out
the name of the object it needs to get a SID for.

An obvious solution would be to have these NIS groups duplicated in AD. 
I'm not sure whether you would need to have full structure of the groups
duplicated there, though, as all what would be needed is ability of AD DC
to resolve group name to SID.

> We have been able to reproduce the 'legacy' and 'fragile' behaviour by
> switching to 'security = user' and using smbpasswd backend (well, tdb). We
> could then combine that with ldapsam or ipasam. That way we don't run
> winbind. However this also still seems to do SID mapping, but works by using
> "LEGACY" SID stuff:
> 
> gid_to_sid: winbind failed to find a sid for gid 339
> LEGACY: gid 339 -> sid S-1-22-2-339
> 
> Is using security = user and ldapsam a good idea? Or is this legacy too and
> something we should not use? If so, does that not mean that Samba in the
> future will only work for file sharing when in an AD domain with either a
> hash based ID mapping or RFC2307 extensions in AD (something that Microsoft
> is essentially deprecating now they've killed SFU/IMU!).
No, it is not a good idea. It is not related to how SFU/IMU are done either.
You effectively want to have two sources to be authoritative for user/group information.

When using 'security = user' you want to configure Samba as PDC. 
If it is not part of AD domain (it wouldn't be with this configuration), AD clients would
consider connecting to this machine as to the machine outside of the domain. Kerberos
authentication from AD machines will not work, only password-based authentication
would work if Samba would know where to authenticate the incoming connections.
To solve this, a forest trust could be established between Samba PDC and AD DC but
this is not possible with centralized PASSDB module like ldapsam because ldapsam 
doesn't support storing trusted domain objects. We only have this support in FreeIPA's 
ipasam module and I pointed to that option already in the comment 5.
Comment 15 David Bell 2016-05-19 14:19:34 UTC
We have a single Active Directory domain "SOTON" / "soton.ac.uk" which is 
running on Windows Server 2012R2 domain controllers. The domain has anonymous 
bind enabled and all the users live in ou=users,dc=soton,dc=ac,dc=uk. The user 
objects do not contain RFC2307(bis) unix attributes, and for various reasons we 
cannot add them.

On the Linux side we use:

nsswitch - NIS
pam - via pam_krb5 configured to talk to our Active Directory for authentication
We run Samba 3.6 on RHEL6, without winbind.

Our NIS domain is 'forest.soton.ac.uk'. All usernames in NIS map exactly to 
usernames in Active Directory. There are no passwords in NIS.

We use share access controls with the 'valid users' parameter and we use 
+group and @netgroup definitions here. 

We then use, in some cases, standard Linux DAC permissions on files, such as 
setting directories to be accessed by members of a group.

In other cases, more frequently, we use 'force user' and 'force group'. This is 
used for things like web hosting so multiple users can manage files as a service 
account for a website.

--------------------------------------------------------------------------------

Packages information:

[root@play01038 ~]# rpm -qai samba\* \*smb\* \*talloc\* \*tdb\* \*ldb\* \*tevent\* \*wbclient\*
Name        : samba-client                 Relocations: (not relocatable)
Version     : 3.6.23                            Vendor: Red Hat, Inc.
Release     : 35.el6_8                      Build Date: Mon 25 Apr 2016 21:45:37 BST
Install Date: Thu 19 May 2016 12:45:04 BST      Build Host: x86-029.build.eng.bos.redhat.com
Group       : Applications/System           Source RPM: samba-3.6.23-35.el6_8.src.rpm
Size        : 42087437                         License: GPLv3+ and LGPLv3+
Signature   : RSA/8, Mon 02 May 2016 16:15:48 BST, Key ID 199e2f91fd431d51
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
URL         : http://www.samba.org/
Summary     : Samba client programs
Description :
The samba-client package provides some SMB/CIFS clients to complement
the built-in SMB/CIFS filesystem in Linux. These clients allow access
of SMB/CIFS shares and printing to SMB/CIFS printers.
Name        : libtevent                    Relocations: (not relocatable)
Version     : 0.9.26                            Vendor: Red Hat, Inc.
Release     : 2.el6_7                       Build Date: Mon 04 Apr 2016 10:00:14 BST
Install Date: Thu 19 May 2016 12:43:08 BST      Build Host: x86-029.build.eng.bos.redhat.com
Group       : System Environment/Daemons    Source RPM: libtevent-0.9.26-2.el6_7.src.rpm
Size        : 57616                            License: LGPLv3+
Signature   : RSA/8, Fri 08 Apr 2016 17:49:30 BST, Key ID 199e2f91fd431d51
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
URL         : http://tevent.samba.org/
Summary     : The tevent library
Description :
Tevent is an event system based on the talloc memory management library.
Tevent has support for many event types, including timers, signals, and
the classic file descriptor events.
Tevent also provide helpers to deal with asynchronous code providing the
tevent_req (Tevent Request) functions.
Name        : libtalloc                    Relocations: (not relocatable)
Version     : 2.1.5                             Vendor: Red Hat, Inc.
Release     : 1.el6_7                       Build Date: Fri 01 Apr 2016 13:44:03 BST
Install Date: Thu 19 May 2016 12:43:07 BST      Build Host: x86-033.build.eng.bos.redhat.com
Group       : System Environment/Daemons    Source RPM: libtalloc-2.1.5-1.el6_7.src.rpm
Size        : 53216                            License: LGPLv3+
Signature   : RSA/8, Fri 08 Apr 2016 17:58:52 BST, Key ID 199e2f91fd431d51
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
URL         : http://talloc.samba.org/
Summary     : The talloc library
Description :
A library that implements a hierarchical allocator with destructors.
Name        : libldb                       Relocations: (not relocatable)
Version     : 1.1.25                            Vendor: Red Hat, Inc.
Release     : 2.el6_7                       Build Date: Mon 04 Apr 2016 12:17:36 BST
Install Date: Thu 19 May 2016 12:43:08 BST      Build Host: x86-031.build.eng.bos.redhat.com
Group       : Development/Libraries         Source RPM: libldb-1.1.25-2.el6_7.src.rpm
Size        : 314320                           License: LGPLv3+
Signature   : RSA/8, Fri 08 Apr 2016 17:46:03 BST, Key ID 199e2f91fd431d51
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
URL         : http://ldb.samba.org/
Summary     : A schema-less, ldap like, API and database
Description :
An extensible library that implements an LDAP like API to access remote LDAP
servers, or use local tdb databases.
Name        : pytalloc                     Relocations: (not relocatable)
Version     : 2.1.5                             Vendor: Red Hat, Inc.
Release     : 1.el6_7                       Build Date: Fri 01 Apr 2016 13:44:03 BST
Install Date: Thu 19 May 2016 12:43:24 BST      Build Host: x86-033.build.eng.bos.redhat.com
Group       : Development/Libraries         Source RPM: libtalloc-2.1.5-1.el6_7.src.rpm
Size        : 14832                            License: LGPLv3+
Signature   : RSA/8, Fri 08 Apr 2016 17:58:53 BST, Key ID 199e2f91fd431d51
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
URL         : http://talloc.samba.org/
Summary     : Developer tools for the Talloc library
Description :
Pytalloc libraries for creating python bindings using talloc
Name        : samba-common                 Relocations: (not relocatable)
Version     : 3.6.23                            Vendor: Red Hat, Inc.
Release     : 35.el6_8                      Build Date: Mon 25 Apr 2016 21:45:37 BST
Install Date: Thu 19 May 2016 12:44:56 BST      Build Host: x86-029.build.eng.bos.redhat.com
Group       : Applications/System           Source RPM: samba-3.6.23-35.el6_8.src.rpm
Size        : 38248548                         License: GPLv3+ and LGPLv3+
Signature   : RSA/8, Mon 02 May 2016 16:16:00 BST, Key ID 199e2f91fd431d51
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
URL         : http://www.samba.org/
Summary     : Files used by both Samba servers and clients
Description :
Samba-common provides files necessary for both the server and client
packages of Samba.
Name        : libtdb                       Relocations: (not relocatable)
Version     : 1.3.8                             Vendor: Red Hat, Inc.
Release     : 3.el6_8.2                     Build Date: Tue 26 Apr 2016 09:07:17 BST
Install Date: Thu 19 May 2016 12:43:08 BST      Build Host: x86-029.build.eng.bos.redhat.com
Group       : System Environment/Daemons    Source RPM: libtdb-1.3.8-3.el6_8.2.src.rpm
Size        : 85520                            License: LGPLv3+
Signature   : RSA/8, Fri 29 Apr 2016 07:45:13 BST, Key ID 199e2f91fd431d51
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
URL         : http://tdb.samba.org/
Summary     : The tdb library
Description :
A library that implements a trivial database.
Name        : samba-winbind-clients        Relocations: (not relocatable)
Version     : 3.6.23                            Vendor: Red Hat, Inc.
Release     : 35.el6_8                      Build Date: Mon 25 Apr 2016 21:45:37 BST
Install Date: Thu 19 May 2016 12:44:54 BST      Build Host: x86-029.build.eng.bos.redhat.com
Group       : Applications/System           Source RPM: samba-3.6.23-35.el6_8.src.rpm
Size        : 6850879                          License: GPLv3+ and LGPLv3+
Signature   : RSA/8, Mon 02 May 2016 16:16:06 BST, Key ID 199e2f91fd431d51
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
URL         : http://www.samba.org/
Summary     : Samba winbind clients
Description :
The samba-winbind-clients package provides the NSS library and a PAM
module necessary to communicate to the Winbind Daemon
Name        : samba4-libs                  Relocations: (not relocatable)
Version     : 4.2.10                            Vendor: Red Hat, Inc.
Release     : 6.el6_7                       Build Date: Tue 12 Apr 2016 09:46:55 BST
Install Date: Thu 19 May 2016 12:43:26 BST      Build Host: x86-027.build.eng.bos.redhat.com
Group       : Applications/System           Source RPM: samba4-4.2.10-6.el6_7.src.rpm
Size        : 18101016                         License: GPLv3+ and LGPLv3+
Signature   : RSA/8, Tue 12 Apr 2016 11:48:32 BST, Key ID 199e2f91fd431d51
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
URL         : http://www.samba.org/
Summary     : Samba libraries
Description :
The samba4-libs package contains the libraries needed by programs that
link against the SMB, RPC and other protocols provided by the Samba suite.
Name        : samba                        Relocations: (not relocatable)
Version     : 3.6.23                            Vendor: Red Hat, Inc.
Release     : 35.el6_8                      Build Date: Mon 25 Apr 2016 21:45:37 BST
Install Date: Thu 19 May 2016 12:45:05 BST      Build Host: x86-029.build.eng.bos.redhat.com
Group       : System Environment/Daemons    Source RPM: samba-3.6.23-35.el6_8.src.rpm
Size        : 18719240                         License: GPLv3+ and LGPLv3+
Signature   : RSA/8, Mon 02 May 2016 16:16:05 BST, Key ID 199e2f91fd431d51
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
URL         : http://www.samba.org/
Summary     : Server and Client software to interoperate with Windows machines
Description :

Samba is the suite of programs by which a lot of PC-related machines
share files, printers, and other information (such as lists of
available files and printers). The Windows NT, OS/2, and Linux
operating systems support this natively, and add-on packages can
enable the same thing for DOS, Windows, VMS, UNIX of all kinds, MVS,
and more. This package provides an SMB/CIFS server that can be used to
provide network services to SMB/CIFS clients.
Samba uses NetBIOS over TCP/IP (NetBT) protocols and does NOT
need the NetBEUI (Microsoft Raw NetBIOS frame) protocol.
Name        : samba-winbind                Relocations: (not relocatable)
Version     : 3.6.23                            Vendor: Red Hat, Inc.
Release     : 35.el6_8                      Build Date: Mon 25 Apr 2016 21:45:37 BST
Install Date: Thu 19 May 2016 12:44:57 BST      Build Host: x86-029.build.eng.bos.redhat.com
Group       : Applications/System           Source RPM: samba-3.6.23-35.el6_8.src.rpm
Size        : 8092058                          License: GPLv3+ and LGPLv3+
Signature   : RSA/8, Mon 02 May 2016 16:16:06 BST, Key ID 199e2f91fd431d51
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
URL         : http://www.samba.org/
Summary     : Samba winbind
Description :
The samba-winbind package provides the winbind daemon and some client tools.
Winbind enables Linux to be a full member in Windows domains and to use
Windows user and group accounts on Linux.

--------------------------------------------------------------------------------

For these tests I've set up a single share 'sambatest'. On disk this is at 
/data/test

The directory /data/test is set to root:cz where cz is a group in NIS. Within 
the directory /data/test there is a directory called /data/test/cz_only. That 
directory is owned by root, grouped to 'cz' and permissions set to 0770.

The test user I'm using is 'entdev1'. In NIS the primary group of this user 
is 'cz'.

Details about the user:

[root@play01038 ~]# getent passwd entdev1
entdev1:*:12758:177:Entdev:/home/entdev1:/bin/bash

[root@play01038 ~]# getent group cz
cz:*:177:

The AD object for entdev1 is:

# entdev1, staff, cz, jf, pk, User, soton.ac.uk
dn: CN=entdev1,OU=staff,OU=cz,OU=jf,OU=pk,OU=User,DC=soton,DC=ac,DC=uk
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: entdev1
sn: Entdev
distinguishedName: CN=entdev1,OU=staff,OU=cz,OU=jf,OU=pk,OU=User,DC=soton,DC=a
 c,DC=uk
instanceType: 4
whenCreated: 20160519092728.0Z
whenChanged: 20160519092817.0Z
displayName: Entdev
uSNCreated: 864115905
memberOf: CN=czStaff,OU=staff,OU=cz,OU=jf,OU=pk,OU=User,DC=soton,DC=ac,DC=uk
uSNChanged: 864116716
department: iSolutions (ext cust)
homeMTA: CN=Microsoft MTA,CN=SRV00047,CN=Servers,CN=Exchange Administrative Gr
 oup (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=University of Southampton,C
 N=Microsoft Exchange,CN=Services,CN=Configuration,DC=soton,DC=ac,DC=uk
proxyAddresses: smtp:Entdev@exchange.soton.ac.uk
proxyAddresses: smtp:Entdev@southampton.ac.uk
proxyAddresses: SMTP:Entdev@soton.ac.uk
proxyAddresses: smtp:entdev1@sotonac.mail.onmicrosoft.com
proxyAddresses: smtp:entdev1@exchange.soton.ac.uk
proxyAddresses: smtp:entdev1@southampton.ac.uk
proxyAddresses: smtp:entdev1@soton.ac.uk
homeMDB: CN=DB021,CN=Databases,CN=Exchange Administrative Group (FYDIBOHF23SPD
 LT),CN=Administrative Groups,CN=University of Southampton,CN=Microsoft Exchan
 ge,CN=Services,CN=Configuration,DC=soton,DC=ac,DC=uk
mDBUseDefaults: TRUE
extensionAttribute9: generic
extensionAttribute10: Active
mailNickname: entdev1
employeeNumber: X000353
name: entdev1
objectGUID:: o0jyJ+pqlEy0iW2SYZPbeQ==
userAccountControl: 512
badPwdCount: 3
codePage: 0
countryCode: 0
employeeID: X000353
badPasswordTime: 131081258560676114
pwdLastSet: 131081236652822960
primaryGroupID: 513
objectSid:: AQUAAAAAAAUVAAAAqmAneB9aqgCMOzUVSzMJAA==
accountExpires: 9223372036854775807
sAMAccountName: entdev1
division: iSolutions (ext cust)
sAMAccountType: 805306368
showInAddressBook: CN=All Users,CN=All Address Lists,CN=Address Lists Containe
 r,CN=University of Southampton,CN=Microsoft Exchange,CN=Services,CN=Configura
 tion,DC=soton,DC=ac,DC=uk
showInAddressBook: CN=Default Global Address List,CN=All Global Address Lists,
 CN=Address Lists Container,CN=University of Southampton,CN=Microsoft Exchange
 ,CN=Services,CN=Configuration,DC=soton,DC=ac,DC=uk
legacyExchangeDN: /o=University of Southampton/ou=Exchange Administrative Grou
 p (FYDIBOHF23SPDLT)/cn=Recipients/cn=entdev1f7f
userPrincipalName: entdev1@soton.ac.uk
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=soton,DC=ac,DC=uk
dSCorePropagationData: 16010101000000.0Z
lastLogonTimestamp: 131081236874111454
textEncodedORAddress: X400:C=UK;A= ;O=ac;S=Entdev;OU1=soton;OU2=exchange;
mail: Entdev@soton.ac.uk
msExchHomeServerName: /o=University of Southampton/ou=Exchange Administrative 
 Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=SRV00047
msExchMailboxSecurityDescriptor:: AQAEgBQAAAAgAAAAAAAAACwAAAABAQAAAAAABQoAAAAB
 AQAAAAAABQoAAAAEABwAAQAAAAACFAABAAIAAQEAAAAAAAUKAAAA
msExchUserAccountControl: 0
msExchMailboxGuid:: jSVZXeV7qkG0EDFKYch6Kg==
msExchPoliciesIncluded: ba25f602-48d3-4ace-bdbf-455568f1638a
msExchPoliciesIncluded: {26491cfc-9e50-4857-861b-0cb8df22b5d7}
msExchPoliciesExcluded: {26491CFC-9E50-4857-861B-0CB8DF22B5D7}
msExchRecipientTypeDetails: 1
msRTCSIP-PrimaryUserAddress: sip:entdev1@soton.ac.uk
msExchRecipientDisplayType: 1073741824
msExchRBACPolicyLink: CN=Default Role Assignment Policy,CN=Policies,CN=RBAC,CN
 =University of Southampton,CN=Microsoft Exchange,CN=Services,CN=Configuration
 ,DC=soton,DC=ac,DC=uk
msExchTextMessagingState: 302120705
msExchTextMessagingState: 16842751
msExchUMDtmfMap: emailAddress:3683381
msExchUMDtmfMap: lastNameFirstName:368338
msExchUMDtmfMap: firstNameLastName:368338
msExchWhenMailboxCreated: 20160519092739.0Z
msExchVersion: 44220983382016

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

The SID of the user is:

S-1-5-21-2015846570-11164191-355810188-602955 SID_USER (1)

--------------------------------------------------------------------------------
TEST ONE: Samba without winbind running. Domain joined via 'net ads join'. 

The smb.conf is as so:

[global]
workgroup = SOTON
server string = %h
realm = SOTON.AC.UK
security = ads
kerberos method = system keytab
password server = * cifsauth.soton.ac.uk
name resolve order = host
local master = no
preferred master = no
wins support = no
client NTLMv2 auth = yes
client lanman auth = no
client plaintext auth = no
lanman auth = no
ntlm auth = no
load printers = no
disable spoolss = yes
client ipc signing = auto
debug level = 10
debug pid = true
max log size = 0

[sambatest]
  path = /data/test
  browseable = yes
  writable = yes
  valid users = +cz +srvadm

[root@play01038 ~]# service winbind status
winbindd is stopped

[root@play01038 ~]# service smb stop
Shutting down SMB services:                                [  OK  ]

[root@play01038 ~]# rm -rf /var/log/samba/*
[root@play01038 ~]# rm -rf /var/lib/samba/*.tdb /var/lib/samba/private/*.tdb

[root@play01038 ~]# domjoin
Enter a username with permission to join the SOTON.AC.UK domain
Username: admdrb
Enter admdrb's password:
Using short domain name -- SOTON
Joined 'PLAY01038' to dns domain 'soton.ac.uk'

[root@play01038 ~]# service smb start
Starting SMB services:                                     [  OK  ]

Now we attempt to connect from smbclient on RHEL7 workstation:

[db2z07@laptop ~]$ rpm -qa|grep samba-client
samba-client-4.2.10-6.el7_2.x86_64
samba-client-libs-4.2.10-6.el7_2.x86_64

[db2z07@evadlaptopz ~]$ smbclient '\\play01038.soton.ac.uk\sambatest' -U 'SOTON\entdev1' -v
Enter SOTON\entdev1's password: 
Domain=[SOTON] OS=[Unix] Server=[Samba 3.6.23-35.el6_8]
smb: \> ls
  .                                   D        0  Thu May 19 13:18:53 2016
  ..                                  D        0  Thu May 19 13:17:45 2016
  cz_only                             D        0  Thu May 19 13:18:53 2016

		206289592 blocks of size 1024. 195743348 blocks available
smb: \> cd cz_only\
smb: \cz_only\> ls
  .                                   D        0  Thu May 19 13:18:53 2016
  ..                                  D        0  Thu May 19 13:18:53 2016

		206289592 blocks of size 1024. 195743348 blocks available
smb: \cz_only\> 

Access works! This was not expected as testing on existing servers resulted
in access not being granted. I suspect this is because we had started running
winbind prior to Red Hat releasing RHBA-2016:0992 which looks to have fixed
the issue where non-kerberos auth didn't work without winbind running.

Here is the full log: http://www.southampton.ac.uk/~db2z07/log.smbd.nowinbind.txt

However, this bug is about running with winbind, and Red Hat and Samba say
we should be running it, so, onto test two:

--------------------------------------------------------------------------------
TEST TWO: Samba running and winbind running. Domain re-joined via net ads join.

The smb.conf is as so:

[global]
workgroup = SOTON
server string = %h
realm = SOTON.AC.UK
security = ads
kerberos method = system keytab
password server = * cifsauth.soton.ac.uk
name resolve order = host
local master = no
preferred master = no
wins support = no
client NTLMv2 auth = yes
client lanman auth = no
client plaintext auth = no
lanman auth = no
ntlm auth = no
load printers = no
disable spoolss = yes
client ipc signing = auto
debug level = 10
debug pid = true
max log size = 0
winbind use default domain = yes
winbind separator = +

[sambatest]
  path = /data/test
  browseable = yes
  writable = yes
  valid users = +cz +srvadm

[root@play01038 ~]# service smb stop
Shutting down SMB services:                                [  OK  ]

[root@play01038 ~]# rm -rf /var/log/samba/*
[root@play01038 ~]# rm -rf /var/lib/samba/*.tdb /var/lib/samba/private/*.tdb

[root@play01038 ~]# domjoin
Enter a username with permission to join the SOTON.AC.UK domain
Username: admdrb
Enter admdrb's password:
Using short domain name -- SOTON
Joined 'PLAY01038' to dns domain 'soton.ac.uk'


[root@play01038 test]# service winbind start
Starting Winbind services:                                 [  OK  ]

[root@play01038 ~]# service smb start
Starting SMB services:                                     [  OK  ]

Now we attempt to connect from smbclient on RHEL7 workstation:

[db2z07@laptop ~]$ rpm -qa|grep samba-client
samba-client-4.2.10-6.el7_2.x86_64
samba-client-libs-4.2.10-6.el7_2.x86_64

[db2z07@evadlaptopz ~]$ smbclient '\\play01038.soton.ac.uk\sambatest' -U 'SOTON\entdev1' -v
Enter SOTON\entdev1's password: 
Domain=[SOTON] OS=[Unix] Server=[Samba 3.6.23-35.el6_8]
tree connect failed: NT_STATUS_ACCESS_DENIED

The relevant part of log.smbd is:

[2016/05/19 14:22:26.718646, 10, pid=31436] smbd/share_access.c:219(user_ok_token)
  User entdev1 not in 'valid users'

Even though the account is in valid users (via +cz).

The full logs for this session are here: http://www.southampton.ac.uk/~db2z07/samba_logs_with_winbind/

--------------------------------------------------------------------------------
TEST THREE: I also want to show you what happens when the share access control 
doesn't matter. For this test I've added the usernames of the accounts 
directly to 'valid users'.

The smb.conf is as so:

[global]
workgroup = SOTON
server string = %h
realm = SOTON.AC.UK
security = ads
kerberos method = system keytab
password server = * cifsauth.soton.ac.uk
name resolve order = host
local master = no
preferred master = no
wins support = no
client NTLMv2 auth = yes
client lanman auth = no
client plaintext auth = no
lanman auth = no
ntlm auth = no
load printers = no
disable spoolss = yes
client ipc signing = auto
debug level = 10
debug pid = true
max log size = 0
winbind use default domain = yes
winbind separator = +

[sambatest]
  path = /data/test
  browseable = yes
  writable = yes
  valid users = entdev1 db2z07

All I've done for this test is wipe the logs and restarted winbind and smb:

[root@play01038 ~]# rm -rf /var/log/samba/*

[root@play01038 test]# service winbind start
Starting Winbind services:                                 [  OK  ]

[root@play01038 ~]# service smb start
Starting SMB services:                                     [  OK  ]

Now we attempt to connect from smbclient on RHEL7 workstation:

[db2z07@laptop ~]$ rpm -qa|grep samba-client
samba-client-4.2.10-6.el7_2.x86_64
samba-client-libs-4.2.10-6.el7_2.x86_64

[db2z07@evadlaptopz ~]$ smbclient '\\play01038.soton.ac.uk\sambatest' -U 'SOTON\entdev1' -v
Enter SOTON\entdev1's password: 
Domain=[SOTON] OS=[Unix] Server=[Samba 3.6.23-35.el6_8]
smb: \> ls
  .                                   D        0  Thu May 19 13:18:53 2016
  ..                                  D        0  Thu May 19 13:17:45 2016
  cz_only                             D        0  Thu May 19 13:18:53 2016

		206289592 blocks of size 1024. 195743348 blocks available
smb: \> cd cz_only
smb: \cz_only\> ls
  .                                   D        0  Thu May 19 13:18:53 2016
  ..                                  D        0  Thu May 19 13:18:53 2016

		206289592 blocks of size 1024. 195743348 blocks available
smb: \cz_only\> 

However from a Windows 8.1 client it does not work:

http://evad.io/shoots/20160519_145101.png

And Windows can't display permissions:

http://evad.io/shoots/20160519_145200.png

The full logs for this session are here: http://www.southampton.ac.uk/~db2z07/samba_logs_with_winbind_nosharecontrol/

--------------------------------------------------------------------------------

TEST FOUR:

However access from windows into the 'cz_only' directory does work when winbind 
is not running:

http://evad.io/shoots/20160519_145638.png

The log files for Windows access when winbind is not running is here: 

http://www.southampton.ac.uk/~db2z07/log.smbd.nowinbind_windowsclient.txt

--------------------------------------------------------------------------------

TEST FIVE: Samba with Winbind, domain joined, with share control set to usernames

On Samba 3.6 on RHEL6 this worked from smbclient, but not from Windows 8.1
On Samba 4.2 on RHEL7 this doesn't work from either.

smb.conf is:

[global]
workgroup = SOTON
server string = %h
realm = SOTON.AC.UK
security = ads
kerberos method = system keytab
password server = * cifsauth.soton.ac.uk
name resolve order = host
local master = no
preferred master = no
wins support = no
client NTLMv2 auth = yes
client lanman auth = no
client plaintext auth = no
lanman auth = no
ntlm auth = no
load printers = no
disable spoolss = yes
log level = 10
debug pid = true
max log size = 0
winbind use default domain = yes
winbind separator = +

[sambatest]
  path = /data/test
  browseable = yes
  writable = yes
  valid users = entdev1 db2z07

Accessing the share via smbclient works, but you can't get into 'cz_only' even
though the account 'entdev1' is in the group (via its primary group).

[db2z07@evadlaptopz ~]$ smbclient '\\play01020.soton.ac.uk\sambatest' -U 'SOTON\entdev1' -v
Enter SOTON\entdev1's password: 
Domain=[SOTON] OS=[Windows 6.1] Server=[Samba 4.2.10]
smb: \> ls
  .                                   D        0  Thu May 19 15:09:33 2016
  ..                                  D        0  Tue May 10 21:12:55 2016
  cz_only                             D        0  Thu May 19 15:09:33 2016

		1570816 blocks of size 1024. 1537872 blocks available
smb: \> cd cz_only
smb: \cz_only\> ls
NT_STATUS_ACCESS_DENIED listing \cz_only\*
smb: \cz_only\>

I've uploaded all the logs for this as well here:

http://www.southampton.ac.uk/~db2z07/samba4_logs_with_winbind_nosharecontrol/

Package information:

[root@play01020 samba]# rpm -qai samba\* \*smb\* \*talloc\* \*tdb\* \*ldb\* \*tevent\* \*wbclient\*
Name        : samba-common-libs
Epoch       : 0
Version     : 4.2.10
Release     : 6.el7_2
Architecture: x86_64
Install Date: Sun 17 Apr 2016 08:51:39 BST
Group       : Applications/System
Size        : 280064
License     : GPLv3+ and LGPLv3+
Signature   : RSA/SHA256, Tue 12 Apr 2016 11:51:15 BST, Key ID 199e2f91fd431d51
Source RPM  : samba-4.2.10-6.el7_2.src.rpm
Build Date  : Tue 12 Apr 2016 09:25:00 BST
Build Host  : x86-030.build.eng.bos.redhat.com
Relocations : (not relocatable)
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
Vendor      : Red Hat, Inc.
URL         : http://www.samba.org/
Summary     : Libraries used by both Samba servers and clients
Description :
The samba-common-libs package contains internal libraries needed by the
SMB/CIFS clients.
Name        : samba-client
Epoch       : 0
Version     : 4.2.10
Release     : 6.el7_2
Architecture: x86_64
Install Date: Sun 17 Apr 2016 08:51:42 BST
Group       : Applications/System
Size        : 1352201
License     : GPLv3+ and LGPLv3+
Signature   : RSA/SHA256, Tue 12 Apr 2016 11:51:21 BST, Key ID 199e2f91fd431d51
Source RPM  : samba-4.2.10-6.el7_2.src.rpm
Build Date  : Tue 12 Apr 2016 09:25:00 BST
Build Host  : x86-030.build.eng.bos.redhat.com
Relocations : (not relocatable)
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
Vendor      : Red Hat, Inc.
URL         : http://www.samba.org/
Summary     : Samba client programs
Description :
The samba4-client package provides some SMB/CIFS clients to complement
the built-in SMB/CIFS filesystem in Linux. These clients allow access
of SMB/CIFS shares and printing to SMB/CIFS printers.
Name        : samba-common
Epoch       : 0
Version     : 4.2.10
Release     : 6.el7_2
Architecture: noarch
Install Date: Sun 17 Apr 2016 08:51:38 BST
Group       : Applications/System
Size        : 449751
License     : GPLv3+ and LGPLv3+
Signature   : RSA/SHA256, Tue 12 Apr 2016 11:53:43 BST, Key ID 199e2f91fd431d51
Source RPM  : samba-4.2.10-6.el7_2.src.rpm
Build Date  : Tue 12 Apr 2016 09:32:32 BST
Build Host  : ppc-036.build.eng.bos.redhat.com
Relocations : (not relocatable)
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
Vendor      : Red Hat, Inc.
URL         : http://www.samba.org/
Summary     : Files used by both Samba servers and clients
Description :
samba-common provides files necessary for both the server and client
packages of Samba.
Name        : tdb-tools
Version     : 1.3.8
Release     : 1.el7_2
Architecture: x86_64
Install Date: Mon 16 May 2016 11:39:17 BST
Group       : Development/Libraries
Size        : 60085
License     : LGPLv3+
Signature   : RSA/SHA256, Fri 08 Apr 2016 18:03:59 BST, Key ID 199e2f91fd431d51
Source RPM  : libtdb-1.3.8-1.el7_2.src.rpm
Build Date  : Fri 01 Apr 2016 12:12:26 BST
Build Host  : x86-017.build.eng.bos.redhat.com
Relocations : (not relocatable)
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
Vendor      : Red Hat, Inc.
URL         : http://tdb.samba.org/
Summary     : Developer tools for the Tdb library
Description :
Tools to manage Tdb files
Name        : libtalloc
Version     : 2.1.5
Release     : 1.el7_2
Architecture: x86_64
Install Date: Sun 17 Apr 2016 08:51:28 BST
Group       : System Environment/Daemons
Size        : 69704
License     : LGPLv3+
Signature   : RSA/SHA256, Fri 08 Apr 2016 17:45:08 BST, Key ID 199e2f91fd431d51
Source RPM  : libtalloc-2.1.5-1.el7_2.src.rpm
Build Date  : Fri 01 Apr 2016 11:22:27 BST
Build Host  : x86-020.build.eng.bos.redhat.com
Relocations : (not relocatable)
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
Vendor      : Red Hat, Inc.
URL         : http://talloc.samba.org/
Summary     : The talloc library
Description :
A library that implements a hierarchical allocator with destructors.
Name        : libtdb
Version     : 1.3.8
Release     : 1.el7_2
Architecture: x86_64
Install Date: Sun 17 Apr 2016 08:51:29 BST
Group       : System Environment/Daemons
Size        : 91464
License     : LGPLv3+
Signature   : RSA/SHA256, Fri 08 Apr 2016 17:49:17 BST, Key ID 199e2f91fd431d51
Source RPM  : libtdb-1.3.8-1.el7_2.src.rpm
Build Date  : Fri 01 Apr 2016 12:12:26 BST
Build Host  : x86-017.build.eng.bos.redhat.com
Relocations : (not relocatable)
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
Vendor      : Red Hat, Inc.
URL         : http://tdb.samba.org/
Summary     : The tdb library
Description :
A library that implements a trivial database.
Name        : libldb
Version     : 1.1.25
Release     : 1.el7_2
Architecture: x86_64
Install Date: Sun 17 Apr 2016 08:51:30 BST
Group       : Development/Libraries
Size        : 345400
License     : LGPLv3+
Signature   : RSA/SHA256, Fri 08 Apr 2016 17:46:43 BST, Key ID 199e2f91fd431d51
Source RPM  : libldb-1.1.25-1.el7_2.src.rpm
Build Date  : Fri 01 Apr 2016 16:26:21 BST
Build Host  : x86-020.build.eng.bos.redhat.com
Relocations : (not relocatable)
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
Vendor      : Red Hat, Inc.
URL         : http://ldb.samba.org/
Summary     : A schema-less, ldap like, API and database
Description :
An extensible library that implements an LDAP like API to access remote LDAP
servers, or use local tdb databases.
Name        : pytalloc
Version     : 2.1.5
Release     : 1.el7_2
Architecture: x86_64
Install Date: Sun 17 Apr 2016 08:51:38 BST
Group       : Development/Libraries
Size        : 23064
License     : LGPLv3+
Signature   : RSA/SHA256, Fri 08 Apr 2016 17:45:07 BST, Key ID 199e2f91fd431d51
Source RPM  : libtalloc-2.1.5-1.el7_2.src.rpm
Build Date  : Fri 01 Apr 2016 11:22:27 BST
Build Host  : x86-020.build.eng.bos.redhat.com
Relocations : (not relocatable)
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
Vendor      : Red Hat, Inc.
URL         : http://talloc.samba.org/
Summary     : Developer tools for the Talloc library
Description :
Pytalloc libraries for creating python bindings using talloc
Name        : libwbclient
Epoch       : 0
Version     : 4.2.10
Release     : 6.el7_2
Architecture: x86_64
Install Date: Sun 17 Apr 2016 08:51:38 BST
Group       : Applications/System
Size        : 72632
License     : GPLv3+ and LGPLv3+
Signature   : RSA/SHA256, Tue 12 Apr 2016 11:51:19 BST, Key ID 199e2f91fd431d51
Source RPM  : samba-4.2.10-6.el7_2.src.rpm
Build Date  : Tue 12 Apr 2016 09:25:00 BST
Build Host  : x86-030.build.eng.bos.redhat.com
Relocations : (not relocatable)
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
Vendor      : Red Hat, Inc.
URL         : http://www.samba.org/
Summary     : The winbind client library
Description :
The libwbclient package contains the winbind client library from the Samba suite.
Name        : libverto-tevent
Version     : 0.2.5
Release     : 4.el7
Architecture: x86_64
Install Date: Tue 22 Mar 2016 10:38:03 GMT
Group       : Unspecified
Size        : 11520
License     : MIT
Signature   : RSA/SHA256, Wed 02 Apr 2014 15:59:47 BST, Key ID 199e2f91fd431d51
Source RPM  : libverto-0.2.5-4.el7.src.rpm
Build Date  : Sun 26 Jan 2014 14:03:04 GMT
Build Host  : x86-019.build.eng.bos.redhat.com
Relocations : (not relocatable)
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
Vendor      : Red Hat, Inc.
URL         : https://fedorahosted.org/libverto/
Summary     : tevent module for libverto
Description :
Module for libverto which provides integration with tevent.

This package provides libverto-module-base since it supports io, timeout
and signal.
Name        : samba-winbind
Epoch       : 0
Version     : 4.2.10
Release     : 6.el7_2
Architecture: x86_64
Install Date: Tue 10 May 2016 21:14:54 BST
Group       : Applications/System
Size        : 1457724
License     : GPLv3+ and LGPLv3+
Signature   : RSA/SHA256, Tue 12 Apr 2016 11:51:14 BST, Key ID 199e2f91fd431d51
Source RPM  : samba-4.2.10-6.el7_2.src.rpm
Build Date  : Tue 12 Apr 2016 09:25:00 BST
Build Host  : x86-030.build.eng.bos.redhat.com
Relocations : (not relocatable)
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
Vendor      : Red Hat, Inc.
URL         : http://www.samba.org/
Summary     : Samba winbind
Description :
The samba-winbind package provides the winbind NSS library, and some
client tools.  Winbind enables Linux to be a full member in Windows
domains and to use Windows user and group accounts on Linux.
Name        : samba-libs
Epoch       : 0
Version     : 4.2.10
Release     : 6.el7_2
Architecture: x86_64
Install Date: Sun 17 Apr 2016 08:51:38 BST
Group       : Applications/System
Size        : 739344
License     : GPLv3+ and LGPLv3+
Signature   : RSA/SHA256, Tue 12 Apr 2016 11:51:16 BST, Key ID 199e2f91fd431d51
Source RPM  : samba-4.2.10-6.el7_2.src.rpm
Build Date  : Tue 12 Apr 2016 09:25:00 BST
Build Host  : x86-030.build.eng.bos.redhat.com
Relocations : (not relocatable)
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
Vendor      : Red Hat, Inc.
URL         : http://www.samba.org/
Summary     : Samba libraries
Description :
The samba4-libs package contains the libraries needed by programs that
link against the SMB, RPC and other protocols provided by the Samba suite.
Name        : samba-client-libs
Epoch       : 0
Version     : 4.2.10
Release     : 6.el7_2
Architecture: x86_64
Install Date: Sun 17 Apr 2016 08:51:39 BST
Group       : Applications/System
Size        : 17528472
License     : GPLv3+ and LGPLv3+
Signature   : RSA/SHA256, Tue 12 Apr 2016 11:51:16 BST, Key ID 199e2f91fd431d51
Source RPM  : samba-4.2.10-6.el7_2.src.rpm
Build Date  : Tue 12 Apr 2016 09:25:00 BST
Build Host  : x86-030.build.eng.bos.redhat.com
Relocations : (not relocatable)
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
Vendor      : Red Hat, Inc.
URL         : http://www.samba.org/
Summary     : Samba client libraries
Description :
The samba-client-libs package contains internal libraries needed by the
SMB/CIFS clients.
Name        : samba
Epoch       : 0
Version     : 4.2.10
Release     : 6.el7_2
Architecture: x86_64
Install Date: Tue 10 May 2016 21:19:34 BST
Group       : System Environment/Daemons
Size        : 1895802
License     : GPLv3+ and LGPLv3+
Signature   : RSA/SHA256, Tue 12 Apr 2016 11:51:09 BST, Key ID 199e2f91fd431d51
Source RPM  : samba-4.2.10-6.el7_2.src.rpm
Build Date  : Tue 12 Apr 2016 09:25:00 BST
Build Host  : x86-030.build.eng.bos.redhat.com
Relocations : (not relocatable)
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
Vendor      : Red Hat, Inc.
URL         : http://www.samba.org/
Summary     : Server and Client software to interoperate with Windows machines
Description :
Samba is the standard Windows interoperability suite of programs for Linux and Unix.
Name        : samba-common-tools
Epoch       : 0
Version     : 4.2.10
Release     : 6.el7_2
Architecture: x86_64
Install Date: Sun 17 Apr 2016 08:51:38 BST
Group       : Applications/System
Size        : 1147010
License     : GPLv3+ and LGPLv3+
Signature   : RSA/SHA256, Tue 12 Apr 2016 11:51:17 BST, Key ID 199e2f91fd431d51
Source RPM  : samba-4.2.10-6.el7_2.src.rpm
Build Date  : Tue 12 Apr 2016 09:25:00 BST
Build Host  : x86-030.build.eng.bos.redhat.com
Relocations : (not relocatable)
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
Vendor      : Red Hat, Inc.
URL         : http://www.samba.org/
Summary     : Tools for Samba servers and clients
Description :
The samba-common-tools package contains tools for Samba servers and
SMB/CIFS clients.
Name        : samba-winbind-clients
Epoch       : 0
Version     : 4.2.10
Release     : 6.el7_2
Architecture: x86_64
Install Date: Mon 16 May 2016 11:27:51 BST
Group       : Applications/System
Size        : 130679
License     : GPLv3+ and LGPLv3+
Signature   : RSA/SHA256, Tue 12 Apr 2016 11:51:20 BST, Key ID 199e2f91fd431d51
Source RPM  : samba-4.2.10-6.el7_2.src.rpm
Build Date  : Tue 12 Apr 2016 09:25:00 BST
Build Host  : x86-030.build.eng.bos.redhat.com
Relocations : (not relocatable)
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
Vendor      : Red Hat, Inc.
URL         : http://www.samba.org/
Summary     : Samba winbind clients
Description :
The samba-winbind-clients package provides the wbinfo and ntlm_auth
tool.
Name        : libtevent
Version     : 0.9.26
Release     : 1.el7_2
Architecture: x86_64
Install Date: Sun 17 Apr 2016 08:51:29 BST
Group       : System Environment/Daemons
Size        : 62280
License     : LGPLv3+
Signature   : RSA/SHA256, Fri 08 Apr 2016 17:47:52 BST, Key ID 199e2f91fd431d51
Source RPM  : libtevent-0.9.26-1.el7_2.src.rpm
Build Date  : Fri 01 Apr 2016 13:24:55 BST
Build Host  : x86-030.build.eng.bos.redhat.com
Relocations : (not relocatable)
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
Vendor      : Red Hat, Inc.
URL         : http://tevent.samba.org/
Summary     : The tevent library
Description :
Tevent is an event system based on the talloc memory management library.
Tevent has support for many event types, including timers, signals, and
the classic file descriptor events.
Tevent also provide helpers to deal with asynchronous code providing the
tevent_req (Tevent Request) functions.
Name        : libsmbclient
Epoch       : 0
Version     : 4.2.10
Release     : 6.el7_2
Architecture: x86_64
Install Date: Sun 17 Apr 2016 08:51:39 BST
Group       : Applications/System
Size        : 151656
License     : GPLv3+ and LGPLv3+
Signature   : RSA/SHA256, Tue 12 Apr 2016 11:51:19 BST, Key ID 199e2f91fd431d51
Source RPM  : samba-4.2.10-6.el7_2.src.rpm
Build Date  : Tue 12 Apr 2016 09:25:00 BST
Build Host  : x86-030.build.eng.bos.redhat.com
Relocations : (not relocatable)
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
Vendor      : Red Hat, Inc.
URL         : http://www.samba.org/
Summary     : The SMB client library
Description :
The libsmbclient contains the SMB client library from the Samba suite.
Name        : samba-winbind-modules
Epoch       : 0
Version     : 4.2.10
Release     : 6.el7_2
Architecture: x86_64
Install Date: Tue 10 May 2016 21:14:54 BST
Group       : Applications/System
Size        : 84781
License     : GPLv3+ and LGPLv3+
Signature   : RSA/SHA256, Tue 12 Apr 2016 11:51:18 BST, Key ID 199e2f91fd431d51
Source RPM  : samba-4.2.10-6.el7_2.src.rpm
Build Date  : Tue 12 Apr 2016 09:25:00 BST
Build Host  : x86-030.build.eng.bos.redhat.com
Relocations : (not relocatable)
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
Vendor      : Red Hat, Inc.
URL         : http://www.samba.org/
Summary     : Samba winbind modules
Description :
The samba-winbind-modules package provides the NSS library and a PAM
module necessary to communicate to the Winbind Daemon
Comment 16 David Bell 2016-05-19 15:47:38 UTC
In my comment above I stated that NTLMSSP authentication from clients still works with Samba 3.6 when winbind is not running (contrary to what I thought my earlier testing had shown). 

However on Samba 4.2 on RHEL7 NTLMSSP authentication continues to not function when winbind is not running. As you've said above this is expected behaviour in modern Samba.

There are thus lots of different scenarios and issues going on here, so I want to summarise them:

- RHEL6 + Samba 3.6 (latest patches from Red Hat):

1) Without winbind: Kerberos auth works, NTLMSSP auth works, NIS group access control works, NIS group checking on directories works. (but only if client ipc signing = auto is added).

2) With winbind: Kerberos auth works, NTLMSSP auth works, NIS group access control doesn't work, NIS group checking in directories works via smbclient but not via Windows clients (again, client ipc signing = auto is required)

- RHEL7 + Samba 4.2 (Latest patches from Red Hat):

3) Without winbind: Kerberos auth works, NTLMSSP auth does not work. NIS group access control works, NIS group checking on directories works. "client ipc signing" is left at the default (mandatory).

4) With winbind: Kerberos auth works, NTLMSSP auth works, NIS group access control doesn't work, NIS group checking doesn't work via smbclient or Windows clients (client ipc signing is left at the default (mandatory).
Comment 17 Alexander Bokovoy 2016-05-19 16:37:10 UTC
(In reply to David Bell from comment #16)
> In my comment above I stated that NTLMSSP authentication from clients still
> works with Samba 3.6 when winbind is not running (contrary to what I thought
> my earlier testing had shown). 
> 
> However on Samba 4.2 on RHEL7 NTLMSSP authentication continues to not
> function when winbind is not running. As you've said above this is expected
> behaviour in modern Samba.
I need to look at the tests in detail but no, Samba 4.2 on RHEL7 case is expected 
right now because bugfixes you have in Samba 3.6 are not yet released for RHEL 7.2.
So it is not a behavior to expect, it is regression from Badlock fixes which was
fixed recently for 3.6.23-35.el6. This is NTLMSSP auth related.

However, the rest stays -- we expect winbindd to be running in domain member case
and we expect to fail if it is not running in domain member configuration in some
corner cases simply because those cases aren't covered by the fallback code.

> There are thus lots of different scenarios and issues going on here, so I
> want to summarise them:
> 
> - RHEL6 + Samba 3.6 (latest patches from Red Hat):
> 
> 1) Without winbind: Kerberos auth works, NTLMSSP auth works, NIS group
> access control works, NIS group checking on directories works. (but only if
> client ipc signing = auto is added).
> 
> 2) With winbind: Kerberos auth works, NTLMSSP auth works, NIS group access
> control doesn't work, NIS group checking in directories works via smbclient
> but not via Windows clients (again, client ipc signing = auto is required)
> 
> - RHEL7 + Samba 4.2 (Latest patches from Red Hat):
> 
> 3) Without winbind: Kerberos auth works, NTLMSSP auth does not work. NIS
> group access control works, NIS group checking on directories works. "client
> ipc signing" is left at the default (mandatory).
> 
> 4) With winbind: Kerberos auth works, NTLMSSP auth works, NIS group access
> control doesn't work, NIS group checking doesn't work via smbclient or
> Windows clients (client ipc signing is left at the default (mandatory).
From the summary above if we ignore NTLMSSP auth failures your claim is effectively
that winbindd and non-winbindd handling of NIS groups in 'valid users' is different.
You want it to be the same. Is this a correct summary?

client ipc signing issue against your Windows Server 2012 configuration
worth a separate investigation.
Comment 18 David Bell 2016-05-20 07:54:29 UTC
(In reply to Alexander Bokovoy from comment #17)

> From the summary above if we ignore NTLMSSP auth failures your claim is 
> effectively that winbindd and non-winbindd handling of NIS groups in 'valid
> users' is different. You want it to be the same. Is this a correct summary?

Our claim is that winbind and non-winbind handling of NIS groups in 'valid users' is different, but also that handling of in-share access control is different between winbind and non-winbind. When winbind is running on RHEL6 access control on directories breaks from Windows and on RHEL6 access control on directories breaks from smbclient and Windows.

> client ipc signing issue against your Windows Server 2012 configuration worth a separate investigation.

Indeed, Thorsten is working on that through my ticket with RH support :)
Comment 19 David Bell 2016-05-20 08:04:29 UTC
Sorry, I meant RHEL7 in my comment. Here is my corrected comment:

"Our claim is that winbind and non-winbind handling of NIS groups in 'valid users' is different, but also that handling of in-share access control is different between winbind and non-winbind. When winbind is running on RHEL6 access control on directories breaks from Windows and on RHEL7 access control on directories breaks from smbclient and Windows."
Comment 20 David Bell 2016-05-25 10:36:09 UTC
> An obvious solution would be to have these NIS groups duplicated in AD. 

We cannot do this because AD doesn't allow group names to be the same as user names, and we have hundreds of clashes between usernames and group names (in addition is normal to have user private groups on Unix, but of course, not on Windows...). Most of our group access is via our department groups which is in the form of a two-digit departmental code such as 'cz' or 'jf' or 'ea' - sadly many user names clash with these. This doesn't matter in NIS, but of course it matters in AD.

We would thus like to extend idmap_nss in the samba source. We are thinking of sending a patch to Samba either with a new idmap_nss_lmap (Legacy map?) module or a patch to idmap_nss. In this function:

static NTSTATUS idmap_nss_unixids_to_sids(struct idmap_domain *dom, struct id_map **ids)

The logic of the function seems to be:

1. If it is a UID, look up the entry via getpwuid to get the name
2. If it is a GID, look up the entry via getgrgid to get the name
3. Look up the name via winbind_lookup_name in Active Directory

If it can't find the matching name (in this case, a group) then it fails in this code:

>		if (!ret) {
>			ids[i]->status = ID_UNMAPPED;
>			continue;
>		}

What we propose is that in this scenario it should return a 'legacy' SID, of the form: S-1-22-2-<gid> or S-1-22-1-<uid>. Samba does this when winbind is not running, so all we have to do is modify the idmap backend to do this within winbind as well.

Alternatively we could write a new module such like "idmap_legacy" which always generates these SIDs based on the S-1-22 SID prefix. 

Can you advise why Samba calls these 'legacy' and if this for some reason is a bad idea? (Its how Samba has worked for us for a long time).

We're working on creating our own module now using the Red Hat samba source package, and if it works for us we'll send it as a patch to samba upstream.
Comment 21 David Bell 2016-06-01 12:12:30 UTC
We have continued working on the problem:

Our custom idmap backend made no difference as Samba seems to not check the members of UNIX groups at all or check what UNIX Groups a user is in when winbind is running.

To test this theory we created the 'srvadm' group in Active Directory and set 'valid users' to be '+srvadm'. The 'srvadm' group also exists in NIS. Samba only grants access if the user is in the 'srvadm' group in AD, it doesn't care what the unix group members are. In fact, the unix group doesn't even have to exist and Samba still grants access as long as the AD group exists and the user is in the AD group.

We are thus certain that 'valid users' when winbind is running does not check UNIX groups (even if it can map between SIDs and GIDs). The man page (and even the Samba source code which repeats the assertion that +group means Unix groups) is wrong. When winbind is running +groups in 'valid users' have to be AD groups and the AD groups must have members in them. This is in contrast to the behaviour without winbind where +groups are UNIX groups and members must be in the unix groups.

Once the share access control hurdle is passed (i.e. using AD groups rather than POSIX groups) then Linux underneath does of course still enforce access control based on UNIX groups. So the groups also have to exist in NIS and have the same members as the groups in AD. And...we need to configure idmap to let Samba map between them - idmap_nss then /does/ work. Without idmap_nss access control still fails.

To be clear there appears to be three access control checking steps:

1. Samba share level access control - Samba consults AD groups exclusively. The groups must exist in AD. The user accessing the share must be in the group in AD. You don't need a idmap config for this to work or RFC2307 extension attributes in AD.

2. Samba file level access control via groups - Samba seems to check access to files and directories. For this to work Samba checks the permissions on the file system and must be able to map the group from the GID, say '5000' in this case, to a SID in AD, and then consults the members of the group in /AD/ not in UNIX, even though the group is on disk on UNIX. For this to work you need to configure 'idmap', e.g. idmap_nss works. (I guess this checking exists to allow ACL checking to work with xattr storage).

3. Linux file level access control via groups - smbd eventually switches to run as the user connecting, at which point the user must be in the group configured in UNIX too (of course!).

Without winbind we can rely on access control with UNIX groups. With winbind running we need to use AD groups which are populated with members and also have UNIX groups populated with the same members and use idmap_nss to allow Samba to map GIDs to SIDs and vice versa.

To conclude: UNIX groups do not work in 'valid users' even though the documentation says they do (and the source code says that too in 4.4.3!). Further, unix groups are not consulted for Samba file level access control checking either, it just attempts to map them to AD groups.

We suggest that this behaviour is incorrect, and that there is no reason why Samba can't map SIDs to GIDs (using idmap_nss or just using 'legacy' SIDs) -and- rely entirely on UNIX groups for access control. It works in this way with UNIX netgroups in 'valid users', but not for groups. Jeremy said above that modern Samba needs SIDs to build ACEs, but Samba needs more than that - it relies entirely on AD and doesn't check unix group membership at all. It would seem when winbind is running Samba is written with the assumption that the systems administrator can use nss_winbind and pam_winbind. We cannot.
Comment 22 Jeremy Allison 2016-06-01 18:19:26 UTC
(In reply to David Bell from comment #21)

> To test this theory we created the 'srvadm' group in Active Directory and set
> 'valid users' to be '+srvadm'. The 'srvadm' group also exists in NIS. Samba
> only grants access if the user is in the 'srvadm' group in AD, it doesn't care
> what the unix group members are. In fact, the unix group doesn't even have to
> exist and Samba still grants access as long as the AD group exists and the user
> is in the AD group.

Hang on a minute. You're expecting winbind to collate members of groups with the same name from different sources ? That's just not what winbind does. That will never work.

winbindd talks to AD-DC's. If you want to use a unix group, set up group mapping locally and make sure it isn't the same name as an AD group.
Comment 23 David Bell 2016-06-01 19:22:50 UTC
> Hang on a minute. You're expecting winbind to collate members of groups with the same name from different sources ? That's just not what winbind does. That will never work.

No, I'm not expecting that - Alexander suggested it might work in the thread above, not I!

I would like Samba/smbd to get members of groups from UNIX, as it has done for us and many other users for the past decade or more. I don't want to use AD sources at all, but it seems Samba's behaviour has changed and it seems its now written to demand that we run winbind and demand that we use AD groups. We can't do these things, thus Samba will in future be useless to us - and I suspect a large number of users!

I would like samba to have a "winbind mode = [default|netlogon]" mode. This mode shoudl exist as per the documentation [from the man page]:

> Even  if  winbind is not used for nsswitch, it still provides a service
> to smbd, ntlm_auth and the pam_winbind.so PAM module, by managing  con-
> nections to domain controllers. In this configuraiton the idmap uid and
> idmap gid parameters are not required.  (This  is  known  as  `netlogon
> proxy only mode'.)

But it seems this feature doesn't actually work/exist. The man page and source code for Samba says that +group is for UNIX groups, but as you now admit, this is also not the case, its actually for AD groups.

> winbindd talks to AD-DC's. If you want to use a unix group, set up group mapping locally and make sure it isn't the same name as an AD group. 

Putting aside the fact that the docs/source don't reflect this, group mapping doesn't work as I've said above in other updates. I don't understand how group mapping could possibly help us. You suggest mapping UNIX groups to other AD groups whose name don't match, huh?!

I do not believe we (The University of Southampton, UK) are being unreasonable in this request. If we can't resolve this then I guess we'll simply stop using Samba because it no longer provides what we perceive to be standard functionality.
Comment 24 Jeremy Allison 2016-06-01 19:32:23 UTC
(In reply to David Bell from comment #23)

> I would like Samba/smbd to get members of groups from UNIX, as it has done for
> us and many other users for the past decade or more. I don't want to use AD
> sources at all

That's not what your original complaint in the bug report is. I quote:

> Samba version: samba 4.2.10-6.el7_2 (Samba 4.2 on RHEL7 server 64-bit)
> Security: 'ads'

If you don't want to use AD sources at all, set the conf:

security = user

don't run winbind, and have a local user database.

smbd will then use the nsswitch calls to get groups.

I would like to know *exactly* what behavior you need to understand your issue. Don't set "security = ads" and then claim 'I don't want to use AD sources at all'. That's inherently contradictory and makes no sense.
Comment 25 David Bell 2016-06-01 20:51:12 UTC
> I would like to know *exactly* what behavior you need to understand your issue. > Don't set "security = ads" and then claim 'I don't want to use AD sources at
> all'. That's inherently contradictory and makes no sense.

We want to use AD for authentication but not authorisation. We want to provide file services to users on Active Directory. We can do this with Isilon and "lwiod" (as much as we wish they still used Samba!), and with other SMB server implementations we have (such as NetApp). I'd love it if Samba could still do this too.

I already asked about security = user above, but Alexander said you should only do that if you're running as a PDC. This would prevent us from using Kerberos authentication and from using Active Directory as the netlogon server. security = user does work - I've tested it - but it requires that I have LM hashed passwords for my 35,000 users on every Samba server, or...in LDAP somewhere else (e.g. an OpenLDAP server) but that has its own set of problems (how do I make it so only Samba should have access to those passwords?).

I believe Samba should be able to function in the away since it does so when winbind is not running...
Comment 26 David Bell 2016-06-01 20:59:01 UTC
Just so you can understand why we want authentication only for AD (and not authorisation), we can't use AD for authorisation because:

1) We don't have RFC2307 extensions in our AD, and adding them breaks third-party sync to Office 365. So we have to maintain our unix data elsewhere, currently NIS but we want to move to something else - probably Red Hat IDM. Also, Microsoft has now killed the IMU/SFU product line, and although you can still add the attributes in, theres no support for clients consuming them and no GUI to edit them. As such Red Hat recommends not storing unix data in AD anymore. 

2) We already have hundreds upon hundreds of servers and hundreds of terrabytes of file storage systems (Isilon, NetApp, Linux systems, Solaris systems) storing UIDs and GIDs from our NIS. We can't move to idmap_rid or similar because the UIDs and GIDs must match the existing ones, but we can't place them in AD either...see above.

3) We can't place our UNIX groups into AD anyway because AD can't have users and group names clashing, except they do clash in hundreds of places in our existing NIS infrastructure since we've had since the early 1990s.
Comment 27 Jeremy Allison 2016-06-01 21:04:40 UTC
The whole point of using AD for authentication is you end up with the kerberos PAC returned in the tickets from AD. This contains the SID list that represents the user.

So what you're telling me is you want to then completely replace that token provided by the kdc with something completely locally generated ? You realize that this is a very unusual request I hope.

The only way I can think this might work is if you set up a 'username map' file (see the smb.conf man page for the description).

Also take a look at this page for a config description that might do what you need:

https://serverfault.com/questions/659017/possible-to-authenticate-samba-via-kerberos-but-without-domain-join
Comment 28 Jeremy Allison 2016-06-01 21:54:54 UTC
Yeah, what it sounds like is you really need a minimally joined system to get the kerberos keytab set up, and then don't run winbind at all in order to force it to use your 'local' nsswitch provided user and group databases.
Comment 29 Jeremy Allison 2016-06-01 21:57:33 UTC
I have a soft spot for UK Universities (I'm a University of Sheffield Alumni myself) so I'll try and help you get this set up so it's working for you.
Comment 30 David Bell 2016-06-01 22:13:07 UTC
Red Hat support already got us to try username map, but it made no difference whatsoever, Samba behaves in exactly the same way with or without it :(
Comment 31 Jeremy Allison 2016-06-01 22:29:05 UTC
Did you try username map without winbind running ? You're going to need to disable winbind to make this work the way you want.
Comment 32 David Bell 2016-06-01 22:32:48 UTC
(In reply to Jeremy Allison from comment #28)

> Yeah, what it sounds like is you really need a minimally joined system to get 
> the kerberos keytab set up, and then don't run winbind at all in order to force
> it to use your 'local' nsswitch provided user and group databases.

So this is what we've done for years and years (net ads join and no winbind running), but the BadLock fixes mean that we can no longer run without winbind, Red Hat say we have to run with winbind on, and I'm told the code paths are 'fragile' without winbind running?
Comment 33 David Bell 2016-06-01 22:33:41 UTC
(In reply to Jeremy Allison from comment #31)

> Did you try username map without winbind running ? 

No, because it all works fine when winbind is not running and we don't even need username map then :D
Comment 34 Jeremy Allison 2016-06-01 22:42:42 UTC
When using krb5 auth you don't need winbind - smbd will validate the incoming ticket. The badlock fixes are to the dce-rpc stack. They don't mandate winbind.

What *exactly* about your previous setup stops working after the upgrade if you simply don't run winbind ?
Comment 35 David Bell 2016-06-01 22:52:32 UTC
(In reply to Jeremy Allison from comment #34)

Ah, sorry, yes, forgot to say about that. We use Kerberos auth for domain bound windows clients, but these days we have hundreds upon hundreds of non-domain bound Mac OS X and Red Hat Enterprise Linux desktops, and many, many more students and staff using their own equipment. In this scenario Kerberos of course doesn't work - none of them are domain bound.

The BadLock fixes broke our ability to do NTLMSSP. Kerberos auth continues to function without issue. We need to support both methods. Red Hat say we can't without running winbind:

> One particular difference brought in by Samba 'Badlock' security release
> compared to older Samba 3.6 versions, is that in case of 'security = domain'
> or 'security = ads' running winbindd is now a requirement. A hybrid
> configuration in which SSSD is used to provide users and groups while Samba is
> supporting access to file shares is currently only possible with Kerberos
> authentication.

> For domain member configurations, Samba has to talk to domain controllers in
> order to authenticate with anything, but Kerberos. This work is done by
> winbindd. The reason for this is that chain authentication requires use of a
> secure channel (schannel) between domain member and domain controller. The
> secure channel has the unfortunate property of enforcing a single connection,
> e.g. only a single process can perform schannel operations using domain member
> credentials. If winbindd is not running, Samba still tries to talk to Domain 
> Controller to perform authentication but this path is currently not possible
> due to security improvements of Samba 'Badlock' security release.

> 'Badlock' security release closes down many fundamental issues Samba code had
> in using DCE RPC connections between domain member and domain controllers.
> Part of the solution was to unify the conditions where these operations
> happen, and move the logic to winbindd.

What is odd is that Red Hat have since patched Samba 3.6 (on RHEL6) such that it now works again (i.e. you can run without winbind and NTLMSSP works), but their Samba 4.2 packages are still not working (i.e. you must run winbind), and Red Hat insist that we are not supported if we don't run winbind...
Comment 36 David Bell 2016-06-01 22:56:42 UTC
(In reply to Jeremy Allison from comment #34)

By the way, many thanks for working on this issue. I realise you do not need to do so and we very much appreciate it.
Comment 37 Jeremy Allison 2016-06-01 23:11:24 UTC
Ah, I get the issue. To do ntlm auth to a remote DC requires schannel. Schannel will only allow *one* concurrent connection between member server and DC (shared state on the remote DC) so it makes sense to consolidate that into winbind and have all the smbd's ask winbind to make that request for them.
Comment 38 Jeremy Allison 2016-06-01 23:31:59 UTC
Ok, as far as I can see the code for forcing a direct smbd->AD-DC ntlm auth is still there in v4.2, just not enabled by default. To enable it, set:

auth methods = guest sam ntdomain

which will bypass the winbind calls. Normally for a domain member the internal auth methods list is set to:

"guest sam winbind:ntdomain"

The above smb.conf global parameter will override this.

To see the relevent code look inside:

source3/auth/auth.c:make_auth_context_subsystem()

WARNING, I have not tested this and it's almost certainly going outside your Red Hat support advice.

Try at your own risk :-).
Comment 39 Volker Lendecke 2016-06-02 06:44:25 UTC
Just a quick addition to this firehose of comments: I've seen more than
one case now where a mode to completely ignore AD group memberships and become 
Samba 2.2 again in terms of just looking at nsswitch is very desirable to
people. It's not only universities. Many organizations just don't have proper
mappings for the Windows primary group and need to work around that.

One area that we need to watch out for here is a proper id mapping. The main
difference here is the user-space acl checks we do for a while now. We need to
*just* use the S-1-22 style SIDs everywhere, because we read the nt style acl
from disk and do se_access_check against that. In the distant past, we did not
do that except for set delete on close.

So count me in for review and/or doing patches :-)
Comment 40 Alexander Bokovoy 2016-06-02 08:10:10 UTC
(In reply to Volker Lendecke from comment #39)
> Just a quick addition to this firehose of comments: I've seen more than
> one case now where a mode to completely ignore AD group memberships and
> become 
> Samba 2.2 again in terms of just looking at nsswitch is very desirable to
> people. It's not only universities. Many organizations just don't have proper
> mappings for the Windows primary group and need to work around that.
> 
> One area that we need to watch out for here is a proper id mapping. The main
> difference here is the user-space acl checks we do for a while now. We need
> to
> *just* use the S-1-22 style SIDs everywhere, because we read the nt style acl
> from disk and do se_access_check against that. In the distant past, we did
> not
> do that except for set delete on close.
> 
> So count me in for review and/or doing patches :-)
:)
So the whole case "Ignore AD group membership from the MS-PAC and rely on the system-provided identities only" would be an enhancement request, right?
Comment 41 Volker Lendecke 2016-06-02 08:50:14 UTC
(In reply to Alexander Bokovoy from comment #40)
> So the whole case "Ignore AD group membership from the MS-PAC and rely on
> the system-provided identities only" would be an enhancement request, right?
From my point of view, yes.
Comment 42 David Bell 2016-06-02 09:12:51 UTC
(In reply to Jeremy Allison from comment #38)

Unfortunatley setting 'auth methods' does not work on Samba 4.2.10-6.el7_2.x86_64:

[2016/06/02 10:10:11.375626,  5, pid=2244, effective(0, 0), real(0, 0)] ../auth/gensec/gensec_start.c:672(gensec_start_mech)
  Starting GENSEC mechanism spnego
[2016/06/02 10:10:11.375700,  5, pid=2244, effective(0, 0), real(0, 0)] ../auth/gensec/gensec_start.c:672(gensec_start_mech)
  Starting GENSEC submechanism ntlmssp
[2016/06/02 10:10:11.375747,  1, pid=2244, effective(0, 0), real(0, 0)] ../librpc/ndr/ndr.c:402(ndr_print_debug)
       negotiate: struct NEGOTIATE_MESSAGE
          Signature                : 'NTLMSSP'
          MessageType              : NtLmNegotiate (1)
          NegotiateFlags           : 0x62088215 (1644724757)
                 1: NTLMSSP_NEGOTIATE_UNICODE
                 0: NTLMSSP_NEGOTIATE_OEM    
                 1: NTLMSSP_REQUEST_TARGET   
                 1: NTLMSSP_NEGOTIATE_SIGN   
                 0: NTLMSSP_NEGOTIATE_SEAL   
                 0: NTLMSSP_NEGOTIATE_DATAGRAM
                 0: NTLMSSP_NEGOTIATE_LM_KEY 
                 0: NTLMSSP_NEGOTIATE_NETWARE
                 1: NTLMSSP_NEGOTIATE_NTLM   
                 0: NTLMSSP_NEGOTIATE_NT_ONLY
                 0: NTLMSSP_ANONYMOUS        
                 0: NTLMSSP_NEGOTIATE_OEM_DOMAIN_SUPPLIED
                 0: NTLMSSP_NEGOTIATE_OEM_WORKSTATION_SUPPLIED
                 0: NTLMSSP_NEGOTIATE_THIS_IS_LOCAL_CALL
                 1: NTLMSSP_NEGOTIATE_ALWAYS_SIGN
                 0: NTLMSSP_TARGET_TYPE_DOMAIN
                 0: NTLMSSP_TARGET_TYPE_SERVER
                 0: NTLMSSP_TARGET_TYPE_SHARE
                 1: NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY
                 0: NTLMSSP_NEGOTIATE_IDENTIFY
                 0: NTLMSSP_REQUEST_NON_NT_SESSION_KEY
                 0: NTLMSSP_NEGOTIATE_TARGET_INFO
                 1: NTLMSSP_NEGOTIATE_VERSION
                 1: NTLMSSP_NEGOTIATE_128    
                 1: NTLMSSP_NEGOTIATE_KEY_EXCH
                 0: NTLMSSP_NEGOTIATE_56     
          DomainNameLen            : 0x0000 (0)
          DomainNameMaxLen         : 0x0000 (0)
          DomainName               : *
              DomainName               : ''
          WorkstationLen           : 0x0000 (0)
          WorkstationMaxLen        : 0x0000 (0)
          Workstation              : *
              Workstation              : ''
          Version: struct ntlmssp_VERSION
              ProductMajorVersion      : NTLMSSP_WINDOWS_MAJOR_VERSION_6 (6)
              ProductMinorVersion      : NTLMSSP_WINDOWS_MINOR_VERSION_1 (1)
              ProductBuild             : 0x0000 (0)
              Reserved: ARRAY(3)
                  [0]                      : 0x00 (0)
                  [1]                      : 0x00 (0)
                  [2]                      : 0x00 (0)
              NTLMRevisionCurrent      : NTLMSSP_REVISION_W2K3 (15)
[2016/06/02 10:10:11.377512,  3, pid=2244, effective(0, 0), real(0, 0)] ../auth/ntlmssp/ntlmssp_client.c:275(ntlmssp_client_challenge)
  Got challenge flags:
[2016/06/02 10:10:11.377557,  3, pid=2244, effective(0, 0), real(0, 0)] ../auth/ntlmssp/ntlmssp_util.c:69(debug_ntlmssp_flags)
  Got NTLMSSP neg_flags=0x62898215
    NTLMSSP_NEGOTIATE_UNICODE
    NTLMSSP_REQUEST_TARGET
    NTLMSSP_NEGOTIATE_SIGN
    NTLMSSP_NEGOTIATE_NTLM
    NTLMSSP_NEGOTIATE_ALWAYS_SIGN
    NTLMSSP_TARGET_TYPE_DOMAIN
    NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY
    NTLMSSP_NEGOTIATE_TARGET_INFO
    NTLMSSP_NEGOTIATE_VERSION
    NTLMSSP_NEGOTIATE_128
    NTLMSSP_NEGOTIATE_KEY_EXCH
[2016/06/02 10:10:11.377700,  3, pid=2244, effective(0, 0), real(0, 0)] ../auth/ntlmssp/ntlmssp_client.c:731(ntlmssp_client_challenge)
  NTLMSSP: Set final flags:
[2016/06/02 10:10:11.377726,  3, pid=2244, effective(0, 0), real(0, 0)] ../auth/ntlmssp/ntlmssp_util.c:69(debug_ntlmssp_flags)
  Got NTLMSSP neg_flags=0x62088a15
    NTLMSSP_NEGOTIATE_UNICODE
    NTLMSSP_REQUEST_TARGET
    NTLMSSP_NEGOTIATE_SIGN
    NTLMSSP_NEGOTIATE_NTLM
    NTLMSSP_ANONYMOUS
    NTLMSSP_NEGOTIATE_ALWAYS_SIGN
    NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY
    NTLMSSP_NEGOTIATE_VERSION
    NTLMSSP_NEGOTIATE_128
    NTLMSSP_NEGOTIATE_KEY_EXCH
[2016/06/02 10:10:11.378033,  3, pid=2244, effective(0, 0), real(0, 0)] ../auth/ntlmssp/ntlmssp_sign.c:509(ntlmssp_sign_reset)
  NTLMSSP Sign/Seal - Initialising with flags:
[2016/06/02 10:10:11.378052,  3, pid=2244, effective(0, 0), real(0, 0)] ../auth/ntlmssp/ntlmssp_util.c:69(debug_ntlmssp_flags)
  Got NTLMSSP neg_flags=0x62088a15
    NTLMSSP_NEGOTIATE_UNICODE
    NTLMSSP_REQUEST_TARGET
    NTLMSSP_NEGOTIATE_SIGN
    NTLMSSP_NEGOTIATE_NTLM
    NTLMSSP_ANONYMOUS
    NTLMSSP_NEGOTIATE_ALWAYS_SIGN
    NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY
    NTLMSSP_NEGOTIATE_VERSION
    NTLMSSP_NEGOTIATE_128
    NTLMSSP_NEGOTIATE_KEY_EXCH
[2016/06/02 10:10:11.381347,  3, pid=2244, effective(0, 0), real(0, 0)] ../source3/libsmb/cliconnect.c:2199(cli_session_setup_done_spnego)
  SPNEGO login failed: Logon failure
[2016/06/02 10:10:11.381534,  0, pid=2244, effective(0, 0), real(0, 0), class=auth] ../source3/auth/auth_domain.c:265(domain_client_validate)
  domain_client_validate: Domain password server not available.
[2016/06/02 10:10:11.381673,  5, pid=2244, effective(0, 0), real(0, 0), class=auth] ../source3/auth/auth.c:252(auth_check_ntlm_password)
  check_ntlm_password: ntdomain authentication for user [db2z07] FAILED with error NT_STATUS_LOGON_FAILURE
[2016/06/02 10:10:11.381695,  2, pid=2244, effective(0, 0), real(0, 0), class=auth] ../source3/auth/auth.c:315(auth_check_ntlm_password)
  check_ntlm_password:  Authentication for user [db2z07] -> [db2z07] FAILED with error NT_STATUS_LOGON_FAILURE
[2016/06/02 10:10:11.381709,  5, pid=2244, effective(0, 0), real(0, 0)] ../source3/auth/auth_ntlmssp.c:188(auth3_check_password)
  Checking NTLMSSP password for SOTON\db2z07 failed: NT_STATUS_LOGON_FAILURE
[2016/06/02 10:10:11.381724,  5, pid=2244, effective(0, 0), real(0, 0)] ../auth/ntlmssp/ntlmssp_server.c:731(ntlmssp_server_check_password)
  ../auth/ntlmssp/ntlmssp_server.c:731: Checking NTLMSSP password for SOTON\db2z07 failed: NT_STATUS_LOGON_FAILURE
[2016/06/02 10:10:11.381739,  2, pid=2244, effective(0, 0), real(0, 0)] ../auth/gensec/spnego.c:708(gensec_spnego_server_negTokenTarg)
  SPNEGO login failed: NT_STATUS_LOGON_FAILURE
Comment 43 Alexander Bokovoy 2016-06-02 14:59:01 UTC
There is an update coming which should make this path working in RHEL 7.2.z, please talk to Red Hat support line to get access to a test build. The update is currently on QE. This is one of bugfixes on top of Badlock fixes.
Comment 44 Jeremy Allison 2016-06-02 19:50:03 UTC
(In reply to Alexander Bokovoy from comment #43)

Alexander, what is the bug here preventing "auth methods = guest sam ntdomain" from working ? Unfortunately the log provided didn't show enough to discover what the problem is.

That code should still work in 4.2, if be unreliable due to the schannel issues.
Comment 45 Alexander Bokovoy 2016-06-02 20:51:37 UTC
(In reply to Jeremy Allison from comment #44)
> (In reply to Alexander Bokovoy from comment #43)
> 
> Alexander, what is the bug here preventing "auth methods = guest sam
> ntdomain" from working ? Unfortunately the log provided didn't show enough
> to discover what the problem is.
> 
> That code should still work in 4.2, if be unreliable due to the schannel
> issues.
There was a regression due to Badlock fixes -- https://bugzilla.samba.org/show_bug.cgi?id=11858 and https://bugzilla.samba.org/show_bug.cgi?id=11849. As I said, it is fixed upstream but RHEL 7 update is in QE process.
Comment 46 Alexander Bokovoy 2016-06-02 20:55:29 UTC
As for signs for that --
../source3/auth/auth_domain.c:265(domain_client_validate)
  domain_client_validate: Domain password server not available.
This means anonymous connection to IPC$ on the domain password server has failed in connect_to_domain_password_server().
Comment 47 Jeremy Allison 2016-06-02 21:00:53 UTC
Ah - understood Alexander - thanks. The code in the "ntdomain" auth module does:

        /* Attempt connection */
        result = cli_full_connection(&cli, lp_netbios_name(), dc_name, dc_ss, 0,
                "IPC$", "IPC", "", "", "", 0, SMB_SIGNING_IPC_DEFAULT);

Which then needs the change:

From be36cbcaf1f2e17301af73051ae7a1ab2dce84ea Mon Sep 17 00:00:00 2001
From: Stefan Metzmacher <metze@samba.org>
Date: Tue, 19 Apr 2016 07:31:50 +0200
Subject: [PATCH 09/30] s3:libsmb: use password = NULL for anonymous
 connections
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

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

Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
Reviewed-by: Günther Deschner <gd@samba.org>
(cherry picked from commit 53be47410236ef7c90fe895f49f300e3fe47a8bf)
---
 source3/libsmb/cliconnect.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/source3/libsmb/cliconnect.c b/source3/libsmb/cliconnect.c
index 039fba2..b518ab8 100644
--- a/source3/libsmb/cliconnect.c
+++ b/source3/libsmb/cliconnect.c
@@ -1343,6 +1343,17 @@ static struct tevent_req *cli_session_setup_gensec_send(
 	talloc_set_destructor(
 		state, cli_session_setup_gensec_state_destructor);
 
+	if (user == NULL || strlen(user) == 0) {
+		if (pass != NULL && strlen(pass) == 0) {
+			/*
+			 * some callers pass "" as no password
+			 *
+			 * gensec only handles NULL as no password.
+			 */
+			pass = NULL;
+		}
+	}

in order to work. David, the code in the Samba git repo for 4.2 should work, but if you want an official Red Hat build you'll have to wait for it to go through QA.
Comment 48 David Bell 2016-06-03 13:00:01 UTC
(In reply to Jeremy Allison from comment #47)

Many thanks guys, Red Hat supplied a QE package and it fixes the problem for us. We can run RHEL6+RHEL7 Samba packages without winbind without issue (well, when Red Hat QE is finished we can :D)

As regards the failure condition in NTLMSSP authentication without winbind:

> To do ntlm auth to a remote DC requires schannel. Schannel will only allow
> *one* concurrent connection between member server and DC (shared state on the
> remote DC) so it makes sense to consolidate that into winbind and have all the
> smbd's ask winbind to make that request for them.

Indeed, but it seems this is already dealt with in smbd without winbind. We've built some tests here to see if we can break NTLMSSP authentication with ~50 authentication requests per second, but we've been unable to do so. I've looked at the code, and if this is the right function, it seems that smbd already deals with the serialization requirement:

in source3/auth/auth_domain.c:

> static NTSTATUS connect_to_domain_password_server(struct cli_state **cli_ret,
> [...]
> 	/* we use a mutex to prevent two connections at once - when a 
>	   Win2k PDC get two connections where one hasn't completed a 
>	   session setup yet it will send a TCP reset to the first 
>	   connection (tridge) */
>
>	/*
>	 * With NT4.x DC's *all* authentication must be serialized to avoid
>	 * ACCESS_DENIED errors if 2 auths are done from the same machine. JRA.
>	 */
>
>	mutex = grab_named_mutex(NULL, dc_name, 10);
>	if (mutex == NULL) {
>		TALLOC_FREE(frame);
>		return NT_STATUS_NO_LOGON_SERVERS;
>	}

Further, the code for grab_named_mutex in source3/lib/server_mutex.c contains this comment:

> /* For reasons known only to MS, many of their NT/Win2k versions
>   need serialised access only.  Two connections at the same time
>   may (in certain situations) cause connections to be reset,
>   or access to be denied.

>   This locking allows smbd's multithread architecture to look
>   like the single-connection that NT makes. */

Does this code not suggest that each smbd will try for up to 10 seconds to get a named mutex before giving up and returning NT_STATUS_NO_LOGON_SERVERS? Is it not then a very rare scenario where there are many hundreds of smbd's all trying to authenticate to the NT password server and one eventually fails because it can't grab the mutex within 10 seconds?

My reading of the code is that the chance of a failure to authenticate under heavy load would be very low (we never have that many users connecting to a single Samba server - our heavy usage platforms are Isilon and NetApp). Its been years since I've programmed C properly though, and I don't pretend to understand the innards of Samba at all, so what are your thoughts on this?

Finally, would you be averse to me sending some patches/pull requests with changes to man smb.conf to document current Samba behaviour (e.g. when running winbind 'valid users' means AD groups...and to document why you'd want to run winbind and the potential for problems with multiple smbds and auth?)
Comment 49 Jeremy Allison 2016-06-03 15:42:26 UTC
Yeah I know about the mutex and serialization. I wrote that code :-).

There were some other issues though that the mutex didn't fix, but I can't remember off the top of my head what the problem was. Metze will, I'm sure :-).

I'm happy to accept patches for the smb.conf man page, and also it would really help to have a section in the wiki covering this if it's not too much trouble.

> "our heavy usage platforms are Isilon and NetApp"

Oh for shame :-). You're wasting University money there, plus NetApp's implementation is, how can I put this... not complete (see the list of Samba -> NetApp interop bugs where the problem is they don't fully implement the protocol).

Glad you're up and working though !

Jeremy.
Comment 50 David Bell 2016-06-03 15:52:29 UTC
(In reply to Jeremy Allison from comment #49)

Well, we're ditching the NetApps at least ;-) The Isilons are here to stay though. Part of the reason we originally bought them was that they ran Samba... now they don't. :(

You might be interested to know that the University of Sheffield is using Novell Netware SMB file servers (and some Windows Server too)... (I know this because they use a libsmbclient-backed python web interface I wrote for them - bargate.io - and they have had issues with libsmbclient talking to Netware 'SMB').

I'll go through the contribution stuff and send some patches for the man pages, and I'll register for the wiki!
Comment 51 Jeremy Allison 2016-06-07 22:24:55 UTC
Looks like this is fixed.