Windows Azure Pack – Active Directory Design Choices

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.

Advantages:

  • No ADDS needed (Advantage?)
  • No VMs for ADDS

Disadvantages:

  • 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

Note:
For Windows Azure Pack build-in functionality like “Console Connect” or “Network Virtualization” you will need to build a Hyper-V cluster.

Extended Forest

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.

Advantages:

  • No additional ADDS forest / Domains needed

Disadvantages:

  • 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.

Advantages:

  • 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.

Disadvantages:

  • 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.

Isolated Forests

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 to keep in mind here 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?!”, please consider the following. When the servers are in separate forests they still can have IP communication, that’s what the firewall is for. So in this case, WAP communicates, through the firewall, with the SPF web service on port 8090. No problem at all!

The security risk of this design is low.

Advantages:

  • No security risks from the DMZ to MGMT domain
  • Ability to create One-way Trust if needed

Disadvantages:

  • 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 might already have expected, I would highly recommend the “Isolated Forests” scenario.
Choose wisely!

Darryl van der Peijl

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">

Our Sponsors





Powered by