[Samba] Classicupgrade FL 2012_R2 NTLM/Kerberos logon

Wed Jun 5 13:52:15 UTC 2024

On Wed, 5 Jun 2024 12:27:56 +0200
Havany via samba <samba at lists.samba.org> wrote:

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

If you can create a new AD domain, that would always be my preferred
method, that way you can leave behind any old ways of doing things
(such as AD Unix IDs starting at 1000). unless you require to specify
individual Unix home directories, you can use the 'rid' idmap backend
on any Unix domain members you may have, which means you do not have to
add anything extra to AD.

Rowland