Connecting to an Azure AD joined machine with an Azure AD user account over Remote Desktop

Windows 10 introduces the ability to join a computer to the cloud directory service Azure AD. This is very similar to the traditional domain join, where you join a computer to an Active Directory domain, run on-premises by one or more Domain Controllers. Both operations lets the computer operate within a common security context and benefit from Single Sign-On (SSO) to all resources that share the same security context. However, joining Azure AD instead of a traditional domain can break things or make them more difficult. There are many examples of this, but the one I want to discuss here is connecting with Remote Desktop (RDP) to an Azure AD joined computer with a user account from Azure AD. Just to be clear; the connection we want to establish is to an Azure AD joined computer, logging on with an account from Azure AD. This account can either be synced from on-premises or be mastered in the cloud, and both federated and password logons are supported. We do not depend on any local accounts on the computer, using tricks such as adding an Azure AD work account to a local account or a Microsoft Account (MSA), this is pure Azure AD.

Connecting Successfully

There are some obvious prerequisites for this to work:

The computer must be joined to Azure AD

Remote Desktop connections must be enabled and allowed through the host firewall

Any other firewall between you and the computer must allow the Remote Desktop protocol

The key to connecting is having Windows 10 present an desktop login screen:

That means that we must disable any form of single sign-on or integrated authentication. This requires the following steps:

On the Windows 10 computer; disable Network Level Authentication (NLA) for Remote Desktop Connections
Open System Properties and navigate to the Remote tab. Under Remote Desktop; make sure Allow remote connections to this computer is enabled, and that Allow connections only from computers running Remote Desktop with Network Level Authentication is unchecked.This will disable the ability on the host to require that authentication happens before a user session is created.

On the computer you are connecting from create an RDP file and add the following settings to it:enablecredsspsupport:i:0authentication level:i:2
Again, these settings disables sending any credentials automatically to the host computer. Leaving Windows with no choice but to display a desktop logon screen. The easiest way to create an RDP file is to open the remote desktop client, enter the name or IP of the computer you want to connect to and then his Save As. This will produce an RDP file that you can add/edit the necessary settings in. For those interested, most of the settings you can specify in an RDP file are listed here. In theory you could also add these settings on the command line, but I have not worked that out.

The last trick to make this work involves the username you specify on the logon screen. It must be in the following format:

AzureAD\<full UPN in Azure AD>

e.g. AzureAD\morgan.simonsen@langskip.no

This is a non-intuitive format for those of us who have connected to Windows over RDP in the past, but it is what works. I have not been able to connect with any other combination of domain, username, DNS domain or UPN, but this may very well change soon.

UPDATE 2015-11-7: On Windows 10 build 10586 the AzureAD prefix is no longer needed. You can just use your UPN.

Closing remarks

When you are joined to Azure AD we are naturally also authenticating against Azure AD, but it might be that you have federated Azure AD against an ADFS server, in which case authentications are redirected back to on-premises. Depending on your setup for authentication you will see the following differences:

Azure AD authenticated users will display the logged on user as: AzureAD\<concatenated display name>. Federated tenants will display the logged on user as <on-premises NetBIOS domain name>\<on-premises sAMAccountName>. This difference is visible if you use the whoami utility or look at the environment variables. Just to be clear, these differences do not have anything to do with remote desktop connections, they are just a consequence of joining Azure AD.

Connecting with a local account to a Windows 10 computer joined to Azure AD would as it does for any other Windows computer.

This is probably not how Microsoft would like us to connect to Azure AD joined machines so we can expect NLA authenticated connections to work some time in the future.

Hi – I have a funny scenario RDP’ing from a AAD joined Win10 pro machine to a non-AAD RDS server (AD joined, and hosted in Azure, but joined to a standard ‘on-premises’ domain). AD is synced using AD connect from ‘on-premises’ to Azure. No ADFS. Win 10 joined to AAD by user using OOBE (fantastically slick!)

When opening MSTSC the default username is always AD_NETBIOS\UPN and there seems to be nothing I can do to change this. Creating custom RDP file and saving creds works for one connection, then all subsequent connections revert to AD_NETBIOS\UPN. The RDS server (and ‘on-premises’ DC it auth’s to) won’t auth the user like that. Works fine with just UPN or AD_NETBIOS\SAMaccountname.

Thanks for this help. Unchecking the NLA box on the host and deleting any stored credentials in RDP was all it took to connect to an AAD Win10 (10586 build 318) box from the current version of RDP for Mac. As you said, no “AzureAD\” prefix needed.