Scroll Top
Evotec Services sp. z o.o., ul. Drozdów 6, Mikołów, 43-190, Poland

Accessing AzureVM with NLA and broken domain trust relationship

img_5c9c00a9ea714

Hosting your VM's in Azure Cloud is excellent. You have all those features, professionally managed and virtually limitless. I don't want to take your time to sell you Azure Services but to share a solution to one of the things I had to solve in Azure and sooner or later you may end up with on. During the test restore for Active Directory and multiple other machines which were much older (or newer) then Active Directory Domain Controller that was restored it turned out one can't log in to most of the devices. First of all your domain password is already changed, but that can quickly be addressed. Your second and more significant problem is Network Level Authentication (NLA), and your 3rd problem is broken trust relationship.

What is the problem?

Having most of the restored machines disconnected from their domain with broken trust relationship and NLA can be a problem as there is no console connection like in your standard Hyper-V or VMWare solutions. You can't just use a console and fix it manually. Therefore even if you have your old or new password, you still can't log in to the machine. One, because NLA (Network Level Authentication) will prevent it, and two, even if you have disabled NLA the newly reset password on Domain Controller will never reach that machine. You can, of course, use the feature provided by Azure to reset your local RDP password which will create a new user or will reset a password for existing one but with NLA enabled you can't log in even with local administrator. So you have to find a way to remove it first. Removing NLA is simple. Just one line of PowerShell changing one entry in the registry and you're done.

$RegistryKey = 'Registry::HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp'
$Name = 'UserAuthentication'
Set-ItemProperty -Path $RegistryKey -Name $Name -Value 0

But I am not logged to the machine, nor I can do it remotely because I have no trust relationship anymore. While looking for an answer, I found a troubleshooting guide advising to attach VHD to another VM, fix registry setting there and boot. While feasible I would do it only as a last resort. In a DR scenario, I can't imagine myself going thru this with every single machine.

Fixing Azure VM trust relationship

As mostly with my blog posts, after trying different things in Azure I was able to find myself a solution on how to deliver PowerShell script without even connecting to the machine. At first, I thought I would just disable NLA, log back in as local Administrator and fix trust relationship. But having access to PowerShell seemed like it would be best to fix everything at the same time so I could just paste code, and have it done in one go.

# Removes NLA (not neeeded if you plan to use 2nd option)
$RegistryKey = 'Registry::HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp'
$Name = 'UserAuthentication'
Set-ItemProperty -Path $RegistryKey -Name $Name -Value 0


# Fixes domain trust
$User = "[email protected]"
$PWord = ConvertTo-SecureString -String "MyPassword!" -AsPlainText -Force
$Credential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $User, $PWord
#Reset-ComputerMachinePassword -Credential $Credential
Test-ComputerSecureChannel -Repair -Credential $Credential

In the script above you can see I've decided to fix two things. Disable NLA and fix trust at the same time. But to be honest, if we're fixing trust to the domain we don't need to disable NLA. Therefore it's recommended only to fix domain trust. Additionally, please notice in the code above there are a login and password in clear text. It's important to NOT use your login and password because whatever will be in that script is audited, and therefore you're exposing passwords for everyone to see. For this purpose, I've created a separate, one-time use user and gave this user proper permissions. You can either fix delegation to create/delete computers for that user or temporary add the user to Domain Admins. I would recommend the first version, but for testing purposes, I've done the worst offense. Ok, so we have a PowerShell script that anyone could have written, but how do we get it to the VM?

Delivering PowerShell script to Azure VM

Open portal.azure.com, go into Virtual Machines and find your machine. Under operations, there is a Run command option.

On the next page, simply choose RunPowerSehllScript

Paste script that we've written above (or any other you would like executed) and just press run.

Now you have to wait for a few seconds, minutes while Azure connects to your VM instances and fixes your trust with the domain or/and disables NLA. After it's done, you can log in to your machine without any effort using your standard domain login and password. Remember to remove/disable account we have created in the beginning after you're done with it.

Posty powiązane