samba - Jan 2023 - Windows 10/11/2019 and Samba-AD 4.x Kerberos login issue (unrelated to Bug 15197)

Hello guys,
there is another Kerberos issue preventing Windows machines from authenticating
properly to Samba DC.
There is an unfortunate time collision with BUG 15197, because the symptoms are
the same.
Ironically is has been described at microsoft for a year now:
https://learn.microsoft.com/en-us/troubleshoot/windows-server/identity/linux-accounts-cannot-get-aes-tickets
?
It happens for both scenarios:
- Samba DC and Windows client
- Windows DC and Samba client
?
Root cause: Windows implementation of Kerberos looks up the LDAP entry of the
opposite host,
specifically "operatingSystemVersion" attribute. For numerical values
less than 6, it assumes the other host is
an old Windows OS (like NT 4.0, Windows 2000 etc). It disables AES encryption
for such hosts - leading
to failed authentication later. Samba fills the
"operatingSystemVersion" attribute with values like
"4.x.x-Ubuntu"
during join or AD provisioning.
?
Manual remedy: edit LDAP entry of the Samba host using eg. ADSI Editor. Adjust
"operatingSystemVersion" attribute
from "4.x.x" to "Samba 4.x.x". Non-numeric characters at the
beginning of the value fix this issue.
?
Possible patch: it would be possible to solve this with a patch to Samba. Samba
could auto-update its LDAP entry.
The entered value would start with non-numeric value. Currently Samba fills
"operatingSystemVersion" attribute
at join/provisioning only.
?
I think it would be worth documenting this in SambaWiki somehow.
?
Regards
Jan

On Fri, 2023-01-27 at 09:38 +0100, Jan Bub?k via samba
wrote:
> Hello guys,
> there is another Kerberos issue preventing Windows machines from
> authenticating properly to Samba DC.
> There is an unfortunate time collision with BUG 15197, because the
> symptoms are the same.
> Ironically is has been described at microsoft for a year now:
>
https://learn.microsoft.com/en-us/troubleshoot/windows-server/identity/linux-accounts-cannot-get-aes-tickets
Thanks for raising this.  Can you please file a bug in our bugzilla?

I've sent you an invite.
>  
> It happens for both scenarios:
> - Samba DC and Windows client
I don't think this is particular aspect is the case, Samba as an AD DC
has never had such behaviour written.
> - Windows DC and Samba client
>  
> Root cause: Windows implementation of Kerberos looks up the LDAP
> entry of the opposite host,
> specifically "operatingSystemVersion" attribute. For numerical
values
> less than 6, it assumes the other host is
> an old Windows OS (like NT 4.0, Windows 2000 etc). It disables AES
> encryption for such hosts - leading
> to failed authentication later. Samba fills the
> "operatingSystemVersion" attribute with values like
"4.x.x-Ubuntu"
> during join or AD provisioning.
>  
> Manual remedy: edit LDAP entry of the Samba host using eg. ADSI
> Editor. Adjust "operatingSystemVersion" attribute
> from "4.x.x" to "Samba 4.x.x". Non-numeric characters
at the
> beginning of the value fix this issue.
>  
> Possible patch: it would be possible to solve this with a patch to
> Samba. Samba could auto-update its LDAP entry.
> The entered value would start with non-numeric value. Currently Samba
> fills "operatingSystemVersion" attribute
> at join/provisioning only.
>  
> I think it would be worth documenting this in SambaWiki somehow.
It certainly would be desirable for Samba to update this routinely in
any case, and understanding this behaviour is important. 

Andrew Bartlett
-- 
Andrew Bartlett (he/him)       https://samba.org/~abartlet/
Samba Team Member (since 2001) https://samba.org
Samba Team Lead, Catalyst IT   https://catalyst.net.nz/services/samba

Samba Development and Support, Catalyst.Net Limited

Catalyst.Net Ltd - a Catalyst IT group company - Expert Open Source
Solutions