Microsoft Defender for Identity
This course introduces you to Microsoft Defender for Identity and is designed to provide you with a good understanding of what Microsoft Defender for Identity is, what it offers, the components that comprise it, and the requirements you must meet to use it.
- Get a basic understanding of Microsoft Defender for Identity
- Learn about the architecture of Microsoft Defender for Identity as well as its components
- Understand the requirements for planning the deployment of Defender for Identity
This quick-hitting course is intended for those who wish to learn what Microsoft Defender for Identity is and what it does.
To get the most out of this course, you should have a general understanding of Azure, particularly Azure Active Directory.
Hello. Welcome to the Architecture of Microsoft Defender for Identity. In this lesson, we will take a look at the components that make up the Defender for Identity offering.
Microsoft Defender for Identity uses proprietary sensors that are installed on your on-prem AD domain controllers to monitor them. These sensors capture network traffic and Windows events on each DC. Defender for Identity then analyzes this data for attacks and threats. Using this information, Defender for Identity learns about your network, which allows it to detect anomalies, and warns you about any suspicious activities that deviate from what it considers normal for your environment.
The THREE main components of Defender for Identity are the Defender for Identity portal, Defender for Identity sensors, and the Defender for Identity cloud service. The image on your screen highlights where these components fit into the overall architecture.
Defender for Identity sensors are installed on the on-prem domain controllers and on your AD FS servers, if you have them. Defender for Identity supports up to 350 sensors by default. That said, you can contact support if you want to install more sensors.
These sensors access the event logs on the DCs and ADFS servers, parse them, and then, once the logs and network traffic are parsed, that parsed information is then sent to the Defender for Identity cloud service.
The sensors will capture and inspect the local traffic of your domain controllers, they will receive Windows Events directly from the domain controllers, and the sensors can even receive RADIUS accounting information from your VPN provider.
These sensors collect data about the users and computers that are part of the Active Directory domain and they perform resolution of users, groups, and computers.
Now, not all logs and network traffic info are sent to the Defender for Identity service. Only the info that Defender for Identity needs is sent. This means only a fraction of the data that the sensors have collected is sent to the service.
The actual Defender for Identity cloud service, as you would expect, runs on Azure infrastructure. As of the time of this course creation, Defender for Identity is deployed in the US, Europe, and Asia. It’s connected to Microsoft's intelligent security graph.
The Defender for Identity portal is where you manage Defender for Identity. It’s used to create your Defender for Identity instance, it displays the data that’s received from the installed sensors, and it allows you to monitor your environment for threats, manage those threats, and investigate those threats.
You can also use the portal to integrate Defender for Identity with other Microsoft security services, to manage configuration settings for your Defender for Identity sensors, and to send email notifications and events whenever security alerts or health issues are detected.
Aside from these three main components we just talked about, there is a fourth component: the Domain synchronizer process.
The domain synchronizer process is the component that synchronizes everything from a specific Active Directory domain proactively. Defender for Identity will randomly choose one of the installed sensors to serve as the domain synchronizer. If that particular sensor goes offline for more than a half hour, another sensor is then automatically chosen to perform the synchronizer process.
So, the key takeaway here is that you have three main components of Defender for Identity. You have the Defender for Identity sensors, which collect and parse the data. You have the Defender for Identity Service, which processes the parsed data into usable insights. And then you have the Defender for Identity Portal, that you use to configure and interface with the Defender for Identity service.
Tom is a 25+ year veteran of the IT industry, having worked in environments as large as 40k seats and as small as 50 seats. Throughout the course of a long an interesting career, he has built an in-depth skillset that spans numerous IT disciplines. Tom has designed and architected small, large, and global IT solutions.
In addition to the Cloud Platform and Infrastructure MCSE certification, Tom also carries several other Microsoft certifications. His ability to see things from a strategic perspective allows Tom to architect solutions that closely align with business needs.
In his spare time, Tom enjoys camping, fishing, and playing poker.