To integrate a legacy application based on Kerberos authentication in an Azure infrastructure as a service (IaaS) scenario, we configure Azure AD Domain Services. In this section, we configure the basic service and integrate an active example application:
Azure AD Domain Services creation
To start the configuration, we need to specify the DNS domain name
, the Azure Subscription
we want to use, and the name of the Resource group
:
Azure AD Domain Services configuration
When enabling Azure AD Domain Services, you will need to specify which Azure virtual network to use. We use a range 192.168.x.x/20
to configure the network:
Virtual network configuration
Add the admin account and your test user as a member of the Azure AD Domain Services
Administrator group
:
Azure AD Domain Services Administrator group members
The summary should look like the following:
Configuration summary
Next, you will be asked to update the DNS configuration to the addresses of your DNS servers provided by Azure AD Domain Services. In my case, these addresses were 192.168.0.4
and 192.168.0.5
:
DNS configuration
The last important step that you need to complete to use the domain you have just created is to enable password synchronization:
Instructions to synchronize users
By default, Azure AD does not store the credential hashes required for Kerberos authentication. You need to populate these credential hashes in Azure AD so that users can use them to authenticate against the domain. The process can be completed by changing the password of the user. You can use the accounts after 20 minutes in Azure AD Domain Services.
Note
You have two options: let passwords expire for all users or instruct these end users to change their passwords.
Users can use Azure AD's self-service password change mechanism from the Azure AD Access Panel page to change their passwords.
To test the Domain Services, we complete the following tasks:
- Install a virtual Windows Server in your Azure IaaS environment by using a deployment template (https://docs.microsoft.com/en-us/azure/active-directory-domain-services/active-directory-ds-join-windows-vm-template):
VM deployment configuration
- Install the administrative tools for Active Directory and DNS on the newly joined server:
Install-WindowsFeature RSAT-ADDS,DNS-Server-Tools
- Connect to
Active Directory Users and Computers
(dsa.msc
) and theGroup Policy Management
console to verify your configuration:
Azure AD Domain Services structure including synchronized objects
- Next, we need to create a
DNS HOST (A)
record for our test application:
- Now, we can install a basic IIS configuration, used to handle the Kerberos part. For this, you need to install the IIS components, choose the Kerberos authentication feature, and activate it on the default website. Only
Windows Authentication
needs to be activated:
IIS Authentication configuration for Kerberos example application
- Next, we will install and configure the Azure AD App Proxy connector to provide the application to your users. We use the following cmdlets to configure the needed, resource-based KCD feature:
# inovitcloudlabs represents the computer name $ConnectorComputerAccount = Get-ADComputer -Identity inovitcloudlabs Set-ADComputer inovitcloudlabs -PrincipalsAllowedToDelegateToAccount $ConnectorComputerAccount setspn -S HTTP/kerb.inovitlabs.ch inovitlabs\inovitcloudlabs
Server Manager IE Enhanced Security Configuration
- Next, we need to download the connector and install it on the server:
Application Proxy agent download and configuration
To configure the connector on the server, you need to provide a user with global administrator rights.
- After installing and configuring the connector, we will add our example app:
Azure AD App Proxy Connector group configuration options
Kerberos example configuration
- Next, we configure the Integrated Windows Authentication
Application IWA configuration
Finally, we assign some users or groups and test the application at https://myapps.microsoft.com. As a result, you should see the IIS test page. We provided a sample Kerberos-based application to Azure AD Domain Services and used the Azure AD App Proxy functionality.