Walk through how to plan and deploy ATA in an enterprise.
- [Instructor] As we talk about how ATA works, there's three components that you'll need to plan for. As you start to install ATA and use it in your environment, the first, and the most important, is the ATA Center, this is really the core of the ATA deployment. It's what receives all the data from your network, does all the analysis, and provides you the alerts and information about what's going on. The second two are often used interchangeably, sometimes exclusively, and sometimes in a combination, are the ATA Gateway and Lightweight Gateway. What the Gateway's responsible for doing is taking the network traffic that your domain controllers send and receive, analyzing that, and forwarding it to the ATA Center.
It's also responsible for taking certain event log information, and forwarding that to the ATA Center as well. With an ATA Gateway, it's actually a separate machine that you install in the network, or sometimes a set of them, and the network ports that your domain controllers are connected to, are actually mirrored to a network interface on the ATA Gateway. This can sometimes be challenging to deploy, especially if you're using virtualization, or you have the main controllers deployed in a cloud environment, or you run a large enterprise where you have domain controllers that are scattered all over the world, you would need quite a few ATA Gateways.
To address this problem, Microsoft created the ATA Lightweight Gateway. The Lightweight Gateway is a set of applications and services that you install on domain controllers, and it does the same thing as the ATA Gateway, but rather than depending on the network to mirror a switch port, it's able to capture all the network traffic directly from the domain controllers' network interfaces, do the same analysis, and forward that to the ATA Gateway. Let's take a look at what this looks like. Fundamentally, if we think about this with just ATA Gateways, we have a couple different things. We have the ATA Center, which is a single machine that you'll deploy, one per forest.
And then you'll have an ATA Gateway, you might have more than one Gateway, but we'll get keep this simple. The ATA Gateway is both connected to the network, through a standard network interface, it has an IP address, everything you're used to. It also has a second connection to the network, which is a port on the switch that's been configured to mirror network traffic. Now we add in the domain controllers. In this instance, we have two of those, those domain controllers are also connected to the same switch on the network, just a standard network connection, but now that switch has been configured to mirror all the traffic that's sent those switch ports, to the second connection on the ATA Gateway.
Additionally, the domain controllers forward certain events from their event logs to the ATA Gateway, and the ATA Gateway combines with the event log data as well as the network data, does a fair bit of analysis, and then sends the results to the ATA Center. The ATA Center is then able to do further processing, and provide you an interface to see the results. If you also had domain controllers where it wasn't practical to use an ATA Gateway, they would still be connected to the network, just like our domain controllers before, but now, rather than using an ATA Gateway, we can install the Lightweight Gateway on each domain controller directly.
That Lightweight Gateway will be able to capture the domain controller's network traffic, as well as special event login information, and send all that information to the ATA Center for processing, just like the ATA Gateway did before. As far as planning for ATA, there's actually some sizing work that you're going to need to do, it's not as simple as flipping on a couple of servers and installing it, simply because you need to have the correct resources in terms of things like CPU, and memory, and storage, and so forth, in order for your deployment to be successful. The first thing to know about ATA, is that one instance of it, one ATA Center, can only handle a single Active Directory forest, so if you have multiple forests, you'll need to repeat this sizing exercise for each of those forests.
Fundamentally, one of the key things you're going to need to determine, is how much network traffic all your domain controllers generate in an aggregate basis. You'll both be looking at the peaks, the maximums, as well as the averages. The good news is you're not on your own to figure this out, Microsoft provides an ATA sizing tool that will go and collect all the data for you, so that you can do the analysis on that. Based on that data, for the ATA Center, you're going to need to size how much CPU, how much memory, and how much storage are required. Those three metrics directly correlate to the network traffic information that you collect from your domain controllers.
So again, that's why it's really important to get that part right. The ATA Gateways themselves, as well as the ATA Lightweight Gateways, also have CPU and memory requirements, no storage, but those are dependent on the network traffic of the domain controllers that they are processing data for, an ATA Gateway will process for one or more domain controllers, whereas a Lightweight Gateway will only handle the domain controller that it's installed on. When it comes to planning for Lightweight Gateways, one thing to keep in mind, you might need to increase the CPU and memory resources that are allocated to your domain controllers.
If they're virtualized, this can often be very easy to do, but if it's on physical hardware, you might actually need to plan hardware upgrades in order to provide the resources that the Lightweight Gateway requires. One of the debates that usually comes up when planning an ATA deployment is, "Well, should I use a Gateway or should I use a Lightweight Gateway?" The challenge with the Gateway is that A, it requires additional servers, and B, it needs to be connected to a network switch with port mirroring enabled. Technically this doesn't seem all that difficult to do, but in practice, it can be fairly involved to make this happen, especially at scale where you need many Gateways.
The Lightweight Gateway solves this problem, because now we don't need port mirroring, it's simply something we install on all our domain controllers, but some people will argue that this isn't as secure because technically if you could compromise a domain controller, you might be able to compromise the Lightweight Gateway, and affect the data that's being sent to ATA. So, the middle ground that some people choose to take, is, "Well why don't we combine both? Maybe in our key data centers, we'll use ATA Gateways, and then in all our other sites, we'll use the Lightweight Gateway." This can help mitigate the concern that potentially a Lightweight Gateway could be compromised, or you might decide that, "You know, a Lightweight Gateway is fine for my environment, I'll deploy that across all my domain controllers, and I won't use any traditional ATA Gateways," either certainly works.
Finally, once you've determined that topology, you've done the sizing exercises, you can start rolling ATA out, you'll install the ATA Center, it has a little bit of configuration work, not too much, and then after that, you can start installing your Gateways, or you could start installing Lightweight Gateways. As soon as you do that, those Gateways or Lightweight Gateways will start sending data to the ATA Center, and ATA will begin that discovery and learning process. That process actually takes several weeks to complete, so one thing to keep in mind, is that while that's going on, the first three to four weeks at least, of your ATA deployment, you probably won't actually see many alerts, or you might see some false positives, as ATA is figuring out what's going on, and learning about how your environment works.
- Authentication options with Azure AD
- Configuring Azure AD Connect for sync and authentication
- Securing remote access with the Azure Application Proxy
- Managing apps and devices with Intune
- Building and deploying a basic Intune policy for iOS or Android
- Protecting data beyond the firewall with Azure Information Protection (AIP)
- Configuring AIP classification labels and protection
- Integrating Exchange and SharePoint with AIP
- Managing risk with Advanced Threat Analytics
- Connecting Office 365 to cloud app security