Dealing with legacy applications that use Kerberos to authenticate users can be complicated. Kerberos, in the Windows ecosystem, involves Active Directory. Servers require to be joined to a domain. You will have to install and configure one or more domain controllers. You will have to open multiple ports from and to theses domain controllers and monitor them.
When a user requests a web application that use Kerberos on a web server, the server will respond with a challenge. But instead of requesting directly a username and a password, the server will require the client to have a ticket for the service from a domain controller. The client comes back to the server with the ticket and lastly, after the verification of the service to the domain controller the client access the web page.
This is perfect for a corporate network but for a web-based or cloud application, it's a security nightmare, even if the process takes place on another computer. You will have to make sure to open a lot of ports between servers, clients and domain controllers.
There is a lot of a situation where you may need a Kerberos authentication in the cloud, from old applications that don't support modern authentication to Azure files used as shared folders.
Imagine a situation, you run a SaaS company with some applications. These applications use an internal or Kerberos authentication system. The second is better as it centralizes and secure password. It, also, permits users to jump from one application to another without the need to enter their login and password.
You have set up a complexes Active Directory infrastructure and you struggle to secure it. Now, how to be able to move in the Cloud these applications without recreating users and without opening your infrastructure to the Internet.
The response for Azure-based applications is Azure Active Directory Domain Services. Azure AD DS or AADDS is an Active Directory Managed service. It offers traditional Microsoft Active Directory tools, like group policy, Kerberos authentication and domain join just like an on-premises Active Directory.
Users from Azure Active Directory tenant are synchronized to Azure AD DS. The synchronization process is similar to the one used by Azure Active Directory to synchronize users. For password, only password hashes are synchronized. It means that object ID in the Azure AD DS is different but it provides SSO to users.
More, as on-premises, active directory domains can be synchronized with Azure Active Directory, you can also synchronize your on-premises users to Azure AD DS, given them SSO experience for legacy cloud-based applications.
Let’s see how to create and manage an Azure AD DS domain.
The first task is to register the resource provider for Azure AD DS.
Register-AzResourceProvider -ProviderNamespace Microsoft.AAD
The second step is to choose the SKU. Currently, there are 3 SKU, Standard, Enterprise and Premium. These SKU determine the number of concurrent connections and the number of objects (from 25k to 500k). Only Enterprise and Premium let you create the forest trust.
To be able to communicate with your IaaS resources, Azure AD DS needs access to your Azure Network architecture. Unlike other managed services, and fortunately, there is no default public access to Azure AD DS. You need to create a Subnet for Azure AD DS. This Subnet will host the two domain controllers deployed by the service. You may need to create 2 other subnets, on for administration VM and another for your workload. For your workload, you can also peer other Vnet.
To deploy the service, you can use the portal, PowerShell or ARM deployment with a template
In PowerShell we first create the Azure Admin group
New-AzureADGroup -DisplayName "AAD DC Administrators" `
-Description "Delegated group to administer Azure AD Domain Services" `
-SecurityEnabled $true -MailEnabled $false `
-MailNickName "AADDCAdministrators"
$AzSubscriptionID = "xxxx-xxxx-xxx-xxxx-xxx"
$AdDomainName = "demo-omc.local"
$AzRGName = "demo-aadds-rg"
$azVnetName = "demoaadds-vnet"
$azSubnetName = "aadds-snet"
$subnetID = "/subscriptions/$($AzSubscriptionID)/resourceGroups/$($AzRGName)/providers/Microsoft.Network/virtualNetworks/$($azVnetName)/subnets/$($azSubnetName)"
$AaddsID = "/subscriptions/$($AzSubscriptionID)/resourceGroups/$($AzRGName)/providers/Microsoft.AAD/DomainServices/$($AdDomainName)"
New-AzResource -ResourceId $AaddsID -Location "northeurope" -Properties @{"DomainName"=$AdDomainName; "SubnetId"=$subnetID} -Force -Verbose
The managed service will deploy 2 domain controllers per replica set in an availability zone.
The services will also create an NSG to protect the service, a load balancer with a NAT Rules to allow Azure AD to connect to domain controllers via WinRM. Even if you can see the domain controllers network interface, servers are not visible. Once deployed the network configuration cannot be modified.
Before doing anything on the new service, you should notice a new group in your Azure Active Directory, AAD DC Administrators. Every member of this group will be automatically a member of the Domain Admin group in the Domain Service. By default, this group is empty. You will need to create a simple user in Azure AD and add it to the group. no Azure Role is needed, more it's strongly discouraging to use any Azure role.
For the last step, we need to configure DNS settings in VNET and Peered VNet. They need to point to the two NIC IP in the domain services.
If you open the Azure AD Domain service page in the Azure Portal, you will notice no real option to manage the domain. You will need to deploy an administration VM in the admin subnet and join it to the domain with the user and password you created for the AAD DC Administrators group. You will need to install Active Directory management tools. After that, you will be able to manage your active directory domain in the same way you do on an on-premises domain.
You will notice some OU specific to Azure AD Domain Services. This OU starts with AADDC and contains objects linked to the services. You will also notice the forest and domain functional level, windows 2012 R2. It's enough to secure Services and user account and to perform Kerberos authentication securely. You will be able to manage LDAPS queries to the managed domain and even open it to the Internet.
Azure Active Directory Domain Service is a great tool if your goal is to deploy a single domain for cloud applications that can't use modern authentication and relay on NTLM or Kerberos to authenticate users. With it, you don't have to deploy and secure and a complex AD infrastructure. You will only have to manage this domain and with synchronization from Azure AD and your on-premise domain you can offer to your users the ability to login with the same username and password they have for other cloud and on-premises app.
AADDS manages the infrastructure for you but you will still have to manage password policy, group policy, service account with the same principles that govern your current AD. You simply not have to manage the servers and infrastructure.
Oldest comments (0)