A successful Microsoft Defender for Identity deployment starts with a plan that reflects your organisation’s identity environment and operating needs. The aim is effective coverage and reliable monitoring, not simply installing sensors. Agree the deployment scope, ownership and ongoing oversight before rollout.
Identity infrastructure connects users, systems and access across the business. Security and IT teams should decide together how sensors will fit into existing processes, who will maintain them and how changes to servers or authentication will trigger a review.
This guide covers sensor placement, version selection, prerequisites, service accounts, capacity planning, licensing and operational monitoring. Use it to identify the decisions your teams need to make before deployment and where specialist support may help.
Key Takeaways
- Match sensor version and placement to each server’s operating system and identity role.
- Prepare auditing, connectivity and service-account permissions for the sensor model you deploy.
- Use the sizing tool where it applies and base capacity decisions on observed environment activity.
- Review Microsoft licensing against the identities in scope and your organisation’s current agreement.
- Assign ongoing responsibility for sensor health, alert review and changes to the identity environment.
Sensor Deployment for Domain Controllers & Other Identity Servers
Choose sensor placement and version for each server’s role and Windows Server build. Confirm the current Microsoft prerequisites before rollout, especially in environments that will use both sensor versions.
Deploy Sensors on Identity Servers
Install sensors on domain controllers, including read-only domain controllers. Domain controllers monitor their own network traffic, so they do not need a dedicated sensor server or port mirroring for this purpose. Microsoft also supports sensors on identity servers such as Active Directory Federation Services (AD FS), Active Directory Certificate Services (AD CS) and Microsoft Entra Connect when those servers are not domain controllers.
Select the sensor version according to Microsoft’s current support guidance for the server’s operating system. Sensor v3 requires an eligible Windows Server build with the applicable cumulative update. Sensor v2 remains relevant to supported older systems and certain deployments.
Do not install both versions on the same server. In a mixed-version environment, record the sensor version assigned to each host before configuring accounts or rollout tasks. Review Microsoft’s sensor v3 prerequisites and sensor v2 prerequisites before making deployment decisions.
For AD CS, confirm that the server hosts the Certification Authority role service. Microsoft’s sensor v2 guidance also distinguishes between direct sensor installation and standalone deployment with port mirroring. Check the supported approach for your sensor version and server configuration before implementation.
Plan Prerequisites & Connectivity
Check the prerequisites for each sensor version before installation. The sensor v2 installer requires .NET Framework 4.7 or later and may install it if it is missing. Installation can require a server restart, so schedule deployments within an appropriate maintenance window.
Microsoft advises against relying on the norestart flag to prevent a restart during a silent installation. Review the relevant sensor installation guidance before scheduling deployment.
For sensor v3, verify the required operating-system updates and Defender for Endpoint onboarding status. Microsoft’s current guidance also states that non-domain-controller activation for AD FS, AD CS and Microsoft Entra Connect servers is in preview and that at least one v3 sensor must be installed on a domain controller in these scenarios. Confirm these conditions against the latest deployment documentation before rollout.
Plan firewall and proxy rules around the traffic each sensor needs. The sensor uses outbound TCP 443 to communicate with the cloud service. TCP 444 is used for communication between the sensor and updater services on the local machine. DNS uses TCP and UDP 53, while UDP 1813 is relevant when monitoring RADIUS authentication.
Network name resolution can use methods including TCP 135, UDP 137 or TCP 3389. Confirm which methods your environment will use and allow the necessary paths.
After installation, confirm that sensors report as onboarded and investigate connectivity failures. A connectivity test should return HTTP status code 200. If you use sensor v2, review whether the DelayedUpdate installation option would help coordinate the timing of service updates.
Prerequisites, Permissions & Directory Service Accounts
Confirm the sensor version before creating or assigning a directory service account. Sensor v3 uses the server’s LocalSystem identity and does not require a directory service account or group managed service account. Sensor v2 uses a directory service account for Active Directory operations.
Keeping this distinction clear avoids unnecessary account configuration and helps security and Active Directory teams agree ownership. Review Microsoft’s gMSA configuration guidance for sensor v2 deployments.
For sensor v2, have the Active Directory team create and configure the required account. If using a group managed service account, authorise the relevant sensor hosts to retrieve its managed password, install it on those hosts and test that it works before configuring the sensor. Apply Microsoft’s documented account permissions and host-scope requirements to your environment.
Configure Security Accounts Manager Remote access where required for the detection capabilities in scope. Defender for Identity uses SAM-R queries to identify local administrators for lateral movement path detection. Apply the relevant network access policy to the computers that need to respond to those queries and keep its scope limited to the intended hosts.
Prepare audit collection for the identity server roles in your deployment. For example, Microsoft’s guidance calls for event collection on relevant servers and identifies event IDs such as 4662, 5136 and 8004 for identity activity.
The events and audit settings required depend on the server role and sensor version. Verify the applicable Windows event collection configuration rather than treating one audit checklist as universal.
Record which identity each sensor uses, which hosts can retrieve a gMSA password and where relevant policies apply. This gives security and IT teams a clear reference when server roles change or responsibilities move. Where the deployment forms part of a broader identity programme, align these records with your identity and access management processes.
Sizing a Defender for Identity Deployment
Plan capacity around the activity your sensors will monitor, not domain-controller counts alone. The Defender for Identity sizing tool applies to sensor v2 deployments. Microsoft states that it is not required for sensor v3. Check the current guidance for the sensor version in scope before using the tool.
For v2 deployments, use the sizing results to inform capacity planning for domain controllers generating monitored activity. Check that the measurement reflects normal operations across relevant sites and periods. Record the assumptions behind your decision so changes to server roles, workload or authentication patterns prompt a review.
Include identity servers beyond domain controllers in the rollout scope. For example, account for AD FS servers that process federated authentication and identify how Microsoft Entra Connect servers fit into the environment. Sensor placement and capacity planning are related, but each should reflect the specific roles and activity being monitored.
Licensing & Cost Considerations in the UK
Review licensing separately from sensor deployment. Installing a sensor on a domain controller does not determine the subscription entitlements for the identities in scope. Ask the Microsoft licensing owner to compare the organisation’s current subscriptions with the identities and capabilities it intends to use.
Microsoft lists Microsoft 365 E5, A5 and G5, along with qualifying F5 Security plans, among the licensing options for Defender for Identity. Some plans have base-licence requirements, so confirm the exact SKU and eligibility against current Microsoft licensing guidance before making a purchasing decision.
Organisations assessing E5 should also consider the wider security and return-on-investment implications of Microsoft 365 E5.
The cost of any change depends on your existing entitlements, deployment scope and Microsoft agreement. Record the licensing owner, scope reviewed, exceptions and approval outcome alongside the deployment governance record. Revisit the decision when subscriptions or the identities in scope change.
Ongoing Monitoring With CyberOne MXDR
Deploying sensors is the start of operational monitoring, not the end of the work. Assign responsibility for sensor health, alert review and changes to the identity environment, then build those tasks into your existing security processes.
CyberOne’s MXDR as a Service combines managed Microsoft Sentinel and Defender to support threat detection and response across enterprise digital assets. For organisations that need ongoing monitoring across a wider Microsoft security environment, this can connect identity alerts with broader investigation and response processes.
The right operating model depends on your environment, existing capabilities and how your teams manage incidents. If you are planning monitoring beyond deployment, contact CyberOne to discuss the operating requirements for your environment.
Frequently Asked Questions
What Are the Prerequisites for Deploying Microsoft Defender for Identity?
Prepare supported Windows Server hosts, required auditing, connectivity and the correct sensor identity for each server. Check each server’s role, operating-system build and sensor version because these affect installation and configuration.
For example, a sensor v2 deployment may require a directory service account, while sensor v3 uses LocalSystem. Review the separate Microsoft prerequisites for the sensor version you intend to deploy.
How Do You Plan a Microsoft Defender for Identity Deployment?
Create a deployment record that lists each server’s role, operating system, sensor version and onboarding owner. Pilot across representative identity infrastructure, then review sensor health and audit coverage before expanding. Include AD FS, AD CS and Microsoft Entra Connect servers where they are in scope.
CyberOne’s Microsoft Security Deployment Services can support organisations coordinating Defender for Identity with a wider Microsoft security rollout.
What Firewall Ports & Network Connectivity Does Defender for Identity Require?
Allow outbound TCP 443 from the sensor to the cloud service and local TCP 444 communication between the sensor and updater services. DNS uses TCP and UDP 53, while UDP 1813 applies when RADIUS authentication is monitored.
Network name resolution may use TCP 135, UDP 137 or TCP 3389, depending on the methods configured in your environment. Confirm the required direction and scope against Microsoft’s guidance for your sensor version.
How Do You Validate & Monitor a Defender for Identity Deployment?
Confirm that sensors report as onboarded, run the connectivity test and review whether the expected Windows events are being collected. The connectivity test should return HTTP status code 200.
Where central monitoring is required, Defender for Identity can send alerts and activities to Microsoft Sentinel or a generic SIEM service.
What Are Common Defender for Identity Deployment Issues?
Start by checking sensor status, operating-system updates, auditing and network access. A failed connectivity test can indicate firewall or proxy restrictions, while missing detections may point to incomplete event collection.
For sensor v2, check .NET Framework installation and account configuration. If setup installs .NET or a silent installation requires a restart, follow Microsoft’s restart guidance and use a maintenance window.
