Azure Stack: Using Azure Active Directory Domain Services for Azure Stack VM’s Authentication and Identity.

Unofficially this would be my next blog in my series about Deploying A Highly Available App Service Solution Series.  However, I also wanted to blog about my experience with using Azure’s AD Domain Services to satisfy our identity needs with Azure Stack based VM’s.  This would allow us not to deploy an entire Active Directory infrastructure within Azure Stack for our App Service Resource Provider infrastructure.

So, let’s talk about Azure AD Domain Services and how I plan to possibly use it for my Azure Stack Highly available deployment of the App Service Resource Provider.  At a high level, I am building out various solutions for our future clients around Azure Stack.  One of my projects is to make sure that everything we deploy like Azure Stack’s App Service RP and other Resource Providers are deployed in an highly available solution.  One of our scenarios is to deploy the supporting infrastructure on external host. With this scenario, the needed authentication and identity will be provided by the customers on-premises active directory.  The Fail over clusters and SQL servers will be joined to their existing Active Directory environment and use service accounts created within that domain.   However, another solution we are testing is to deploy those same clusters built on Azure Stack IaaS VM’s.  Which brings into question how will we provide authentication and identity to these VM’s and service accounts needed for the Windows Fail over Cluster, etc.

There are a few thoughts to how this could happen but one of them would be to build out a completely separate and standalone Active Directory infrastructure within the Default Provider Subscription that will only be used by the App Service back-end infrastructure.  This solution is something I have been working on and have deployed and we had been headed that direction until I stared researching Azure AD Domain Services.

This blog will focus on how to make it possible to authenticate against an Azure AD Domain from within Azure Stack.  To be fair, I have only started to use Azure AD Domain Services very recently and I truly hope what I am blogging about is actually best practice or at least something that can be recommended as a solution. I don’t have the cost for this solution so that may be something someone should look at before going this route.

There are a few steps to this process.  I would highly recommend having a more detailed plan together before deploying this in a production environment.  For instance, the naming of the virtual networks, Site to Site VPN planning, subnet planning, resource groups, IP ranges, etc.

Connect Azure Stack to Azure Using a Site-to-site VPN

The first thing we want to do is setup our Site-to-site VPN connection between Azure and Azure Stack.  For a good reference you can look at the Microsoft Docs website.

https://docs.microsoft.com/en-us/azure/azure-stack/azure-stack-connect-vpn

Here is the high level information I will be using as we move forward:

DFW_Azs-Azure-S2S

Azure Stack

Azure

Resource Group

Azs.dfw.infrastructure

Azs-dfw-infrastructure

Virtual network name

Azs-DFW-vNet

Azure-DFW-vNet

Virtual network address space

10.1.0.0/16

10.100.0.0/16

Subnet name

FrontEnd

DomainServices

Subnet address range

10.1.0.0/24

10.100.0.0/24

Gateway subnet

10.1.1.0/24

10.100.1.0/24

Create Resource Group

The first thing I did was create the resource groups in both Azure and Azure stack.  For Azure, make sure the region you are going to have your virtual network created also has the Active Directory Domain Services available.  I do not think it is available in every region at this time.  I could be wrong, it happens more than I would admit.

Lessons Learned:  I created everything in West Central US.  However, when I got to the point to create VM’s within my vNet that I created I was not able to create VM’s within that Region.  I got errors that my subscription was not allowed to create VM’s in West Center US.  So I had to recreate everything in South Central US.

Create Virtual Network and Gateway Subnet

I have combined the Azure and Azure Steps together in my blog.  There is a point where you can’t move forward with Azure Stack configurations until you have gone to a certain point with the Azure configurations.  Then again, you will need to make sure you complete the last steps in the Azure Stack configurations before you can complete the Azure configurations.  Confusing?  I will point what steps are as we go forward.

First, let’s create the virtual network for both Azure and Azure Stack.

  1. Go to your resource group and click Add  in the overview blade.  You can also go to the Marketplace as well.
  2. Search for Virtual Network, select it, click create.
  3. Fill in the information needed and select our resource group we created.
  4. For Azure, select the location, which we selected West Central US.  For Azure Stack it will be defaulted to the local region you created when deploying the stamp.
  5. Click Create and wait or a few minutes.

azurevnetsettings

Now after the virtual network has been created we are going to create our Gateway subnet.  We will leave the default name of GatewaySubnet for both Azure and Azure Stack.

  1. Click on the newly created virtual network.
  2. Within the Setting section click on Subnets.
  3. Click on the + Gateway Subnet toward the top of that blade.
  4. For the Azure Stack address range I made sure it was 10.1.1.0/24 and clicked OK. For the Azure address range I made sure it was 10.100.1.0/24 and clicked OK.

addAzureGatewaySubnet

Now both virtual networks should have two subnets.  I will add another subnet for my management VM’s for use later.  At this point we should be ready to move forward.  On the Azure Stack side I will be adding a few others in order to support my App Service infrastructure deployment.

azuresubnetview

