-1

I'm experiencing a very strange issue with a one-way trust setup where users from a trusted domain (Domain A) can successfully log in to the trusting domain (Domain B), however password change attempts fail with "Configuration information could not be read from the domain controller, either because the machine is unavailable, or access has been denied.".

The set up is: Domain A - 2x Win 2012 R2 and 1x Win 2008 R2* Domain Controllers (running at Win 2008 R2 AD level) Domain B - 2x Win 2016 Domain Controllers (running at Win 2016 AD level)

*Yes I know, EOL, it's being turned off soon.

I also don't believe the functional AD level has any bearing on the issue.

Typically users establish a VPN connection and then RDP onto a 2016 Terminal Server in Domain B using their Domain A accounts. Fine so far. They can access resources from Domain A while logged into the Domain B terminal server. Still fine. However once a password expires on an account a user cannot change it. I have verified the Trust is working correctly and DNS is functioning as I can query the Domain A servers using their FQDN from Domain B and their local IP's are reported back to me.

I've sat on the active DC watching the Security logs and attempted a password change from Domain B and I see nothing at all. I can see my user logging in and opening applications.

Am I correct in my thinking of how this all works? Domain B Terminal Server > Domain A Domain Controller

We run Splunk and it has visibility of both domains and I've also run a local instance of Wireshark on the terminal server but I'm not that good at filtering out the noise in either of these applications to narrow in on the correct comms. All I see in Wireshark are CLDAP entries from the terminal server to the DC on the other end.

I've exhausted my searches here and elsewhere. The 2012 DC's do not have KB4012219 installed to restrict remote calls to SAM. The fact I don't see any errors on the Domain A DCs tells me the requests do not even make it from Domain B. But I don't see any obvious deny's in Splunk.

Additional testing I have carried out is using "nltest /dsgetdc: " from the Domain B Terminal Server and it errors with cannot find the domain.

Any ideas?

wrathchild
  • 1

1 Answers1

0

The issue has been resolved. The cause was down to firewall rules. Rules were configured to allow AD traffic between the Domain Controllers only, whereas the requests were coming directly from the Terminal Server in Domain B to the Domain Controllers in Domain A. Once my colleague saw this happening in the logs he applied the same rules to the Terminal Server and I was then able to successfully change a user password.

wrathchild
  • 1