In this blog I will discuss different Active Directory designs, focusing on the use of Windows Azure Pack. Since Windows Azure Pack is nothing different from a regular web service, these designs can be used in a very generic way.
When talking Active Directory, we are actually talking security.
The design decisions you make can have a huge impact on the vulnerability of your infrastructure.
Windows Azure Pack is offering a number of services that can be accessed from the Internet like the Tenant Portal and Tenant Public API, and don’t forget the “Remote Console” feature which will need a Remote Desktop Gateway server accessible from the Internet as well.
It is recommended to put servers in a DMZ/Perimeter network which can be accessed from the outside. Since they are reachable from the potentially ‘hostile’ external world, these servers can become subject to intrusion or hijacking by attackers. The DMZ/Perimeter network is a containment area so that a breached server does not gain immediate access to your internal infrastructure.
So, let’s get started!
I will discuss the following four different Active Directory designs and sum up the Advantages and Disadvantages.
– No Active Directory in DMZ / Perimeter Network
– Extended Forest
– Forest with child domains
– Isolated Forests
The following terms will be used:
ADDS Active Directory Domain Services
DMZ / Perimeter Network The zone for external facing services
Local Network The zone for internal services
Local infrastructure Infrastructure (servers) in the Local Network
Perimeter infrastructure Infrastructure (servers) in the Perimeter Network
No Active Directory in DMZ / Perimeter Network
You can implement Windows Azure Pack without the use of Active Directory, so you don’t have to create a separate domain for WAP in the perimeter. Windows Azure Pack will use the local server’s Security Accounts Manager (SAM) database to authenticate identities and will use SQL authentication for the databases.
The security risk of this design is medium.
No ADDS needed (Advantage?)
No VMs for ADDS
– Managing of users and the servers need to be done locally on each server
– You cannot setup Failover Clusters without ADDS (Hyper-V, SQL Always on, ..)
– The Kerberos protocol or certificates are not available for local SAM authentication.
– Centralized updates (WSUS) cannot be implemented
– No ability to use ADFS
For Windows Azure Pack build-in functionality like “Console Connect” or “Network Virtualization” you will need to build a Hyper-V cluster.
An extended forest scenario places domain controllers that belong to the forest domain in the perimeter network.
This model allows identities to access resources in the perimeter network from both the Internet and the local network without requiring multiple domains or having to set up trust relationships between internal forest and perimeter forest for authentication.
Actually the Local infrastructure is extended into the Perimeter Network.
The security risk of this design is high.
– No additional ADDS forest / Domains needed
– The Local Active Directory infrastructure is accessible to domain-joined computers or domain users in the perimeter network.
– No security isolation so hijacking a domain controller, hijacks the entire domain.
Forest with child domains
A forest with child domains scenario places all domains in the same forest.
All domains within the same forest will have an automatically created trust between them, meaning they can access resources from each other.
Logically this scenario is very similar to the “Extended Forest” scenario described above. The difference is that you will create a separate domain (=tree) for each purpose instead of putting all users and computers in the same domain.
Actually the “Perimeter infrastructure” like the Tenant portal is placed in the Local Network in this scenario.
The security risk of this design is high.
– The “Perimeter” Active Directory infrastructure is accessible to domain-joined computers or domain users in the Local Active Directory infrastructure. (Advantage?)
– No need to create additional forest.
– The Local Active Directory infrastructure is accessible to domain-joined computers or domain users in the “Perimeter” Active Directory infrastructure.
– Active Directory schemas are shared among all Domain controllers.
– When creating a Forest-trust with another Forest, the other Forest will have access to your whole forest
– Inadequate security isolation between domains within one forest
– You need to set access rights manually for each domain if you don’t want the users and computers in the perimeter network to access the Local Active Directory infrastructure.
The isolated forest scenario provides the perimeter network with a dedicated deployment of an ADDS forest. In this model, the forest in the perimeter network does not formally communicate with any other forest on the network. The identities that are stored in this forest have meaning only inside the same forest.
The thing here to keep in mind is management of the DMZ domain.
Your MGMT users do not have access to the DMZ domain, which can be mitigated by creating a One-Way trust.
Typically your MGMT domain also holds System Center components like Configuration Manager or Data Protection Manager.
These products have no access to the DMZ domain and require a Two-way Trust between the forests to function properly, unless you are willing to work with certificates.
If you’re thinking “But how does WAP communicate with SPF and VMM?!”, mind the following.
When the servers are in separate forests they still can have IP communication, that’s what the firewall are for.
So in this case, WAP communicates, through the firewall, with the SPF webservice on port 8090.
No problem at all!
The security risk of this design is low.
– No security risks from the DMZ to MGMT domain
– Ability to create One-way Trust if needed
– Multiple forests must be created and managed
– Some services like DPM need a Two-way trust which will undo the safety of the separate forests
As you probably already expect, I would highly recommend the “Isolated Forests” scenario.