samba - Apr 2016 - Moving from samba-3.6.23-25.el6_7.x86_64 to samba-3.6.23-30.el6_7 has broken access to our MAC OS X clients

I've now tired both

client ipc signing = auto

or

client signing = required
server signing = auto
---

that did not work...Also tied winbindd and that was a disaster of a
different sort.

It wouldn't use the local unix groups first, which will cause way too
many issues.

All along, however, the PCs that connect (when not trying to use
winbindd) have consistently

been able to connect and use the proper groups to access the files on
the server.

This appears to just be a MAC OS X issue..  Any other thoughts?

Thanks

--Karen

This issue is not limited to just MAC OS X clients. I walked into the 
office the other morning (the morning after the update was released) and 
none of my MS Windows Terminal Servers could login to the domain (an 
Samba NT Domain).  None ( 0 out of 10 of 2003 and 2008 Servers). Nor 
could I issues the command: # net server domain -U <username> which is 
my normal sanity check on the Samba DC.

This update as released from the upstream provider (in my case I am a 
CentOS shop and the upstream is Redhat) included several security 
patches at once. On April 12 on the Release Announcements for the 
patches were

"These are Security Releases in order to address CVE-2015-5370 
<https://www.samba.org/samba/security/CVE-2015-5370.html>, CVE-2016-2110 
<https://www.samba.org/samba/security/CVE-2016-2110.html>, CVE-2016-2111 
<https://www.samba.org/samba/security/CVE-2016-2111.html>, CVE-2016-2112 
<https://www.samba.org/samba/security/CVE-2016-2112.html>, CVE-2016-2113 
<https://www.samba.org/samba/security/CVE-2016-2113.html>, CVE-2016-2114 
<https://www.samba.org/samba/security/CVE-2016-2114.html>, CVE-2016-2115 
<https://www.samba.org/samba/security/CVE-2016-2115.html> and 
CVE-2016-2118 <https://www.samba.org/samba/security/CVE-2016-2118.html>. 
" See samba.org for more detail.

I unfortunately do not have the time at this point to troubleshoot and 
provide debug logs so I just reverted back to samba-3.6.23-25.el6_7 and 
everything is working as expected (i put a yumlock on Samba to prevent 
upgrades until a new upstream release is provided).

My recommendation is to skip this release and revert back to 3.6.23_25 
(you should find the 3.6.23_25 release in the Updates repository) and 
wait until the next release comes out.

Bob
--bs

--

On Wed, Apr 20, 2016 at 03:42:47PM -0500, Karen Magee
wrote:
>                     Also tied winbindd and that was a disaster of a
> different sort.
> 
> It wouldn't use the local unix groups first, which will cause way too
> many issues.
> 
> All along, however, the PCs that connect (when not trying to use
> winbindd) have consistently
> been able to connect and use the proper groups to access the files on
> the server.
I hear your frustration - we've had the same troubles.  My understanding
of this (which may be wrong) is:

 - The Badlock patches broke something in the Samba server which
   means it's no longer able to contact the Windows AD in order to
   authenticate users.

 - Windows clients who are on the domain are still able to authenticate
   because they have a valid Kerberos ticket from the AD server, but
   GNU/Linux and Mac OS X clients cannot.  [We haven't configured any
   non-Windows clients to talk Kerberos to the Windows AD server so
   it's unknown whether that would provide a workaround.]

 - But Winbind is still able to authenticate users against AD because it
   has "a much more robust and well-used codepath".
   
 - This is not likely to get fixed in the near future, so you must run
   Winbind if you have any GNU/Linux or Mac OS X clients.

 - But when you connect from a Windows client using Winbind, it uses
   the Windows AD groups for access control instead of the Unix groups.

This is basically broken on CentOS/RHEL 6.  If you have a Red Hat
subscription then you might try opening a ticket, but I wouldn't
hold up much hope.  The Samba project won't help you as they don't
support this version any more.

In CentOS/RHEL 7 this is somewhat better, as we've found this morning
after a frantic switchover.  You still have to run Winbind, but if you
put "username map script = /bin/echo" into the config then it will
use the Unix access permissions and (fingers crossed) it *seems* to be
now working as it did before the patches hit.

(Note: I also added "winbind trusted domains only = yes" but whether
that makes any difference I can't say, and I'm going to stop fiddling
with it now it's working.)

Ian Collier.

On 21/04/16 12:46, Ian Collier wrote:
> I hear your frustration - we've had the same troubles.  My
understanding
> of this (which may be wrong) is:
>
>   - The Badlock patches broke something in the Samba server which
>     means it's no longer able to contact the Windows AD in order to
>     authenticate users.
My understanding is that the Badlock patches fixed a multitude of 
security problems, also from work that I and Louis have carried out, it 
now looks possible that the problem lies in the way that the update 
packages have been created. I do not have any problems, but I build 
Samba with just './configure --enable-debug --without-systemd'. Louis 
initially had problems, but, after he built his owns debs, his computers 
now seem to be working correctly.
>
>   - Windows clients who are on the domain are still able to authenticate
>     because they have a valid Kerberos ticket from the AD server, but
>     GNU/Linux and Mac OS X clients cannot.  [We haven't configured any
>     non-Windows clients to talk Kerberos to the Windows AD server so
>     it's unknown whether that would provide a workaround.]
>
>   - But Winbind is still able to authenticate users against AD because it
>     has "a much more robust and well-used codepath".
>     
>   - This is not likely to get fixed in the near future, so you must run
>     Winbind if you have any GNU/Linux or Mac OS X clients.
>
>   - But when you connect from a Windows client using Winbind, it uses
>     the Windows AD groups for access control instead of the Unix groups.
That is how it is supposed to work in an AD domain:

Unix groups in /etc/passwd are local groups and as such, will be unknown 
to AD.
To have a Unix group that is known to AD, it first needs to created as 
an AD group and then given a gidNumber attribute, or use the 'rid' 
backend on a domain member.

Rowland
>
> This is basically broken on CentOS/RHEL 6.  If you have a Red Hat
> subscription then you might try opening a ticket, but I wouldn't
> hold up much hope.  The Samba project won't help you as they don't
> support this version any more.
>
> In CentOS/RHEL 7 this is somewhat better, as we've found this morning
> after a frantic switchover.  You still have to run Winbind, but if you
> put "username map script = /bin/echo" into the config then it
will
> use the Unix access permissions and (fingers crossed) it *seems* to be
> now working as it did before the patches hit.
>
> (Note: I also added "winbind trusted domains only = yes" but
whether
> that makes any difference I can't say, and I'm going to stop
fiddling
> with it now it's working.)
>
> Ian Collier.
>