Remotely Managing Windows Endpoints Part II: Azure AD Joined Hosts

Part I

Alright, now on to where things get more complicated, WinRM connections to and from Azure AD joined clients. I’m going to use two acronyms throughout this post that I want to define now:

• HAADJ – A Hybrid Azure AD Joined device. For the context of this post, this device could also be a purely AD joined device.
• AADJ – A purely Azure AD Joined, specifically logged into with a hybrid (synced via Azure AD Connect) identity.

There are two scenarios I’ll cover, each with their own nuisances: Azure AD clients as the source, and as the destination. If you’re following along from Part I, I’ve since reverted the existing WinRM firewall rule on my servers to normal, so no IPSec is required.

• AADJ -> HAADJ WinRM
• HAADJ -> AADJ WinRM
• Conclusion

AADJ -> HAADJ WinRM

From an AADJ client, let’s just try to etsn to a server and specify credentials. Surely it will just work, right? I’ve got Azure AD Connect in place, along with Azure AD Kerberos and Hybrid Cloud Kerberos Trust. I can log in with Windows Hello for Business and successfully access on-premises resources without issue. Well…

No dice. Since the source client isn’t domain-joined, and we’re attempting to use normal WinRM (not over HTTPS), Kerberos mutual authentication at the device level cannot occur. The source device does not have an identity in AD. I guess we’ll just need to go back to Hybrid devices. Wrong!

We can go about fixing this in two different ways. First, the easy, but less secure route: Trusted Hosts. Let’s configure a Settings Catalog profile in Intune to set some WinRM settings:

Similar to the policy we created in AD in part I, I’m enabling the settings I desire, while additionally configuring the Trusted Host list to include my wildcarded AD domain name. This configuration will instruct the client to not perform Kerberos mutual authentication at the device level, and allow the connection to succeed for that domain. This does pose a security risk, because if a compromised device can assume the DNS name of a domain client, you can inadvertently send your credentials to it.

We can at least counter this by configuring NTLM authentication restrictions on the client, or by adding the user account being used to the Protected Users group to prevent NTLM authentication and only allow Kerberos authentication. Both of these can be pretty powerful in securing your environment further. For now, we’re going to test this as-is.

If you were to try to run the same command, it will still fail, because we were trying to use the “short” name and letting DNS suffix search order handle things. That won’t fly here, we’ll now need to use the FQDN in order to connect:

We’re in! But, can we make the connection not rely on Trusted Hosts? Yes, with certificates! Let’s configure WinRM on the server side to accept connections over HTTPS over port 5986. I already have a PKI infrastructure in place (check out Chris Kibble‘s excellent series on PKI here: Standing up a Microsoft Certificate Authority for more guidance), and server authentication certificates enrolled on my servers for securing IIS and SQL, so let’s use that certificate for WinRM as well. Two birds stoned at once, right?

Configuring this isn’t straightforward; it will need to be scripted and deployed via a management tool such as ConfigMgr or Intune. The following is an example script that can configure it; this will need tweaking depending on the environment.

Next, we need to go back to our GPO and create a rule for inbound TCP 5986, as there’s no builtin rule for it.

Next, since I’m using an internal PKI, I need to configure trusted certificate profiles for the root and subordinate CAs in Intune, which is a straightforward configuration (see Configure and use PKCS certificates with Intune for further information). Finally, we’ll remove the Trusted Hosts configuration from the WinRM configuration profile we created earlier, and test things out. First, let’s try the short name again, but add the -UseSSL parameter.

Since the certificate issued to my server only contains the FQDN, name matching fails, and the connection fails. One more time, with the FQDN…

Success! This is a much more secure configuration, as the client is now able to establish a form of trust to validate the server it is connecting to. If a rogue device were to take over the DNS name, and present a certificate with the same name, but an issuer not trusted by the client, connections would fail. As I stated earlier, this methodology will work when connecting to either AD or Hybrid AD joined devices, because the authentication “source of truth” for both types is still AD at the end of the day. Now let’s complicate things further…

