Darryl van der Peijl wrote this great guest blog on design considerations for Active Directory in a Windows Azure Pack environment:
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. Read More »