This post demonstrates how to connect to your Azure AD tenant to enable legacy applications that rely on LDAP for authentication.
Before this announcement, the only way you could install an application in the Microsoft Azure cloud that required LDAP was to install a directory controller on a virtual network. For companies that have already a local AD infrastructure, creating a replica AD controller in Azure was not a big issue, but for any company that is cloud-only, this required not only to create a primary DC in Azure but also to enable Azure AD connect and reverse the source of authority. As a result, you could no longer manage users in the cloud.
If your business uses Microsoft services such as Office 365, Intune, Dynamics CRM Online, or you already created a directory in an Azure subscription, and you do not have a local AD infrastructure, then you would be managing a “cloud-only” tenant. See:
Before the release of Azure AD Domain Services, you had to do the following, and for a cloud-only organization some of these steps were difficult to implement:
· Create a subscription in Azure, define a virtual network in Azure, create a Virtual Machine and promote it to an AD controller, and configure the AD controller in Azure with the domain(s) that were used by these users.
· Use a PowerShell script to download from Azure AD tenant all users and groups hosted in Azure. Verify the data.
· Re-create manually (or writing/using a script to create) users and groups in the local/Azure-hosted AD controller. Verify the newly created users and groups.
· Note that when AD Connect is enabled the source of authority for users and groups will change from “managed in the cloud” to “managed on a directory controller”. As soon as the synchronization is enabled, users and groups can no longer be managed (created, updated or deleted) on the cloud portal. This step needs to be planned carefully as all admins typically utilize the Office 365 portal to manage users and will need to be retrained to now create/modify/delete users and groups on a Directory Controller. This is a big change for them.
· Install AD Connect on the Directory Controller
· Enable synchronization and watch for replication issues.
· Finally, plan for users to reset their passwords as the PS script to download users will not download any password from your AD tenant.
Azure AD Domain Services (in public preview) allows you to eliminate many of these steps. You can continue to manage all users and groups in the cloud and at the same time get a virtual Directory Controller in the cloud that you do not need to build or manage. You will be able to connect to that virtual Directory Controller in order to join Virtual Machines created in Azure or use LDAP services.
If you do not have yet a subscription in Azure, create one at
Ideally, the email address you should use to create this new subscription should be the UPN/email address of an Azure AD user (or even better a service account) that has the Global Admin role enabled in your AD tenant. See:
If you already have a subscription, you need to connect your AD tenant to that subscription. The steps will be slightly different if you created this Azure subscription with an organizational account or a Microsoft account but the general method is to log in your Azure subscription and…
· Click New -> App Services -> Active Directory -> Directory -> Custom Create.
· Under Directory, choose Use existing directory. We’re going to have to sign you out of the portal now, so choose I am ready to be signed out now.
· Sign back into the portal as a global admin of the directory you want to add. (If you weren’t already a global admin, you will be after a round of sign in and then sign out.)
· You’ll be asked when you sign in if you want to use your existing AD tenant with your subscription. Click Continue, and then click Sign out now.
· Sign back in again, and go back to Settings -> Subscriptions. Select your subscription, and then click Edit Directory. Select the Azure AD tenant that you want to use.
Now you should have the correct directory in your
A Virtual Network in Azure
Before we continue enabling Domain Services, note the following restrictions:
You can currently only enable AAD Domain Services with a classic Virtual Network. You cannot use a Virtual network that has been created with the Resource Manager deployment model. If you have an existing Virtual Network created with the Resource deployment model and you already have VMs deployed onto it, you will need to create a new classic Virtual Network and interconnect the two Virtual Networks. It is likely that this restriction will not exist when Azure AD Domain Services is in GA.
You will need to use a Virtual Network in Azure that was defined as a regional virtual network. You cannot use a virtual network that was defined with an affinity group. You will know if your existing virtual network was defined as a regional VN or an affinity group by downloading the Export configuration XML option (select your network and click on Export button at bottom of page) and searching for affinity group and/or region.
If you need to upgrade from a virtual network defined with an affinity group to a region VNET, use this page for guidance:
Currently, you can connect Azure AD Domain Services for your AD tenant to only ONE virtual network. If you have multiple subscriptions sharing the same AD tenant, you will need to interconnect your existing virtual networks to the virtual network that was selected when enabling Domain Services.
To do a VNET to VNET connection, see:
Your virtual machines must be hosted on a virtual network, even if you have only one virtual machine.
If you have not defined a Virtual Network in your subscription, create one using this page:
Enable Azure AD Domain Services
Note on step 1: After adding admin users to this group, you may need to wait approximately 20 minutes for the changes to take effect. Note that regular users (for example the ones who will be using the LDAP application) do not need to be added to this group. Do not select Microsoft Accounts that were added to your AD tenant. Only select users defined in that directory as organizational accounts. If the users you select do not have any admin role (even service administrator in your subscription will do), they will not suddenly become administrators, and as an example these users will not be able to use their credentials to join a Virtual Machine to the domain defined in Azure AD Domain Services.
Note on step 2: Define a subnet for the IP addresses that Azure AD Domain Services will generate, such as ADDNSSubnet and make sure you select this subnet when selecting the network in next step. You can choose which subnet to use. You can create an additional subnet for hosting your Virtual Machines such as FrontEndSubnet.
Note on step 3: Enabling DS can take up to 20 minutes. You will get a first IP address created in the subnet you defined in a previous step. It can take another 30 minutes to get the secondary IP address. You need those two IP addresses for the next step. If your subnet starts at 0, the two IP addresses will be x.x.x.4 and x.x.x.5.
Note on step 4: verify the IP addresses you enter. These are the two IP addresses listed under the Domain Services section in the Configure tab of your directory.
Note on step 5: Follow the “Cloud-only tenants – Enable NTLM and Kerberos credential hash generation in Azure AD”
After you click on the URL http://myapps.microsoft.com , make sure you select the correct directory at the top right corner if you have multiple directories listed in your subscription. This is a drop-down box and you can switch to the correct directory.
If you do not see the “Change password” tile, this means that you are signed in as a Microsoft account user. Sign out and sign in with an organizational account in that directory.
Note: If you are a cloud-only tenant, skip the rest of this page as you do not need to install or enable Azure AD Connect.
Create/Re-use a Virtual Machine
You can now create or use an existing Virtual Machine on the virtual network selected in step 2 above. We selected the Windows Server Datacenter 2012 R2 image.
Ideally, your Virtual Machine should be on a different subnet than the one defined for Azure AD Domain Services. We hosted this new VM on the FrontEndSubnet subnet.
Log onto this Virtual Machine using RDP.
Manually join this machine to your domain. Type Windows Key – X on the Virtual Machine and select System. In the “Computer name, domain, and workgroup settings” section, click on Change Settings. In Computer Name tab, click on Change. Select Member of Domain and enter the domain defined when enabling Domain Services. You will be asked to authenticate. Type the credentials of a global admin in your directory – presumably the same one you entered in the AAD DC Administrators group and for which you reset the password. After rebooting, your Virtual Machine will be joined to the domain.
Note: domain\user seems to work better than user@domain when being prompted for credentials after joining the domain.
On this Virtual Machine, verify that the Group Policy Management feature is installed and install it if it is not present. It will not be installed by default on a new Virtual machine.
Install the AD DS and AD LDS Tools feature. Do NOT install the Active Directory Domain Services server role! Click Next and add the feature located under Remote Server Administration Tools – Role Administration Tools – AD DS and AD LDS Tools – AD DS Tools.
Selecting Active Directory Administrative Center will automatically select AD DS Snap-ins and Command-Line. Click Next and Install.
Reboot Virtual Machine
The server does not need to be rebooted for these two installations but you will want to log out and log in using an admin user that was added to the AAD DC Administrators group. If you are unable to log in, wait at least 20 minutes after AAD Domain Services was enabled and retry.
Under Server Manager – Tools, select Active Directory Users and Computers. Under your domain, you will see new OUs:
Locate the AAD DC Administrators group.
Note: do not attempt to add members from the server (or create users or reset passwords, …). All changes must be made from the cloud portal (http://myapps.microsoft.com) or in the directory in your Azure subscription. The changes will then be synched and you can verify changes by opening this group. Allow 20 minutes for sync to complete. Remember also to expire passwords – once – after DS is enabled for anybody logging on to this server.
You can also verify that the Virtual Machine you are logged on was added to the AADDC Computers OU (You can create manually entries for computers/servers if needed). Under AADDC Users, you should see all the users in your directory, including the Microsoft accounts that were added to this directory.
Under Servers – Tools, select Group Policy Management and you can view the two GPOs that were added under domain – Group Policy Objects:
AADDC Computers GPO
AADDC Users GPO
Verify that LDAP services are available.
AD LDS installed a number of tools, including LDP.exe. You can launch LDP.EXE either from the Server Manager or from the Windows command line. From LDP.EXE, you’ll first want to connect to the LDAP server. From the Connection menu, select Connect. The connection screen will prompt for the LDAP server hostname and port number:
Enter the first IP address generated when enabling Domain Services in step 2.
If you successfully connect, look at the output and locate the entry named “dnsHostName”. You can ping this DNS name.
Locate in the output the line named “rootDomainNamingContext” and append this line to the DNS Name entry.
If you specified (when enabling Azure AD Domain Services) an AD tenant domain such as “mytestdomain1.onmicrosoft.com”, your LDAP_SERVER will look like this:
Under Connection, Disconnect and Connect. Enter second IP address to get your secondary LDAP server setting.
You can now test authentication. From the Connection menu, select Bind. Select Simple Bind and enter the user name and password. Make sure the user name is the complete UPN with domain name. Check also that the domain name of this user’s UPN matches the “DNS domain name of Domain Services” defined in step 7 in page: “Enable Azure AD Domain Services”.
If you are not successful, make sure the password for this user (or service account) was reset after Domain Services was enabled.
For additional examples on how to use LDP.exe, see:
After you install your LDAP application on the Virtual Machine, enter the LDAP_SERVER in the settings and test authentication. If you get authentication failures, make sure the password for this user was reset once after Domain Services was enabled on this AD tenant and try again.
Note: you cannot use a Microsoft account added to the directory to authenticate. You will get an invalid token error.
When this post was created, Azure AD Domain Services was still in Public Preview. Some features may be added when it becomes General Availability.