HAADJ -> AADJ WinRM

Doing the reverse of the above scenario is a bit trickier. Since we already know utilizing normal WinRM will fail due to Kerberos mutual authentication not being able to complete at the device level, we know we will need to use either Trusted Hosts or certificates.

I’m going to skip configuring Trusted Hosts here, as it is a similar configuration as before, with a caveat that also affects using certificates: DNS registration. Azure AD clients are NOT a member of an AD domain, and they should NOT be registering DNS records in the AD domain DNS zone. To solve this, I’m going to create a new DNS zone named aad.ajf.one and configure my AADJ clients to use that suffix and have records registered there via DHCP. Then, I’m going to use the Intune Certificate Connector to issue server authentication certificates to the AADJ clients via a PKCS profile. In a production environment, I’d most likely opt to use NDES and SCEP as it is a more secure configuration, at the expense of a bit more complexity.

I’ve created a new DNS zone on my domain controller and configured it to support both nonsecure and secure dynamic updates. This is necessary as the client will not be able to authenticate to AD to securely create records, which is another reason to create a new zone.

Next, I’ll configure the necessary DHCP and DNS settings to make registration work. For DHCP, I will configure option 15 on the reservation for an AAD client to aad.ajf.one. For DNS, I’ll use a configuration profile in Intune for a few settings.

After verifying the profile applied via Intune, I can release/renew DHCP on the AADJ client and confirm the DNS record is created.

We have a success! Note that I configured the DNS suffix search order as well; this is not strictly necessary for what we are configuring for WinRM, but it’s a good practice. Now, we need to deal with certificate enrollment.

I am already using PKCS to enroll a client authentication certificate, so I just need to set up a new template on my CA and configure a new PKCS profile in Intune and assign it to a group containing my AADJ device.

After syncing things up on the client side…

Another success! Now, we can use Intune to configure WinRM and a similar form of the script from part I to configure the WinRM HTTPS listener. This time, we’ll need the script to directly specify the domain name, and we’ll also have it enable and start the WinRM service. Finally, we’ll use a firewall rule profile in Intune to open port 5986.

Now, for the moment of truth. Will we be able to successfully connect to an AADJ client from an HAADJ client via WinRM? Well, no, not just yet. What credential do we use? Up to this point, we’ve been using AD credentials, since we were connecting to effectively AD hosts. A pure AADJ device doesn’t know how to use those credentials from a WinRM perspective. You can try all of the forms of username you want (like AzureAD\username@domain.tld for example) but it isn’t going to work. We need to use a local account to finish this off.

As for making that local account configuration, I leave that up to you. There are various community-based Cloud LAPS solutions out there (such as the one from the MSEndpointMgr folks), as well as LAPS coming soon to Azure AD, so I think this problem will be eventually solved. For my lab demo, I manually set the local Administrator account password and enabled the account.

Finally, the moment you’ve been waiting for:

Let’s walk through the above image:

1. Connected to an Azure AD joined client via WinRM over HTTPS, secured with a valid and trusted certificate issued via internal PKI.
2. Authenticated using the local Administrator account on the remote device.
3. Created a PS drive to connect to a share on a server, using an AD domain credential.
4. Browsed a file on said share.

Conclusion

• Is making WinRM into Azure AD joined devices possible? Yes
• Can it be done in a secure fashion. Yes
• Is it really necessary? No
• Is it really neat? Absolutely!

In the era of “modern management”, I am a firm believer that it’s time to start treating clients like cattle, the same that we [should] be doing for servers for a while now. Use configuration management platforms such as Intune or ConfigMgr (or both, co-management is great!). Create the policies, scripts, and deployments necessary to get your endpoints in the state you desire, and verify that configuration. These tools have features built-in to ensure that the configuration you specify is in fact configured, and can remediate as needed.

This was a fun experiment, and Johannes owes me a beer 🍺