Forum Discussion
Root DFS and ntlm hardening
Hi all
Recently we have tried to harden our NTLM. After applying some settings the access to the root of our domain has become intermittent \\domain.co.uk but all the namespaces as well as symbol etc I der the root are working fine and can be navigated to without an issue.
DCs have now been applied the same settings which are send LM and ntlm and use V2 if negotiated. The issue is intermitted as it it will work on a DC and then stop and then work again.
Similar is on the end user devices.
We have on prem DCs and all devices are in tuned and entra joined.
We are hybrid but we do not sync or write the devices to ad.
Replication and DFS itself are healthy.
Issue are some users who have AFS paths already mapped to their devices it fails to connect to them sometimes. But new mapping works.
Any ideas or assistance will be appreciated.
2 Replies
Hi
Long story short of where we are.
After a lot of investigationg and comparing settings we discovered that our intuned client machines have Sent NTLM v2 and refuse lm and ntlm settings enabled as well as require 128 bit encryption and ntlmv2. Servers were inconsistent so we set them all to send lm and ntlm and send ntlmv2 if negotiated with the other settings set to no minimum. This did not resolve the problem. We then tested each DC and we dicovered that only one answered and others failed. The only difference between that DC and other was Network Security: Restrict NTLM: Incoming NTLM traffic. The working DC had a setting of Deny all domain accounts while other servers had Deny All accounts. Once we changed that we were able to aloways load the \\domain.co.uk path.
Now obviously this is not the most secure way of doing this but how would i now go on about resolving this issue and making secure and my cyber team happy?
In addition to the below can you let me know how i would do this:
"confirm how the user obtains Kerberos tickets"
Thank you in advance.Regards
The selected setting is not NTLM hardening: “Send LM and NTLM, use NTLMv2 session security if negotiated” still allows LM and NTLM authentication. The intermittent failure of the domain DFS root, while child paths work, points toward inconsistent domain-controller referral or authentication paths rather than an unhealthy namespace. Enable NTLM auditing before denying anything and review the NTLM Operational log on domain controllers and namespace servers. During a failure, record the active domain controller, inspect the DFS referral cache, verify DNS and domain-controller connectivity, and test TCP 445 to the referred namespace server. Compare those results with a working attempt and check whether existing mapped paths contain stale referrals. Entra-joined devices that are not AD computer objects can follow a different authentication path, so confirm how the user obtains Kerberos tickets. Correct the inconsistent dependency first, then apply a consistent NTLMv2-only or deny policy in stages.
