I’ve previously written about Azure AD Domain Services and what you need to consider before using it –> https://msandbu.org/things-you-need-to-consider-before-using-azure-ad-domain-services/ now one of the new features which was announced during Microsoft Ignite was something called Azure Active Directory Domain Services Resource Forest (which is now in Public Preview) as an additional option when deploying Azure AD DS.
NB: Now you should take note that this deployment model is only availble for new deployments and you cannot currently covert existing configurations.
So what is the intention of using a Resource Forest?
Resource forests has been something that many enterprises and I’ve used from an MSP perspective for other deployments where we wanted to seperate users to access services such as Exchange/Lync and such. In that case there was a one-way trust between Forest A to Forest B, meaning that each user in the main forest had a shadow/resource user in Forest B which they used to authenticate to Exchange/Lync in this case.
In this scenario with resource domains in Azure AD DS it allows us to create an instance that has a one directional trust with your on-premise domains and eliminates the need to sync password hashes to Domain Services. So what Microsoft does is essentially setup a set of Azure VMs which are configured as domain controllers and an AD DS domain as part of an existing forest. A trust relationship is then configured to an on-premises AD DS environment. Other Azure VMs can domain-join to this resource forest in the cloud. User authentication runs over a VPN / ExpressRoute connection to the on-premises AD DS environment. So it allows to authenticate to the resource forest but not the other way.
So when use this?
- Your intended use of Azure fits one of the distributed deployment patterns, and a dependency between your on-premises environment and Azure is acceptable.
- The resources you plan to deploy to Azure require a different domain configuration or structure than your existing domains provide, or you want to grant a high level of administrative autonomy to teams who administer the Azure-hosted domain.
- You can grant a high level of administrative autonomy to teams that manage the Azure-hosted Active Directory domain.
Now something you need to be aware of using a resource forest.
- All content of the global catalog will be replicated to Active Directory and can be efficiently accessed from Azure-hosted resources.
- Replication traffic between your on-premises network and Azure is limited to global catalog replication. This might help limit your overall bandwidth consumption.
- Users sign-in using your on-premises Active Directory Domain Services, which removes the need to synchronize on-premises user password hashes
- Resource forests are ideal when your organization cannot take advantage of password hash synchronization, exclusively uses smart cards for user authentication, or has complicated application platforms that may need to be lifted to Azure in phases
- Users continue to sign-in using your on-premises Active Directory Domain Services but authenticate to applications and workloads (resources) hosted in the Azure AD Domain Services by way of a one-way outbound forest trust to the on-premises Active Directory Domain Services using either a site-to-site virtual private network (VPN) or preferably an ExpressRoute.
- User sign-in to a resource forest should be limited only to users who need to manage resources in the resource forest. For this reason, resource forests only receive copies of cloud users, groups, and group memberships.
Once you have configured a new Azure AD Domain Service Resource Forest within an existing VNET where you have a VPN or ER configured, you just need to go into the setup of the trust. Note that you also need to configure trust on the other side first before the connection is successful.
w