First time here? Check out the FAQ!
THIS IS A TEST INSTANCE. Feel free to ask and answer questions, but take care to avoid triggering too many notifications.
Ask Your Question
0

Kerberos not working, NTLM working since upgrading domain from 2008R2 to 2019.

Hello,

We have upgraded our two active directories from 2008 R2 to 2019 this week.

As soon as we have upgraded them, we had a lot of computers who were no longer able to access to our 3 remaining windows 2003 servers shared folders.

I've unchecked the feature "Automatically supress SMB 1.0/CIFS" without any success on many computers.

I've tried enabling all encryption types allowed for Kerberos.

All computers can access the servers by ip address but using hostname with Kerberos just blocks.

I've tried checking wireshark packets, I only see RST, ACK packets, trying 3 times before stop attempting. My network skills just stops there : https://drive.google.com/file/d/1vVPA...

Does anyone have any idea on what would block the kerberos protocol ? Thanks

Xnate's avatar
1
Xnate
asked 2024-01-22 13:30:36 +0000
edit flag offensive 0 remove flag close merge delete

Comments

It't not a PCAP file. And it's only unsupported for over 8 years (https://learn.microsoft.com/en-us/lif...),

hugo.vanderkooij's avatar hugo.vanderkooij (2024-01-22 14:03:45 +0000) edit
more
  • delete
add a comment see more comments

1 Answer

0

Do you have a trace file? That JSON file is not really helpful.

Server 2003 only supports SMB v1. The newer Windows version will use SMB v3. To access shares hosted by Server 2003 you need the SMB v1 feature on the client side. This is installed as an optional Windows feature.

Even with the SMB v1 client installed you might run into trouble.

With respect to the Kerberos ticket: Please check, if the Server 2003 and newer servers share at least one common encryption algorithm. This would be visible in the Kerberos requests. I would expect RC4 on both sides.

And then some: In case your Server 2003 needs to access an SMB share hosted by a newer server:

SMB (or, hopefully, SMB2/3) can be quite picky during the session setup phase.

Please check your GPO and the trace file:

  • In the Session Setup Request you will find a Security Blob
  • The security blob might contain a field called LAN Manager response or NTLM response
  • Both fields should be zero
  • Expect a Kerberos ticket in a domain environment

Please note, that SMB1/2/3 (or the underlying security layer) will reject the session if

  • You gave the right password
  • BUT the session setup response comes with an outdated hash (LM or NTLM Hash)
  • AND the hashing algorithm is denied by GPO

If the client sends a hash (LM or NTLM) that is "forbidden" (disabled) on the server side, the server will reject the session. Even if you gave a valid NTLM v2 hash. Or a valid Kerberos ticket.

Again, a trace file will greatly help to confirm or debunk this theory.

A bit background information might come from my blog post at packet-foo.com

Best of luck

Eddi

Eddi's avatar
2.4k
Eddi
answered 2024-01-22 17:25:16 +0000, updated 2024-01-22 20:44:22 +0000
edit flag offensive 0 remove flag delete link
more

Comments

add a comment see more comments

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account. This space is reserved only for answers. If you would like to engage in a discussion, please instead post a comment under the question or an answer that you would like to discuss.

Add Answer