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.
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.
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.
Alternatively, is there a way to use 'security = user' and allow Kerberos authentication to provide single sign on for Windows desktop clients?
(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.
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.
(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?
(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.
> 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!).
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. :(
(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.
(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!).
David, can we see the logs you promised in the comment 8?
Also, please use the following instructions when generating logs: https://www.samba.org/~asn/reporting_samba_bugs.txt
(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.
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
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).
(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.
(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 :)
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."
> 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.
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.
(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.
> 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.
(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.
> 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...
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.
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
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.
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.
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 :(
Did you try username map without winbind running ? You're going to need to disable winbind to make this work the way you want.
(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?
(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
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 ?
(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...
(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.
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.
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 :-).
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 :-)
(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?
(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.
(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
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.
(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.
(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.
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().
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.
(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?)
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.
(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!
Looks like this is fixed.
Created attachment 14532 [details] samba configuration file
(In reply to Jeremy Allison from comment #51) This is still an issue with Samba version 4.7.1 on RHEL 7.5. We have a samba server which is a domain member using ADS authentication. After upgrading our domain controllers to Windows Server 2016R2 Samba is no longer able to enumerate local unix/ldap groups properly. Upon attempting to access a share which is set to allow access to a unix group samba shows a message like this in the log files. [2018/10/16 22:32:21.760267, 3] ../lib/util/access.c:361(allow_access) Allowed connection from 10.201.65.1 (10.201.65.1) [2018/10/16 22:32:21.760320, 3] ../libcli/security/dom_sid.c:210(dom_sid_parse_endp) string_to_sid: SID Mas_MDC is not in a valid format Mas_MDC is a group that exists on our OpenLDAP server however it does *not* exist in AD. Is there a way to force Samba to look at local/NIS user data first when winbind is running? To get around this I've updated our valid users entries to simply list all users in the group but I believe that is a hack and shouldn't be necessary in the first place. Attached is an example copy of the smb.conf file.