Trust relationship failed - Cannot logon to Azure VM with domain or local user

[Björn Stahlberg]

Hi,

so we've got 3 VMs. A domain controller and 2 ADFS servers in Azure. For unknown reasons, the trust relationship failed between the two ADFS servers and the domain. I therefore cannot logon to both using a domain user. Also, if I try to login using a local account, I get the "requires network level authentication (nlm), but domain controller cannot be contacted" error. Network seems to be fine I can ping, remote desktop and whatever protocol between all 3 servers. They are in the same subnet. So.. what happened here and how can gain back access to the machines?

Regards

Björn

[#2]

as to the failed trust relationship i can only speculate, but i would like to confirm you current configuration. On the Vnet did you specify the DC as the Name server, or set it on the Nic of each VM? Also is this DC the first DC in a new Forest or have you extended your Domain to Azure? and finaly what NSG rules are you using between the VM's ?

[#3]

Hi Kent,

Yes, the DC is the primary name server for the Vnet and therefore the primary server for both of the failed VMs. We extended our domain to Azure so the DC is an additional DC to a single domain in a single forest. The configuration has been working fine so far for months. NSG rules are standard as far as I can tell. All traffic is permitted within the Vnet and there is an additional rule to allow inbound traffic from our Web Application Proxies. I attached a screenshot for reference. The DC does not have a NSG set.

[#4 · Accepted solution]

well the only thing i can think to mention is that you could consider 2 DC's in an availability set. Perhaps you single DC experienced a crash, have you created a new site topology for Azure in your ADDS configuration ? if you need to recover the VM's i would suggest using nested virtualization in another vm.

Azure recommends the following Create a separate virtual data disk for storing the database, logs, and SYSVOL for Active Directory. Do not store these items on the same disk as the operating system. Note that by default, data disks that are attached to a VM use write-through caching. However, this form of caching can conflict with the requirements of AD DS. For this reason, set the Host Cache Preference setting on the data disk to None. For more information, see Placement of the Windows Server AD DS database and SYSVOL.
Deploy at least two VMs running AD DS as domain controllers and add them to an availability set.

[#5]

We double checked all the settings and services and weren't able to identify any issues. However, after restarting the domain controller in Azure and then restarting both ADFS machines, we were able to login via RDP and a local admin account.  To me it seems like some service on the domain controller did not work as intended. Unfortunately we were not able to track this down any further.

[#6]

One thing you may want to consider, it happens to me often. Windows has the "network awareness service" it determines the Firewall profile. if the DC or the ADFS server are unable to contact a valid ADDS DNS server the profil may go to public. I like to delay the start up of this service on my ADDS servers, for unknown reasons sometimes it failes to validate its location if i dont.