Domain Joining Windows Azure roles

Windows Azure Connect supports domain joining Windows Azure role instances (i.e. the Virtual Machines on which your role runs) to an on-premises Active Directory. This opens up many scenarios such as logging in to Windows Azure role instances using domain accounts, connecting to an on-premises SQL server using Windows Integrated Auth, and migrating Line of Business (LOB) applications to the cloud that assume a domain-joined environment. This blog post provides a step-by-step walk through of how to domain join Windows Azure roles using Windows Azure Connect.

0. If you are new to Windows Azure Connect and haven’t used it before, please read this tutorial to learn the basics about Connect.

1. First you need to prepare your domain for Connect.

a) In the current CTP release, Connect requires a domain controller with an AD-integrated DNS server running on the same machine

b) The DNS server should be configured to listen on all IP address. You can verify this by going to DNS Manager, right click on your server -> Properties, as shown in the below dialog.


c) We recommend you create a separate Organization Unit (OU) in Active Directory for your Windows Azure Role instances so that they can be easily managed. This step is optional, if you don’t specify an OU in the Connect plug-in settings, Azure Role instances will join the default computers container in AD.

d) In the Connect plug-in settings, you will need to specify a domain user account with permission to join machines to the domain and (optionally) the OU described above.

e) You will need to encrypt the password for this user account.

  • Start the Visual Studio Command Prompt as Administrator


  • Create a certificate by typing the following command, provide your own CN value and certificate file name in the highlighted area.

makecert -sky exchange -r -n "CN=MyEncryptionCert" -pe -a sha1 -len 2048 -ss My -sr localMachine "MyEncryptionCert.cer"

  • After creating the certificate, you will need to export it. Open mmc snap-in for certificates -> Computer Account -> Personal -> Certificates. Find the certificate you just created, right click on the certificate -> All tasks -> Export -> Check Export private key -> enter a password -> follow through the wizard


  • Sign in to the Windows Azure portal, click on “Hosted Services, Storage account and CDN” on the left side, then select the “Hosted Services (n)” node. Under your Azure subscription, select the Azure service you are working on, select “Certificates”, then click “Add Certificate” on the tool bar. In the pop-up, select the certificate you just exported, provide the password for the certificate, and click on “Create”.


  • In Visual Studio, go to the Property page of the Role you are domain joining. Click the “Certificate” tab, then “Add Certificate”. Select “LocalMachine” as the Store Location, and “My” as Store Name, and choose the certificate you created in the previous step.


  • Now that you have prepared a certificate for encrypting your domain password, the next step is to actually encrypt it. Open notepad.exe, copy the script below into the notepad, change my_password (highlighted below) to the password you want to use.
$password = "


$certs = dir cert:\LocalMachine\My
[System.Reflection.Assembly]::LoadWithPartialName("System.Security") | Out-Null
$collection = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2Collection
$certs | ForEach-Object { $collection.Add($_) } | Out-Null
$cert = [System.Security.Cryptography.x509Certificates.X509Certificate2UI]::SelectFromCollection($collection, "", "Select a certifciate", 0)
$thumbprint = $cert[0].thumbprint
$pass = [Text.Encoding]::UTF8.GetBytes($password)
$content = new-object Security.Cryptography.Pkcs.ContentInfo -argumentList (,$pass)
$env = new-object Security.Cryptography.Pkcs.EnvelopedCms $content
$env.Encrypt((new-object System.Security.Cryptography.Pkcs.CmsRecipient(gi cert:\LocalMachine\My\$thumbprint)))
write-host "Writing encrypted password, cut/paste the text below the line to CSCFG file"
[Convert]::ToBase64String($env.Encode()) | Out-File .\encrypted_password.txt
Invoke-Item ".\encrypted_password.txt"
  • Launch a Windows Powershell console, copy and paste the modified script to the Powershell window and run it. Choose the certificate you just created when prompted. This script will output your encrypted password, for example:


You will use the encrypted password in the next step.

2. Next you need to enable your Windows Azure role for Connect (see steps listed in this tutorial) and configure it for domain-joining, by providing the domain join settings in your ServiceConfiguration.cscfg file. These settings are listed below.





<Setting name="Microsoft.WindowsAzure.Plugins.Connect.EnableDomainJoin" value="true" />

Set “EnableDomainJoin” to true if you would like domain join Windows Azure role instances to on-premise AD.


<Setting name="Microsoft.WindowsAzure.Plugins.Connect.DomainFQDN" value="" />

Set “DomainFQDN” to the fully qualified domain name of which your role instances need to join (see highlighted example).


<Setting name="Microsoft.WindowsAzure.Plugins.Connect.DomainControllerFQDN" value="" />

Optionally, you can set “DomainControllerFQDN” to the fully qualified domain name of the domain controller (see highlighted example).


<Setting name="Microsoft.WindowsAzure.Plugins.Connect.DomainAccountName" value="corp\testuser" />

Set “DomainAccountName” to the domain account that has permission to domain join Windows Azure role instances (see highlighted example).