Create the Virtual Network Gateway

Now let us create the virtual network gateways for both Azure and Azure Stack.

For Azure this is the information I will be using:

Azure

Gateway Name

Azure-AZS-GW

Gateway Type

VPN

VPN Type

Route Based

SKU

VpnGw1

Public IP Address Name

Azure-GW-DfW-PIP

Location

West Central US

  1. Click on add in the resource group or go to the marketplace directly.
  2. Search for Virtual Network Gateway and select it, then click Create.
  3. Fill in the information needed such as the name etc.
  4. Once finished click Create

azurevirtualgateway

Note:  It will take time for the provision of the public IP address.

For more information on the Azure VPN Gateway SKU’s here is a link:

https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-about-vpngateways#gwsku

For Azure Stack this is the information I will be using:

Azure Stack

Gateway Name

AzS-DFW-GW

SKU

High Performance

Public IP Address Name

Azs-DFW-GW-PIP

  1. Click on add in the resource group or go to the marketplace directly.
  2. Search for Virtual Network Gateway and select it, then click Create.
  3. Fill in the information needed such as the name etc.
  4. Depending on the SKU you are using the section for the IP will be named differently.  I used High performance so the section I create the Public IP is called First IP configuration.  Click on that and click New, then name the public IP.
  5. Once finished click Create

Note:  The actual Deployment process takes less than a few minutes.  However, The public IP will not be available until after you create the Connection object.

 

Create the local network gateway resource

We now should have three objects in our resource group.  The Virtual network gateway, the public IP address, and the Virtual Network.  Now I will create the local network gateway in both Azure and Azure Stack.

azurergview01

When you create the Azure virtual network gateway the public IP address is provisioned as soon as you create that resource.  However, in Azure Stack that IP address isn’t created and linked to the virtual network gateway until you create the connection.  So at this point you can’t create the local network gateway in Azure until you have created the local network gateway in Azure Stack and the Connection in order to get the needed public IP address.

Here is the information I will be using:

Azure Stack

Azure

Local Gateway Name

Azure-dfw-local-gw

Azs-dfw-local-gw

Public IP Address

xxx

xxx

Address Space

10.100.0.0/24, 10.100.1.0/24

10.1.0.0/24, 10.1.1.0/24

Location

DFW

West Central US

  1. Click on add in the resource group or go to the marketplace directly.
  2. Search for Local Network Gateway and select it, then click Create.
  3. Enter the information in the proper fields.
  4. Click Create

azurelocalgw

Create the connection

Now we can create the connection between the two local gateways. Once again, please make sure you have created these steps on Azure Stack first in order to get the public IP address needed to complete the this step and the last step in Azure Cloud.

Here is the information that I will use to create the connections:

Azure Stack Azure
Connection Type Site-to-Stie (Ipsec) Site-to-Site (Ipsec)
Location DFW West Central US
Virtual network Gateway Azs-DFW-GW Azure-AzS-GW
Local network Gateway Azure-DFW-Local-GW AzS-DFW-Local-GW
Connection Name Azs-DFW-GW-Azure-DFW-Local-GW Azure-AzS-GW-AzS-DFW-Local-GW
Shared key (PSK) 54321abc 54321abc
  1. Click on add in the resource group or go to the marketplace directly.
  2. Search for Connection and select it, then click Create.
  3. Under Basic Settings select the Connection type:
    In Azure Stack there is only one option.  In Azure you will have 3 options. Make sure you select Site-to-site (IPsec) for both.
  4. Click OK
  5. Under Settings select your Virtual Network Gateway and Local Network Gateway.
  6. Create a Connection name or keep what was presented.
  7. Create a Shared Key that will be used for both connections
  8. Click Create

Test Connectivity

There are a few different ways you can test connectivity.  The first is within the portal by clicking on the actual connection resource.  Under the Overview section you should see a Status of Connected.

connected

I created another subnet on my Virtual Network that I am going to place my management vm’s in on both Azure and Azure Stack.  That subnet network for Azure is  10.100.2.0/24 and for Azure Stack is 10.1.2.0/24.  I also had to add these to the local network gateway configuration as well.  Then I created a VM that I will use for management tools within this Subnet on both Azure an Azure Stack.    Once created I  ran the following script to allow ICMP request.

New-NetFirewallRule  –DisplayName “Allow ICMPv4-In”  –Protocol ICMPv4

From my VM in Azure Stack I am able to ping my server in Azure.

azshostpingtoazure

From my VM in Azure I am able to ping my server in Azure Stack.

azurehostpingtoazs

Now you have connectivity between Azure and Azure Stack we are ready to move forward with creating our Azure Active Directory Domain Services in order to join our Azure Stack VM’s to a domain.

 

 

Configure Azure Active Directory Domain Services

