Identity security

This section describes the design decisions associated with identity security for system(s) built using ASD's Blueprint for Secure Cloud.

Estimated reading time: 11 minutes

Identity security

Identity security underpins all Microsoft cloud-based service offerings, and forms the basis of the company’s Zero Trust approach and Secure Future Initiative. Identity security is also an essential component of ASD’s Modern Defensible Architecture (MDA), which provides a strategic framework for the consistent application of security principles throughout the design, development and maintenance of systems.

Microsoft Entra ID and Microsoft Defender for Identity provide a broad range of technical capabilities to safeguard the identities used in an organisation: Entra ID manages identities and access controls, and Defender for Identity monitors and detects suspicious activity within Windows Server identity infrastructure, used together they help organisations protect access and identify potential security threats across both cloud and on-premises environments.

Microsoft Entra ID

Entra ID provides a number of features to manage identities and control access to organisation resources, and provides an effective means to meet a number of ASD’s Information Security Manual (ISM) requirements.

Identity management

Centralised identity management reduces unnecessary authentication and enables simplified and holistic management of administrative configurations and security operations. Entra ID’s identity management features include:

User and group management allowing organisations to create, store, and manage users, groups, and devices in a centralised location
User provisioning and deprovisioning automating the process of creating and removing accounts and access rights
Single sign-on (SSO) enabling users to access multiple applications and resources using a single set of credentials
Password management providing self-service password reset (SSPR), password policies and weak password checking
Entitlement management allowing organisations to manage and control access to resources based on business requirements and roles
Lifecycle workflows automating tasks related to user lifecycle, such as onboarding and offboarding

Access control

Controlling access to resources is crucial for maintaining security, data integrity and compliance. Entra ID’s access control and security features include:

Role-based access control (RBAC) enabling administrators to assign roles and permissions to users based on their responsibilities
Conditional Access allowing organisations to enforce security policies based on user, device, network and a number of other conditions
Multi-factor authentication (MFA) requiring users to provide multiple forms of verification
Privileged Identity Management (PIM) providing fine-grained control and monitoring of access to critical resources
Access reviews allowing organisations to periodically review and validate user access to ensure it remains appropriate
Authentication protocols supporting various authentication protocols like OpenID Connect, OAuth, and SAML
Password-free authentication offering passwordless authentication options like windows Hello for Business, FIDO2 and Microsoft Authenticator

Other features

Identity Protection detecting risky user behaviour and sign-ins and makes access decisions
Directory synchronisation allowing organisations to synchronise their on-premises Active Directory with Entra ID
Reporting and analytics providing insights into user activity and access patterns
Integration with other Microsoft cloud platforms seamlessly integrating with other Microsoft services
External identities Providing a range of security and enabling services for B2C and B2B collaboration

Defender for Identity

Microsoft Defender for Identity (MDI) uses signals from Windows Server identity infrastructure to proactively assess identity security posture and respond to identity security incidents. MDI is managed and operated from the Defender portal and is an integration component of Defender XDR, sharing its signals and correlating events with other Defender XDR services.

Design decisions

Decision point	Design decision	Justification
Use Defender for Identity	Deploy Defender for Identity for all hybrid environments	Enable threat detection and response capabilities for identity servers

MDI components

MDI consists of three main components:

1. The Defender portal

The Defender portal is the primary operational interface for MDI and is used to create the MDI workspace, add or activate MDI sensors, and manage the limited configuration options available to configure sensors, tag devices, and manage alerting and notification rules.

2. MDI sensors

MDI sensors are software agents installed directly on Domain Controllers (DC), Active Directory Federation Services (AD FS), Active Directory Certificate Services (AD CS), and Entra Connect servers. The sensors analyse network traffic and Windows events and send the parsed information to the MDI cloud service.

3. The MDI cloud service

The MDI cloud service ingests sensor information and uses machine learning and threat intelligence from Microsoft’s Intelligent Security Graph to detect and alert on suspicious activity via the Defender portal. The MDI cloud service runs on Azure infrastructure in select regions determined by the proximity of an organisation’s Entra ID tenant at the time the MDI workspace was created.

Design decisions

Decision point	Design decision	Justification
MDI location	Australia	Help ensure data is under and jurisdiction of the Australian Government, help ensure confidentiality, and help minimise potential impacts from international service outages

If the MDI cloud service had been previously deployed to an incorrect location, it is possible to have the workspace location changed by raising a support case. Changing the location is a destructive process but will not affect other XDR services. Further information can be found in this Microsoft blog article.

Deployment considerations

Deploying MDI is a manageable process that requires a number of prerequisite configurations to be in place for success. In addition to the linked Microsoft Learn documentation herein, organisations may also find this Microsoft Setup Expert guide and this Microsoft blog article useful.

The following should be considered before attempting to deploy MDI:

Server capacity

MDI sensors deployed on Domain Controllers (only) in busy environments can require additional server resources to operate effectively. A capacity sizing tool exists to assist deployment planning and should be run on each Domain Controller prior to sensor deployment.

MDI sensors will self-sacrifice performance and begin limiting analysis if there is ever resource contention on the server. Notifications for these events will appear in the Defender portal.

Network planning

Each sensor deployed requires internet connectivity to the MDI cloud service:

Forward proxy configurations can be used although SSL inspection and interception are not supported
Use of ExpressRoute circuits with Microsoft Peering are supported

Internal network controls may also need to be modified to permit protocols used with Network Name Resolution (NNR) (among others). NNR performs fingerprinting that greatly enriches sensor data by translating IP address information into computer names.

Design decisions

Decision point	Design decision	Justification
Enable NNR	Use all primary and secondary NNR methods	Enrich threat detection data

