[Samba] problem with domain and samba3x

Gaiseric Vandal gaiseric.vandal at gmail.com
Mon Jun 20 21:32:09 UTC 2016


On 06/20/16 15:19, Rowland penny wrote:
> On 20/06/16 19:53, Dale Schroeder wrote:
>> On 06/17/2016 4:31 PM, peter lawrie wrote:
>>> Hi all
>>> About 18 months ago I connected 14 new Windows 7 PCs to a Centos5.1 
>>> server
>>> with samba3x as domain members.  There are no other servers on site.
>>> Today, I had to visit to connect up a PC in a new location. As I would
>>> normally do I checked for Centos updates and found 35 outstanding 
>>> including
>>> samba3x 3.6.23-12.el5_11 and samba3x-client, samba3x-common, 
>>> samba3x-doc,
>>> samba3x-domainjoin-gui, samba3x-swat, samba3x-winbind, 
>>> samba3x-winbind-devel
>>>
>>> Having completed the cabling I tried to log the PC in but received 
>>> 'trust
>>> relationship between this workstation and primary domain failed'. 
>>> Several
>>> times I removed it from the domain and added it back again - this 
>>> made no
>>> difference. I noted the time on the PC was 7 minutes out from the 
>>> server,
>>> so corrected that, removed from the domain, added it in again but 
>>> had the
>>> same message.
>>> Thinking it was just related to this PC, I left it configured as a
>>> workgroup member, created a new local user to match the domain 
>>> username it
>>> had been using and connected it to the server shares.
>>>
>>> Then I went to another PC which had an unrelated issue which needed
>>> attention but when I tried to logon to the domain received the same 
>>> domain
>>> trust failure message.
>>> Only then did I suspect that the samba3x update may have been the 
>>> cause so
>>> I removed it installed 3x 3.6.23-9 - now when I tried to login I get 
>>> "there
>>> are no login servers available to service the login request"
>>>
>>> As other users were complaining about losing access to the server 
>>> shares, I
>>> then had to visit every PC, remove each of them from the domain into a
>>> workgroup, create a local user on each to match the samba username 
>>> and copy
>>> the profile. Needless to say, a job which should have taken 1 to 2 
>>> hours
>>> took 7.
>>>
>>> I still have no idea why the problem occurred, is there an issue 
>>> with the
>>> latest samba update. All I could find online was that the update 
>>> related to
>>> a fix for badlock vulnerability.
>>> Peter Lawrie
>> Peter,
>>
>> The badlock patches have been a big problem for Samba classic 
>> domains.  Many have posted asking for help, but I have seen no 
>> solution presented on this list; i.e. the silence is deafening. It 
>> may be that NT4 classic domains will not work going forward.
>>
>> For example, refer to the post by Peter Tuharsky: 
>> http://www.spinics.net/lists/samba/msg134710.html
>>
>> In all actuality, Samba 4.3.x pre-badlock had already broken classic 
>> ldap domains.
>
> I did some testing before the badlock patches and did manage to get an 
> ldap based NT4 PDC running and connected a Unix client to it, but this 
> was a test domain and it didn't use smbldap-tools.
>
> I think one of the problems is that nobody has logged a bug report for 
> this problem, so nobody is looking in to it, another problem is that 
> windows is trying to deter the use of NT4-style domains, it is my 
> understanding that Win10 will not connect to one out-of-the-box. They 
> could (and probably will) make the use of NT4 domains impossible at 
> any time.
>
> Rowland
>
>>
>> So, if anyone has a working Samba/openldap NT4 classic domain 
>> post-badlock patches, would you please share your config to help 
>> these people?
>>
>> And, if you have a working 4.3 or 4.4 classic domain config, please 
>> help me out.
>>
>> Thanks,
>> Dale
>>
>>
>>
>
>
Windows 10 clients can be connected to a non-badlock patched 
classic-domain.    Requires the same registry changes as Windows 7 to 
set "DomainCompatibilityMode" = 1

(I think this would be same as disabling RequireSignOrSeal in group 
policy.)    The samba badlock patches change  the default behavior of 
samba server to require signing.   It may be that you need to explicitly 
set "server signing" and "client signing" to auto to force the older 
behavior.

I was never able to make patch domain members work with a non-patch 
domain controller.     (Also running Samba 3.x as classic domain. )  I 
suspect the reverse is true.    Even with disabling signing on the samba 
member servers, I was getting schannel and spnego errors so something 
changed there too.    I could  get the patched member servers to join 
the domain but domain users from windows or samba would not be allowed 
to access resources.


I had expected that patched domain controller would would with a patched 
member server and that the windows machines would auto-negotiate 
everything but  now I doubt that.








More information about the samba mailing list