This post has been republished via RSS; it originally appeared at: ITOps Talk Blog articles.
If you've created a Windows Server virtual machine in Azure and are joining it to an Azure AD Domain Services managed domain or logging onto it via RDP, there are a couple of errors you can hit. Let's look at the error messages and possible causes.
Problem: You're trying to add your Windows Server VM to your Azure AD DS domain (by changing it from the current Workgroup). This prompts you for user credentials for the domain, requiring a user account that exists in Azure AD (which syncs to your AADDS domain). When you provide the credentials of a new "native" Azure AD user (not synced from an existing Active Directory environment), you get the error "The referenced account is currently locked and may not be logged on to."
You've checked the user account in Azure Active Directory and it is not locked out.
Possible causes: Azure Active Directory doesn't generate the required password hashes needed by AAD DS for Kerberos and NTLM authentication until AAD DS has been enabled in your tenant. Up until that point, those hash types aren't ever needed. Once AAD DS has been enabled, the password hashes are created the next time your AAD native users change their password. This then needs approximately 20 minutes to sync from AAD to AAD DS.
Note: This doesn't impact users synced from existing on-premises Active Directory domains, as they already use those authentication methods and Azure AD Connect synchronizes those hashes from the on-prem domain into AAD DS.
The solution is to get the user to log in to their Azure AD account, change their password, and wait for the sync to complete. The "account lock out" error can make you scratch your head, but give it a password reset and a little time, then try again later.
For more information, see Enable user accounts for Azure AD DS
Problem: A user that exists in Azure AD is trying to log on to an Azure AD DS domain joined Windows Server VM in Azure via a Remote Desktop Session, and they're getting the error "the connection was denied because the user account is not authorized for remote login."
Cause: A Windows Server VM on Azure is still a Windows Server, and it can be easy to get tied up among all the different places that you manage security and permissions. If you've checked the Azure VM's Identity and Access Management pane for a relevant virtual machine login role assignment (administrator or user) and you are still getting this error, the words "remote login" are your hint here. Inside the server operating system, the local server system properties has a section called Remote, which controls if connections via RDP are allowed and who is allowed to initiate them. If 'Allow remote connections to this computer' is selected, by default members of the Administrators group can connect, but nobody else.
This screenshot shows I've added an individual user from my AAD DS domain, and they can now log in, but a better solution is to add an AAD DS Group, and manage the membership of that group in Azure Active Directory.
Note: When you join an Azure Windows Server VM to an AAD DS domain, two domain groups are automatically added to the local Administrators group on the server - AAD DC Administrators and Domain Admins. The AAD DC Administrators group is visible to you inside Azure Active Directory. People that you add to this group will have access to both administer the server and to log on to it via Remote Desktop. Also, these RDP login rights are separate from any network level configuration that may restrict access between the user's device and the server's RDP port, including their local network and the server's Azure network security group.
Learn more about Azure AD Domain Services:
Frequently asked questions about Azure Active Directory Domain Services