Network issues can be troubleshooted by checking the sensor logs.

Server configuration

A number of pre and post-deployment tasks must be performed on servers to enable sensor installation and ensure they can operate to their full capabilities. The Test-MdiReadiness.ps1 script exists to assess compliance with several prerequisite server configurations. Guides also exist to address the following key configurations:

Event collection - ensure the correct events are audited and included in Windows event logs
Directory Service accounts (DSA) - ensure servers can be queried for entities found in network, event and trace data
Security Account Manager Remote (SAM-R) protocol - ensure Directory Service accounts can query and identify remote accounts
Action account - ensure MDI can take remediation actions on potentially compromised accounts

Design decisions

Decision point	Design decision	Justification
Additional event collection	Collect all events important to MDI¹	Enhance threat detection
Use of Directory Service accounts	Use Group Managed Service Accounts (gMSA) with read-only permissions	Enhance threat detection while securing and simplifying credential management across servers
Use of SAM-R protocol	Enable the Directory Service account to perform SAM-R queries²	Enable lateral movement detection
Use of action accounts	Use the default LocalSystem account and do not reuse Directory Service accounts³	Enable response actions while applying the principle of least privilege

1: Different server roles have different event collection requirements.

2: Enabling SAM-R can replace permissions used in the domain, enable in audit mode first.

3: Action accounts require write permissions on user accounts to perform actions.

Sensor types and deployment options

Two sensor types are available for installation: the classic (versions 2.x) sensor, and the new (versions 3.x) sensor.

While the new sensor can be installed on Windows Server 2019 and newer, it does not offer the same feature parity and protections as the classic sensor, in addition:

The new sensor can currently only be installed on Domain Controllers running Windows Server 2019 and newer
The new sensor is installed and updated via Microsoft Defender for Endpoint (MDE), and so requires the server to be onboarded to MDE and have appropriate server licensing

The classic sensor is not affected by the above constraints and can also be deployed as a standalone sensor.

Standalone sensors are classic sensors installed on separate servers with port mirroring from identity servers and a number of additional configurations (compared to an integrated deployment). Standalone sensor deployments are used in environments where integrated sensors are not able to be installed, and where more isolation is required due to network design, separation of services, or infrastructure capacity. Standalone sensor deployments, by virtue of the sensor’s isolation from the identity servers they protect, are also not able to offer the same feature parity as integrated sensor deployments.

Design decisions

Decision point	Design decision	Justification
Sensor types/versions	Install classic (versions 2.x) sensors	Maximise threat detection and response capabilities
Sensor deployment options	Deploy integrated senors (not standalone sensors) where possible	Maximise threat detection and response capabilities and minimise complexity

Deployment scope

MDI sensors should be installed on all Domain Controllers in all forests, even forests with no trust, and including read-only Domain Controllers; and on all AD FS, AD CS, and Entra Connect servers, even in clustered configurations.

Design decisions

Decision point	Design decision	Justification
Sensor deployment scope	Deploy sensors to all applicable servers	Maximise threat detection and response capabilities

Licensing

MDI is enabled at the tenant level requiring all users that benefit from the service to have an E5 or equivalent license assigned.

Investigating deployment issues

Critical health issues with sensors will be displayed in the Defender portal.

Each sensor’s logs should also be checked after deployment to ensure the completeness of its capabilities are enabled and not being blocked by misconfigurations or other issues.

The New-MDIConfigurationReport PowerShell command can be a helpful tool to validate System Access Control Lists (SACLs) and the presence of the MDI related Group Policy Objects (GPOs).

Known issues may also provide insights into deployment or operation anomalies.

Operational considerations

The following should be considered before using MDI:

Updating sensors

Sensors update automatically. It is possible to enabled delayed update on classic (versions 2.x) sensors in the Defender portal’s Identities settings section. The delayed update setting will stage an update for 72 hours before deployment, which may be useful in mitigating the impacts of failed updates. New (versions 3.x) sensor updates can be similarly staged via MDE deployment rings.

Entity tagging

Entity tagging can enhance the sensitivity of threat detection and response capabilities for important users, groups and devices. Tags can be viewed and applied in the Defender portal’s Identities settings section, with three types of tags supported:

The Sensitive tag for users, devices and groups - apply to high-value or sensitive assets like administrative or senior executive accounts and workstations
The Honeytoken tag for users and devices - apply to accounts created specifically to lure malicious actors
The Exchange server tag for devices - assign to Microsoft Exchange servers¹

1: MDI will also automatically tag Exchange servers and a number of other sensitive users, groups and devices.

Design decisions

Decision point	Design decision	Justification
Entity tagging	Apply entity tags to all applicable users, groups and devices	Help protect high-value or sensitive assets

Alerting

Some MDI alerts require learning periods to identity patterns of behaviour which can take up to 30-days to confirm. During the learning period it can be useful for MDI operators to enable the test mode in the Defender portal’s Identities settings section. Test mode sets applicable alert thresholds to low, triggering alerts sooner and more frequently, enabling MDI users to experience alerts, observe identity behaviour, and gain familiarity with their environment. When test mode is disabled, thresholds return to their default setting of high. While keeping alert threshold set to high is recommended, thresholds can be changed if necessary.

Exclusions

MDI detection and response actions can be excluded for specific IP addresses, computers, domains and users, and can be excluded globally or for specific detection rules. Excluding actions can be useful to reduce false positives, focus on critical issues, or to avoid unnecessary investigations into legitimate activities. Situations where exclusions could be considered include, suppressing alerts triggered by a security scanning tool, or preventing a break glass or service account from being disabled.

ASD's Blueprint for Secure Cloud