[Samba] 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

[Rowland penny]

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