<Setting name="Microsoft.WindowsAzure.Plugins.Connect.DomainPassword" value="MIIBFwYJKoZIhvcNAQcDoIIBCDCCAQQCAQAxgckwgcYCAQAwLzAbMRkwFwYDVQQDExBNeUVuY3J5cHRpb25DZXJ0AhCTEsiJ0zzrjktvASTLQh7qMA0GCSqGSIb3DQEBAQUABIGABGQW6efUv3fpewvgCcqxqfzJu5gmlUqXPg60aggvDeBYwyPL6xVqZ9DZYiYxbBmHSjJgzrIrLY+rP3EMtV/8G4f6hvyewasWvJgMe2vzwcMGSKqixcIRnCLuLov7zLgCsYylzZ1h4j/SIf0gUBtwC1leW4C07z+KtQb8fdDbi5wwMwYJKoZIhvcNAQcBMBQGCCqGSIb3DQMHBAiyEoiHBP8V8YAQ2PN+j2uY07qpS93N15uQkA==" />

Set “DomainPassword” to the encrypted password you got in previous step (see highlighted example).


<Setting name="Microsoft.WindowsAzure.Plugins.Connect.DNSServers" value="" />

Set “DNSServers” to the fully qualified domain name of the domain controller (see highlighted example).


<Setting name="Microsoft.WindowsAzure.Plugins.Connect.DomainOU" value="OU=AzureMachines,DC=corp,DC=contoso,DC=com" />

Optionally, you can specify an OU container for your Azure role instances to join (see highlighted example).


<Setting name="Microsoft.WindowsAzure.Plugins.Connect.Administrators" value="corp\user1, corp\group1" />

Optionally, you can specify existing on-premise AD users and groups (as a comma separated list) to add to the local Administrators group for your Azure role instances (see highlighted example).


<Setting name="Microsoft.WindowsAzure.Plugins.Connect.DomainSiteName" value="" />

Reserved for future use. Leave the value as an empty string.


Now that your Windows Azure roles is enabled for domain join, you can deploy it to Windows Azure. Once your Windows Azure role is successfully deployed and they are running in a “Ready” state, you should be able to see the role instances in the Connect portal (To enter the Connect portal, click the “Virtual Network” tab in the Azure portal, and then select the Windows Azure subscription that you want to use for Connect)

3. Next install the Connect endpoint software on the Domain Controller (see steps listed in this tutorial if this is new to you).

4. Using the Connect portal, create a local machine group, which is connected to the Windows Azure Roles that you wish to domain join and has the Domain Controller as a member (see steps listed in this tutorial if this is new to you).

Once the “connection” is created between the Windows Azure role and the local group with the Domain Controller, within a few minutes you should see that the Windows Azure role instances are domain joined. You can tell if this has happened because the role instance names in the Connect portal will have domain suffixes (e.g.


You should also see that the Windows Azure instances have been added as new computers in your Active Directory. In the screenshot below the Windows Azure instances were configured to join an OU “AzureMachines” in Active Directory.


You can verify that your role instances are actually domain-joined. For example, using the Remote Access feature in the Windows Azure portal, you can log into a role instance using a domain user account that was added to the Administrators group for your role. You can then view Computer Properties to confirm that the role instance is indeed domain-joined, as shown in the screenshot below.


Note: if you configured  Active Directory to apply Group Policy to your domain-joined Windows Azure instances, please make sure that the Group Policy does not configure a proxy server that is not reachable by Windows Azure.   This will ensure that your domain-joined role instances continue to work with Windows Azure Connect; otherwise they may lose connectivity.

--Jason Chen

Comments (7)

Cancel reply

  1. Kalyan says:

    Powerful feature. In this scenario, can a Windows AD user connect to a intranet web site (that only accepts windows authentication) hosted on this role using their AD credentials.

    Or is it still mandatory to use ADFS 2.0?


  2. Pavel Slavov says:

    great post. thank you very much. it was difficult to achive Connect configuration before the post, but now it includes some crucial shortcuts which will be very useful

  3. Windows Azure Connect Team says:

    @Kalyan: You can use the AD domain-join capability of Windows Azure Connect to configure your web role to use Windows integrated authentication – this particular scenario does not require use of ADFS.  ADFS does enable a number of other scenarios and could also be used to enable single sign-for users using their AD credentials.

  4. tomchris says:

    When putting in your password, if you use any special characters, be sure to escape them.  Here is information about escaping characters:…/dd347662.aspx

    For example, myPass"w0rd should be myPass`"w0rd using the backtick (`).

  5. says:

    Very helpful post, thank you. I have tried and tested the domain joining successfully, with an independent test domain on a single DC. AD itself holds the functional level of "Windows Server 2008 R2".

    However, our dev domain still has the functional level, "Windows Server 2003". We have one DC (in dev domain) that is a 2008 R2 server. I have installed Connect endpoint on this DC and added it to the group in virtual network. Endpoint successfully works. However Azure VM does not join the domain join and seems like waiting forever, saying "The process 'AzureAgentIntegrator.exe' has changed the state of the instance to "Busy"" in Status. I can login to the VM using a local account, and i can also browse the shared folders of the DC from VM (with AD credentials), but if i try to manually join the VM to domain it fails to find the same DC.

    I was suspecting could it be because of the functional level of domain? Does anybody have a clue ?

  6. Ujwal says:

    Helpful post..

    I am using VM role and have machine with my own VHD. Next I am trying to join corp net from that machine.. but its unable to find domain in  AD controller. Am I missing something..?? Is it possible to join corp net on machine on azure..

    Appreciate for you information

  7. Saravana says:

    As windows azure connect has been retired from portal(7/3/2013). this blog wont help me for adding azure role domain to onpremises domain. Please let me know how can we add the azure role(web/worker) in to virtual network & on premises domain. or suggest me any helpful link like this blog.

Skip to main content