Active Directory Considerations in Azure Virtual Machines and Virtual Networks Part 5 – Domains and GCs

  • Article

imageIn the first part of this series on Active Directory considerations in Azure Virtual Machines and Virtual Cloud and Datacenter Solutions HubNetworks we talked about Hybrid cloud and how you can leverage hybrid cloud to extend you corporate network. In the second part, we went over some Azure Virtual Machines and Virtual Networks basics so that you had a foundation on which you could understand some of the Active Directory issues. In the third part of the series we looked at the question of whether or not it was safe to put domain controllers in Azure Virtual Machines and Virtual Networks and where you should put Active Directory related files. In part 4, we talked about the role of read-only domain controllers. If you missed any of these, you can find the one you want to go to from the list below:

In today’s article, we’ll look at the various domain and forest configurations you might deploy in Azure Virtual Machines and Virtual Networks and consider the security implications. Then we’ll discuss the role of the Global Catalog and what the effects of putting a Global Catalog in the cloud might be.

Domain and Forest Considerations

In the last article we focused on the advantages and use of read-only domain controllers for providing directory services to applications hosted in the Azure Virtual Machines and Virtual Networks cloud. While read-only domain controllers are a great option, I did mention that not all applications will work with read-only domain controllers. Also, while they are a good option if you’re providing directory services to cloud based applications, they might not be the best option if you want to provide disaster recovery or local domain controllers for remote offices. In those, and other scenarios, you’ll probably want a full read/write domain controller.

When considering putting a full read/write domain controller in the cloud, you’ll first want to ask yourself how much you trust the Azure Virtual Machines and Virtual Networks infrastructure. Keep in mind that Azure Virtual Machines and Virtual Networks is a public cloud, which means that you’re using a shared compute, networking and storage infrastructure. In such an environment, isolation is a key operating principle and the Azure team is very aware of that. We believe that we’ve done a good job with that and that you can safely place read/write domain controllers into the Azure Virtual Machines and Virtual Networks cloud.

For more information on Azure security, please see Windows Azure Security Overview.

If we can agree that it’s safe to put read/write domain controllers in the Azure Virtual Machines and Virtual Networks cloud, the next step is to consider what kind of domain/forest configuration you want to deploy. Some of the options include:

  • Deploy DCs that are part of the same domain in the same forest
  • Deploy DCs that are part of a different domain in the same forest and configure a one-way trust
  • Deploy DCs that are of a different domain in a different forest and configure a one-way trust

One could argue that the first option represents the least secure option, since if the domain controller in the cloud is compromised, the entire production directory services infrastructure would be impacted. The second and third options appear to me to be more secure, since there is only a one-way trust. Obviously, the last option would be the most secure, but there is administrative overhead that you will need to take into account and not all deployment scenarios will necessarily support this kind of configuration.

I do want to make it clear at this juncture that I’m not the go-to guy for the Active Directory security model. What I do want to do here, however, is to bring up the options that are available so that you can start the conversation with your Active Directory security experts. This conversation will lead to a result where you’ll be able to decide what type of domain/forest setup you’ll want to use in your Azure Virtual Machines and Virtual Networks environment.

Another thing you’ll want to consider is any compliance issues. A lot of PII can be stored in these read/write domain controllers and there may be regulatory issues that you’ll need to consider. There are also cost considerations. You’ll end up generating a lot more outbound traffic (depending on authentication load) and there will also be outbound replication traffic that you’ll need to factor into the cost equation.

For detailed coverage of Active Directory security considerations, please see Best Practice Guide for Securing Active Directory Installations.

Global Catalog Considerations

If you’re not an Active Directory expert, you probably have heard of Global Catalog servers but might not be sure what they are. While I don’t want to go into all the exquisite details of the Global Catalog, let’s agree on a definition. A Global Catalog server is a domain controller that keeps information about all objects in its domain and partial information about objects in other domains. There you go, now we have a definition.

If you want to learn more about Global Catalog servers, please see What is the Global Catalog.

A Global Catalog enables an application to ask a single domain controller one question that might refer to multiple domains, even though that domain controller is not a member of the domain for which the question is being asked. They do contain a partial copy of the rest of the forest, and this information is a defined attribute set while is filtered to a Global Catalog server. This is also known as the Partial Attribute Set or PAS.

