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

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

On Thu, Apr 21, 2016 at 01:25:14PM +0100, Rowland penny
wrote:
> My understanding is that the Badlock patches fixed a multitude of security
> problems,
That's not disputed, and is why we have persevered in trying to make the
patched version work instead of just reverting back to the previous version
(you'll note that one response on this thread advocated doing that).
>           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'. 
I doubt this.  The OP is about samba 3.6.23-30 which essentially
no longer exists except in packaged form.  And I'm referring to the
fact that AD authentication in the samba binary is broken (i.e. not
using the separate winbindd binary), which Andrew Bartlett appears
to have agreed with in Debian bug 820981.  Everyone who has got it
working so far (including you, I suspect) is running winbindd.
> 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.
But people with a long-established Unix authentication system are not
going to do this: duplicating all the Unix groups in AD is a faff and
will only lead to problems in the long run when they aren't kept in sync.

The answer is to use the username map (which translates the AD identities
into Unix ones); it just happens not to work properly in 3.6.23.

Ian Collier.

On 21/04/16 15:32, Ian Collier wrote:
> On Thu, Apr 21, 2016 at 01:25:14PM +0100, Rowland penny wrote:
>> My understanding is that the Badlock patches fixed a multitude of
security
>> problems,
> That's not disputed, and is why we have persevered in trying to make
the
> patched version work instead of just reverting back to the previous version
> (you'll note that one response on this thread advocated doing that).
>
>>            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'.
> I doubt this.  The OP is about samba 3.6.23-30 which essentially
> no longer exists except in packaged form.  And I'm referring to the
> fact that AD authentication in the samba binary is broken (i.e. not
> using the separate winbindd binary), which Andrew Bartlett appears
> to have agreed with in Debian bug 820981.  Everyone who has got it
> working so far (including you, I suspect) is running winbindd.
This is really the way to go and is the way the DC works, it will not 
work if you do not have winbindd running. You don't have to use it on a 
domain member, you just have to run it.
>
>> 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.
> But people with a long-established Unix authentication system are not
> going to do this: duplicating all the Unix groups in AD is a faff and
> will only lead to problems in the long run when they aren't kept in
sync.
No, you don't have to keep them in sync, you create them in AD, give 
them a gidNumber (this could be the one they had in /etc/group) and then 
remove them from /etc/group.
>
> The answer is to use the username map (which translates the AD identities
> into Unix ones); it just happens not to work properly in 3.6.23.
The username map is now only really used to map 'Administrator' to the 
Unix user 'root', anything else is old NT4
style.

It is however your domain, so do it your way, whatever works for you :-)

Rowland
> Ian Collier.
>