Working with Azure AD Domain Services has actually been pretty easy so far.  From my perspective the hardest part was waiting for the service to be provisioned.  That will take some time so be prepared to wait for a long time.  My environment is going to be setup in a cloud-only organization.  Which basically means this environment will not be syncing an on-premise Active Directory to Azure Active Directory and all identities only reside in the cloud.  More information can be found online at the Microsoft Docs location.  It is a great resource to read more about this service, find out if it is right for you, and read more about the different ways to deploy Azure AD Directory Services to your organization.

https://docs.microsoft.com/en-us/azure/active-directory-domain-services/active-directory-ds-overview

 

Enable Azure Active Directory Domain Services

There are a few things you must make sure you have handy.  First make sure you have a valid Azure Subscription.  Make sure you have an Azure AD directory.  In my case it is a cloud only directory but if I had decided to integrate with my on-premises AD we would need to make sure it was synchronized with AAD.  The Azure Subscription we are using must be associated with the Azure AD directory we are going to use.  Also, I need to have access to a global administrator account.

For the first task we are going to Enable Azure AD Domain Services.

  1. Within the Azure Portal search for Domain Services.  Once you find Azure AD Domain Services click on that.adds01
  2. Configure the basic settings.adds02
  3. Select the proper virtual networkadds03
  4. Configure the Administrator group.  For now I will add the required groups and users after it has been deployed.adds04
  5. Click on OK on the summary to start creating your Domain Services.  The deployment will take some time.  So go get some coffee and a donut or two and enjoy the view from your office window if you have one.adds05

    adds06

 

Update DNS Settings for the Azure and Azure Stack Virtual Network

After the new service is successfully deployed you we will need to do some required configuration steps.  First we need to Update DNS server settings for both are virtual network in Azure and our virtual network in Azure Stack.  The update process is automatic in Azure by clicking on the configure button on the overview screen within the Domain Services window.

adds-configure01

For Azure Stack, click on the virtual network we created earlier.  Click on DNS servers, then change the DNS servers from Default (Azure-provided) to Custom.  Since I designated my first subnet 10.100.0.0/24 for Domain Services, our Domain controllers should now be 10.100.0.4 and 10.100.0.5.  Add those as our custom DNS servers.

azsdnschange

Note:  Once the DNS settings have been changed you will need to restart any VM’s in that virtual network in order for the new DNS settings to take effect. 

Enable Password Hash Synchronization

The last step is to enable password hash synchronization to Azure Active Directory Domain Services.  This will need to be done on all existing accounts in order to authenticate using the new domain services.  There are different steps needed based on how your organization is setup.  If you only have cloud-only user accounts like I do then the steps are different compared to if you are syncing identities from your on-premise directory using Azure AD Connect.

https://docs.microsoft.com/en-us/azure/active-directory-domain-services/active-directory-ds-getting-started-password-sync

  1. Log on to the Azure AD Access Panel as the user that you want to enable NTLM and Keberos password hash.  (This is for cloud-only user accounts)
  2. In the top right corner click on the name and select profile.
  3. In the profile window, click change password.
  4. Change the password and click Submit.

changepassword

testadminprofle

testadminproflechangepass

In my experience you will need to wait for a while before this account is ready to authenticate against the Domain Services.  I would wait for at least 30 mins before trying to join computes to the new domain.

We now have a fully functional Azure Active Directory Domain Services up and running.   The next steps would be to build a management server to manage your new domain and to start adding VM’s to your new Azure AD Domain Services.

 

Adding Azure and Azure Stack VM’s to Domain Services.

Adding Azure and Azure VM’s to Azure AD DS is not any different than adding a VM or physical host to an existing on-premises domain.

For the Azure VM that was created early they will need to be rebooted in order to get the new DNS settings.  Then you should be able to  add the machine to the domain like normal.  For the Azure Stack VM, you will need to stop any VM’s in that virtual network.  A restart doesn’t seem to get the new DNS settings.  However, once I stopped and started the VM within the portal the VM now has the DNS settings.

I have joined my Azure VM using the GUI like I would any other server.

addtodomainaddtodomain01

 

 

 

 

Now we can log back on to this server using our domain credentials.

 

Here is my results when I joined my Azure Stack VM to the domain.

azurestackjoindomain

At this point you now have Azure VM’s and Azure Stack VM’s authenticating on the newly created Azure Active Directory Domain Services deployed in Azure.

 

Final Thoughts

My brain hurts.  That is all I have to say so far.  This is just the beginning of my journey with deploying highly available Azure Stack solutions.  I still have so much more to learn about Azure technologies.  I know that as I grow in my knowledge I will probably look back at this deployment and shake my head. For now, this seems to be a valid solution for our Azure Stack authentication and Identity needs.  Time will tell?

 

Deploying A Highly Available App Service Solution Series:

Azure Stack: Deploying A Highly Available App Service Solution Series

Azure Stack: Highly Available App Service Solution – Part II – Did I just start eating an elephant?

 

Tagged with: , , , , ,
Posted in Active Directory Domain Services, App Services, Azure, Azure Stack, Uncategorized

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Follow Kristopher Jon Turner on WordPress.com
Categories
Archives
Follow me on Twitter
%d bloggers like this: