Andrew Bartlett
2024-Jun-04 20:02 UTC
[Samba] Classicupgrade FL 2012_R2 NTLM/Kerberos logon
On Tue, 2024-06-04 at 12:48 +0200, Havany via samba wrote:> Hi samba list, > > I work on an classicupgrade of our NT4/ldap domain. > > On my tests (DC and filer are on FreeBSD and zfs file system, client > is > a Windows 10 22H2): > > -> I'm able to do this classicupgrade and keep all users able to > connect > on computers with their domain account. > > -> In a second step I configure samba DC to improve security and by > the > way I upgrade our FL to 2012_R2, schema to 69 and ad dc FL to 2016 > (commented line below are uncommented at this step):> -> After a while (~2-3 days): > * I'm unable to logon with an AD account on the Win10 client, on the > DC > I have nothing in the logs files > * I'm able to access to a share on the filer from W10 client and on > the > DC (sysvol), and on the DC log I can see entry about NTLM2 success > log-in : > > [2024/06/04 11:20:16.375698, 3] > ../../auth/auth_log.c:876(log_authentication_event_human_readable) > Auth: [SMB2,NTLMSSP] user [<user>] at [Tue, 04 Jun 2024 > 11:20:16.375682 CEST] with [NTLMv2] status [NT_STATUS_OK] > workstation > [<hostname>] remote host [ipv6<IP>:30676] became <user> [<SID>]. > local > host [ipv6<IP>:445] > > * If I rejoin the Win10 to the domain nothing change > * If I change the user password, I'm able to open session on the W10 > and > I see logs about kerberos authentication on DC.I think what is happening is that the DC has only the NT hash for users and computers, but that clients are expecting that the DC has an AES key given the domain is in such a high FL> * If on the DC I do "kinit" of on user that have not is password > changed > I'm able to take akinit on the DC will be honouring the krb5.conf settings, which may still allow the AS-REQ with the rc4-hmac key.> I suspect that my problem have a link with the FL upgrade to 2012_R2 > and > DC to 2016. > > My questions : > > 1 - Do you think this problem come from the FL upgrade ? > 2 - Why user without password changed can get a kerberos ticket on > the > DC but seems not to get it on Win10 client ? > 3 - Is there a way to allow fallback to ntlm2 when a session is > opened > on the client if kerberos doesn't work ?That final point (3) would be question about client configuration, but you really don't want that, you need to get to Kerberos as fast as possible. This is a complex situation, I would have expected it would still be possible to keep user accounts working with just an NT hash (sadly), but you would need to take network traces to show the clients still sending that. Also note that by updating the FL, FAST should now be used. This is good, but might make the traces harder to interpret. Due to the complexity of the migration (I presume you have a very large domain otherwise you would have just changed the passwords) I suggest working closely with your Samba commercial support provider to see if anything can be done on Samba's side. Otherwise leave the FL lower and set all the accounts to 'must change password at next logon' would be my suggestion. Andrew Bartlett -- Andrew Bartlett (he/him) https://samba.org/~abartlet/ Samba Team Member (since 2001) https://samba.org Samba Team Lead https://catalyst.net.nz/services/samba Catalyst.Net Ltd Proudly developing Samba for Catalyst.Net Ltd - a Catalyst IT group company Samba Development and Support: https://catalyst.net.nz/services/samba Catalyst IT - Expert Open Source Solutions
Hello, Given what Rowland told me, I checked our DNS configuration and to avoid side effects, I disabled IPv6. Le 04/06/2024 ? 22:02, Andrew Bartlett a ?crit?:> On Tue, 2024-06-04 at 12:48 +0200, Havany via samba wrote: >> >> * If I rejoin the Win10 to the domain nothing change >> * If I change the user password, I'm able to open session on the W10 >> and >> I see logs about kerberos authentication on DC. > > I think what is happening is that the DC has only the NT hash for users > and computers, but that clients are expecting that the DC has an AES > key given the domain is in such a high FL > > >> * If on the DC I do "kinit" of on user that have not is password >> changed >> I'm able to take a kerberos ticket > > kinit on the DC will be honouring the krb5.conf settings, which may > still allow the AS-REQ with the rc4-hmac key. >With kinit on the DC it seems to use arcfour-hmac-md5 : Kerberos: heim_audit_setkv_number(): setting kv pair #auth_event=11 Kerberos: Client sent patypes: ENC-TS Kerberos: heim_audit_vaddkv(): kv pair[0] client-pa=ENC-TS Kerberos: Looking for PK-INIT(ietf) pa-data -- moi2021 at ADMIGT.NETTEST.EC-M.FR Kerberos: Looking for PK-INIT(win2k) pa-data -- moi2021 at ADMIGT.NETTEST.EC-M.FR Kerberos: Looking for ENC-TS pa-data -- moi2021 at ADMIGT.NETTEST.EC-M.FR Kerberos: heim_audit_vaddkv(): kv pair[0] pa=ENC-TS Kerberos: ENC-TS Pre-authentication succeeded -- moi2021 at ADMIGT.NETTEST.EC-M.FR using arcfour-hmac-md5>> I suspect that my problem have a link with the FL upgrade to 2012_R2 >> and >> DC to 2016. >> >> My questions : >> >> 1 - Do you think this problem come from the FL upgrade ? >> 2 - Why user without password changed can get a kerberos ticket on >> the >> DC but seems not to get it on Win10 client ? >> 3 - Is there a way to allow fallback to ntlm2 when a session is >> opened >> on the client if kerberos doesn't work ? > > That final point (3) would be question about client configuration, but > you really don't want that, you need to get to Kerberos as fast as > possible. > > This is a complex situation, I would have expected it would still be > possible to keep user accounts working with just an NT hash (sadly), > but you would need to take network traces to show the clients still > sending that. Also note that by updating the FL, FAST should now be > used. This is good, but might make the traces harder to interpret.Ok it confirm what I thank about. On an failed authentication I have those kerberos logs : Received krb5 TCP packet of length 211 from ipv4:<ClientIP>:57922 kdc_process: Received KDC packet of length 203 from ipv4:<ClientIP>:57922 Kerberos: Probing for AS-REQ Kerberos: Not a FAST request Kerberos: AS-REQ moi2020@<SHORTDOMAIN> from ipv4:<ClientIP>:57922 for krbtgt/<SHORTDOMAIN>@<SHORTDOMAIN> Kerberos: heim_audit_setkv_number(): setting kv pair #auth_event=11 Kerberos: Client sent patypes: 128 Kerberos: heim_audit_vaddkv(): kv pair[0] client-pa=128 Kerberos: Looking for PK-INIT(ietf) pa-data -- moi2020@<SHORTDOMAIN> Kerberos: Looking for PK-INIT(win2k) pa-data -- moi2020@<SHORTDOMAIN> Kerberos: Looking for ENC-TS pa-data -- moi2020@<SHORTDOMAIN> Kerberos: Need to use PA-ENC-TIMESTAMP/PA-PK-AS-REQ Kerberos: as-req: sending error: -1765328359 to client Kerberos: Making non-FAST KRB-ERROR Kerberos: heim_audit_vaddkv(): kv pair[0] elapsed=0.004752 Kerberos: heim_audit_vaddkv(): kv pair[0] e-text=Need\sto\suse\sPA-ENC-TIMESTAMP/PA-PK-AS-REQ Kerberos: AS-REQ ERR_PREAUTH_REQUIRED ipv4:<ClientIP>:57922 moi2020@<SHORTDOMAIN> krbtgt/<SHORTDOMAIN>@<SHORTDOMAIN> client-pa=128 e-text=Need\sto\suse\sPA-ENC-TIMESTAMP/PA-PK-AS-REQ elapsed=0.004752 And if I change password I have : Received krb5 TCP packet of length 211 from ipv4:<ClientIP>:57925 kdc_process: Received KDC packet of length 203 from ipv4:<ClientIP>:57925 Kerberos: Probing for AS-REQ Kerberos: Not a FAST request Kerberos: AS-REQ moi2020@<SHORTDOMAIN> from ipv4:<ClientIP>:57925 for krbtgt/<SHORTDOMAIN>@<SHORTDOMAIN> Kerberos: heim_audit_setkv_number(): setting kv pair #auth_event=11 Kerberos: Client sent patypes: 128 Kerberos: heim_audit_vaddkv(): kv pair[0] client-pa=128 Kerberos: Looking for PK-INIT(ietf) pa-data -- moi2020@<SHORTDOMAIN> Kerberos: Looking for PK-INIT(win2k) pa-data -- moi2020@<SHORTDOMAIN> Kerberos: Looking for ENC-TS pa-data -- moi2020@<SHORTDOMAIN> Kerberos: Need to use PA-ENC-TIMESTAMP/PA-PK-AS-REQ Kerberos: as-req: sending error: -1765328359 to client Kerberos: Making non-FAST KRB-ERROR Kerberos: heim_audit_vaddkv(): kv pair[0] elapsed=0.005030 Kerberos: heim_audit_vaddkv(): kv pair[0] e-text=Need\sto\suse\sPA-ENC-TIMESTAMP/PA-PK-AS-REQ Kerberos: AS-REQ ERR_PREAUTH_REQUIRED ipv4:<ClientIP>:57925 moi2020@<SHORTDOMAIN> krbtgt/<SHORTDOMAIN>@<SHORTDOMAIN> client-pa=128 e-text=Need\sto\suse\sPA-ENC-TIMESTAMP/PA-PK-AS-REQ elapsed=0.005030 Received krb5 TCP packet of length 291 from ipv4:<ClientIP>:57926 kdc_process: Received KDC packet of length 283 from ipv4:<ClientIP>:57926 Kerberos: Probing for AS-REQ Kerberos: Not a FAST request Kerberos: AS-REQ moi2020@<SHORTDOMAIN> from ipv4:<ClientIP>:57926 for krbtgt/<SHORTDOMAIN>@<SHORTDOMAIN> Kerberos: heim_audit_setkv_number(): setting kv pair #auth_event=11 Kerberos: Client sent patypes: ENC-TS, 128 Kerberos: heim_audit_vaddkv(): kv pair[0] client-pa=ENC-TS,128 Kerberos: Looking for PK-INIT(ietf) pa-data -- moi2020@<SHORTDOMAIN> Kerberos: Looking for PK-INIT(win2k) pa-data -- moi2020@<SHORTDOMAIN> Kerberos: Looking for ENC-TS pa-data -- moi2020@<SHORTDOMAIN> Kerberos: heim_audit_vaddkv(): kv pair[0] pa=ENC-TS Kerberos: ENC-TS Pre-authentication succeeded -- moi2020@<SHORTDOMAIN> using aes256-cts-hmac-sha1-96> > Due to the complexity of the migration (I presume you have a very large > domain otherwise you would have just changed the passwords) I suggest > working closely with your Samba commercial support provider to see if > anything can be done on Samba's side. Otherwise leave the FL lower and > set all the accounts to 'must change password at next logon' would be > my suggestion. >Yes our domain is a bit large (not too much but...). We are an engineer school with around 400 Windows computers and 1500 active users. We try 2 scenarios : - A "Big bang" migration to an new domain made from scratch : but we need to migrate all users, computers, laptops, filers without loosing profiles, files server access... In a short time (1-2 weeks maximum) - A "classicupgrade" migration, but it need several steps to improve security. And at the same time, and we are afraid to import "silently" many misconfiguration from our old NT4 Domain that could have an impact in the future. We want to migrate on July, and we don't work with a Samba commercial provider ;). In your opinion, should we continue with the 'classicupgrade' method or should we migrate to a new, clean domain? Thank you both for your help.> Andrew Bartlett > >