[Samba] Classicupgrade FL 2012_R2 NTLM/Kerberos logon

Havany havany at asalluhi.fr
Wed Jun 5 10:27:56 UTC 2024 

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

More information about the samba mailing list