New (and only available within Azure) are the Azure Active Directory Domain Services. This service is based on Azure Active Directory and the data replicated into it. It provides Domain Services as a service to subscription administrators and can be very useful for many scenario’s where domain services are required, but security or management of domain controllers in the cloud is a concern.
In many documents, you will see that you need to replicate user password [hashes] into AAD to make it fully work.. but this post is about how you can avoid that using Kerberos Constraint Delegation with Protocol Transition….
Architecture
The basic principle of AAD-DS is to create a new forest (and thus domain) from the information that is in Azure Active Directory (AAD). This means that users in AAD are replicated into this new domain including (if available) their passwords. (The passwords are hashed and irreversibly encrypted). The users are added to the domain as if someone created new user accounts in an OU including all their details as listed in AAD. The newly created domain runs on two (managed by Microsoft) domain controllers that are linked to a customer VNET. This means that the domain controllers are by default not accessible through the public internet.
The advantage of AAD-DS is that now it is possible to join machines to the domain, through Windows domain join or (Linux based) Kerberos trusts. Also, applications that require an LDAP provider can use the AAD-DS to function properly.
When combining AAD-DS with an on-premises domain that replicated information to AAD, a very powerful service becomes available. Users from the on-premises Active Directory are replicated into AAD (for example to support Office 365). When enabling AAD-DS these users now become available on Azure IaaS for virtual machines and applications. But the synchronization engine that replicates users from on-premises to AAD can filter out which accounts should actually be replicated. So it is possible not to replicate service accounts or administrative accounts into AAD, which means they are also not available in AAD-DS.
In fact, very advanced scenario’s now also become available that may benefit certain scenario’s. As the AAD-DS just copies the information from the AAD, every user in AAD will be represented in AAD-DS. And AAD supports the upload of user information from multiple sources. It would now for example be possible to provide the following scenario:
A company has two internal domains. These domains are for two separate entities and by compliance or security these domains cannot have a domain trust. The business however wants to have a shared portal where employees hosted in both domains can login to.
The picture above shows the possibility that this company now has. They can replicate the users to AAD, then to AAD-DS and allow these users to logon the application servers in Azure that are joined to the AAD-DS domain.
Within AAD there are two types of domains. Managed and Federated. And while a domain type per FQDN (and subsequent child domains) can only be either one of them, an AAD tenant will allow multiple domains in different types. For example, a tenant could have contoso.com as a federated domain, while also having tailspinstoys.com as a managed domain.
When creating the AAD-DS for that AAD instance, all users from all domains are replicated into AAD-DS. This brings up a new possibility; replicate users from on-premises to AAD-DS while also hosting users that are only created on AAD.
As such, it is possible now to create independent (managed) users on AAD that are created solely to be added to the AAD-DS without any access to the on-premises domain. For example, it can be used to allow an external service provider to have a logon to the (above pictured) application servers without any account to the on-premises environment. But as the account is still being managed through AAD itself, the administrators of AAD have full control over the account and can manage it if required. Even more, if AAD Premium is being used, the service provider can reset/manage its own account through the AAD premium portal.
Kerberos Constraint Delegation
As Kerberos services are now provided by the AAD-DS instance, Kerberos Constraint Delegation is also available. It allows for identities to be used in backend services
The advantage of Kerberos is the possibility of pass-through. One server can receive a ticket and give it to the next hop to identify the user on a second level. Picture a webservice with SQL behind it. When a user logs on to the webservice, generally a service account is used to connect to the backend SQL server. That service account has all the rights on the database and the security of the user is handled in the code of the web application. If someone would hack the application and give the order to delete the sql database the function will be performed regardless of the users privileges. Even more, the logs in the sql server will only show the service account as the account that gave the delete all order.
Fig. Web application with SQL backend
Now with Kerberos, we can grant the right to pass tickets from the web server to the SQL server so that the user is authenticated to the webserver AND the SQL server. This is called delegation
Fig. Kerberos delegation
There are two types of delegation within Kerberos:
- Unconstrained – The 1st hop can forward the user credentials (or to be more precise request a ticket on behalf of the user) to any other server in the forest. The user must authenticate using Kerberos to the first hop
- Constrained Delegation: The 1st hop can only forward the user credentials to specified SPN’s
Lastly, with the constrained delegation, the user can authenticate with Kerberos to the 1st hop (Constrained using Kerberos) or other forms of authentication such as NTLM, BASIC, SAML etc (Constrained Delegation using any authentication protocol).
As Kerberos delegation works without the actual password of the logged on user for the backend services (the user needs to logon to the first hop only), it makes certain scenario’s available that are unique to the AAD / AAD-DS environment.
Federated to Kerberos
With Kerberos Constraint Delegation with Protocol transition users can login to the first hop with any authentication protocol, which includes federated logon. By design federated logons using SAML, OAuth or any other forms are accepted. Azure Active Directory uses these federated logons for authentication to cloud services which we can then use to convert back (using KCD+PT) to Kerberos.
This design principle was the idea behind the AAD Proxy connector. A small service available with AAD that allows on-premises resources that use Kerberos or federated logins to be exposed to the cloud and protected by AAD logins. In short, if a company had a SharePoint portal internally that uses Kerberos authentication, they could now expose it to the internet and users would be required to logon with their AAD credentials.
The AAD Proxy will publish the internal resource not only through AAD authentication, but will also use the enterprise class protection against DDOS attacks and many more other things in Azure.
In the above picture the simplified solution is shown. On the right side we have the internal web server with the internal URL. A second server is the Azure Proxy connector. This server is basically a Windows server with a single application (the connector) running on it. The connector creates an outbound connection to the Azure subscription and awaits further instructions. On Azure a new Proxy Application is created and this application will have the external and internal URL configured, along with the authentication option.
When the user opens the external URL, the request is forwarded to the connector server which handles the final traffic to the web server. As the proxy connector server only creates an outbound connection, there is no need to publish the webserver directly on the firewall.
This authentication is based on federation and the token can be forwarded to the internal server or converted into a Kerberos token if configured. This means that based on federation, SSO can be achieved even though the identity objects within each system are not necessarily the same (but the identities belong to the same user).
Federated to Kerberos with AAD-DS
While the AAD proxy was intended to be used to publish on-premises services, the combination of it with AAD-DS creates new architectural options to enhance security of to enhance functionality.
Figure 4: AAD-DS + Proxy
The picture above shows the logical architecture for user identity switching in order to access a services. On the left is a windows (or Linux base) workstation that needs to access the resource server that only allows Kerberos authentication.
The user on the workstation logs on to Azure Active Directory with his/her username and password of the AAD when requesting access to the AAD proxy server. As the user provides the credentials to the AAD proxy server, this server actually goes into AAD-DS to match the logged on UPN of the user (or any other attribute) and “impersonates” the user for access to the resource.
From the resource server perspective, it is as if the user logged on to the server with Kerberos.
This is all possible as in the backend the users in the Azure Active Directory are synchronized to the Azure Active Directory Domain services. But this synchronization is more of a duplication of user properties on newly created objects. As such, the users in the AAD-DS do have the same logon name and other attributes, they do not have a similar Pre-Windows 2000 logon name, they do not have an equal SID or object ID, they are in fact unique objects that have equal attributes as a result of the synchronization.
When combining an on-premises Active Directory into the architecture, the following picture appears:
Figure 5 AD + AAD + AAD-DS + Proxy
Users from the local Active Directory are replicated into Azure AD (AAD) and then synchronized into the AAD-DS. The same statement as above applies. While replication or synchronization are the terms for this method, they are actually independent objects with their own unique GUID’s and object ID’s that share the unique attributes such as UPN. As such, users that are in the AAD-DS cannot just logon to on-premises systems.
Federated to Kerberos with AAD-DS without passwords
The user in the above pictures authenticates to the AAD proxy using credentials from the AAD. As the AAD proxy needs to impersonate the user, it actually will use Kerberos Constraint Delegation (KCD) to impersonate the user. For this, the AAD Proxy does not need to know the password of the user within AAD-DS. In fact, the password of the AAD-DS user does not need to be the same as on AAD. Or to go even further, the user does not even need a password on AAD-DS.
Go go one step further, when a domain in AAD is configured as federated, user passwords do not have to be present on AAD either. Logon to the actual AAD will be based on federation services that are linked to the local Active Directory.
In the above scenario, users only have a password on the local Active Directory (on-premises). The AAD domain is configured as federated which means that the actual logon to AAD will be done through the help of (on-premises) federation services such as ADFS, Okta or Ping Federate. When a user has access to the AAD (based on the already federated authentication from the federation service) he/she can request tokens to access SAML/Federated based services such as Office 365, but also the AAD proxy. There is no password for the user stored in AAD.
When enabling AAD-DS in this scenario, the user identity from AAD is replicated/synchronized into the AAD-Domain Service. While the user does not have a password in AAD, the user also does not have a password in AAD-DS. This means that the user cannot logon to the systems interactively (such as through the console or directly through IIS or any other service). It does however open the possibility for the user to logon to services (bound to this AAD-DS) through the use of Kerberos Constraint Delegation with Protocol Transition. This as the impersonating server (in this case the AAD Proxy) does not require to know the password for the user as Kerberos will provide the impersonation.
Given the above mentioned scenario’s it is now possible to join the servers (Linux and Windows) to AAD-DS, have users login to web services with their corporate credentials, secured through AAD (supported by federation to provide the actual user password) published by AAD Proxy or another solution that is capable of providing Federated-to-KCD-PT capabilities.
[credit shared with Tomasz Onyszko from predica.pl]