Ask Your Question
0

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

asked 2024-01-22 13:30:36 +0000

Xnate gravatar image

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

edit retag flag offensive 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 gravatar imagehugo.vanderkooij ( 2024-01-22 14:03:45 +0000 )edit

1 Answer

Sort by ยป oldest newest most voted
0

answered 2024-01-22 17:25:16 +0000

Eddi gravatar image

updated 2024-01-22 20:44:22 +0000

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

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2024-01-22 13:30:36 +0000

Seen: 188 times

Last updated: Jan 22