For more information on the Partial Attribute Set, please see How the Global Catalog Works.

There are a number of reasons why you might not want to make your domain controller in the Azure Virtual Machines and Virtual Networks a Global Catalog server. Some of these include:

  • Size – inbound replication will start and might contain information you don’t necessarily need. However, there is no cost to you for inbound replication, so there’s no negative impact in that regard. However, depending on the size of your organization, you might need a larger sized VM that has the requisite storage – this is going to cost more for the larger VM instance.
  • Global catalog servers replicate PAS content between themselves – which means that this information will be passed to GCs you put in the Azure Virtual Machines and Virtual Networks cloud
  • There’s a chance that the GC in the Azure Virtual Machines and Virtual Networks cloud will become a preferential source to another GC somewhere in the world. This is not optimal, as this results in a situation where it starts sending updates from the cloud that happen in a domain that represents a geography that you don’t really care about in the cloud and subsequently eats up a lot of outbound bandwidth, which is bandwidth you pay for.

Those are some reasons why you wouldn’t want to put a GC in the cloud. With those reasons in mind, when would you put a GC in the cloud? One obvious one would be when you have a single domain forest. However, remember our discussions about potential security implications.

What should you do if you have two domains in the same forest, where one is on premises and the second is in the Azure Virtual Machines and Virtual Networks cloud? The answer is to make the DCs in the cloud GCs.

Why? Because during authentication as the user logs on, there needs to be access to a group type in Windows Active Directory called a Universal Group and Universal Groups require a GC in order to populate. This means that a GC is a required step in all authentication scenarios where you have more than a single domain.

Also, consider if you want the domain controllers in Azure Virtual Machines and Virtual Networks to require a round trip to the on premises network in order to access a GC at every single authentication attempt. This is a tradeoff and it depends on what the replication requirements would be versus how many authentication attempts are made. We don’t think so much about these issues when Active Directory is on premises only, but when we enter an environment where egress traffic is billable, our design consideration must take this factor into account.

The fact is that workloads in the cloud that authenticate against a domain controller in the cloud will still generate outbound authentication traffic if you don’t have a GC in the cloud. It’s difficult to provide hard and fast guidance because this scenario is fairly new, and you’re likely going to have to figure out the relative costs of the different options (authentication traffic versus replication traffic) or wait until we have something based on our experiences that we might be able to share with you in the future.

What we do know is that the GCs are used to expand Universal Group membership, which is likely going to lead to even less predictable costs associated with GCs since they host every domain (in part). However, something that might complicate issues even more, or at least require more study, is the effect of placing an Internet facing service that authenticates with Active Directory.

One option is to take advantage of Universal Group Membership Caching, but there are issues with this solution and you probably will want to consider those. For more information on Universal Group Membership Caching, please see Enabling Universal Group Caching for a Site.

Finally, most replication for this GCs in the Azure Virtual Machines and Virtual Networks cloud is going to be inbound, so cost is not an issue there. Outbound replication is possible, but this can be avoided by configuring the right site links.

Summary

In this blog post, part 5 in our series on Active Directory considerations in Azure Virtual Machines and Virtual Networks, we talked about the domain/forest models you might want to use when putting domain controllers in the Azure Virtual Machines and Virtual Networks cloud. We discussed the security considerations that you will want to address when deciding the best approach for your Active Directory in the cloud deployment scenario. We then went over the subject of GCs in the cloud and some things that you’ll want to think about in this area. As you can tell, there is a lot of uncharted water in this area, in spite of the fact that Active Directory is over a decade old. But our experiences have been with on premises deployments and costs for network traffic and storage haven’t been so much of an issue. Now we’ll need to consider these issues as well as traditional infrastructure issues related to performance, scalability and availability.

HTH,

Tom

Tom Shinder
tomsh@microsoft.com
Principal Knowledge Engineer, SCD iX Solutions Group
Follow me on Twitter: https://twitter.com/tshinder
Facebook: https://www.facebook.com/tshinder
image

Go Social with Building Clouds! Building Clouds blog Private Cloud Architecture Facebook page Private Cloud Architecture Twitter account Building Clouds Twitter account Private Cloud Architecture LinkedIn Group Cloud TechNet forums TechNet Cloud and Datacenter Solutions Site Cloud and Datacenter Solutions on the TechNet Wiki