[Samba] Problem after update version 4.15.0

[rme at bluemail.ch]

Hello

>> No, Time is NTP-Synchronized.
> 
> Yeah, same here, but still, for some reason, sometimes 1 pc is off..
> Thats why im asking.. Check, dont assume..

You are totally right and I couldn't agree more. But yes I have checked. 
The time is 100% correct and synchronized. "net time" also properly 
updates the clock.


> Definitly strange, but im thinking, are these pc's syspreped.
> And was there SID reset at that time.

No. I am using remote installation. The machines are all PXE-booted and 
launching setup with unattended.xml with a minimum configuration only 
(like license keys, time zone and local account). There is no image 
adjustments, just the basic Windows 10 Professional WIM/ESD image and 
specifially no cloning involved.

And again, this seems to happen only on a fraction of my existing 
machines. Not on one which is also installed since a longer time but 
joined to the domain just a few days before 4.14.7 to 4.15 upgrade.


>> Yes, even older. I was even using SAMBA-ldap on pre-4.0 releases. But
>> this particular machine was added later, for sure after 4.0
>> AD upgrade.
>> Sure I don't remember exact dates of upgrade. But yes this Domain was
>> upgraded all the way since first Samba 4.x releases. However
>> I don't see
>> why this should cause such issues and why there is no proper
>> migration.
>> So we might be looking at some upgrade/migration issues but my
>> understanding was that Samba should actually handle this and not just
>> start denying computer account logins on upgrade.
>> Sure if the machine using some legacy authentication method
>> or anything
>> like this, then I would expect Samba first to force the
>> client to update
>> the password or authentication method before completely
>> locking it out.
> 
> Ah, im pretty sure your "source" of the problem is this.

This is working fine since years and I would still call it a Samba bug 
if after an upgrade it suddenly stops working for some machines. I would 
assume at least an upgrade path. It's not like I want to upgrade from 
4.0 to 4.15. I am actually running a fully working installation on 
4.14.7 and just do the upgrade to 4.15 where it stops working.

Though I know that there are some maintenance tasks to be done on 
upgrading. I also did upgrade from older domain levels to newer ones in 
previous releases.

Actually we had some nice discussions on upgrading topics already the 
two of us:
<https://lists.samba.org/archive/samba/2016-August/201773.html>

Thanks again :-)

I did also have a nice discussion on domain level upgrade and bug in 
Samba (failing to set proper msDS-SupportedEncryptionTypes). At this 
point in time I had do to "samba-tool domain level raise" and 
"samba-tool domain schemaupgrade" but still Samba would not properly 
upgrade msDS-SupportedEncryptionTypes from the set value of 31 to the 
expected value of 28 (RC4,AES128,AES256) so I needed to do this 
manually. See here:
<https://bugs.archlinux.org/task/66023#comment190563>

I would however have expected that the "samba-tool domain schemaupgrade" 
would have handled this properly, updating the domain controller AD 
object with proper attributes supported by the Samba version installed.

Perhaps we are looking at a similar problem now. However I already 
checked the values of msDS-SupportedEncryptionTypes for all objects 
yesterday. They all report value 28 for all involved machines:
- Domain controller: msDS-SupportedEncryptionTypes: 28
- Non-Working client: msDS-SupportedEncryptionTypes: 28
- Working client: msDS-SupportedEncryptionTypes: 28

as reported by "samba-tool computer show <name>"
Also as reported yesterday the diff of "samba-tool computer show <name>" 
for a working and a non-working machine only shows differences in names 
and timestamps, not in encryption values or other attributes.

>> Yes, I did this. Set my servers to static entries and clients
>> to dynamic using regex.
> 
> So, it seems there must be more thats off,

Also I am not sure how this could be related and why Samba would 
suddenly report the machine account password to be wrong even if DNS 
entries would be incorrect.


> And what if you compair the 2 ldap objects of a working and not working
> There IS a difference somewhere.

"samba-tool computer show <computername>"
should show those attributes. And as mentioned there is no single 
difference in any attribute (also not in the number of attributes) on a 
working and a non-working machine. Of course names and timestamps of 
last logon, last change etc. are not identical too.



>> At login?
>> First of all no user can log on to the affected machines
>> (except local user accounts).
> 
> While on Samba 4.17.. Then users can login.

Valid point, but actually impractical. I would have to make sure that 
every single machine gets an admin-login before I could do the upgrade. 
In an environment where you have machines which might not be used for 
months it's not really practical to do.
Moreover none of the users do have admin privileges, so I can't use a 
logon script.
I might be able to use a GPO machine startup script or my software 
deployment system which runs in the background. But still I would need 
to be sure each machine is re-joined before starting the upgrade.

So at best this is an ugly work-around. But still think the issue should 
be tracked down in Samba.



> Then you run the script in the "computer" context" and a computer
>   can maintain its own records as far i know.
> You might needed to add an xlm file locally first *can be done with GPO's.
> 
> I just found this one,
> https://mcpmag.com/articles/2015/03/05/rejoin-a-computer-from-a-domain.aspx
> Read it, that might give the idea on howto rejoin them.
> Because, i think its really needed..

Thank you for the input. But I think we might get lost in such 
workarounds rather than tracking down the root cause. We can't really 
ask all administrators using Samba domain controllers anywhere in the 
world to do this pre-preparation to re-join all machines before doing 
any Samba upgrades to 4.15. Moreover the Arch Linux link you provides 
indicates that it might not even help to re-join the machine.


> Your domain is even older then mine, i started with 4.1.x
> And im even thinking currenlty to, setup a complete new fresh domain.

I don't see why it should be necessary. Samba provides backwards 
compatibility and the database files are just fine after the upgrade. 
Samba also provides samba-tool domain level and domain upgrade tools for 
exactly this purpose. If the tools don't work, the tools should be fixed.


> Your welkom..

Much appreciated.

Rainer