CrowdStrike

Identity Protection and MFA

Prestataire Informatique RODRIGUEZ

03/29/2026

  1. Identity Protection and MFA
    1. Identity Protection Overview
      1. About Falcon Identity Protection
        1. Requirements
        2. Setup
          1. On-premises Active Directory
          2. Cloud integrations
        3. Falcon Flight Control support
          1. Requirements
      2. Understanding Falcon Identity Protection
      3. Falcon Identity Protection pages
        1. Monitor
        2. Identity-based Incidents
        3. Policy
        4. Reports
        5. Threat Hunter
        6. System notifications
        7. Administration
      4. Using Identity Protection in Falcon Fusion SOAR workflows
    2. Identity Monitoring
      1. Identity Protection Monitoring
        1. Domain Security Overview
          1. Goal
          2. Scope
          3. Risk Score
          4. Score Trend
          5. Risk Matrix
          6. Entities
          7. Risk
        2. Monitor insights by category
          1. Understand different categories
            1. Trend graph
            2. Entity table
              1. Entity actions
            3. Entity attribute icons
          2. Privileged identities
            1. Identity protection privileges overview
          3. Users
          4. Endpoints
          5. Non-human identities
          6. Risk analysis
          7. Event analysis
        3. Use custom insight filters
        4. Manage and view entities
          1. Overview tab
          2. About tab
            1. Business card / endpoint information
              1. Linked accounts
            2. Privileges
            3. Local administrators
            4. Azure AD Roles
              1. Viewing a role’s members
              2. Exporting role members
            5. Groups
              1. About groups
              2. Viewing a group’s members
              3. Exporting group members
          3. Assets tab
            1. Endpoints
            2. Applications
            3. Top destinations
            4. Assigned subscriptions
          4. Activity tab
          5. Risk tab
          6. Timeline tab
          7. Entity actions
            1. Authorizers
              1. Manage authorizers
      2. Identity-based Incidents, Detections, and Risks
        1. Identity-based Incidents, Detections, and Risks
        2. Incidents and policy
        3. View identity-based detections
          1. View overview info about identity-based detections
          2. View details of identity-based detections
            1. View full details of an identity-based detection
            2. Modify identity-based detections
            3. Use identity-based detections as triggers in workflows
          3. Filter dashboards
            1. Manage custom filters
        4. View identity-based incidents
          1. Incidents page structure
          2. Use the Filter box
          3. Understand incident status
            1. Change the status of a single incident
            2. Change the status of multiple incidents to the same status
          4. Identity-based Incident details
            1. View related events
          5. Identity-based Detection Exceptions
            1. View exceptions
            2. Add exceptions to an alert
            3. Acknowledge & Trust
          6. Detection Settings
            1. Detections aggression level
            2. Geolocation configuration
        5. Appendix A: Detection reference
          1. 51126 - Access from blocklisted location
            1. MITRE ATT&CK® tactics and technique
            2. Investigate
            3. Exclusion scenarios
            4. Remediate
          2. 51124 - Access from IP with bad reputation
            1. MITRE ATT&CK® tactics and technique
            2. Investigate
            3. Exclusion scenarios
            4. Remediate
          3. 51127 - Access from multiple locations concurrently
            1. MITRE ATT&CK® tactics and technique
            2. Investigate
            3. Exclusion scenarios
            4. Remediate
          4. 51125 - Access from unusual geolocation
            1. MITRE ATT&CK® tactics and technique
            2. Investigate
            3. Exclusion scenarios
            4. Remediate
          5. 51110 - Anomalous RPC (account discovery)
            1. MITRE ATT&CK® tactics and technique
            2. Investigate
            3. Exclusion scenarios
            4. Remediate
          6. 51114 - Anomalous RPC (credential access)
            1. MITRE ATT&CK® tactics and technique
            2. Investigate
            3. Exclusion scenarios
            4. Remediate
          7. 51114 - Anomalous RPC (remote services)
            1. MITRE ATT&CK® tactics and technique
            2. Investigate
            3. Exclusion scenarios
            4. Remediate
          8. 51111 - Anomalous RPC (scheduled task)
            1. MITRE ATT&CK® tactics and technique
            2. Investigate
            3. Exclusion scenarios
            4. Remediate
          9. 51115 - Anomalous RPC (valid accounts)
            1. MITRE ATT&CK® tactics and technique
            2. Investigate
            3. Exclusion scenarios
            4. Remediate
          10. 51104 - Anomalous RPC (ZeroLogon)
            1. MITRE ATT&CK® tactics and technique
            2. Investigate
            3. Exclusion scenarios
            4. Remediate
          11. 51128 - Bronze Bit exploit
            1. MITRE ATT&CK® tactics and technique
            2. Investigate
            3. Exclusion scenarios
            4. Remediate
          12. 51121 - Credential scanning (Active Directory)
            1. MITRE ATT&CK® tactics and technique
            2. Investigate
            3. Exclusion scenarios
            4. Remediate
          13. 51122 - Credential scanning (web-based)
            1. MITRE ATT&CK® tactics and technique
            2. Investigate
            3. Exclusion scenarios
            4. Remediate
          14. 51109 - DC PsExec execution
            1. MITRE ATT&CK® tactics and technique
            2. Investigate
            3. Exclusion scenarios
            4. Remediate
          15. 51139 - Excessive activity from multiple endpoints
            1. MITRE ATT&CK® tactics and technique
            2. Investigate
            3. Exclusion scenarios
            4. Remediate
          16. 51140 - Excessive activity to multiple endpoints
            1. MITRE ATT&CK® tactics and technique
            2. Investigate
            3. Exclusion scenarios
            4. Remediate
          17. 51116 - Forged PAC attack
            1. MITRE ATT&CK® tactics and technique
            2. Investigate
            3. Exclusion scenarios
            4. Remediate
          18. 51100 - Golden Ticket attack
            1. MITRE ATT&CK® tactics and technique
            2. Investigate
            3. Exclusion scenarios
            4. Remediate
          19. 51123 - Hidden object discovered
            1. MITRE ATT&CK® tactics and technique
            2. Investigate
            3. Exclusion scenarios
            4. Remediate
          20. 51143 - Identity verification denied
            1. MITRE ATT&CK® tactics and technique
            2. Investigate
            3. Exclusion scenarios
            4. Remediate
          21. 51142 - Identity verification timed out
            1. MITRE ATT&CK® tactics and technique
            2. Investigate
            3. Exclusion scenarios
            4. Remediate
          22. 51118 - NTLM relay activity
            1. MITRE ATT&CK® tactics and technique
            2. Investigate
            3. Exclusion scenarios
            4. Remediate
          23. 51158 - OverWatch Identity detection
            1. MITRE ATT&CK® tactics and technique
            2. Investigate, Exclusion scenarios, Remediate
          24. 51119 - Password brute force attack (Active Directory)
            1. MITRE ATT&CK® tactics and technique
            2. Investigate
            3. Exclusion scenarios
            4. Remediate
          25. 51120 - Password brute force attack (web-based)
            1. MITRE ATT&CK® tactics and technique
            2. Investigate
            3. Exclusion scenarios
            4. Remediate
          26. 51144 - Policy rule match (access)
            1. MITRE ATT&CK® tactics and technique
            2. Investigate
            3. Exclusion scenarios
            4. Remediate
          27. 51146 - Policy rule match (account event)
            1. MITRE ATT&CK® tactics and technique
            2. Investigate
            3. Exclusion scenarios
            4. Remediate
          28. 51147 - Policy rule match (detection)
            1. MITRE ATT&CK® tactics and technique
            2. Investigate
            3. Exclusion scenarios
            4. Remediate
          29. 51145 - Policy rule match (federated access)
            1. MITRE ATT&CK® tactics and technique
            2. Investigate
            3. Exclusion scenarios
            4. Remediate
          30. 51148 - Privilege escalation (Azure service principal)
            1. MITRE ATT&CK® tactics and technique
            2. Investigate
            3. Exclusion scenarios
            4. Remediate
          31. 51131 - Privilege escalation (endpoint)
            1. MITRE ATT&CK® tactics and technique
            2. Investigate
            3. Exclusion scenarios
            4. Remediate
          32. 51113 - Privilege escalation (user)
            1. MITRE ATT&CK® tactics and technique
            2. Investigate
            3. Exclusion scenarios
            4. Remediate
          33. 51169 - Short-lived account usage
            1. MITRE ATT&CK® tactics and technique
            2. Investigate
            3. Exclusion scenarios
            4. Remediate
          34. 51108 - Suspicious domain replication
            1. MITRE ATT&CK® tactics and technique
            2. Investigate
            3. Exclusion scenarios
            4. Remediate
          35. 51168 - Suspicious account alteration
            1. MITRE ATT&CK® tactics and technique
            2. Investigate
            3. Exclusion scenarios
            4. Remediate
          36. 51117 - Suspicious Kerberos ticket reuse
            1. MITRE ATT&CK® tactics and technique
            2. Investigate
            3. Exclusion scenarios
            4. Remediate
          37. 51133 - Suspicious lateral movement
            1. MITRE ATT&CK® tactics and technique
            2. Investigate
            3. Exclusion scenarios
            4. Remediate
          38. 51106 - Suspicious LDAP search (Kerberos misconfiguration)
            1. MITRE ATT&CK® tactics and technique
            2. Investigate
            3. Exclusion scenarios
            4. Remediate
          39. 51159 - Suspicious LDAP search (AD-CS reconnaissance)
            1. MITRE ATT&CK® tactics and technique
            2. Investigate
            3. Exclusion scenarios
            4. Remediate
          40. 51105 - Suspicious LDAP search (accounts)
            1. MITRE ATT&CK® tactics and technique
            2. Investigate
            3. Exclusion scenarios
            4. Remediate
          41. 51163 - Suspicious LDAP search (ML)
            1. MITRE ATT&CK® tactics and technique
            2. Investigate
            3. Exclusion scenarios
            4. Remediate
          42. 51164 - Suspicious web-based activity (ML)
            1. MITRE ATT&CK® tactics and technique
            2. Investigate
            3. Exclusion scenarios
            4. Remediate
          43. 51160 - Anomalous certificate-based authentication
            1. Investigate
            2. Exclusion scenarios
            3. Remediate
          44. 51161 - Anomalous certificate-based authentication (user mismatch)
            1. Investigate
            2. Exclusion scenarios
            3. Remediate
          45. 51162 - Anomalous certificate-based authentication (unusual TGS request)
            1. Investigate
            2. Exclusion scenarios
            3. Remediate
          46. 51141 - Suspicious machine alteration
            1. MITRE ATT&CK® tactics and technique
            2. Investigate
            3. Exclusion scenarios
            4. Remediate
          47. 51102 - Suspicious protocol implementation (NTLM relay)
            1. MITRE ATT&CK® tactics and technique
            2. Investigate
            3. Exclusion scenarios
            4. Remediate
          48. 51101 - Suspicious protocol implementation (Pass the Hash)
            1. MITRE ATT&CK® tactics and technique
            2. Investigate
            3. Exclusion scenarios
            4. Remediate
          49. 51103 - Suspicious protocol implementation (valid accounts)
            1. MITRE ATT&CK® tactics and technique
            2. Investigate
            3. Exclusion scenarios
            4. Remediate
          50. 51165 - Unusual access to a user entity (Kerberoasting)
            1. MITRE ATT&CK® tactics and technique
            2. Investigate
            3. Exclusion scenarios
            4. Remediate
          51. 51132 - Unusual access to an application
            1. MITRE ATT&CK® tactics and technique
            2. Investigate
            3. Exclusion scenarios
            4. Remediate
          52. 51135 - Unusual login to an endpoint
            1. MITRE ATT&CK® tactics and technique
            2. Investigate
            3. Exclusion scenarios
            4. Remediate
          53. 51137 - Unusual service access to an endpoint
            1. MITRE ATT&CK® tactics and technique
            2. Investigate
            3. Exclusion scenarios
            4. Remediate
          54. 51129 - Use of stale endpoint
            1. MITRE ATT&CK® tactics and technique
            2. Investigate
            3. Exclusion scenarios
            4. Remediate
          55. 51130 - Use of stale user account
            1. MITRE ATT&CK® tactics and technique
            2. Investigate
            3. Exclusion scenarios
            4. Remediate
          56. 51153 - Skeleton key attack
            1. MITRE ATT&CK® tactics and technique
            2. Investigate
            3. Exclusion scenarios
            4. Remediate
          57. 51155 - Suspicious LDAP search (KrbRelay)
            1. MITRE ATT&CK® tactics and technique
            2. Investigate
            3. Exclusion scenarios
            4. Remediate
          58. 51156 - Honeytoken account alteration
            1. MITRE ATT&CK® tactics and technique
            2. Investigate
            3. Exclusion scenarios
            4. Remediate
          59. 51157 - Honeytoken account activity
            1. MITRE ATT&CK® tactics and technique
            2. Investigate
            3. Exclusion scenarios
            4. Remediate
        6. Appendix B: Risk factors
      3. Identity Protection Reports
        1. Overview
        2. Scheduling and saving reports
          1. Scheduling options
          2. Scheduling a report
          3. Downloading a report
        3. Predefined reports
        4. Custom reports
      4. Identity Protection System Notifications
        1. Identity Protection System Notifications
        2. Notification types
        3. Domain and connector monitoring
          1. Configuration process
          2. Step 1. Install the Foundry app
          3. Step 2. Configure the Fusion SOAR workflow
    3. Investigation
      1. Identity Protection Threat Hunter
        1. Identity Protection Threat Hunter
        2. Saving custom reports
    4. Identity Protection Configuration
      1. Identity Protection Administration
        1. Overview
        2. Domains
          1. Domain management
          2. Domain controller monitoring status
          3. Domain controllers activity graph
        3. Domain Controller hosts
        4. Subnets
          1. Add a subnet
          2. Check distribution of subnet configuration
        5. MFA connectors
          1. Set up the Falcon Identity Verification Dialog
            1. Falcon Identity Verification Dialog requirements
          2. Instant messaging providers
            1. Microsoft Teams
              1. Integration process
              2. Step 1. Confirm an existing, configured Entra IDaaS connector
              3. Step 2. Configure the Microsoft Teams SOAR Actions plugin in the CrowdStrike Store
              4. Step 3. Confirm the Identity Protection Microsoft Teams connector
            2. Slack
              1. Integration process
              2. Step 1. Configure the Slack v2 SOAR plugin in the CrowdStrike Store
              3. Step 2. Confirm the Identity Protection Slack connector
          3. Cloud-based MFA providers
            1. Supported cloud-based MFA data connectors
            2. Microsoft Entra MFA (including Legacy Microsoft Entra MFA)
              1. Integration process
              2. Step 1. Obtain the tenant domain and assign a secret to the Entra Multi-Factor auth client
              3. Step 2. Configure the Entra MFA connector in the Falcon console
            3. CyberArk Identity
              1. Integration process
                1. Step 1. Get your Tenant URL and Tenant ID values from CyberArk Identity
                2. Step 2. Create an authentication profile in CyberArk Identity
                3. Step 3. Create an authentication policy in CyberArk Identity
                4. Step 4. Create an OAuth 2.0 client and service account in CyberArk Identity
                5. Step 5. Configure the CyberArk Identity connector in the Falcon console
            4. Duo
              1. Prerequisites
              2. Integration process
            5. Entrust
              1. Integration process
                1. Step 1. Create an Authentication API application in Entrust IDaaS
                2. Step 2. Add a resource rule to your Authentication API application in Entrust IDaaS
                3. Step 3. Note user details in Entrust IDaaS
                4. Step 4. Configure the Entrust MFA connector in the Falcon console
            6. ForgeRock
              1. Prerequisites
              2. Integration process
              3. Step 1. Configure the ForgeRock journey
              4. Step 2. Configure the ForgeRock MFA connector in the Falcon console
            7. TOTP-compatible authentication application
              1. Prerequisites
              2. Integration process
            8. RSA Cloud Authentication Service (CAS)
              1. Prerequisites
              2. Integration process
              3. Use RSA CAS assurance levels in Identity Protection Policy
            9. Okta Verify
              1. Prerequisites
              2. Integration process
              3. Step 1. Create a service account and API key in Okta
              4. Step 2. Configure the Okta Verify connector in the Falcon console
            10. OneLogin
              1. Prerequisites
              2. Integration process
              3. Step 1. Create API credentials in OneLogin
              4. Step 2. Configure the OneLogin connector in the Falcon console
            11. Symantec
              1. Prerequisites
              2. Integration process
            12. PingID
              1. Integration process
            13. Cloud MFA (protocol based)
              1. Integration process
          4. On-premises MFA providers
            1. Set up the CrowdStrike on-premises MFA enablement tool
              1. Prerequisites
              2. Create an API client
              3. Install the CrowdStrike on-premises MFA enablement tool interactively
              4. Install the CrowdStrike on-premises MFA enablement tool using the command-line
              5. Remove the CrowdStrike on-premises MFA enablement tool
            2. Supported on-premises MFA data connectors
            3. RADIUS-based
              1. Prerequisites
              2. Integrate Cloud Microsoft Entra MFA using NPS extension
              3. Integrate generic RADIUS servers
            4. RSA Authentication Manager (RSA AM)
              1. Integration process
                1. Step 1. Import the RSA AM server certificate into the on-premises MFA enablement tool
                2. Step 2. Enable the SecurID authentication API in RSA AM
                3. Step 3. Create an authentication agent in RSA AM
                4. Step 4. Configure the RSA AM connector in the Falcon console
          5. FalconID MFA
        6. IDaaS connectors
          1. Microsoft Entra ID (entity and activity ingestion)
            1. Prerequisites
            2. Integration process
              1. Step 1. Create an application in Entra ID and grant it the required permissions
              2. Step 2. Get your Tenant Domain value
              3. Step 3. Get your Application ID and Application Secret values
              4. Step 4. Create a custom role with access to read RBAC properties
              5. Step 5. Configure the Microsoft Entra ID connector in Identity Protection
          2. Okta SSO
            1. Prerequisites
            2. Integration process
        7. OIDC integrations
          1. Device conditions
          2. Entra ID EAM
            1. Prerequisites
            2. Integration process
              1. Step 1. Create a Falcon OIDC client for Entra EAM
              2. Step 2. Create an Entra ID external authentication method
              3. Step 3. Configure your Microsoft MFA policy
          3. Okta
            1. Prerequisites
            2. Integration process
              1. Step 1. Create a Falcon OIDC client for Okta
              2. Step 2. Create an Identity provider in Okta
              3. Step 3. Create an authenticator in Okta
        8. Risk Configuration
          1. Manage compromised password detection
            1. Manage the HaveIBeenPwned dictionary
            2. Manage the custom passphrases dictionary
          2. Manage risk detection
        9. Settings
          1. Email notifications
            1. Configure email notifications
          2. Audit Log
          3. Time Zone
          4. MFA Branding
          5. Business Privileges
            1. Configure business privileges
        10. Appendix A: IP addresses used to contact third-party services
        11. Appendix B: ForgeRock MFA journey example
      2. Identity Protection Policy
        1. Overview
        2. Understand triggers
        3. Understand conditions
        4. Understand actions
        5. Manage Identity Protection rules
          1. Create Identity Protection rules
          2. Edit Identity Protection rules
            1. Add rule conditions
          3. Delete Identity Protection rules
          4. Duplicate a policy rule
          5. Re-order policy rules
          6. Check distribution of policy rules
        6. Configure multi-factor authentication (MFA)
          1. Verify identity by using MFA
          2. Delegate MFA to an external Federation integration
            1. Define an Identity Protection policy rule that responds to a Federated Access trigger:
        7. Configure policy settings
          1. Settings distribution
          2. Fail mode
          3. Fallback identity verification connector
          4. MFA UI Fallback Timeout
        8. View policy analytics
        9. Use rule templates
          1. Anomalous authentication
          2. Anomalous geographic login to Federated applications
          3. Application authentication
          4. Block honeytoken activity
          5. Compromised password detected
          6. Inactive user access
          7. Privileged user protection from compromised password
          8. Privileged user secured authentication
          9. Privileged users access control
          10. Restrict RDP (programmatic)
          11. Restrict workstation authentication (admins)
      3. Identity Protection in Fusion SOAR
        1. Overview
        2. Create a workflow based on an Identity Detection trigger
          1. Requirements
          2. Steps
        3. Create a workflow to send email notifications about identity detections
          1. Requirements
          2. Steps
        4. Create workflows to enforce MFA for users and endpoints involved in EPP detections
          1. Requirements
          2. Procedure overview
          3. Step 1: Create a Fusion SOAR workflow to add users and endpoints involved in detections to the Identity Protection watchlist
          4. Step 2: Create a second workflow to remove users and endpoints from the Identity Protection watchlist when the detection is resolved
          5. Step 3: Create Identity Protection policy rule to enforce MFA for watched users
          6. Step 4: Create an Identity Protection policy rule to enforce MFA for watched endpoints
        5. Create a workflow to enforce MFA when an alert is triggered
          1. Requirements
          2. Steps
        6. Create a workflow to enrich detections with Identity context
          1. Requirements
          2. Steps
        7. Create a workflow to revoke Entra and Okta sessions and Entra tokens
          1. Requirements
          2. Steps
    5. Falcon Privileged Access
      1. Falcon Privileged Access Overview
        1. Overview
        2. Requirements
        3. Understanding JIT
          1. JIT triggers
            1. Microsoft Teams trigger
              1. Teams trigger requirements
            2. Entra EAM trigger
              1. Entra EAM trigger requirements
          2. JIT end user experience
            1. Automatic JIT policy user experience
            2. By-request JIT policy user experience
              1. Authorizer JIT requests
            3. MFA user experience
          3. Permission sets
          4. Privilege duration and expiration
            1. Continuous evaluation
        4. Monitoring JIT
        5. Managing JIT privileges
          1. Create a JIT policy
          2. Edit a JIT policy
          3. Delete a JIT policy
          4. Disable JIT
          5. View JIT audit events
      2. Just-in-Time Access for Entra ID
        1. Overview
        2. Requirements
        3. JIT setup for Entra ID
        4. Create a JIT policy for Entra ID
      3. Just-in-Time Access for AD Groups
        1. Overview
        2. Requirements
        3. Create a JIT policy for AD groups
      4. Falcon Privileged Access in Fusion SOAR
        1. Overview
        2. Create a workflow to revoke active JIT permission assignments
          1. Requirements
          2. Steps
    6. Identity Protection Integration
      1. Integrating Identity Protection with AD FS
        1. Overview
          1. Requirements
        2. Falcon Identity Protection integration with AD FS
        3. Configure Falcon Identity Protection for AD FS integration
          1. Create an API client
          2. Allow AD FS to access Falcon Identity Protection
            1. Trust the Falcon Platform Certificate Authority (CA) certificates
        4. Set up the Identity Protection AD FS Adapter
          1. Install the Identity Protection AD FS Adapter
          2. Enable the AD FS Authentication Adapter
          3. Modify the AD FS Authentication Adapter Configuration
      2. Integrating Identity Protection with PingFederate
        1. Overview
          1. Requirements
        2. Configure Falcon Identity Protection for integration
          1. Create an API client
          2. Allow PingFederate to access Falcon Identity Protection
            1. Trust the Falcon platform Certificate Authority (CA) certificates
        3. Configure PingFederate for integration
          1. Deploy the adapter in PingFederate
            1. Download and install the PingFederate adapter
            2. Set up the adapter in PingFederate
          2. Configure PingFederate integration
            1. Configure enforcement by Falcon
            2. Configure external enforcement
            3. Get host information from PingFederate
        4. Troubleshooting
          1. Enable debug logging from the Identity Protection adapter
    7. FalconID
      1. FalconID
        1. Overview
          1. Requirements
          2. How FalconID works
          3. Understanding the CrowdStrike Falcon app capabilities
          4. FalconID passkey and enrollment considerations
          5. FalconID network considerations
          6. Setting up FalconID
          7. Before you begin
        2. Configure Identity Protection to use FalconID
          1. Add the FalconID connector
          2. Create a policy rule for FalconID
        3. Enroll users with FalconID
          1. View FalconID users and enrollment status
          2. Send invitation emails to users
          3. Reinvite users
          4. Delete invitations
          5. Complete enrollment on a mobile device
        4. FalconID authentication
          1. Example authentication workflows
            1. Example workflow: Cross-device direct authentication
            2. Example workflow: Cross-device indirect authentication
            3. Example workflow: Same-device direct authentication
            4. Example workflow: Same-device indirect authentication
        5. View FalconID audit log entries

Identity Protection and MFA

Monitor user traffic and behavior in your organization.

Discover how to secure human, non-human, and AI identities across on-premises, cloud, and SaaS environments with Falcon Identity Protection and MFA. This comprehensive solution monitors user traffic and behavior, detects anomalies, and enforces real-time threat prevention and IT policy enforcement.

  • Identity Protection Overview: Understand how Falcon Identity Protection monitors traffic to build user behavioral profiles to help identify unusual user behavior.
  • Identity Monitoring: Monitor user activity, detect unusual behavior, and identify and manage potential security threats.
  • Investigation: Proactively search through raw events to detect and identify security events using Threat Hunter.
  • Identity Protection Configuration: Configure MFA, Identity Protection policies, Fusion SOAR workflows, and Just-in-Time Access to effectively safeguard your environment and respond to risk.
  • Identity Protection Integration: Integrate Falcon Identity Protection with your existing federation software.

Identity Protection Overview

Understand how Falcon monitors traffic to build user behavioral profiles to help identify unusual user behavior.

About Falcon Identity Protection

Falcon Identity Protection monitors network traffic to build user behavioral profiles to help identify unusual user behavior. It enables frictionless Zero Trust security with real-time threat prevention and IT policy enforcement through the use of identity, behavioral, and risk analytics.

Requirements

Subscription:

  • Falcon Identity Threat Detection

  • Falcon Identity Threat Protection

Domain Controller OS: Falcon sensor supports domain controllers on Windows 2008 R2 or later.

Roles: These roles have access to Falcon Identity Protection:

  • Falcon Administrator

  • Falcon Security Lead

  • Falcon Investigator

  • Falcon Analyst - read only

  • Endpoint Manager

  • Identity Protection Policy Manager

  • Identity Protection Domain Administrator

Setup

Identity Protection Overview
On-premises Active Directory
To set up Falcon Identity Protection, you must deploy the Falcon sensor for Windows on your domain controllers. The Falcon sensor adds visibility, threat detection, and enforcement to Microsoft Active Directory.
Tip: You can use the Identity Protection onboarding wizard to guide you through the onboarding process. Go to Identity protection > Monitor > Onboarding.

When installed on a domain controller, the Falcon sensor collects domain info, processes network traffic, and evaluates and enforces policy rules in your environment.

This solution combines simple deployment with ease of management, and eliminates the need for additional resources.

To deploy Falcon Identity Protection, follow these high-level steps:

  • Install the Falcon sensor for Windows on your domain controllers.

    See Falcon Sensor for Windows Deployment.
    Note: If you decided during provisioning that Identity Protection should not be automatically enabled on domains, you must enable each domain before Identity Protection will work. For more info, see Domain management.
  • Configure the IDP Domain and Connector Monitoring Falcon Foundry application, along with Fusion SOAR workflows, to proactively alert you to connector and domain issues. See Domain and connector monitoring.

  • Optionally, integrate Falcon Identity Protection with your existing federation software.

    See:

Cloud integrations
Enhance your Falcon Identity Protection experience by integrating with the following cloud services:
  • Entra ID Identity as a Service (IDAAS): Extend Identity Protection’s visibility and threat detection capabilities to all of your cloud applications protected by Entra ID, enabling the scenario where Identity Protection correlates SSO activities to the cloud-only and hybrid user accounts. For more info, see Microsoft Entra ID (entity and activity ingestion).
  • Okta SSO: Extend Identity Protection’s threat detection capabilities to all of your cloud applications protected by Okta, enabling the scenario where Identity Protection correlates SSO activities to the hybrid user accounts. For more info, see Okta SSO.
  • AWS IAM Identity Center: Gain access to additional detections, risk insights, and enhanced visibility by configuring the AWS IAM Identity Center integration. For more info, see Plan Your AWS Registration.
  • Entra ID EAM: Improve your Microsoft Entra ID security posture with Entra ID external authentication method (EAM) OIDC integration in Falcon. For more info, see Entra ID EAM.
To correlate between cloud reported activities and the Falcon sensor and support device policy access conditions in OIDC integrations, set up the Falcon browser extension on end user devices by following these steps:
  1. In the Falcon console, go to Host setup and management > Manage endpoints > Browser extension policies .
  2. Make sure you have a policy with Enable automatic installation selected. For more info, see Falcon Browser Extension.

Falcon Flight Control support

Falcon Identity Protection is supported in multi-CID enterprise organizations with Falcon Flight Control. Contact Support. For US-GOV-1 and US-GOV-2 customers, contact Support to configure optimal Identity Protection performance.

For more information about Falcon Flight Control environments, see Falcon Flight Control and Multi-CID Support.

Requirements

  • A parent CID that has a Falcon Identity Protection subscription enabled

  • All domain controllers of a specific domain must be in a single CID
If the domain controllers are not in the same CID as an endpoint, the following limitations apply:
  • Push-only MFA. No MFA prompt is displayed on that endpoint.
  • Local administrator and guest account risks cannot be calculated.
  • Falcon installed and ZTA score conditions cannot be calculated.
Tip: To avoid these limitations, install domain controllers in a parent CID where all the endpoints in a domain are in the child CIDs of the parent.

Understanding Falcon Identity Protection

Falcon Identity Protection identifies enterprise threats with a high degree of accuracy without adding significant overhead to help ensure that legitimate business activities are not disrupted.

By monitoring traffic both inside and outside your network, Falcon Identity Protection builds user behavioral profiles that can help identify anomalous user behavior.

In the initial training stage, which typically takes around two weeks, Falcon Identity Protection learns the behavior of every user, including when and where they log in, their role in the organization, the systems they access, the computers they use, the strength of their passwords, and other relevant info. For each user, a profile is created and a risk score is assigned.

Falcon Identity Protection builds these baselines of individual user behavior to identify anomalies that might indicate attacks or unauthorized access attempts. Baselines are built from data gathered by the Falcon Identity Protection detection engine and from third-party solutions such as cloud SSO, and other sources.

Over time, a user’s profile is updated as the network and the user’s behavior evolves, such as with new user roles and actions.

After the baselines are established, you can apply a policy to remediate issues without requiring intervention. Falcon Identity Protection can block traffic, notify administrators, or require that the user performs multi-factor authentication.

If a policy is in place, Falcon Identity Protection can detect when users misuse resources either intentionally or because an attacker has stolen their identity or credentials.

When Falcon Identity Protection detects a threat, it takes the appropriate action based on a configured policy.

Falcon Identity Protection pages

This section gives an overview of the functionality Falcon Identity Protection provides, and links to in-depth documentation.

The Falcon Identity Protection app consists of these pages:

Monitor

The Domain Security Overview page gives you the tools you need to better evaluate the risks and threats to which your network is exposed, enhancing the organizational security posture.Domain security overview page

It provides you with an overview of your environment and indicates whether your environment follows best security practices.

For example, you can see how many privileged users there are and how this number has changed over time, whether you are using unmanaged endpoints, how many users have compromised or GPO exposed passwords, and more.

You can find more information about entity trends in your environment with the following dashboards: Users, Privileged identities, Non-human identities.

For more information, see Identity Protection Monitoring.

Identity-based Incidents

The Identity-based Incidents page lets you better evaluate the security events occurring in your system and take the necessary actions to mitigate the risks they pose.Identity-based incidents page

You can act on the incidents directly from the page. You can manage the incident life cycle, add notes, filter, sort, examine, and perform forensic analysis of incidents.

For more information, see Identity-based Incidents, Detections, and Risks.

Policy

The Policy Rules page is used to define a number of rules that determine what actions to take in response to certain triggers observed in your environment. These triggers can be authentication requests, alerts, or account changes, such as updating your password.

Each rule can have a set of conditions that must be met for the rule to apply. The combination of these rules forms your Identity Protection policy.


Define a number of rules that determine what actions to take in response to certain triggers observed in your environment

Each rule in your policy is made up of the following three components:

  1. Trigger: Defines what invokes the rule.

  2. Conditions: Any number of requirements that must be met for the rule to apply.

  3. Actions: Defines what the rule does when its trigger occurs and all its conditions are met.

For more info, see:

Reports

The Reports page allows administrators to perform a number of report oriented activities that include:

  • Saving predefined reports.

  • Scheduling the download and distribution of predefined reports.

  • Reviewing a list of saved predefined and custom reports.

Reports can be defined and downloaded immediately, or scheduled for later downloading and distribution. Most reports can be distributed in PDF or CSV formats. Depending on the type of info in a report, it might be limited to one format type though.

To view the Reports page, go to Identity protection > Configure > Reports.

For more information, see Identity Protection Reports.

Threat Hunter

Threat Hunter enables security analysts to proactively search through raw events, detect and identify security events, or further investigate security events reported by the system.

You can create your own search criteria, which you can save for use at a later stage, or you can use a predefined search. You can also modify a predefined search and save it for later use.

To display Threat Hunter, go to Identity protection > Explore > Threat Hunter.

For more information, see Identity Protection Threat Hunter.

System notifications

System Notifications displays events that might require your attention. The number of active notifications is also shown in parenthesis.

To display the system notifications, go to Identity protection > Configure > System notifications.

You can filter notifications as follows:

  • All Notifications

  • Connectors

  • Software Update

  • System Coverage

For more information, see Identity Protection System Notifications.

Administration

You can configure these aspects of your Identity Protection environment:

  • MFA connectors: Configure integrations for multi-factor authentication (MFA).

  • IDaaS connectors: Configure integrations for Identity as a Service (IDaaS).

  • OIDC integrations: Configure integrations for OpenID Connect (OIDC).

  • Domain Controller hosts View the traffic inspection status of each DC host.

  • Domains: View the domains monitored by Identity Protection.

  • Subnets: Configure subnets for use in Identity Protection.

  • Settings: Configure miscellaneous parameters.

  • Risk Configuration: View and configure Compromised Password Detection for your network.

For more information, see Identity Protection Administration.

Using Identity Protection in Falcon Fusion SOAR workflows

For info about how you can combine Identity Protection policy rules with Fusion SOAR workflows to increase security, see Identity Protection in Fusion SOAR.

Identity Monitoring

Identity Protection Monitoring

Understand and evaluate the risks and threats your network is exposed to so you can enhance your security posture.

Domain Security Overview

The Domain Security Overview page gives you the tools you need to better evaluate the risks and threats to which your network is exposed, enhancing the overall security posture.

Laying out the foundations for a better network security, company executives and security and risk teams members can gain an immediate insight into the overall network risks based on a specific objective. Go to Identity protection > Monitor > Domain security overview to grasp at a glance the risk level and the priorities facing your organization from the attack surface perspective, so you can timely implement efficient mitigation steps.Domain security overview page

It provides you with an overview of your environment and indicates whether your environment follows best security practices.

For example, you can see your risk score and how this number has changed over time, how many privileged users there are, a list of your highest risks, and more.

Goal

You can address different goals, each characterized by the specific risks. Whether you are preparing for pen testing or working on an AD Hygiene project, select the corresponding option from the Goal list to align the overview page to the specific requirements. The following goals are available:

Goal Description

AD Hygiene

Assesses the risks related to AD management and auditing: password vulnerabilities, suspicious privilege modifications, and stealthy privileges.

Pen Testing

Evaluates the security of your network by performing a simulated cyber attack, known as penetration test or pen test for short.

Privileged Users Management

Assesses the risks related to the management of privileged user accounts on critical devices and applications.

Reduce Attack Surface

Warns you about the different attack vectors that can be exploited in an attempt to enter data to or extract data from your network environment.
Scope

This option allows you to limit the scope of the security assessment by one of the network domains monitored by Identity Protection.Limiting the scope of the security assessment

Risk Score

This is an overall security risk score, with 10 being maximum risk, for the currently selected domain.An example risk meter

The issues that contributed to the risk score are listed below in descending order of severity. This allows you to identify the most critical issues of the greatest consequence and focus on their remediation.

Score Trend

This graph shows the general direction of changes in the risk score during the last few weeks, helping you to measure the security enhancement progress.Plot of the score trend over time

Clicking a date in the graph shows the risk score, and the risks for the selected date.

Risk Matrix

The matrix shows the risks rated by likelihood and consequences:

  • Likelihood is based on the Identity Protection research team’s extensive knowledge and reflects the easiness of exploiting a vulnerability in combination with commonly known attack vectors. The degrees of likelihood are: Unlikely, Possible, and Likely.

  • Consequences denote the severity of a specific event’s impact on the organization’s security posture. The consequences might range from the attacker taking over a specific account to moving laterally in the network or taking over the entire domain, and in each case the vulnerability is rated accordingly. The consequences can be: Minor, Moderate, and Major.

The various risk levels are color-coded as follows:

  • Red: Indicates high risks that present the most serious and far-reaching threats. To improve the organization's security posture, these risks must be targeted without delay.

  • Orange: Indicates medium risks that must be closely monitored and investigated and resolved or mitigated at the earliest.

  • Green: Indicates low risks that must be resolved at the earliest convenience.

The number inside the shape denotes the current number of risk factors with the same likelihood and impact.

For example, according to the following example matrix, there are, among others, one Unlikely low risk item with Minor consequences and four Possible medium risk items with Moderate consequences:The matrix of risks, likelihood vs. consequences

Entities

This panel contains the most up-to-date information about the current number of accounts, users, endpoints, and privileged users in the domain or tenant.

Note: This panel only displays if the current date is selected in the Score Trend graph.
Risk

These are the different factors that negatively affect the security assessment score.


Risks are displayed in a table format.

You can expand each of the risks contributing to the currently displayed risk score and learn about its nature and how it can be reduced or neutralized.

To view the entities involved in the risk or affected by it, click Show Related Entities. This opens a side panel with the list of entities that can be investigated individually, saved as a CSV file, or as a Custom Insight.

Monitor insights by category

You can monitor the information by using the category tabs at the top of the page:

Understand different categories

Category pages each provide the following functionality:

  • Use the Interval drop-down to limit the results to this from the Last Day, Last Week, Last Month, or a custom timeframe.

  • Use the subcategory tiles to choose the type of data to display. These tiles, which are different for each category, show the number of entities in the subcategory and the change in that number during the selected interval.
    Tip: You can scroll through the tiles using arrows at each end of the row.

  • The trend graph shows how the number of entities in the selected subcategory has changed during the selected interval. For more info, see Score Trend.

    • Use the Filter button to define filters on the displayed entities and display exactly the cross section of data you require, save a filter as a Custom Insight, or apply a saved Custom Insight.

  • The entity table lists all the entities in the selected subcategory, with some additional data about them, and the option to select an entity and perform an action on it. For more info, see Entities.
    Tip: Click an entity name to see its summary panel. Click the name again in the summary panel to view all of the details on the Entity page. For more info, see Manage and view entities.

    • If you click CSV from the Save as drop-down menu, a CSV file of the data displayed in the Entity Table is downloaded to your workstation.

    • If you click PDF from the Save as drop-down menu, a PDF file showing the data displayed in the Trend and in the Entity Table is generated and downloaded to your workstation.

    Note: The CSV and PDF reports display the current status of included entities. For example, if you generate a report of all entities that were stale 7 days ago, but some of them are no longer stale, the report will list their current status. However, the report will correctly include all of the entities that were stale at that time.

  • On the Privileged Identities, Users, Endpoints, Non-Human Identities, and Custom Insights pages, if you click Custom Report from the Save as drop-down menu, the New Custom Report dialog opens so that you can define the details for saving and distributing the data displayed in the Entity Table as a Custom Report. The report is saved as per your selections and added to the Saved Reports list on the Reports page. For more info, see Identity Protection Reports.

Trend graph

Privileged identities trend graph

The figure above is an example of the Trend graph of privileged user entities detected during the last week.

If you click a point in the graph, the number of entities is displayed in the box that is opened at the point, and the net change is displayed in the summary statistics below.

Entity table

The Entity table lists the entities satisfying the criteria defined by the Category, Interval and selected subcategory, or by a filter or Custom Insight, together with additional data about them.


A number of entities in the entity table.

The Entity table includes these columns:

Column Description

Type

Icons indicate one of these types:

  • Human user
  • Programmatic user
  • Azure service principal
  • Endpoint
  • Group

Primary Name

From the entity’s account.

Secondary Name

Used to uniquely identify an entity, using a format depending on the entity type.

For example, an AD managed user entity might use the format DOMAIN/sAMAccountname.

Department

From the entity’s account.

Org Unit

From the entity’s account.

Attributes

Icons that indicate entity attributes. Hover the pointer over an icon to see a description.

For a complete list of entity attribute icons, see Entity attribute icons.

hover over icon to see description

Score

The entity’s risk score.

Actions menu (⋮)

Allows you to perform an action on the relevant entity. See Entity actions.

Entity actions

In addition to the entity actions described in the Entities section, there are additional actions available for entities within the table.

Action Description

Exclude From Insight

This entity is not displayed in this specific Insight. For example, Disaster Recovery accounts which are stale by definition. To view excluded accounts, click the Excluded counter above the list.

Include in Insight

Reverse the Exclude From Insight action.

You can also perform actions on multiple lines or on all lines by selecting the checkboxes to the left of each line or to select all lines, by selecting the checkbox to the left of the heading label Type. As soon as you select a checkbox, a drop-down action menu appears on the right, from which you can select an action to perform on all the selected entities.

Entity attribute icons
Entity attribute icons help you quickly identify different types of entities. If you need more detailed info, you can open the entity’s summary panel.
Tip: Click an entity name to see its summary panel. Click the name again in the summary panel to view all of the details on Identity Protection Monitoring.
Table 1.
Entity attribute Description Icon
Application Server The endpoint is an application server. Application server
Authorized The account has an authorizer or authorizers. For more info, see Authorizers. Authorized
Cloud only The entity only exists on the Azure AD Tenant. Cloud only
Compromised Password The user has a password that Identity Protection has evaluated as vulnerable to being guessed using dictionary attacks. Compromised password
Deleted Account The account was deleted. Deleted account
Disabled The account has been disabled. Disabled
DNS Server A domain name server that stores the DNS records for the domain. DNS server
Domain Controller The server computer processes security authentication requests (logging in, checking permissions, etc.) within a Windows domain. Domain controller
Executive The user account belongs to an executive. Executive
File Server The endpoint is a file server. File server
GPO Exposed Password The user has a password that is likely to become known, or might have already become known, to persons that should not know it, for example a password found in Group Policy Preference objects. GPO exposed password
Honeytoken The user account is intended to deceive an attacker into using the account. Honeytoken
Hybrid account The account exists on both the on-premises Active Directory Domain and the Azure AD Tenant. Hybrid account
Inactive The user account has been dormant or inactive for between 21 and 90 days. Inactive
Locked The account is locked. Locked
Mail Server The endpoint is a mail server. Mail server
Marked The user has been singled out by security analysts for special attention so that they can easily identify them throughout the Falcon console. The user remains marked for 48 hours. Marked
Never Logged In The user account has never logged into an endpoint. Never logged in
Privileged The user or entity has permissions beyond those of a typical user or entity. For more info, see Identity protection privileges overview. Privileged
Programmatic A user account not belonging to a human user. Programmatic
Server The endpoint is a server. Server
Shared Endpoint The endpoint is used by multiple users. Shared endpoint
Shared User The privileged user logs in from multiple locations. Shared user
Stale The user account has been dormant or inactive for more than 90 days. Stale
Unmanaged Endpoint The endpoint is not registered in the domain and does not have any Group Policies running on it. Unmanaged endpoint
VDI Endpoint The endpoint is a virtual desktop infrastructure endpoint. Identity Protection considers being an administrator on greater than 5% of total endpoints to be excessive. VDI endpoints are capped at contributing 3% of the 5% threshold, and each VDI endpoint is considered to be one-tenth of a physical endpoint when performing the calculation. VDI endpoint
Watched A user that security administrators should pay special attention to, for example, users under notice or who have resigned or who for whatever reason are believed to be motivated to cause harm to the organization. Watched
Privileged identities

Privileged identities are users or entities that have permissions beyond those of a typical user or entity. Identity protection tracks and analyzes privileged identities to reduce unintended risk to your system.

There are many types of privileges, which can be obtained in many ways. For more information, see Identity protection privileges overview.

These are the Insights menu subcategories when the Category is Privileged Users:

Subcategory Description

Privileged

Shows all privileged users and the change in their number during the selected interval.

Best practice: Minimize the number of privileged users.

Stealthy

Shows a list of accounts that have privileges that were not obtained through AD protected groups. In some cases, those privileges might have been granted by mistake. Attackers might target such accounts because they are not as well protected as built-in privileged accounts.

Using Unmanaged Endpoints

Shows the privileged users who are using unmanaged endpoints, which are endpoints not registered in the domain and on which Group Policies are not running. Unmanaged endpoints are considered to be at greater risk of exposure to viruses and other malicious software, so privileged users put themselves and the organization at greater risk by using them.

Best practice: Ensure that privileged users are not using unmanaged endpoints.

Stale

A stale user is one whose account has been dormant or inactive for more than three months. Stale users pose a risk because they are unlikely to be monitoring their email and can remain unaware of suspicious activity conducted in their accounts. A programmatic stale privileged user (a process or service rather than a human) poses the risk of a broken or out-of-date process with excessive privileges that can be leveraged by attackers.

Best practice: Periodically (every 90 days) monitor stale users and delete or disable any that are found.

Password Never Expires

While it might be acceptable in restricted contexts for some programmatic users to have passwords that never expire, it is considered unacceptable for human users because it affords attackers an unlimited time frame to eventually guess passwords by brute-force attacks. Also, this might be an indication that the human user is running scripts, which should be done only from accounts dedicated to that purpose.

Best practice: Enforce a policy that users must periodically change their passwords.

Compromised Password

Compromised passwords are vulnerable to being guessed using dictionary attacks. Identity Protection evaluates the strength of user passwords and marks as compromised those it finds as vulnerable.

Best practice: Require as a policy that users use strong passwords.

High Risk

Privileged users with risk scores greater than 7.5 are labeled High Risk. You can define a Custom Insight to define high-risk privileged users using other criteria.

GPO Exposed Password

A GPO exposed password is one that is likely to become known, or might have already become known, to persons to whom it should not be known, for example a password found in Group Policy Preference objects. A privileged user with a GPO exposed password poses an exceptional risk, more so than a nonprivileged user.

Best practice: Review the Group Policy and ensure that GPO Exposed Passwords are not used.

Shared

A privileged user who logs in from multiple locations.
Identity protection privileges overview

Privileged access puts your system at higher risk because it allows an entity to bypass standard controls and execute privileged operations that are not available to a standard account. For this reason, Identity protection tracks and analyzes privileged entities.

Privileges can be granted to an entity in many different ways, either directly or stealthily. For example, a user is considered privileged if they belong to a protected group or a nested group inside a protected group. Alternatively, a user is considered stealthy if their rights are granted using a direct delegation of the ACL and not through group membership.

You can also define an entity as privileged using custom configuration of Identity Protection through the Business Privileges function. To configure business privileges, go to Identity protection > Configure > Settings. For more information, see Business Privileges.

The following table gives a complete list of privileges and the way they are granted.

Table 1. Identity protection privilege determination
Privilege Description Granted by
Account Operator Can create, modify, and delete accounts for users, computers, groups and locations in the Users or Computers containers and organizational units in the domain, except the Domain Controllers organizational unit Being a member of Account Operators protected group
Administrator Has full control of all domain controllers in the domain Being a member of Administrators protected group
Administrative Group Controller A stealthy privilege type that indicates an entity has permission to add members to a group that is privileged (or can become one) The permission is calculated by examining which non-administrative groups and users are allowed to modify the list of members of the administrative group by either:
  • Having direct access to the group’s member list, either by having Control Access or by having Write permissions on MEMBERS_ATTR
  • Having access to create children of the administrative group, either a user or a group. See RIGHT_DS_CREATE_CHILD
For more info, see How to remove Administrative Group Controllers privileges?. For US-GOV-1 and US-GOV-2 customers, see How to remove Administrative Group Controllers privileges?
Administrator Password Controller A stealthy privilege type that indicates an entity has permission to change the password of another entity that is privileged (or can become one) The permission is calculated by examining which non-administrative groups and users have Reset password permission or can edit the userPassword attribute.

For more info, see How to remove Administrator Password Controller privileges?
Any Azure Privileged Has any Azure privileges Having any of the following privileges:
  • Azure Access Privileges
  • Azure Application Privileges
  • Azure Credentials Privileges
  • Azure Global Privileges
  • Azure Security Privileges
Any Privileged Account Service Delegation Common ancestor type of service delegation type privileges Having any of the following privileges:
  • Unconstrained Privileged Account Service Delegation
  • Constrained Privileged Account Service Delegation
For more info, see How to remove Constrained/Unconstrained Account Service Delegation privileges?. For US-GOV-1 and US-GOV-2 customers, see How to remove Constrained/Unconstrained Account Service Delegation privileges?
Azure Access Privilege Has Azure access privileges Having one of the following Azure AD Roles:
  • Conditional Access Administrator
  • External Identity Provider Administrator
Azure Application Privilege Has control over cloud applications Having one of the following Azure Administrative Roles:
  • Application Administrator
  • Cloud Application Administrator
  • Exchange Administrator
Azure Credentials Privilege Has control over user credentials Having one of the following Azure Administrative Roles:
  • Authentication Administrator
  • Privileged Authentication Administrator
  • Helpdesk Administrator
  • Password Administrator
  • User Administrator
  • Authentication Policy Administrator
Azure Global Privilege Has full control over the tenant Having one of the following Azure Administrative Roles:
  • Global Administrator/Company Administrator
  • Privileged Role Administrator
Azure Security Privilege Can manage security-related features in Azure Having one of the following Azure Administrative Roles:
  • Security Administrator
  • Security Operator
Backup Operator Can back up and restore all files on domain controllers in the domain, regardless of individual permissions on those files Being a member of Backup Operators protected group
Builtin Administrator Has full control over the system Being a member of Builtin Administrators protected group
Business Privilege Having any of the custom-configured Business Privileges Custom configuration of Identity Protection through the Business Privileges function. A user or a group is added manually with privileges by assigning the group or user to the Business Privileges and signaling to the system that the users or group members are privileged beyond the AD management.

To configure business privileges, go to Identity protection > Configure > Settings. For more information, see Business Privileges.
Certificate Publisher Allowed to publish certificates for users in Active Directory The endpoint is a member of the Cert publishers Active Directory group

For more info, see Certificate Authority Servers and related attack paths in Identity Protection. For US-GOV-1 and US-GOV-2 customers, see Certificate Authority Servers and related attack paths in Identity Protection.
Constrained Privileged Account Service Delegation A stealthy privilege type that indicates an entity is permitted to access specific resources on behalf of privileged users The permission is calculated by examining which non-administrative groups and users have delegation permissions on an administrator that allows delegation.

For more info, see How to remove Constrained/Unconstrained Account Service Delegation privileges?. For US-GOV-1 and US-GOV-2 customers, see How to remove Constrained/Unconstrained Account Service Delegation privileges?
Domain Admin Has full control of the domain Being a member of Domain Admins protected group
Domain Controller A server computer that processes security authentication requests (logging in, checking permissions, etc.) within a Windows domain Having all of the following:
  • The endpoint is part of AD Site
  • Member of Domain Controllers protected group
Domain Level Admin Common ancestor type of domain level type privileges Having any of the following privileges:
  • Administrator
  • Builtin Administrator
  • Domain Admin
  • DomainControllersAdminRole
  • Krbtgt Account
  • Read-Only Domain Controller
Effective Replicator A stealthy privilege type that indicates an entity has permission to replicate domain information, including hashes The permission is calculated by examining which non-administrative groups and users have Replicating Directory Change All permission on the domain.

For more info, see How to remove Effective Replicator privileges?. For US-GOV-1 and US-GOV-2 customers, see How to remove Effective Replicator privileges?
Enterprise Admin Has full control of all domains in the forest Being a member of Enterprise Admins protected group
Extensive Local Administrator An entity which is a local administrator on many Endpoints (except Domain Admins) Identity Protection considers greater than 5% of total endpoints to be excessive. VDI endpoints are capped at contributing 3% of the 5% threshold, and each VDI endpoint is considered to be one-tenth of a physical endpoint when performing the calculation.
Forest Level Admin Common ancestor type of forest level type privileges Having any of the following privileges:
  • Enterprise Admins
  • Schema Admins
Krbtgt Account A service account that is used by the Key Distribution Center (KDC) service Being a member of the KRBTGT protected group
Object-SID History Takeover A stealthy privilege type that indicates an entity receives privileges granted by the ‘sidHistory’ Active Directory attribute. The sidHistory attribute represents a list of previous SIDs of the object, which it can have if it was moved from another domain. For an example of a possible danger, see Unsecure SID History attributes. The risk is calculated by examining which non-administrative groups and users have a privileged objectSID in their Object-SID History.

For more info, see How to remove Object-SID History Takeover privileges?
Operator Level Admin Common ancestor type of operator level type privileges Having any of the following privileges:
  • Account Operators
  • Backup Operators
  • Print Operators
  • Replicators
  • Server Operators
Permissions On Account Controller A stealthy privilege type that indicates an entity is allowed to modify the list of accounts that have effective privileges on an administrator. In actuality, this stealthy privilege occurs when an entity is permitted to gain control over an administrator account by modifying its ACL. The privileges are calculated by examining which non-administrative groups and users have one of the following permissions: For more info, see How to remove Permissions On Account Controller privileges?. For US-GOV-1 and US-GOV-2 customers, see How to remove Permissions On Account Controller privileges?
Print Operators Can manage, create, share, and delete printers connected to domain controllers in the domain and Active Directory printer objects in the domain Being a member of the Print Operators protected group
Privileged Common ancestor type of all admin privileged (Any Administrative) Having any of the privileges in this table
Privileged Application Controller A stealthy privilege type that indicates an entity has an Azure role that can add credentials to an administrative application, and use it to login as a privileged application, or that it is an owner of a privileged application The privileges are calculated by examining which non-administrative groups and users have either:
  • One of the following Azure roles, in an environment in which there is at least one privileged application:
    • Application Administrator
    • Cloud Application Administrator
    • Exchange Administrator
  • Direct ownership of a privileged application
For more info, see How to remove Privileged Application Controller privileges?. For US-GOV-1 and US-GOV-2 customers, see How to remove Privileged Application Controller privileges?
Read-Only Domain Controller A Domain Controller within a Windows domain that stores a read-only copy of the Active Directory database Being a member of the Read-Only Domain Controllers protected group
Replicator Supports directory replication functions and is used by the File Replication service on domain controllers in the domain Being a member of the Replicators protected group
Schema Admin The Schema Admins group is authorized to make schema changes in Active Directory Being a member of the Schema Admins protected group
Server Operator Can log in interactively, create and delete shared resources, start and stop some services, backup and restore files, format the hard disk, and shut down the computer Being a member of the Server Operators protected group
Stealthy Administrators Common ancestor type of effective admin type privileges (all stealthy admins) Having any of the following privileges:
  • Administrative Group Controller
  • Administrator Password Controller
  • Unconstrained Privileged Account Service Delegation
  • Constrained Privileged Account Service Delegation
  • Effective Replicator
  • Object-SID History Takeover
  • Permissions On Account Controllers
  • Privileged Application Controller
Unconstrained Privileged Account Service Delegation A stealthy privilege type that indicates an entity is permitted to access any resources on behalf of privileged users The permission is calculated by examining which non-administrative groups and users have delegation permissions on an administrator that allows delegation.

For more info, see How to remove Constrained/Unconstrained Account Service Delegation privileges?. For US-GOV-1 and US-GOV-2 customers, see How to remove Constrained/Unconstrained Account Service Delegation privileges?

Privileges are arranged in a hierarchy that allows you to focus on multiple related privileges at once. For example, filtering for Any Privileged Account Service Delegation returns all entities with either Unconstrained Privileged Account Service Delegation or Constrained Privileged Account Service Delegation privileges.

Privileges hierarchy:
  • Any Administrative
    • Stealthy Administrator
      • Administrative Group Controller
      • Administrator Password Controller
      • Any Privileged Account Service Delegation
        • Unconstrained Privileged Account Service Delegation
        • Constrained Privileged Account Service Delegation
      • Effective Replicator
      • Object-SID History Takeover
      • Permissions On Account Controllers
      • Privileged Application Controller
    • Any Azure Privileged
      • Azure Access Privileges
      • Azure Application Privileges
      • Azure Credentials Privileges
      • Azure Global Privileges
      • Azure Security Privileges
    • Domain Level Admins
      • Administrators
      • Builtin Administrators
      • Domain Admins
      • Domain Controllers
      • Krbtgt Accounts
      • Read-Only Domain Controllers
      • Certificate Publishers
    • Forest Level Admins
      • Enterprise Admins
      • Schema Admins
    • Operator Level Admins
      • Account Operators
      • Backup Operators
      • Print Operators
      • Replicators
      • Server Operators
    • Extensive Local Administrators
    • Business Privilege
Users

These are the Insights menu subcategories when the Category is All Users:

Subcategory Description

High Risk

Users with risk scores greater than 7.5 are labeled High Risk. You can define a Custom Insight to define high-risk users using other criteria.

Password Never Expires

It is considered unacceptable for human users to have passwords that never expire because it affords attackers an unlimited time frame to eventually guess passwords by brute-force attacks. Also, this might be an indication that the human user is running scripts, which should be done only from accounts dedicated to that purpose.

Best practice: Require as a policy that users must periodically change their passwords.

Compromised Password

Compromised passwords are vulnerable to being guessed using dictionary attacks. Identity Protection evaluates the strength of user passwords and marks as compromised those it finds are vulnerable.

Best practice: Require as a policy that users use strong passwords.

GPO Exposed Password

A GPO exposed password is one that is likely to become known, or might have already become known, to persons to whom it should not be known, for example a password found in Group Policy Preference objects.

Best practice: Review the Group Policy and ensure that GPO Exposed Passwords are not used.

Shared

A user who logs in from multiple locations.

Stale

A stale user is one whose account has been dormant or inactive for more than three months. Stale users pose a risk because they are unlikely to be monitoring their email and can remain unaware of suspicious activity conducted in their accounts.

Best practice: Periodically (every 90 days) monitor stale users and delete or disable any that are found.

Marked Users

A marked user is one whom security analysts have singled out for special attention so that they can easily identify them throughout the Falcon console. A user remains marked for 48 hours by default.

Watched Users

A watched user is one to whom security administrators should pay special attention, for example, users under notice or who have resigned or who for whatever reason are believed to be motivated to cause harm to the organization.

Honeytoken

An account flagged as honeytoken is used to deceive an attacker to use those accounts. Account activities or changes will trigger a dedicated detection that indicates potential malicious activities in the network. For more information, see the Knowledge Base article, What are the best practices for setting up honeytoken accounts in Falcon Identity Protection?
Endpoints

These are the Insights menu subcategories when the Category is Endpoints:

Subcategory Description

High Risk

Endpoints with risk scores greater than 7.5 are labeled High Risk. You can define a Custom Insight to identify high-risk endpoints using other criteria.

Unmanaged

An unmanaged endpoint is one not registered in the domain, and on which Group Policies are not running.

Shared

Endpoints from which multiple users log in, for example, a kiosk.

Unmanaged Used by Privileged Users

Unmanaged endpoints from which privileged users log in.

Shared Used by Privileged Users

Shared endpoints from which privileged users log in. These represent a risk because attackers or malware on the shared endpoint might be able to locate traces of an administrator’s password that remain even after the administrator has logged out.

Stale

A stale endpoint is one that has not been used for more than three months.
Non-human identities

Non-human identities are digital identities for applications, services, or devices such as service accounts. Identity protection tracks and analyzes non-human identities to reduce unintended risk to your system.

These are the subcategories on the Non-Human Identities tab:

Subcategory Description

From Active Directory

Non-human identity from the Active Directory. This list includes accounts that were classified as programmatic automatically or manually.

From Entra ID

Entra ID-based non-human identities. This list includes Entra Service Principals defined in your environment.

Microsoft Entra service principals are security identities that applications, services, and automation tools used to authenticate and access specific Azure resources. They represent the local instance of an application within a specific tenant, enabling non-human access to protected resources. Organizations should implement the principle of least privilege with service principals, granting only the minimum permissions necessary for automated processes to function properly.

Privileged

Shows all privileged non-human identities and the change in their number during the selected interval.

Best practice: Minimize the number of privileged non-human identities.

Privileged from Active Directory

Privileged non-human identities from the Active Directory. This list includes accounts that were classified as programmatic automatically or manually.

Privileged from Entra ID

Privileged Entra ID-based non-human identities. This list includes Entra Service Principals defined in your environment.

High Risk

Non-human identities with risk scores greater than 7.5 are labeled High Risk. You can define a Custom Insight to define high-risk non-human identities using other criteria.

Medium Risk

Non-human identities with risk scores labeled Medium Risk. You can define a Custom Insight to identify medium-risk non-human identities using other criteria.

Low Risk

Non-human identities with risk scores labeled Low Risk. You can define a Custom Insight to identify low-risk non-human identities using other criteria.
Compromised Password

Compromised passwords are vulnerable to being guessed using dictionary attacks. Identity Protection evaluates the strength of user passwords and marks as compromised those it finds as vulnerable.

Best practice: Require as a policy that users use strong passwords.
Duplicate Password

Two or more user accounts share the same password. Using duplicated passwords across multiple accounts can lead to lateral movement and credential stuffing attacks if one account is compromised, resulting in a breach.

Best practice: Ensure each account has a unique password.
Stale

A stale non-human identity is one whose account has been dormant or inactive for more than three months. A stale non-human identity poses the risk of a broken or out-of-date process with excessive privileges that can be leveraged by attackers.

Best practice: Periodically (every 90 days) monitor stale non-human identities and delete or disable any that are found.
Watched A watched non-human identity is one to whom security administrators should pay special attention, for example, accounts that were detected as suspicious by external sources.
Stealthy Shows a list of non-human identities that have privileges that were not obtained through AD protected groups. In some cases, those privileges might have been granted by mistake. Attackers might target such accounts because they are not as monitored as other well known privileged accounts.
External Registered Application A service principal that represents an application registered in a different tenant has an External registered application attribute and the registered tenant field includes the external tenant ID only.

Tip: External applications that are registered in known Microsoft tenants also display this information.
Application Controllers

Users that have management authority over organizational applications and can leverage their permissions to perform administrative tasks related to those applications. These individuals manage Microsoft Entra service principals, which are security identities that applications and services use to authenticate and access Azure resources, with some applications potentially having privileged access.

Best practice: Implement proper governance for application controllers, carefully monitoring those who manage applications with elevated permissions while maintaining comprehensive audit trails of their activities.
Risk analysis

These are the Insights menu subcategories when the Category is Risk Analysis:

Subcategory Description

Membership by Severity

A bar graph showing the distribution of risk score by severity across OUs or Departments (depending on your selection) is displayed along with a detailed breakdown for each OU or Department.

Membership by Impact

A bar graph showing the distribution of risk score by impact across OUs or Departments (depending on your selection) is displayed along with a detailed breakdown for each OU or Department.

Membership by impact graph

The Risk Analysis - Membership by Impact page displays a four-quadrant graph. The X-axis plots the OU’s or Department’s risk scores and the Y-axis plots the impact of the scores, which indicates the potential damage the OU or Department poses to the enterprise. For example, OUs with a high risk score whose users have limited access privileges pose a lesser risk than OUs with the same high risk score whose users have extensive access privileges.

Outliers

The Risk Analysis page displays a four-quadrant graph by users. The X-axis plots the user’s risk scores and the Y-axis plots the impact of the user’s risk score, which indicates the potential damage the user poses to the enterprise. For example, users with a high-risk score and limited access privileges pose a lesser risk than users with the same high-risk score but with extensive access privileges.

Note: Identity Protection considers the following factors when assessing impact: the user’s business role, privileges, exchange delegations, and similar users.

Each of the quadrants in the graph represents a different combination of risk score and impact. Each bubble represents the number of users in a region of the graph (a given combination of risk score and impact). The larger the bubble, the greater the number of users in that region. Users in the upper-right quadrant (high impact, high risk score) are of the greatest concern, and you should investigate those as a priority. Users in the other quadrants pose less of a danger to the enterprise.

  • Hover over a bubble to view information about the users it represents.
  • Drag a rectangle over a bubble to zoom in and see its component bubbles (if there are any).
  • To reset the zoom factor to the default, click Reset zoom.
Event analysis
Note: Identity Protection includes Identity-Based Event Analysis dashboards, using the same customizable widget experience as other modules in the Falcon platform, to ease the investigation process. To view the dashboards, go to Identity Protection > Explore > Event analysis dashboard.

The table below lists the Insights menu subcategories when the Category is Events Analysis.

Subcategory Description

Top User Account Lockouts

Shows the number of top users by account lockouts.

Password Changes

Shows the number of password changes every day.

Account Modified

Shows the number of accounts modified every day.

New User Accounts

Shows the number of new user accounts created every day.

Disabled User Accounts

Shows the number of accounts disabled every day.

Top User Login Failures

Shows the number of top users with failed logins.

Login Failures by Error Code

Shows details of the reasons for logon failures.

Top Active User by Access

Shows details of the top users by service access events.

Login Failures by Department

Shows details of the login failures by department.

User logins by type

Shows the number of user logins by type, such as SSO, VPN, or Domain.

Click the button for each subcategory to show the total number of events for that subcategory that happened in your domain over the selected time period. The information is shown in either a logarithmic or linear bar chart. Click an event in the bar chart or in the list to view a detailed list of events on the Threat Hunter page.

Use custom insight filters

Custom insights are insights you can create with a custom filter and save for future use.

Filters enable you to display any cross-section of the entities in the Entity Table. You can define a filter to search for the relevant data and save it as a Custom Insight so that you can reuse it later.

When you define a filter, apply a custom insight, or change and save it, the Trend and Entity Table data changes accordingly.

  • To apply a custom insight filter, select it from the list.

  • To delete a custom insight filter, click the delete icon (X) in the upper-right corner, and then click Yes, Continue.

    Important: You cannot undo a deletion.

  • To define a custom insight filter:

    1. Click New Custom Insight.

    2. On the filter page, specify any of these applicable parameters:

      Tip: To reset all fields to the default values, click the menu icon, and then click Reset.

      • Entity Name: The full or partial name of an entity.

      • Endpoint Classification: Select the endpoint classification in the network. The available classifications include, but are not limited to, application server, DNS server, domain controller, Exchange Server, File Server, VDI (Virtual Desktop Infrastructure) endpoint, workstation, and more.

      • Group: Select or enter any Group that exists in the monitored domains.

      • Microsoft Entra Role: Select or enter any Azure AD Role that exists in the monitored tenant.

      • Entra join type: Limit the search by the Entra join type: Hybrid-joined, Joined, or Registered.

      • Risk Factors: Limit the search by any of the risk factors detected and prevented by Identity Protection.

      • Privileges: Select from the privileges assigned to the entity.

      • Has Incidents: To search for the entities with reported incidents, select Yes. To ignore whether the entity has reported incidents, select Any Or None.

      • Attributes: Select the entity’s attributes.

      • Domain / Tenant: Select any or all domains or tenants monitored by Identity Protection.

      • Organization Unit: This list contains the entire Organization Unit (OU) tree for every domain monitored by Identity Protection. To limit the search by an OU, select it in the list.

      • Department: Select from a list of all departments available in Active Directory.

      • Account Type: Select the entity’s account type: Any User, Endpoint, Group, Human, Programmatic or Role.

      • Business Privileges: Select from all available business roles.

      • Risk Severity: Specify a range of the entity’s risk severity values by dragging and dropping the ends of the scale.

      • Subscription Assigned Roles: Find entities that have the specified assigned role in any subscription.

      • Subscription Name: Find entities that have an assigned role in the specified subscription.

    3. To see the results of the filter in the Trend and the Entities table, click Apply.

    4. To save the filter as a custom insight:

      1. Click the menu icon, and then click Save As Custom Insight.

      2. Provide a title, and then click Save.

Manage and view entities

An Entity encapsulates and summarizes all the system information about an organizational or network entity. The most common entities are users and endpoints, but there are also entities representing Azure Service Principals and entity groups, such as Active Directory groups.

Tip: You can find more information about entity trends in your environment with the following dashboards: Users, Privileged identities, Non-human identities.

Entity objects are usually derived from external data sources. For instance, all user accounts in an Active Directory domain covered by Falcon Identity Protection are represented as entities.

Moreover, entities do not always represent a single account. An LDAP user, for example, might be correlated with an IDaaS account, resulting in a single, unified entity.

These hybrid and cloud-only entities are created when Identity Protection extracts data from either an Active Directory (AD) domain or an Entra tenant. We refer to Hybrid entities as those which exist on both the on-premises AD domain and the Entra tenant. Whereas we refer to cloud-only entities as those which only exist on the Entra tenant.

Click an entity’s name to open the entity profile overview panel. Click the entity name again or click More beside any panel name to open the full Entity page.Example of a user account in the entity details page

When the Entity page is fully expanded, you can navigate it by selecting any of the following tabs:

  • Overview

  • About

  • Assets

  • Activity

  • Risk

  • Timeline

Overview tab

The Overview tab provides a high-level summary of an entity's profile. The top section shows the entity name, their current risk score, their attributes represented as icons, and the time of their latest detected activity in the network latest activity in the network and on the cloud or other SSO sources latest activity in the cloud.

In addition, the top section includes a vertical ellipsis icon (⋮) that opens the Actions menu.

The rest of the Overview tab is made up of a number of panels, each corresponding to another tab—About, Activity, Assets, and Risk—and containing a subset of fields from the respective tab.

This unified view allows you to evaluate at a glance whether the user requires special attention. To delve into any particular set of user-related details, click More beside the respective panel name and the corresponding tab opens. When the Entity page is fully extended, the link More changes to the Show more bar below the panel.

About tab

This is a comprehensive set of data pertaining to each user or endpoint in the domain. It is comprised of the following categories, depending on the entity type, each represented in a separate card:

  • Business Card (Users and Groups) / Endpoint Information (Endpoints)

  • Privileges

  • Local Administrators

  • Azure AD Roles

  • Groups

Business card / endpoint information

This section contains information about users, groups, Azure Service Principals, or endpoints. Some of the data is gathered from identity providers such as Active Directory or Azure AD.

Item Description Entity Type

Enabled

 Yes or No

User, Endpoint
Source accounts The number of source accounts for the entity. Click See details to see the Data source, Account Name, Most Recent Activity, and Status of each source account.

User, Endpoint

Organizational Unit

A subdivision within an on-premises Active Directory to which the account belongs. This field shows the entire hierarchy, starting from the top organizational unit.

User, Endpoint, Group

Created

The date and time the account was created.

All

Account type

The account type of the entity. One of:

  • User,
  • Endpoint
  • Azure Service Principal
  • Group
  • Azure AD role
Note: accounts flagged as honeytoken will have this information displayed next to their account type.

All

Domain / Tenant

A list of the AD domains and tenants in which the account exists.

User, Group, Azure Service Principal

Title

The account owner’s title in the organizational structure.

User

Department

The department to which the account belongs.

User

Managed by

The account’s direct manager, as specified in an on-premises Active Directory.

User

Description

Entity description

User, Endpoint, Group

Email address

The account’s primary email address

User

Classification

Identity Protection learns accounts over time and classifies them as Human, Programmatic, or Executive.

To assist with classification, Identity Protection uses information such as:

  • the display name of the account
  • whether it has a phone number
  • whether it is used in scripts
  • whether the majority of authentications are interactive

If Identity Protection incorrectly classifies an account, you can alter it by clicking Classify As... and selecting the correct option.

Notes:
  • The account is classified as Unknown until the classification is determined.
  • User profiles continue to show notifications about learning the behavior until classification is completed and the first traffic is seen.

User, Endpoint

ZTA Score

The Zero Trust Assessment (ZTA) score given to the endpoint. ZTA scores are between 1 (insecure) and 100 (secure).

Endpoint

Last password change

A relative period when the latest account password change occurred, for example, a month ago. To see the exact time, hover over the relative time value.

User

Password policy strength

An evaluation of the password policy applied to the account. The evaluation considers both password length and complexity. Clicking See details displays the Password Policy (group or fine-grained) and its configuration parameters.

User

Entra ID registered authentication methods

A list of the user’s Entra ID registered multi-factor authentication methods. Clicking See details displays more info about the user’s Entra ID registered authentication methods.

You might see users with listed authentication methods but still receive an Account without MFA configured risk if the user does not have an authentication method that meets the organization policy in Entra ID.

User
Linked accounts A list of accounts that are linked to the entity. For more info, see Linked accounts. User

Distinguished name

An attribute used by Active Directory to uniquely reference the entity. It is often referred to as DN or FDN. It is a fully qualified path of the names that traces the entry back to the root of the tree. For example the distinguished name of a group entity called Partners could be: cn=silvapartners, ou=distribution, dc=silvalaw.com

Endpoint, Group

Enabled for users to sign-in

Specifies whether the service principal account is enabled, or not.

One of:

  • Yes (enabled)
  • No (disabled)

Azure Service Principal

Supported account types

The Microsoft accounts that are supported for the current application. Comes from the signInAudience property of Azure service principals.

One of:

  • Single tenant (AzureADMyOrg)
  • Multiple tenants (AzureADMultipleOrgs)
  • Personal accounts and multiple tenants (AzureADandPersonalMicrosoftAccount)
  • Personal accounts (PersonalMicrosoftAccount)

Azure Service Principal

Service principal object ID

The unique identifier of the service principal in Azure.

Azure Service Principal

Registered tenant ID

Specifies the type and ID of the tenant where the application is registered

One of:

  • External ({tenant ID})
  • External (Microsoft) ({tenant ID})
  • Registered App ({tenant name}) ({tenant ID})
  • Managed Identity ({tenant ID})

Azure Service Principal

Owners

The users who are configured in Azure as owners, and therefore have control over the application associated with the service principal.

Note: Shown if the service principal AND associated app are both in the same tenant

Azure Service Principal

Application ID

The unique identifier of the application associated with the service principal.

Azure Service Principal

App registration object ID

The Azure unique identifier of the app registration object associated with the app and service principal.

Note: Shown if the service principal AND associated app are both in the same tenant

Azure Service Principal

SPNs

The Service Principal Names (SPN) attribute of the user or endpoint.

Tip: Hover over an SPN and then click the Show Related Events icon to open Threat Hunter and see actual service usage:

Open Threat Hunter to see actual SPN service usage.

This can be a good starting point for additional investigations.

User, Endpoint

SID

The Security IDentifier (SID), is a unique ID number that a computer or domain controller uses to identify an entity. It is a string of alphanumeric characters assigned to each user on a Windows computer, or to each user, group, and computer on an on-premises domain-controlled network.

User, Endpoint, Group

Scope

Defines what types of objects can belong to the group, what types of groups the group can be a member of and the scope of objects that security groups can be given access to. Active Directory Domain Services defines three group scopes: Universal, Global and Domain Local.

Group

Type

Indicates whether a group is defined as a Security group, Distribution group, or Microsoft 365 group.

Group

Default AD group

Indicates whether the group is a built-in Active Directory group.

Group

Membership Type

Indicates Azure AD membership type of Assigned or Dynamic.

Group

AD Roles Enabled

Indicates if roles can be assigned to a cloud group in Azure AD.

Group

Operating system

Operating System name. For example, Windows 7 Enterprise 6.1.

Endpoint

Entra join type

Indicates the endpoint’s Entra join type: Hybrid-joined, Joined, or Registered.

Endpoint

Device ID

The endpoint’s Entra device ID.

Endpoint

Object Owner

Entra ID has a dedicated field for the device owners, represented in Identity Protection as endpoint owner. This property exists for eligible devices, in addition to analytic-based association for users that usually or uniquely use specific devices.

Endpoint

MDM

Mobile Device Management used to manage this device. For example, Intunes.

Endpoint

Compliant

Indicates whether the endpoint is configured as compliant by Entra ID.

Endpoint

Registration date

The endpoint’s Entra ID registration date.

Endpoint

Linked accounts

Linked accounts are two or more independent accounts that belong to the same person, for example, administrators that have a privileged account for their administrative tasks and a personal account for daily usage. Identity Protection uses ML algorithms to determine if two accounts are linked based on their properties. The most similar accounts are linked automatically. You can also manually link or unlink two accounts by following these steps:

  1. On the desired entity’s details page, click the Actions menu (⋮).
    Note: For entities that already have existing linked accounts, you can also click Manage linked accounts next to the Linked accounts field in the Business Card panel of the About tab.
  2. Click Manage linked accounts.
    Note: The Search for accounts field displays all of the accounts that are currently linked to this account. If there are no existing links then this field is blank.
  3. To remove an existing link, click the x next to its name.
  4. To add a link, enter the name of the account that you want to link to.
  5. Update the Search for accounts field until it displays all of the accounts that you want to link to.
  6. Click Save.

For more info about linked accounts, see Linked accounts in Identity Protection.

Privileges

This panel of the About tab is available only for Privileged accounts. It shows you the reasons why the account is classified as such. Privileged entities belong to protected groups or a nested group inside a protected group. For example, within Active Directory, a default set of highly privileged accounts and groups are considered protected accounts and groups.

An entity can become privileged for a number of reasons. For example, the entity has an Azure AD privileged role, belongs to a group with privileged role, or belongs to a nested group inside a privileged group.

Local administrators

Local Administrator is a user account that is allowed to perform any action on a local computer, but is unable to modify information in Active Directory for other computers and other users.

Important: Local administrator information requires the existence of a Falcon sensor on the endpoint.

Local administrators are commonly used as a starting point for penetrating the network and exploiting this breach to move laterally, gradually expanding the attack surface. This threat, however, usually remains siloed and can be detected only in the aftermath. Identity Protection retrieves information about local administrators based on deployed Falcon sensors.

  • In user accounts, the Local Administrators section contains the list of endpoints where the user has Local Administrator privileges as a domain group member, a domain user, or a local user.

  • In group accounts, the Local Administrators section contains the list of endpoints where the domain group members have Local Administrator privileges.

  • In endpoint accounts, the Local Administrators section contains the list of users that have Local Administrator privileges on this endpoint. To see when the latest query was performed, hover over the Information button adjacent to the section name.

The indication that a user account is also a Local Administrator on an endpoint appears in the user account's Assets tab.

A special case of the local administrator is a local account that controls access to a single endpoint, where local account credentials are stored. Local accounts can be duplicated if machines are created from the same image and inherit the same local administrator username and password. By compromising one of these machines, an attacker can extract the credentials from the local Security Account Manager (SAM) database and move laterally to other machines. This is why duplicated local accounts are considered a risk factor that will be detected during a security assessment. A local account defined on an endpoint is shown in the Local Administrators section of the endpoint's About tab. If this local account is duplicated on more than one machine, it will appear as: Local account (shared on X endpoints), where the number of endpoints is a link opening the list of endpoints in a side panel.

If no information is displayed in the Local Administrators section of an endpoint account, it might be due to any of the following reasons:

  • The endpoint is not a Windows machine. Local administrators cannot be defined on a non-Windows machine, therefore, no local administrator information can be retrieved from it.

  • The endpoint is a Domain Controller. Local administrators cannot be defined on a Domain Controller, therefore, no local administrator information can be retrieved from it.

  • A Falcon sensor isn’t detected on this endpoint. This could be because it is not yet installed or the Identity Protection subscription doesn’t exist for this CID.

    Note: It might take up to 24 hours after sensor deployment for a value to appear here.

  • The endpoint is not joined to the domain and is not covered by the local administrator’s query.

Users or groups that have a significant footprint as local administrators present a greater security risk and must be watched more closely.

  • Identity Protection considers being an administrator on greater than 5% of total endpoints to be excessive

  • VDI endpoints are capped at contributing 3% of the 5% threshold, and each VDI endpoint is considered to be one-tenth of a physical endpoint when performing the calculation.

Such accounts are classified as Extensive Local Administrators, which allows you to apply filters and create custom insights to monitor them.

Azure AD Roles

The Azure AD Roles panel of the About tab displays information retrieved from Azure Active Directory. The Azure AD Roles panel lists Azure Administrative Roles that the account holds in the tenant that is configured using the Azure IDAAS connector. Click a role to display a panel that lists the Role members and their attributes.

You can access roles:

  • From an entity's About page

  • By searching for them by name in the Search bar

  • By opening them from any point in the application in which they appear

Click an Azure AD role to open the Azure AD role overview page and view the role's members and a selection of their attributes.

Click an Azure AD role's name or icon to:

  • View the privileges granted to that role.

  • See a link to the description of the role.

Some Azure AD roles are considered privileged. For a list of Identity privilege types, see Identity protection privileges overview.

Viewing a role’s members

When you view a role's members the default view shows you all the entities that have the applicable role.

Exporting role members

You can export a list of a role's members and their attributes as a CSV file by clicking Export CSV located above the members list.

Groups

Groups display information retrieved from Active Directory and Azure AD that provides you with the context and scope within which the group operates, such as the group type, its members, and their connection to other entities.

You can access groups:

  • From an entity’s About page.

  • By searching for them by name in the Search bar.

  • By opening them from any point in the application in which they appear.

An entity’s About page lists the groups for which the entity is a member. A group that is marked with a crown icon indicates that the group is a privileged group, and that its members are privileged.

About groups

Click a group to open the group overview page and view the group's members, a selection of their attributes, and their risk score.

Click a group's name or icon to:

  • Drill down to view the group’s details as displayed in the group’s business card.

  • See if a group is nested within another group.

  • View the privileges of that group.

Note: Identity Protection tracks changes in group membership for all user accounts. However, auto-removal of a user from an AD group by an expiration date might not be immediately effective in Identity Protection.

Viewing a group’s members

One characteristic of a group is that they can be nested. When you view a group's members the default view shows you all the entities that belong to the group and its subgroups.

To view members that only belong to the selected group, click Show direct members only.

Exporting group members

You can export a list of a group's members and their attributes as a CSV file by clicking Export CSV located above the members list.

Assets tab

This tab includes the endpoints, applications, and top destinations that the user accesses often, which makes them part of their behavioral baseline. This information is available after Identity Protection gains visibility of the account traffic and determines usage patterns. Once assets are shown, they are used to detect anomalous activity and to define policy rules using the Baseline condition.

The tab contains the following sections:

Endpoints

This section lists the endpoints that the user regularly accesses. Each entry contains:

  • Endpoint name

  • IP

  • Last login time

  • Owner: this tag is added if this is the only user using this endpoint

  • Local administrator: this tag is added if the user is a local administrator of the endpoint.

Applications

This section lists applications that have been regularly accessed. Each entry contains:

  • Application Name

  • Last login time

Top destinations

This section contains a list of the servers the user RDPs to on a regular basis. Each entry contains:

  • Endpoint name

  • IP

  • Last login time

  • Local administrator: this tag is added if the user is a local administrator of the endpoint.

Assigned subscriptions

This section lists the assigned built-in roles for subscriptions an entity has in Azure. Each entry contains:

  • Subscription Name

  • Subscription ID

  • List of assigned built-in roles

Click Open menu in an entry to:

  • View all users assigned to the subscription

  • View the subscription details in Azure

Activity tab

This tab contains comprehensive information about the user's recent and current network activity.

These sections show info in the Activity tab:

Section Description

Login History

The history of the user's logins for the last 90 days, including the type of connection, the endpoint from which the login originated, its type and IP address, and the login date and time (to see the exact time, hover over the date). The connections shown here comprise, among others, LDAP, Kerberos, and Cloud SSO logins. The login geolocation is indicated on the map. Regular, unusual, and forbidden locations are color-coded, allowing you to quickly detect any anomaly. Clicking an endpoint in the table opens its profile in a side panel.

Note: Login geolocation is only available for SSO logins.

Logged On

The endpoints on which the user was recently active. This is determined by examining the LDAP GPO Searches performed in the last 4 hours. The information includes the endpoint type, its primary and secondary names, the department and organizational unit to which the endpoint belongs, its attributes (for example, Server, Privileged, and so on), its risk score, and the login date and time. Clicking an endpoint in the table opens its profile in a side panel.

Application Usage

This section contains the details about the user's access to cloud applications, including the application name, the type and IP address of the device used, and the access date and time (to see the exact time, hover over the date).

User sign-ins

Shows details about the users who have signed into an application that is associated with a service principal, including:

  • Primary: the Primary name of the user
  • Secondary: an alternative identifier assigned to the user by Identity Protection
  • Device type: details of the device used to perform the sign in
  • IP Address: IP of the device used to perform the sign in
  • Time: when the sign in occurred

On-Prem Service Access

This section contains the details about the user's access to services, including the originating endpoint, the service type, the destination, and the access date and time (to see the exact time, hover over the date).
Risk tab

This section shows the user's risk trend for the last 30 days and the main risk factors. Hovering over a date in the trend diagram shows the risk score on this particular date and its difference from the previous risk score.

Timeline tab

The Timeline is a chronologically presented series of events related to an account. The categories of events shown in the timeline include:

  • Alerts. These are the main components of incidents relating to the account.

  • Changes to the account. For example, the account name changed, it was disabled or deleted, or its authorizers were modified.

  • Changes in the state of the account. These state changes include the account becoming stale or inactive, or a compromised password was detected.

  • Policy rule matches. The account has matched the criteria for an existing Identity Protection policy.

Entity actions

These actions are available from the Entity actions menu. The actions menu differs according to the entity type and its attributes. For example, whether the entity is a user or an endpoint, on the watch list or not on the watch list, is Cloud Only or Hybrid, and other attributes.

Action Description

Mark entity

Mark the entity so that it can be easily identified elsewhere in the Falcon console. An entity remains marked for 48 hours by default.

Unmark entity

Unmark the entity. This action is only available for marked entities.

Add to watchlist

Add the entity to the watch list. This action also increases the entity’s risk score.

Remove from watchlist

Remove the entity from the watched list. This option appears only for watched entities.

Set classification

Override automatic classification. For example, the analyst can specify that an endpoint classified as a server is a workstation, or that a human user is actually an executive, or an unclassified user account is a programmatic account.

This is valuable when the user wants to override classification or speed up classification. Identity Protection does not change the analyst’s classification even if it determines that the entity should be classified otherwise.

Also, Identity Protection uses the analyst’s classification as input for its own classifications, for example, for determining similar users.

Note: Classifying an endpoint as an impersonator server causes Credential scanning or Password brute force attack detections from it to have a lower severity or be completely filtered out of detection results in some cases. Classifying an endpoint as an impersonation server causes Unusual login to an endpoint detections to be completely filtered out of detection results in all cases.

Manage authorizers

Specify a user, multiple users, or groups, who will authenticate other accounts when a policy requires authentication or verification.

Notifications that appear as Authorizers Changed are: authorizers added, authorizers removed, or the combination of both authorizers added and authorizers removed. For more information, see Authorizers.

Flag as honeytoken

Flag a specific entity as honeytoken. Account activities or changes will trigger a dedicated detection. For more information, see the Knowledge Base article, What are the best practices for setting up honeytoken accounts in Falcon Identity Protection?

Remove honeytoken flag

Remove the honeytoken flag from the entity. This option appears only for entities flagged as honeytokens.

Show Recent Events

Displays a list of recent events for the selected user.
Authorizers
Use Manage authorizers to assign an authorizer to accounts that don’t allow MFA configuration, including the following types of accounts:
  • Shared accounts
  • Programmatic accounts
  • Accounts for users that don’t have the ability to perform MFA
  • Accounts for temporary employees or contractors

The authorizer can be a user, a group of users, or a combination of both. When an MFA is triggered for an account with multiple authorizers, the account user is prompted to choose an authorizer from the list of options. In instances when that user-driven choice is not possible, an MFA is sent to all authorizers assigned to the account, but only one authorizer needs to approve. For information about MFA options, see MFA connectors.

The policy rules that apply to the account determine when an MFA is sent to the authorizer or authorizers. For more information, see Identity Protection Policy.

Manage authorizers

To assign or remove authorizers from an account:
  1. Go to the desired Entity’s page, for which you want to add an authorizer.
  2. Select Manage authorizers from the Entity actions menu.
  3. In the Manage authorizers dialog, search for a user or user group to add as an authorizer for the entity.
    Note: You can add multiple authorizers, including user groups, if desired.
  4. Optional. To remove an authorizer from the entity, click the x next to their name.
  5. Click Save.

Identity-based Incidents, Detections, and Risks

Understand and work through the info provided in detections and incidents.

Identity-based Incidents, Detections, and Risks

An incident is a group of detections and supplemental or extra information of anomalous security events. An incident is indicative of malicious intent, over time, involving the same entities, and that require the attention of administrators.

Identity Protection categorizes incidents according to their type and severity.

A detection is a warning about an anomalous security event, an event that does not conform to the pattern of behavior for an entity as observed by Identity Protection in the past or which is known to be indicative of malicious intent. For example, protocol manipulation typically associated with attack tools.

As more detections occur that relate to an incident, the incident type might change. For example, an Unusual use of endpoint incident can become, as it accumulates additional related detections, a Suspicious movement incident or even a Probable Insider Threat incident.

The diagram below shows the flow of information from events to incidents, as events occur over time.


Incidents comprise of Detections, which comprise of Events.

Note the following:

  • Not all events are security events that become elements of detections.

  • An event can become an element of a detection that preceded it in time.

  • A detection can become an element of an incident that preceded it in time.

Important: When a detection is triggered, CrowdStrike recommends reviewing the involved entities (users or endpoint) for events that may show additional context. Events can occur both before and after the detection that may suggest related adversary activity, such as credential access, lateral movement, data exfiltration, or file encryption. Adversaries often attempt to perform many activities, so CrowdStrike recommends that your organization perform additional review and risk mitigation when detections and preventions occur.

Incidents and policy

The policy by its nature acts in real time based on the information available at the time it is triggered. Detections are generated in retrospect, after the event occurs, based on its conformance or nonconformance to the involved entities’ historical patterns of behavior over time, and require a holistic analysis of a wide range of data.

Note: Actions taken by the policy do not create detections unless specifically set to do so in Policies. For example, if the policy blocks a connection, the event is logged in the policy audit log, but no detection is created because the event does not necessarily indicate malicious intent and does not require the attention of a security administrator.

View identity-based detections

You can get an overview of identity-based detections in a dashboard, or details of individual detections in a table.

Identity-based detections are also available in the unified detections view. For more info, see Detection Monitoring.

View overview info about identity-based detections

View a summary of identity-based detections in a dashboard by navigating to Identity Protection > Monitor > Detections dashboard .


IDP dashboard

The Detections dashboard can be filtered by time, severity, status, detection name, user name, assigned to, hostname, objective, tactic, tags, technique (by MITRE), and domain/tenant.

You can view widgets containing the following information in the Detections dashboard:

  • Number of detections by severity

    • Note that informational-severity detections are filtered by default.

  • Most recent detections

  • Assigned detections per user

  • Detections by objective

  • Detections by severity

  • Detections by status

  • Detections by name

  • Source users most involved in detections

  • Source endpoints most involved in detections

You can use these widgets in custom dashboards. For more info, see Customizable dashboards.

View details of identity-based detections

View detailed info about identity-based detections on the Identity-based detections page by navigating to Identity Protection > Monitor > Identity-based Detections.


detection details

You can use the open menu to perform these actions on identity-based detections:

  • View detection details, such as the users and endpoints involved.

  • Update the detection status.

  • Assign the detection to a user for further investigation or resolution.

  • Add tags or comments to the detection.

  • Configure attributes.

The Identity-based Detections page displays the list of detections. You can search or filter the list and view details for individual detections.

  1. Go to Identity Protection > Monitor > Identity-based Detections .

  2. Use the Search detections field or filter menus to find specific types of detections. Type the search criteria or select the filter and then click Apply.


    Use the filters to find specific types of detections.

  3. From Manage detections attribute templates or the open menu :

    Customize detection attributes to adjust what information appears in the list of detections, helping you triage detections more quickly and easily. For more info, see Detection Attribute Management.

  4. Click a detection to get more context in the summary panel.

    • To view more details about elements involved in the detection, select an option from the Investigate menu:

      • Investigate activities. Search for activities relating to the detection, using the activity ID. You must have a subscription for Falcon Investigate to perform the search.

      • Investigate involved users. Search for activities involving the user relating to the detection. You must have a subscription for Falcon Investigate to perform the search.

      • Investigate involved endpoints. Search for activities involving the source endpoint relating to the detection. You must have a subscription for Falcon Investigate to perform the search.

      • Search for involved entities in Threat Hunter. Search in Identity Protection Threat Hunter for activities performed by the entities involved in the detection.

    • To take action on a detection, select an option from the Actions menu. The specific actions that you can take on a detection depend on the detection type and your user role. Examples of actions that you can take from within a detection:
      • View the full details of a detection, by selecting Actions > Details view, or by clicking See full detection.
      • Copy the detection to your clipboard.
      • Edit the status of the detection.
      • Add a comment to the detection.
      • Add an exclusion for the detection type with the involved entity. For more info, see Identity-based Detection Exceptions.
    Important: When a detection is triggered, CrowdStrike recommends reviewing the involved entities (users or endpoint) for events that may show additional context. Events can occur both before and after the detection that may suggest related adversary activity, such as credential access, lateral movement, data exfiltration, or file encryption. Adversaries often attempt to perform many activities, so CrowdStrike recommends that your organization perform additional review and risk mitigation when detections and preventions occur.
View full details of an identity-based detection

In the summary panel, click See full detection to view all detection details. The specific sections shown vary by detection type.

To edit the status of the detection, click Edit status. The Investigate menu and Actions menu are also available here.
  • Description and Summary: General information about the detection including severity, tactic & technique, and status. For more info about specific detection types, see Appendix A: Detection reference.
  • Indicators and details: More detailed information about what triggered the detection.
  • Source endpoint: More detailed information about the source endpoint of the suspicious activity that triggered the detection. This is usually the endpoint that might be compromised so should be examined closely. The specific tabs shown vary based on your active subscriptions and might include Host, Vulnerabilities, Cloud, and more.
  • User: More detailed information about the account involved in the detection, which is most often the user that performed the suspicious activity that triggered the detection.
  • Destination endpoint: More detailed information about the destination endpoint of the suspicious activity that triggered the detection. The specific tabs shown vary based on your active subscriptions and might include Host, Vulnerabilities, Cloud, and more.
  • Related activities: A chronological list of activities related to the detection. Each related activity includes additional details, including Account name, Event, and more.
  • Recommended actions: A list of actions recommended to investigate and remediate the detection.
  • Status log: A chronological list of the current and previous status of the detection including comments, command line history, executed processes, and more.
Modify identity-based detections

Update the status, assign a user, or add tags and comments to identity-based detections.

  1. Go to Identity Protection > Monitor > Identity-based Detections .

  2. Select one of these options:

    1. Modify a single detection: Locate the detection and from the Actions menu, select Edit status.


      Edit the status of a detection

      Tip: You can also modify a detection from the summary panel by using the Actions menu.

    2. Bulk modify detections: Select multiple detections, and then click Edit.


      Edit the status of multiple detections in bulk.

  3. Modify the detection as needed.

    • Use the Status and Assigned to options to change the status or assigned user.

    • Enter a new tag or remove existing tags using the Detection tags field.

    • Enter a comment in the Add comment field.

  4. Click Update status.

Use identity-based detections as triggers in workflows

Orchestrate automated actions triggered by identity detections in Fusion SOAR.

To reach your workflows, go to Fusion SOAR > Fusion SOAR > Workflows .

A workflow has only one trigger. Edit the trigger for an existing workflow or create a new workflow.

When you set up the trigger, complete these tasks:

  1. In the Add trigger panel, search for identity and then expand Identity & Access.

  2. Click Detection > Identity Detection.

In the workflow, you can add conditions based on the detection details.

For more information, see Fusion SOAR.

Filter dashboards

Apply filters to update the detection information shown in your dashboard or table. For example, you can filter to show only activity during the past day or only activity with a certain severity. You can also save your preferred filter combinations to use later.

To apply a filter:

  1. Click a filter to view the available values.

    Tip: Click More filters to view additional filter options.

  2. Specify the values you want to filter by:

    • Select the values you want to include in the filter.

    • For filters that have a search field, you can enter a value and select it. You can also use a wildcard (*).


      Filter options with manually entered value including wildcard

    • To exclude a value, hover over it and click Exclude.


      Filter options with an excluded value

  3. When you’re finished, click Apply.

    Tip: To remove an applied filter, click the X on that filter.

You can apply multiple filters and values. Typically, filter behavior works as follows:

  • Selected values within a filter combine with an OR operator

  • Multiple filters combine with an AND operator


Two filter options with multiple values selected

For example, this filter combination is evaluated as:

(OS version is Windows 10 OR Windows Server 2019) AND (Group is CR Systems)

Tip: Click Clear all to remove applied filters and revert the page to its default filter values. Click Reset to default in the More filters dropdown menu to remove applied filters and revert the page to its default filter values and filter parameters.

More filters dropdown menu showing the Reset to default button.
Manage custom filters

Create custom filters to save frequently used filter combinations:

  1. Apply the filters you want to use as a custom filter.

  2. Open the Add or remove saved filters menu and click Save.

Apply custom filters from the Saved filters menu.


Saved custom filters menu

Modify existing custom filters:

  1. Select the filter from the Saved filters menu.

  2. Open the Add or remove saved filters menu and select an action:

    • Save: Save your filter changes.

    • Save as: Save a copy of the filter without affecting the original.

    • Delete: Delete the filter.

    • Rename: Rename the filter.

When you modify a saved filter, an asterisk appears by its name until you save your changes.

View identity-based incidents

The Identity-based Incidents page lets you better evaluate the security events occurring in your system and take the necessary actions to mitigate the risks they pose.
Note: You can also view identity-based incidents, now known as identity-based cases, in Falcon Cases. Go to Next-Gen SIEM > Monitor and investigate > Cases. For more info, see Cases.
Identity-based incidents page

You can act on the incidents directly from the page. You can manage the incident life cycle, add notes, filter, sort, examine, and perform forensic analysis of incidents.

Note: By default, informational incidents are not displayed. To display them, click Show Informational Incidents.
Incidents page structure

The structure of the Incidents page is as follows:

  • Interval: In the upper-right corner, a drop-down menu lists available intervals to display incidents. For example, Last Day, Last Week, Last Month, All Time. You can also specify a Custom date range.

  • Incidents by Status: A color-coded graph providing an overview of the total number of incidents and their status. Click a metric on the graph to display a list of the corresponding incidents.

  • Incidents by Severity: A color-coded bar graph that helps to evaluate the number of incidents based on their severity. Click a bar on the graph to display a corresponding list of the incidents. User similarity is one of the factors used to determine the severity of an incident.

  • New vs. Closed: A list of recent dates, showing the number of incidents opened and closed on each of those dates. This helps to evaluate and track the incident resolution rate. Click a bar on the graph to display a corresponding list of the incidents.

  • Involved Entities by Type: A bar graph showing the distribution of incidents among users (human and programmatic) and endpoints (non-domain-joined and managed). This information helps to identify the users and endpoints most frequently involved in incidents and whether the incidents are caused by user actions or are programmatic (in which case addressing the problem might require assistance from IT personnel).

  • A Filter box, by which you can search incidents by tags, for example, by Incident Type, Severity, Status or Entities.

  • A list of incidents, depending on the selections in the other controls, as well as sorting by incident type, severity, and status. By default, incidents are sorted by last update time. You can change this default sort to be based on incident create time.

Use the Filter box

The Filter box enables you to filter incidents by predefined tags. Where available, you can drill down to lower levels on a tag. For example, the tag Severity, enables you to drill down further to select the level of severity of High, Medium, or Low (or you can select all).

To filter incidents:

  1. On the Incidents page, click Add Filter.

  2. Select the required tag. The selected tag appears in the filter box.

  3. If there are additional optional tags available, a Plus icon appears next to the tag name. Select all applicable tags.

  4. To reset filter tags, click Reset. To clear the last selected filter option, click Clear All.

Understand incident status

You can change the status of a single incident or multiple incidents with the same current status.

These statuses are available for incidents:

Status Description

New

This is the initial status of a newly-opened incident. An incident remains in the New status until an administrator changes its status or it is automatically changed by Identity Protection.

Open

An investigation of the incident has begun, but the incident’s status has not yet been changed.

Suppressed

An administrator changed the status of the incident to Suppressed, indicating that future incidents of this type should be considered as not carrying any risk and should not appear in the reports.

A suppressed incident continues to be updated with any relevant new events, but the incident is not flagged and its time and severity is not changed. If, after 5 days, new events occur, a new incident is created and the new events added to the new incident.

Resolved

An administrator changed the status of the incident to Resolved after completing an investigation. When this happens, the incident no longer contributes to the involved entity’s risk score.

Auto Resolved

The incident was resolved automatically, for example by verifying the user’s identity, or based on other valid criteria. Only the Identity Protection system can set an incident’s status to Auto Resolved.

For example, an incident is triggered due to the first use of an endpoint by a user. Assuming a policy rule triggered Identity verification and the end user approved the action, this incident might be auto-resolved. The detection rules evaluate additional events. If there is no additional evidence to support or indicate that the activity is malicious, it credits it by marking it as Auto Resolve.

The purpose of this is to reduce the load from the Security Analysts so they can review the meaningful incidents.
Change the status of a single incident

  1. Click an incident’s menu icon. The available actions depend on the incident’s current status.

  2. Select one of the actions from the menu.

Change the status of multiple incidents to the same status

  1. Select the check box of all applicable incidents with the same status.

  2. Click Actions and select the status.

    Note: If the selected incidents have different statuses, a warning icon appears next to the word Action and you are not able to change their statuses. The available actions depend on the current status of the incidents.

  3. Click Save.

Identity-based Incident details

Click an incident on the Identity-based Incidents page to see the Incident details page:


A suspicious movement incident on the details page.

The Incident details page contains the following:

  • A chronological list of the events (including supporting events) comprising the incident, including a short description of each event.

  • Involved Users: A profile of the users. Click the name to go to the entity’s page.

  • Involved Endpoints: A profile of the endpoints. Click the name to go to the entity’s page.

  • Comments: See related comments and log information during the incident investigation, for example reference tickets to external systems or data about the involved entities.

  • Recommendations: Lists the recommended actions to take to resolve the incident.

You can change an incident’s status using the Actions menu.

View related events

The Related Events option is available from the following locations:

  • Policy Audit Log entry

  • Threat Hunter event

This option enables you to view events related to the current event. Hover over an event to see the event details. If the event has related events, the Show Events icon appears on the bottom right of the event details. To display a list of related events, click the Show Events icon.

Identity-based Detection Exceptions

By using exceptions you can build a set of rules that are applied to security incidents encountered by your organization. Setting up the rules allows you to modify industry best practices with respect to Incidents and Incident detections, and to modify the default response to incident detections to match your organization's needs. This includes:

  • Enabling or disabling detections

  • Adding exceptions to detections to reflect specific behavior and practices inherent in your organization

  • Using Acknowledge & Trust to provide visibility of the exceptions that you implement across your organization

View exceptions

Go to Identity protection > Configure > Detection exclusions to view a list of alerts and any exceptions that you put in place to modify the treatment of the alerts.

  • For any alert that contains exceptions, a label that indicates the number of exceptions associated with the alert is shown next to the alert name.

  • The alert title bar functions as a toggle to show or hide the alert's details. Click anywhere in an alert's title bar to alternately expand or collapse an alert's details pane.

  • Alerts are enabled by default.

  • You can search for Alerts by name or by type.

Add exceptions to an alert

To add an exception to an alert.

  1. From the list of alerts, select and expand the alert for which you want to add an exception.

  2. Click Add New Exception.

  3. In the Select condition type list, select a condition. For a list of conditions, see Understand conditions.

  4. If options are available for the selected condition, select one or more conditions from the available list.

  5. Click Save.

Acknowledge & Trust

You can use the Acknowledge & Trust feature as a quick means of assigning a specific exception to an alert. This determination is used to evaluate future alerts.

For example, if a user’s access to a peer’s endpoint was flagged as abnormal, and this alert was later deemed to be an Acknowledge & Trust exception, then later alerts of the same conditions are not flagged.

Creating an exception using Acknowledge & Trust:

  1. Click an incident to display the list of incident alerts.

  2. Hover over an alert and click Acknowledge & Trust.


    Hover over an alert in an incident to show the Acknowledge & Trust button.

  3. In the Acknowledge & Trust dialog, review the exception condition. Optionally, add a comment and then click Acknowledge & Trust Alert.

  4. The icon associated with the incident alert is now shown in Grey and an exception for the alert is added to the Exceptions list.

Detection Settings

Go to Identity protection > Configure > Detection settings to set the detections aggression level and configure the geolocation settings.

Detections aggression level

You can increase the Detections aggression level above our best practice recommendation. We do not recommend enabling Detections aggression level setting outside of PEN testing or other internal testing scenarios.

This setting might trigger a significant increase in specific detections and tag routine activities as malicious. For example, similar suspicious activities that previously produced a single detection during a specific timeframe will now produce repeated detections in that timeframe. For a complete list of impacted detections and conditions, see Identity Protection increased aggression level. For US-GOV-1 and US-GOV-2 customers, see Identity Protection increased aggression level.

Set the Detections aggression level:

  1. Go to Identity protection > Configure > Detection settings .

  2. Enable Detections aggression level.

Geolocation configuration

When Identity Protection is integrated with a Federation provider (PingFederate or AD FS) or with a Cloud SSO, it gains visibility into the real IP addresses and the geographic locations from which users access the network. You can add countries to a blocklist and trigger an alert when there is access from these locations. Conversely, you can add countries to an allowlist and block access from countries not included in the allowlist.

For example, if North Korea is in the blocklist, any access attempt from that country triggers an Access from Forbidden Country alert.

If you add the US and Canada to the allowlist, then any access attempt from outside these countries triggers an Access from Forbidden Country alert.

Be aware that when you add a location to an allow or blocklist, Unusual Location detection is disabled. This means if the origin country for a particular activity is included in an allow or blocklist, it's excluded from unusual location reviews. It doesn't mean that unusual detections aren't generated for activity that originates in a country that isn't included in an allow or blocklist.

Configure locations lists:

  1. Go to Identity protection > Configure > Detection settings .

  2. In the Geolocation configuration area, click Configure.

  3. Select Blocklist or Allowlist.

  4. You can add an entire continent to a list by selecting it, or add individual countries by clicking the plus sign and then selecting the countries one by one.

  5. Click Save.

Appendix A: Detection reference

The following detections are generated by Identity Protection. Each is listed with how it is detected, the possible scenarios (malicious and non-malicious), and the recommended actions to address and resolve it.

51126 - Access from blocklisted location

A user accessed the network or cloud from a blocklisted country, region, or from outside the permitted regions.

This could indicate stolen credentials being used by hackers to access enterprise data.

MITRE ATT&CK® tactics and technique
Investigate

  • Check if other users accessed from the same IP

  • Check if the account activity is known to the user

Exclusion scenarios

You might be able to mark this detection as an exclusion in these scenarios:

  • The end user is on a vacation or business trip

  • Automated services are accessing monitored cloud services on servers hosted in a forbidden country

  • This is an exception for a group of user accounts

Remediate

  • Create a policy to enforce MFA for all user activities

  • If the location is usually allowed in the network, consider updating the country allowlist or blocklist

  • If the activity is found to be malicious:

    • Force a password change for the compromised user account

    • Investigate what further activities were performed by the user account

    • Add the user to the watch list

51124 - Access from IP with bad reputation

A user accessed the network or cloud from an IP that has a bad reputation of being associated with internet attacks.

This could indicate that user account credentials were stolen and are now being used by an adversary from a suspect IP.

MITRE ATT&CK® tactics and technique
Investigate

  • Check if other users accessed from the same IP

  • Check the following, depending on the specific IP reputation:

    • Benign cases are a result of a corporate proxy/gateway not being recognized by Identity Protection
    • Check if the IP is known to be associated with the organization
    • In most cases, if the IP isn’t associated with the organization, the user’s local IP is rotating in the ISP and was previously associated with malicious behavior

  • Check if the account activity is known to the user

Exclusion scenarios

You might be able to mark this detection as an exclusion in these scenarios:

  • A user shared their account with another user for legitimate purposes and both are using the account

  • A user account is being used by an automated script or service that performs operations on behalf of the user from a datacenter location

  • This is an exception for a group of user accounts

Remediate

  • Create a policy to enforce MFA for all user activities

  • If the specific IP address is triggering multiple benign detections, add the IP address or IP range to the allowlist by marking the detection as an exclusion

  • If the activity is found to be malicious:

    • Force a password change for the compromised user account

    • Investigate what further activities were performed by the user account

    • Add the user to the watch list

51127 - Access from multiple locations concurrently

A user accessed the network or cloud from more than one location in close time proximity. The distance between the locations was greater than the theoretical speed of travel between them.

This could indicate that user credentials were stolen, for example by phishing, and the account is being abused by multiple adversaries.

MITRE ATT&CK® tactics and technique
Investigate

  • Check if other users accessed from the same IPs

  • Check if the account activity is known to the user

  • Check if the IP is known to be associated with the organization. Most benign cases are a result of a corporate proxy or gateway not being recognized by Identity Protection

Exclusion scenarios

You might be able to mark this detection as an exclusion in these scenarios:

  • The user is travelling to an anomalous location that is not common for the organization's users

  • This is an exception for a group of user accounts

Remediate

  • Create a policy to enforce MFA for all user activities

  • If the activity is found to be malicious:

    • Force a password change for the compromised user account

    • Investigate what further activities were performed by the user account

    • Add the user to the watch list

51125 - Access from unusual geolocation

A user accessed the network or cloud from an unusual location not common to the user or the network.

This could indicate that user credentials were stolen, for example by phishing, and the account is being abused by an adversary.

MITRE ATT&CK® tactics and technique
Investigate

  • Check if other users accessed location from the same IP

  • Check if the account activity is known to the user

Exclusion scenarios

You might be able to mark this detection as an exclusion in these scenarios:

  • The user is travelling to an anomalous location that is not common for the organization's users

  • This is an exception for a group of user accounts

Remediate

  • Create a policy to enforce MFA for all user activities

  • If the activity is found to be malicious:

    • Force a password change for the compromised user account

    • Investigate what further activities were performed by the user account

    • Add the user to the watch list

51110 - Anomalous RPC (account discovery)

A user executed an account discovery DCE/RPC command targeting a domain controller (DC) for the first time.

This could indicate an attacker using an anomalous DCE/RPC command to configure DC.

MITRE ATT&CK® tactics and technique
Investigate

  • Check if the account activity is known to the user

Exclusion scenarios

You might be able to mark this detection as an exclusion in these scenarios:

  • A new or rare IT tool configures the DC by using DCE/RPC commands

  • This is an exception for a group of endpoints, IPs, or users

Remediate

  • Review source endpoint data to find the initiating process, and remediate the endpoint

  • Create a policy to enforce MFA for all user activities

51114 - Anomalous RPC (credential access)

A user executed a credential access DCE/RPC command targeting a domain controller (DC) for the first time.

This could indicate an attacker using an anomalous DCE/RPC command to configure DC.

MITRE ATT&CK® tactics and technique
Investigate

  • Check if the account activity is known to the user

  • Check if the user account has domain admin or equivalent privileges

Exclusion scenarios

You might be able to mark this detection as an exclusion in these scenarios:

  • A new or rare IT tool configures the DC with a DCE/RPC command

  • This is an exception for a group of endpoints, IPs, or users

Remediate

  • Review source endpoint data to find the initiating process, and remediate the endpoint

51114 - Anomalous RPC (remote services)

A user executed a remote service DCE/RPC command targeting a domain controller (DC) for the first time.

This could indicate an attacker using an anomalous DCE/RPC command to configure DC.

MITRE ATT&CK® tactics and technique
Investigate

  • Check if the account activity is known to the user

  • Check if the user account has domain admin or equivalent privileges

Exclusion scenarios

You might be able to mark this detection as an exclusion in these scenarios:

  • A new or rare IT tool configures the DC with a DCE/RPC command

  • This is an exception for a group of endpoints, IPs, or users

Remediate

  • Review source endpoint data to find the initiating process, and remediate the endpoint

  • Create a policy to enforce MFA for all user activities

51111 - Anomalous RPC (scheduled task)

A user executed a scheduled task DCE/RPC command targeting a domain controller (DC) for the first time.

This could indicate an attacker using an anomalous DCE/RPC command to configure DC.

MITRE ATT&CK® tactics and technique
Investigate

  • Check if the account activity is known to the user

  • Check if the user account has domain admin or equivalent privileges

Exclusion scenarios

You might be able to mark this detection as an exclusion in these scenarios:

  • A new or rare IT tool configures the DC with a DCE/RPC command

  • This is an exception for a group of endpoints, IPs, or users

Remediate

  • Review source endpoint data to find the initiating process, and remediate the endpoint

  • Create a policy to enforce MFA for all user activities

51115 - Anomalous RPC (valid accounts)

A user executed a valid accounts DCE/RPC command targeting a domain controller (DC) for the first time.

This could indicate an attacker using an anomalous DCE/RPC command to configure DC.

MITRE ATT&CK® tactics and technique
Investigate

  • Check if the account activity is known to the user

  • Check if the user account has domain admin or equivalent privileges

Exclusion scenarios

You might be able to mark this detection as an exclusion in these scenarios:

  • A new or rare IT tool configures the DC with a DCE/RPC command

  • This is an exception for a group of endpoints, IPs, or users

Remediate

  • Review source endpoint data to find the initiating process, and remediate the endpoint

  • Create a policy to enforce MFA for all user activities

51104 - Anomalous RPC (ZeroLogon)

A ZeroLogon exploit attempt was detected.

MITRE ATT&CK® tactics and technique
Investigate

  • Check if the relevant domain controller is patched for CVE-2020-1472

Exclusion scenarios

You might be able to mark this detection as an exclusion in these scenarios:

  • A new or rare IT tool configures the DC with a DCE/RPC command

  • This is an exception for a group of endpoints, IPs, or users

Remediate

  • Review source endpoint data to find the initiating process, and remediate the endpoint

  • Make sure to patch all domain controllers for CVE-2020-1472

51128 - Bronze Bit exploit

A constrained delegation flow was performed by an account without sufficient privileges, indicating a Bronze Bit attack was executed.

This could be caused by an adversary that has compromised an account with delegation permissions to a privileged resource, and they used it to access the privileged resource as any desired user.

MITRE ATT&CK® tactics and technique
Investigate

  • Check if the relevant domain controller is patched for CVE-2020-17049

Exclusion scenarios

You might be able to mark this detection as an exclusion in these scenarios:

  • Protocol transition was recently enabled for an account with constrained delegation privileges

  • This is an exception for a group of endpoints, IPs, or users

Remediate

  • Make sure to patch all domain controllers for CVE-2020-17049

  • Review constrained delegation privileges of the additional account and remove them if not necessary

  • Review endpoint data to find the initiating process and remediate both source and target endpoints

  • Create a policy to enforce MFA for all user activities

51121 - Credential scanning (Active Directory)

Multiple failed authentication attempts were made in a short time frame, from the same machine within the domain.

This could indicate that malware or an automated script installed by a rogue end user is trying to guess passwords for multiple end user accounts.

MITRE ATT&CK® tactics and technique
Investigate

  • Check the pattern and volume of failed authentication attempts to assess if volume of failed authentication attempts is common for the endpoint

  • Machines with multiple authentications are statistically more prone to an excessive number of failed authentication attempts

  • Check how the attacker launched the credential scanning attack:

    • Case one: When the authentication machine is the target endpoint, it's common for an attacker to have network access to the endpoint. For example, an externally facing server.
    • Case two: When the authentication machine is the source endpoint, the machine might be compromised.
Exclusion scenarios

You might be able to mark this detection as an exclusion in these scenarios:

  • A machine that is performing multiple authentication attempts on end users' behalf, for example delegation or impersonation, has been incorrectly classified

  • This is an exception for a group of endpoints or IPs

Remediate

  • If the attacker was able to launch the credential scanning attack:

    • Applicable to case one: Apply relevant firewall rules to block attacker’s network access.
    • Applicable to case two: Review endpoint data to find the initiating process and remediate endpoint activity.
    • Applicable to all: Review successful authentication attempts originating from the same source. If this type of activity is found, it’s often also malicious.

  • Applicable to case one: Apply relevant firewall rules to block attacker’s network accessApplicable to case two: Review endpoint data to find the initiating process and remediate endpoint activityApplicable to all: Review successful authentication attempts originating from the same source. If this type of activity is found, it’s often also malicious.

  • If the user account is successfully authenticated:

    • Force a password change for the compromised user account

    • Investigate what further activities were performed by the user account

    • Add the user to the watch list

51122 - Credential scanning (web-based)

Multiple failed authentication attempts were made in a short time frame, from the same IP address outside the domain.

This could indicate that malware or an automated script is trying to guess passwords for multiple end user accounts.

MITRE ATT&CK® tactics and technique
Investigate

  • Check the pattern and volume of failed authentication attempts to assess if volume of failed authentication attempts is common for the endpoint

  • Machines with multiple authentications are statistically more prone to an excessive number of failed authentication attempts

Exclusion scenarios

You might be able to mark this detection as an exclusion in these scenarios:

  • This is an exception for a group of endpoints or IPs

Remediate

  • Review successful authentication attempts originating from the same source. If this type of activity is found, it’s often also malicious.

  • If the user account is successfully authenticated:

    • Force a password change for the compromised user account

    • Investigate what further activities were performed by the user account

    • Add the user to the watch list

51109 - DC PsExec execution

A user executed a PsExec command on a domain controller (DC) for the first time.

This could indicate that an attacker has obtained credentials for a system and is attempting to access it by running a local executable file with root level privileges on the remote system.

MITRE ATT&CK® tactics and technique
Investigate

  • Check if the account activity is known to the user

Exclusion scenarios

You might be able to mark this detection as an exclusion in these scenarios:

  • A domain administrator is using PsExec for the deployment of updates

  • This is an exception for a group of endpoints, IPs, or users

Remediate

  • Review source endpoint data to find the initiating process, and remediate the endpoint

  • Create a policy to enforce MFA for all user activities

  • If this isn’t an approved action, take active measures to rebuild your AD environment

51139 - Excessive activity from multiple endpoints

A user performed network logins from an unusual number of endpoints compared to the maximum usage in previous periods.

This could indicate that malware is spreading across multiple machines in the network.

MITRE ATT&CK® tactics and technique
Investigate

  • Check if the account activity is known to the user

Exclusion scenarios

You might be able to mark this detection as an exclusion in these scenarios:

  • An administrator is fixing or configuring multiple machines in the network

  • This is an exception for a group of users

Remediate

  • Review source endpoints data to find the initiating process, and remediate endpoints

  • Create a policy to enforce MFA for all user activities

51140 - Excessive activity to multiple endpoints

A user performed network logins to an unusual number of endpoints compared to the maximum usage in previous periods.

This could indicate that malware is attempting to move laterally across the network, or an end user attempting to access various services. This user might be over-privileged.

MITRE ATT&CK® tactics and technique
Investigate

  • Check if the account activity is known to the user

  • Check if the targets are mainly user accounts or machine accounts

Exclusion scenarios

You might be able to mark this detection as an exclusion in these scenarios:

  • An administrator is fixing or configuring multiple machines in the network

  • This is an exception for a group of users

Remediate

  • Review endpoint data to find the initiating process, and remediate endpoints

  • Create a policy to enforce MFA for all user activities

51116 - Forged PAC attack

A Forged PAC attack was executed in the network.

This may indicate that malware is attempting to move laterally across the network.

MITRE ATT&CK® tactics and technique
Investigate

  • Check if domain controllers are patched for MS14-068

Exclusion scenarios

You might be able to mark this detection as an exclusion in these scenarios:

  • Unusual software is using unusual Kerberos commands, a possible but improbable scenario

  • This is an exception for a group of endpoints, IPs, or users

Remediate

  • Make sure to patch your domain controllers for MS14-068

  • Create a policy to enforce MFA for all user activities

  • Review source endpoint data to find the initiating process, and remediate the endpoint activity

  • If the attempt was successful:

    • Review the activities that were performed with the ticket and remediate all affected accounts and machines

    • Take active measures to rebuild your AD environment

51100 - Golden Ticket attack

A Golden Ticket was detected, based on the analysis of Kerberos ticket PAC fields. This could indicate that malware is attempting to move laterally across the network.

MITRE ATT&CK® tactics and technique
Investigate

  • Check for suspicious domain replication detections in your environment

  • Compare Kerberos ticket duration to the value configured in your group policy objects (GPO):

    • Kerberos tickets with durations longer than the configured value might indicate a Golden Ticket attack. However, if you have recently updated your GPO values, Identity Protection might not have the updated settings, and flagged a Golden Ticket attack

Exclusion scenarios

You might be able to mark this detection as an exclusion in these scenarios:

  • The default Kerberos configuration was changed

Remediate

  • Review source endpoint data to find the initiating process, and remediate the endpoint activity

  • Track Golden Ticket activities to find other affected endpoints and users

  • Take active measures to rebuild your AD environment

  • Create a policy to enforce MFA for all user activities

51123 - Hidden object discovered

A hidden account was discovered, the ACL on the account prevents its discovery by administrators and all users. Hidden objects can't be found by AD management searches.

This could indicate that an account is being used as a backdoor and is under the control of an attacker who tries to prevent the account from being enumerated.

MITRE ATT&CK® tactics and technique
Investigate

  • Check the relevant deny ACL and validate its need

Exclusion scenarios

You might be able to mark this detection as an exclusion in these scenarios:

  • The account has some legitimate reason for being configured by admins to prevent enumeration

  • This is an exception for a group of users

Remediate

  • Revert the relevant deny ACL

  • Create a policy to enforce MFA for all user activities

51143 - Identity verification denied

A user denied a policy identity verification request.

This could indicate that account credentials were used by malware or by a rogue end user unaware of policy.

MITRE ATT&CK® tactics and technique

  • Not applicable

Investigate

  • Check if the account activity is known to the user

Exclusion scenarios

You might be able to mark this detection as an exclusion in these scenarios:

  • The user does not understand MFA, a possible but improbable scenario

  • This is an exception for a group of users

Remediate

  • Assume the machine and end user account have been compromised

51142 - Identity verification timed out

A user didn't respond to a policy identity verification request.

This could indicate that account credentials were used by malware or by a rogue end user unaware of policy.

MITRE ATT&CK® tactics and technique

  • Not applicable

Investigate

  • Check if the account activity is known to the user

Exclusion scenarios

You might be able to mark this detection as an exclusion in these scenarios:

  • The user forgot their phone, or the phone is out of signal range

  • The user simply neglected to respond in time

  • The user account is used by a script

  • This is an exception for a group of users

Remediate

  • If activity is non-interactive, modify policy to stop challenging user for the particular use-case

51118 - NTLM relay activity

Traffic analysis revealed NTLM credentials were used to attack a machine that wasn't the original target of the authentication session.

This could indicate that an attacker used malware to steal NTLM credentials and then attempted to run code and perform other malicious activities on another server.

MITRE ATT&CK® tactics and technique
Investigate

  • Check if the source endpoint, which is suspected of relaying credentials, shared an IP with the target endpoint to rule out noise created by endpoint association errors

  • Check if the target endpoint enforces SMB signing or if the target DC enforces LDAP signing and LDAPS channel bindings

Exclusion scenarios

You might be able to mark this detection as an exclusion in these scenarios:

  • A machine has multiple DNS records or NetBIOS names. On this machine, one identity was used to connect to a server and another identity was used to generate NETLOGON.

  • This is an exception for a group of endpoints, IPs, or users

Remediate

  • Review source endpoint data to find the initiating process, and remediate the endpoint

  • Review target endpoint to examine the activities performed using the suspected relayed session and remediate endpoint

  • Create a policy to enforce MFA for all user activities

  • Work to disallow NTLM traffic in your network

  • Enforce SMB signing, LDAP signing and LDAPS channel bindings on all endpoints in the network

51158 - OverWatch Identity detection

Falcon OverWatch has detected malicious activity related to an identity-based event.

An OverWatch Identity detection can be triggered by the OverWatch team of threat hunters due to any underlying identity-based detection type included in this document.

For more information, see View OverWatch Identity Detections.

MITRE ATT&CK® tactics and technique

  • Falcon Overwatch using the technique relevant to the underlying identity detection type

Investigate, Exclusion scenarios, Remediate
Consult the Notes from OverWatch section of the detection summary panel for information about the detection and recommended actions.
Note: For additional context regarding the underlying identity detection type, click View original.
51119 - Password brute force attack (Active Directory)

A user’s password was repeatedly entered incorrectly from an unusual machine within the domain.

This could indicate that an end user is trying to guess another end user’s password.

MITRE ATT&CK® tactics and technique
Investigate

  • Check the authentication pattern to determine if it's likely for the user

  • Check if the account activity is known to the user

  • Check successful authentication attempts originating from the same source

Exclusion scenarios

You might be able to mark this detection as an exclusion in these scenarios:

  • An end user who accidentally attempted to log in to another end user’s account and thus entered an incorrect password

  • An unusual coincidence where an end user logs in from a new machine and also forgets their password

  • This is an exception for a group of endpoints, IPs, or users

Remediate

  • If the brute force attack appears to be successful:

  • Check if the authentication machine is the target endpoint, it's common for an attacker to have network access to the endpoint. For example, an externally facing server.Check if the authentication machine is the source endpoint; the machine might be compromised

    • Apply relevant firewall rules to block attacker’s network access

  • Check if the authentication machine is the target endpoint, it's common for an attacker to have network access to the endpoint. For example, an externally facing server. Check if the authentication machine is the source endpoint; the machine might be compromised

    • Review endpoint data to find the initiating process, and remediate the endpoint

  • If there was a successful authentication attempt originating from the same source, it's often also malicious:

    • Force a password change for the compromised user account

    • Investigate what further activities were performed by the user account

    • Add the user to the watch list

51120 - Password brute force attack (web-based)

A user’s password was repeatedly entered incorrectly from an unusual IP address outside of the domain.

This could indicate that a malicious adversary is trying to guess an end user’s password.

MITRE ATT&CK® tactics and technique
Investigate

  • Check the authentication pattern to determine if it's likely for the user

  • Check if the account activity is known to the user

  • Check successful authentication attempts originating from the same IP

Exclusion scenarios

You might be able to mark this detection as an exclusion in these scenarios:

  • An end user who accidentally attempted to log in to another end user’s account and thus entered an incorrect password

  • An unusual coincidence where an end user logs in from a new machine and also forgets their password

  • This is an exception for a group of IPs, or users

Remediate
If there was a successful authentication attempt originating from the same source, it's often also malicious:
  • Force a password change for the compromised user account
  • Investigate what further activities were performed by the user account
  • Add the user to the watch list
51144 - Policy rule match (access)

An Identity Protection policy rule was triggered by access. The severity level is predefined when creating the policy.

MITRE ATT&CK® tactics and technique

  • Not applicable

Investigate

  • Not applicable

Exclusion scenarios

  • Not applicable

Remediate

  • Not applicable

51146 - Policy rule match (account event)

An Identity Protection policy rule was triggered by an account event. The severity level is predefined when creating the policy.

MITRE ATT&CK® tactics and technique

  • Not applicable

Investigate

  • Not applicable

Exclusion scenarios

  • Not applicable

Remediate

  • Not applicable

51147 - Policy rule match (detection)

An Identity Protection policy rule was triggered by a detection. The severity level is predefined when creating the policy.

MITRE ATT&CK® tactics and technique

  • Not applicable

Investigate

  • Not applicable

Exclusion scenarios

  • Not applicable

Remediate

  • Not applicable

51145 - Policy rule match (federated access)

An Identity Protection policy rule was triggered by federated access. The severity level is predefined when creating the policy.

MITRE ATT&CK® tactics and technique

  • Not applicable

Investigate

  • Not applicable

Exclusion scenarios

  • Not applicable

Remediate

  • Not applicable

51148 - Privilege escalation (Azure service principal)

An Azure service principal received new privileges.

MITRE ATT&CK® tactics and technique
Investigate

  • Investigate how the service principal received the additional privilege

Exclusion scenarios

You might be able to mark this detection as an exclusion in these scenarios:

  • This is an exception for a group

Remediate

  • Revert the relevant new privilege

  • Create a policy to enforce MFA for all user activities

51131 - Privilege escalation (endpoint)

An endpoint received new privileges.

MITRE ATT&CK® tactics and technique
Investigate

  • Investigate how the endpoint received the additional privilege

Exclusion scenarios

You might be able to mark this detection as an exclusion in these scenarios:

  • This is an exception for a group

Remediate

  • Revert the relevant new privilege

  • Create a policy to enforce MFA for all user activities

51113 - Privilege escalation (user)

A user received new privileges.

MITRE ATT&CK® tactics and technique
Investigate

  • Investigate how the account received the additional privilege

Exclusion scenarios

You might be able to mark this detection as an exclusion in these scenarios:

  • This is an exception for a group

Remediate

  • Revert the relevant new privilege

  • Create a policy to enforce MFA for all user activities

51169 - Short-lived account usage

An account was created and deleted by the same actor within a short time window, with activity detected between creation and deletion, potentially indicating suspicious activity.

MITRE ATT&CK® tactics and technique
Investigate

  • Check if the account creation and deletion pattern is known to IT administrators

  • Review the activities performed between account creation and deletion

  • Check if the account was added to any privileged groups

  • Verify if this aligns with legitimate IT operations or automation processes

Exclusion scenarios

You might be able to mark this detection as an exclusion in these scenarios:

  • A legitimate IT tool or script creates temporary accounts as part of normal operations

  • Authorized automation systems that use temporary service accounts for specific tasks

  • This is an exception for a group of endpoints, IPs, or users

Remediate

  • Force a password reset for any accounts that may have been compromised

  • Investigate what activities were performed by the temporary account

  • Review and strengthen account creation policies and monitoring controls

51108 - Suspicious domain replication

A user or machine account executed a suspicious domain replication (DRSUAPI) request.

This could indicate that malware or malicious code is trying to steal domain secrets or is attempting to configure the domain with malicious configuration.

MITRE ATT&CK® tactics and technique
Investigate

  • Check the user or machine account and source endpoint

  • Check if new software was deployed on the relevant endpoint that legitimately performs domain replication

Exclusion scenarios

You might be able to mark this detection as an exclusion in these scenarios:

  • A machine was installed with software that fetches domain information, or even passwords, regularly

  • This is an exception for a group of endpoints, IPs, or users

Remediate

  • If the activity is found to be malicious, then the DC is compromised

  • Take active measures to rebuild your AD environment

51168 - Suspicious account alteration

An account was modified in a suspicious manner that may indicate malicious activity such as persistence or privilege escalation attempts.

MITRE ATT&CK® tactics and technique
Investigate

  • Check if this change is part of an authorized account modification by a legitimate administrator

  • Review the account alteration details to understand what was changed

  • Review recent activities for the modified account and the account that performed the modification to identify any suspicious access patterns

  • Determine if the target account is privileged, as this increases the severity of potential compromise

  • Investigate the account that performed the modification for signs of compromise

  • Check the alteration type:

    • BadSuccessor: Examine the target account to determine if the msDS-SupersededManagedAccountLink attribute also references the dMSA DN. The impersonation only works with mutual references.

Exclusion scenarios

You might be able to mark this detection as an exclusion in these scenarios:

  • The account modification is legitimate and part of documented administrative tasks

  • The change was performed by an authorized identity team member as part of planned account management activities

Remediate

  • If unauthorized, immediately revert the account changes

  • Force a password change on the affected accounts

  • Consider disabling the account as an immediate containment action if compromise is suspected

51117 - Suspicious Kerberos ticket reuse

A Kerberos ticket generated by one machine was used by another machine.

This is consistent with a Pass the Ticket attack, and could indicate that malware is attempting to move laterally across the network and escalate its privileges.

MITRE ATT&CK® tactics and technique
Investigate

  • Check if the source endpoint shared an IP with the additional endpoint to rule out noise created by endpoint association errors

  • Check if the compromised IP is part of a NAT segment

Exclusion scenarios

You might be able to mark this detection as an exclusion in these scenarios:

  • Incorrect IP address resolution has occurred

  • A machine with several DNS records and/or using a dynamic IP address on multiple networks. For example, WIFI and VPN.

  • This is an exception for a group of endpoints, IPs, or users

Remediate

  • Review the source endpoint and additional endpoint data to find the initiating process, and remediate endpoints

  • Track compromised ticket activities to find other affected endpoints and users

  • Create a policy to enforce MFA for all user activities

  • If the compromised IP is part of a NAT segment, add a network label to reduce noise from the segment

51133 - Suspicious lateral movement

A user performed a network login from a machine that doesn't normally serve remote requests.

This could indicate that malware is using valid credentials to access data or to move laterally across the network.

MITRE ATT&CK® tactics and technique
Investigate

  • Check if the account activity is known to the user

Exclusion scenarios

You might be able to mark this detection as an exclusion in these scenarios:

  • A maintenance script is performing unusual administrative actions. For example, a network scanner.

  • An administrator is working from an unusual server or workstation.

  • This is an exception for a group of users

Remediate

  • Review source endpoint data to find the initiating process, and remediate both source and target endpoints

  • Create a policy to enforce MFA for all user activities

51106 - Suspicious LDAP search (Kerberos misconfiguration)

A user executed a suspicious LDAP search request to enumerate AD accounts. These searches are commonly performed by known reconnaissance attack tools, such as Bloodhound or Impacket.

This could indicate that an attacker is trying to gather initial data from the network and discover vulnerabilities by using LDAP commands.

MITRE ATT&CK® tactics and technique
Investigate

  • Check if the source endpoint is running an AD management software package

Exclusion scenarios

You might be able to mark this detection as an exclusion in these scenarios:

  • The same LDAP command is being used by a legitimate IT tool to configure the network

  • This is an exception for a group of endpoints, IPs, or users

Remediate

  • Review source endpoint data to find the initiating process, and remediate the endpoint activity

  • Review further activities performed with the user account from the compromised endpoint

51159 - Suspicious LDAP search (AD-CS reconnaissance)

A user executed a suspicious LDAP search enumerating Active Directory Certificate Services configurations.

This could indicate that an attacker is trying to gather initial data from the network and discover vulnerabilities by using LDAP commands.

MITRE ATT&CK® tactics and technique
Investigate

  • Check if the source endpoint is running an AD management software package

  • Check if the account activity is known to the user

  • Check if the LDAP command is common in the organization and has been seen before

Exclusion scenarios

  • The same LDAP command is being used by a legitimate IT tool to configure the network

  • This is an exception for a group of endpoints, IPs, or users

Remediate

  • Review source endpoint data to find the initiating process, and remediate the endpoint activity

  • Look for tools known for carry out this reconnaissance behavior: for example certipy (using events such as ProcessRollup2)

  • Try to determine the kind of reconnaissance that was carried out from the command line, for example look for the find command line

  • Check for other related reconnaissance detections

  • Review further activities performed with the user account from the compromised endpoint

51105 - Suspicious LDAP search (accounts)

A user executed a suspicious LDAP search request looking for Kerberos misconfigurations. These searches are commonly performed by known reconnaissance attack tools, such as Bloodhound or Impacket.

This could indicate that an attacker is trying to gather initial data from the network and discover vulnerabilities by using LDAP commands.

MITRE ATT&CK® tactics and technique
Investigate

  • Check if the source endpoint is running an AD management software package

  • Review further activities performed with the user account from the compromised endpoint

Exclusion scenarios

You might be able to mark this detection as an exclusion in these scenarios:

  • The same LDAP command is being used by a legitimate IT tool to configure the network

  • This is an exception for a group of endpoints, IPs, or users

Remediate

  • Review source endpoint data to find the initiating process, and remediate the endpoint activity

51163 - Suspicious LDAP search (ML)

A user executed a suspicious LDAP search request that meets the cloud-based behavioral machine learning model high confidence threshold for malicious queries. This detection is based on query similarities, such as filter or attributes, to known attack tools or attackers’ TTPs.

This could indicate that an attacker is trying to gather initial data from the network and discover vulnerabilities by using LDAP commands.

MITRE ATT&CK® tactics and technique
Investigate

  • Check if the account activity is known to the user

  • Check if the LDAP command is common in the organization and has been seen before

Exclusion scenarios

You might be able to mark this detection as an exclusion in these scenarios:

  • The same LDAP command is being used by a legitimate IT tool to configure the network

  • This is an expected behavior for the involved user, endpoints, or IPs

Remediate

  • Review source endpoint data to find the initiating process, and remediate the endpoint activity

  • Review further activities performed with the user account from the compromised endpoint

51164 - Suspicious web-based activity (ML)

A user performed a web-based activity that is considered anomalous according to a machine learning model.

This could indicate that user credentials were stolen, for example by phishing, and the account is being abused by an adversary.

MITRE ATT&CK® tactics and technique
Investigate
  • Check the findings that triggered the detection in detection analysis. For findings related to:
    • IP address or ISP domain
      • Check if there are other users with activities from the same IP
      • Check if the ISP domain name is legitimate
      • Check if the ISP is classified as a data center, and whether data center use is appropriate for the user’s role
      • Check if the ISP domain and classification meet organizational policies, for example with respect to the use of personal VPN or the use of public WiFi
    • Location, country or distance
      • Check the ISP domain and classification to evaluate if the user has actually traveled or is using a VPN or a data center
      • If the user has traveled, check if travel to the location or country is allowed and approved by the organization
    • OS, device or browser
      • Check the OS or browser version against versions used previously by the user to determine if there was a minor version upgrade or a larger change
      • Check if use of the OS, device, or browser is allowed and still supported within the organization
    • Application
      • Check if the application being accessed is sensitive and whether it is appropriate for the user’s role
    • Activity Time
      • Check the activity time and country to see if the user could be traveling to a different time zone
      • Check if the user has recently started working irregular hours
  • Check if the account activity is known to the user
Exclusion scenarios
You might be able to mark this detection as an exclusion in these scenarios:
  • The user is traveling to a location that is not common for the organization's users
  • An end user is performing anomalous activity for a legitimate business purpose, such as a position change, new project, or rare administrative maintenance
  • A user account is being used by an automated script or service that performs operations on behalf of the user from a data center location
  • A corporate proxy or gateway might not be recognized by Identity Protection
Remediate
  • If the activity is found to be malicious:
    • Depending on the privileges of the user, force a password change for the compromised user account or disable the account completely
    • Investigate what further activities were performed by the user account
    • Investigate if further activities were performed by other accounts with the same IP
    • Add the user to the watchlist
  • Create a workflow to revoke sessions for users involved in similar detections in the future
51160 - Anomalous certificate-based authentication

A user performed an anomalous certificate-based authentication, which might indicate suspicious activity originating from the source endpoint.

Investigate

  • Check if the account activity is known to the user

  • Check the settings of the certificate template that was used

  • Check if the certificate template was previously used by other users

  • Check the authentication pattern to determine if it's likely to be performed by the user

  • Check if there are any successful authentication attempts originating from the same source user and endpoint

Exclusion scenarios

You might be able to mark this detection as an exclusion in these scenarios:

  • This is the first time certificate template authentication was enabled by the domain policy

  • The same authentication was performed by a legitimate IT tool

Remediate

  • Review all of the certificate template settings, to determine whether they are configured according to the domain policy or not

  • Review further activities performed by the user account

  • If the activity is found to be malicious:

    1. Open the certificate management tool from the certificate authority (CA) endpoint that issued the misconfigured template

    2. Revoke the certificate template

51161 - Anomalous certificate-based authentication (user mismatch)

A lower-privileged entity performed an unusual Kerberos certificate-based authentication to a higher-privileged entity, which might indicate malicious activity.

Investigate

  • Check if the account activity is known to the user

  • Check the settings of the certificate template that was used

  • Check if the high-privileged user has previously authenticated from the same source endpoint

  • Check if the certificate template was previously used by other users

  • Check the authentication pattern to determine if it's likely to be performed by the user

  • Check if there are any successful authentication attempts originating from the same source user and endpoint

Exclusion scenarios

You might be able to mark this detection as an exclusion in these scenarios:

  • This is the first time certificate template authentication was enabled by the domain policy

  • The same authentication was performed by a legitimate IT tool

Remediate

  • Review the certificate template that was used for the misconfigured settings, if needed

  • Review all of the certificate template settings, to determine whether they are configured according to the domain policy or not

  • Review further activities performed by the user account

  • Review source endpoint data to find the initiating process, and remediate the endpoint

  • If the activity is found to be malicious:

    1. Open the certificate management tool from the certificate authority (CA) endpoint that issued the misconfigured template

    2. Revoke the certificate template

51162 - Anomalous certificate-based authentication (unusual TGS request)

A user executed a self-request for a Ticket Granting Service (TGS), following a Kerberos certificate-based authentication, which may indicate malicious activity.

Investigate

  • Check if the account activity is known to the user

  • Check if the user previously performed Kerberos certificate-based authentication

  • Check the authentication pattern to determine if it's likely to be performed by the user

Exclusion scenarios

You might be able to mark this detection as an exclusion in these scenarios:

  • The same authentication was performed by a legitimate IT tool

Remediate

  • Review the certificate template that was used for the misconfigured settings, if needed

  • Review further activities performed by the user account

  • Review source endpoint data to find the initiating process, and remediate the endpoint

51141 - Suspicious machine alteration

A machine account was altered in a way that indicates a noPac exploitation attempt, for example CVE-2021-42278 and CVE-2021-42287.

MITRE ATT&CK® tactics and technique
Investigate
Exclusion scenarios

You might be able to mark this detection as an exclusion in these scenarios:

  • Machines are being configured in an irregular manner

  • This is an exception for a group of endpoints, IPs, or users

Remediate
51102 - Suspicious protocol implementation (NTLM relay)

An NTLM authentication occurred with fields indicating that their authentication was used in an NTLM relay attack.

This could indicate that malware is attempting to move laterally across the network and escalate its privileges.

MITRE ATT&CK® tactics and technique
Investigate

  • Check if the account activity is known to the user

  • Check if the target endpoint enforces SMB signing or if the target DC enforces LDAP signing and LDAPS channel bindings

Exclusion scenarios

You might be able to mark this detection as an exclusion in these scenarios:

  • Legacy software exists on the network that uses deprecated encryption standards

  • Incorrect network configuration exists

  • This is an exception for a group of endpoints, IPs, or users

Remediate

  • Review endpoint data to find the initiating process and remediate endpoint

  • Review the target endpoint to examine the activities performed using the suspected relayed session, and remediate the endpoint

  • Create a policy to enforce MFA for all user activities

  • Work to disallow NTLM traffic in your network, especially NTLMv1

  • Enforce SMB signing, LDAP signing, and LDAPS channel bindings on all endpoints in the network

51101 - Suspicious protocol implementation (Pass the Hash)

An authentication protocol, such as NTLM, Kerberos, or SMB, occurred with fields indicating that their authentication was used in a Pass the Hash attack.

This could indicate that malware is attempting to move laterally across the network and escalate its privileges.

MITRE ATT&CK® tactics and technique
Investigate

  • Check if the source endpoint is executing a legacy software product and authenticating with a proprietary authentication stack

  • Check if the account activity is known to the user

Exclusion scenarios

You might be able to mark this detection as an exclusion in these scenarios:

  • Legacy software exists on the network that uses deprecated encryption standards

  • Incorrect network configuration exists

  • This is an exception for a group of endpoints, IPs, or users

Remediate

  • Review source endpoint data to find the initiating process, and remediate the endpoint

  • Create a policy to enforce MFA for all user activities

51103 - Suspicious protocol implementation (valid accounts)

An authentication protocol, such as NTLM, Kerberos, or SMB, was used in an unusual manner consistent with known attack tools such as Mimikatz or Impacket.

This could indicate that malware is attempting to move laterally across the network and escalate its privileges.

MITRE ATT&CK® tactics and technique
Investigate

  • Check if the source endpoint is executing a legacy software product and authenticating with a proprietary authentication stack

  • Check if the account activity is known to the user

Exclusion scenarios

You might be able to mark this detection as an exclusion in these scenarios:

  • Legacy software exists on the network that uses deprecated encryption standards

  • Incorrect network configuration exists

  • This is an exception for a group of endpoints, IPs, or users

Remediate

  • Review source endpoint data to find the initiating process, and remediate the endpoint

  • Create a policy to enforce MFA for all user activities

51165 - Unusual access to a user entity (Kerberoasting)

An end user accessed the service principal name (SPN) that is registered to a user account. The access was deemed anomalous based on several factors such as user classification, requested encryption type, and previous activities.

This could indicate that an end user requested a service ticket for offline password cracking (Kerberoasting).

MITRE ATT&CK® tactics and technique
Investigate
  • Determine whether the end user requires the use of the target service and assess the riskiness of the users involved
  • Check if the account activity is known to the user
Exclusion scenarios

You might be able to mark this detection as an exclusion in these scenarios:

  • An end user is performing anomalous activity for a legitimate business purpose, such as a position change, new project, or rare administrator maintenance
Remediate
  • If the target account is a regular user, it is recommended to remove the SPN and assign it to a dedicated service account
  • If the user denies performing the action, there is a high probability of malware on the machine or in the network, and you should alert the Incident Response Team
51132 - Unusual access to an application

A user accessed an application for the first time.

This could indicate:

  • An end user accessing servers to illicitly acquire information, usually because the end user is over-privileged

  • Malware is using valid credentials to access data or to move laterally across the network

MITRE ATT&CK® tactics and technique
Investigate

  • Check if the account activity is known to the user

  • Check for other anomalies from the user account

Exclusion scenarios

You might be able to mark this detection as an exclusion in these scenarios:

  • An end user is performing anomalous activity for a legitimate business purpose, such as a position change, new project, or rare administrative maintenance

  • This is an exception for a group of endpoints, IPs, or users

Remediate

  • Force a password change for the user account

  • Review the application logs to assess user activity

  • Create a policy to enforce MFA for all user activities

51135 - Unusual login to an endpoint

A user logged in interactively or programmatically to a machine for the first time.

This could indicate an end user stealing another end user’s credentials to access data for which they do not have the required privileges, or malware using credentials acquired by illicit activities in the network.

MITRE ATT&CK® tactics and technique
Investigate

  • Check if the account activity is known to the user

  • Check the source endpoint logs to verify that the IP is associated with the correct machine

Exclusion scenarios

You might be able to mark this detection as an exclusion in these scenarios:

  • An end user is performing anomalous activity for a legitimate business purpose

  • This is an exception for a group of endpoints, IPs, or users

Remediate

  • Review source endpoint data to find the initiating process, and remediate the endpoint

  • Create a policy to enforce MFA for all user activities

51137 - Unusual service access to an endpoint

A user requested access to a service on an endpoint for the first time.

This could indicate:

  • An end user accessing servers to illicitly acquire information, usually because the end user is over-privileged

  • Malware using valid credentials to access data or to move laterally across the network

MITRE ATT&CK® tactics and technique
Investigate

  • Check if the account activity is known to the user

  • Check the source endpoint logs to verify that the IP is associated with the correct machine

Exclusion scenarios

You might be able to mark this detection as an exclusion in these scenarios:

  • An end user is performing anomalous activity for a legitimate business purpose, such as a position change, new project, or rare administrative maintenance

  • This is an exception for a group of endpoints, IPs, or users

Remediate

  • Review source endpoint data to find the initiating process, and remediate the endpoint

  • Create a policy to enforce MFA for all user activities

51129 - Use of stale endpoint

An endpoint not used in the last 90 days became active.

This could indicate:

  • Malware attempting to use or forge a stale unused computer or end user account

  • A former end user, such as a former employee attempting to connect his own device to the network

MITRE ATT&CK® tactics and technique
Investigate

  • Review previous and current endpoint activity

Exclusion scenarios

You might be able to mark this detection as an exclusion in these scenarios:

  • An end user returned after a very long absence

  • This is an exception for a group of endpoints

Remediate

  • Confirm that the endpoint was stale because of a legitimate end user absence, such as vacation or sick leave, and is not an overlooked outdated account. You can schedule a stale endpoint report to help with this.

51130 - Use of stale user account

A user account not used in the last 90 days became active.

This could indicate:

  • Malware attempting to use a stale account

  • A former end user, for example a former employee is attempting to connect with their previous password

MITRE ATT&CK® tactics and technique
Investigate

  • Check if the account activity is known to the user

Exclusion scenarios

You might be able to mark this detection as an exclusion in these scenarios:

  • An end user returned after a very long absence

  • This is an exception for a group of users

Remediate

  • Create a policy to enforce MFA for all user activities

51153 - Skeleton key attack

A domain controller (DC) is rejecting recommended cryptographic algorithms, and is demanding a weaker RC4 algorithm instead.

This could indicate that the domain is compromised, or that the DC is incorrectly configured.

MITRE ATT&CK® tactics and technique
Investigate

  • Check that the domain controller is not explicitly configured to only accept the RC4 algorithm.

Exclusion scenarios

You might be able to mark this detection as an exclusion in these scenarios:

  • You have a strong technical reason why your domain controllers can only accept the RC4 algorithm.

Remediate

  • If you have not explicitly configured the domain controller to accept only the RC4 algorithm, assume that your domain is compromised, and alert the Incident Response Team.

51155 - Suspicious LDAP search (KrbRelay)

A user executed a suspicious LDAP search indicative of a privilege escalation attempt. These searches are commonly performed by known attack tools, such as KrbRelay or KrbRelayUp.

This could indicate that an attacker is trying to gather initial data from the network and discover vulnerabilities by running LDAP commands.

MITRE ATT&CK® tactics and technique
Investigate

  • Review related accounts activities:

    • The account whose identity was impersonated.

    • The account from which the tool was run.

  • Review source endpoint data to find the initiating process:

    • Look for tools known to carry out this attack: krbrelay.exe, krbrelayup.exe (using events such as ProcessRollup2).

    • Try to determine the kind of privilege escalation that was carried out from the command line.

    • Check for other related detections.

  • Review related network activity that occurred close to the time of the detection (using events such as NetworkConnectIP4 and ProcessRollup2):

    • Look for a local TCP connection from a COM server (svchost.exe) to a suspicious process which then connects to a domain controller.

    • Look for usage of port 12345 in local traffic.

      Note: Ports other than 12345 may also be used for this type of attack.
Exclusion scenarios

You might be able to mark this detection as an exclusion in this scenario:

  • The same LDAP search is being used by a legitimate IT tool to configure the network.

Remediate

  • Consider creating a policy to enforce MFA for activities related to the involved accounts and endpoints.

  • Determine the scale of the attack and perform the appropriate remediation actions. If you determine that the full domain was compromised, rebuild your AD environment.

51156 - Honeytoken account alteration

A honeytoken account was altered in a way that can indicate an exploitation attempt.

We monitor one of the following changes to the account:

  • Password reset

  • Disabled account becoming enabled

  • Email change

MITRE ATT&CK® tactics and technique
Investigate

  • Check if the detected account is suspicious.

  • Investigate who performed the change using audit logs and rule out account compromise.

Exclusion scenarios

You might be able to mark this detection as an exclusion in these scenarios:

  • This is an exception for a group of users.

  • This is an expected activity from a specific source endpoint. In this case, use Exception Manage view to select specific source endpoints to exclude.

  • Account alteration-based detections for this honeytoken aren't relevant.

Remediate

  • If the account change is suspicious, restore the account settings to their original state.

  • Remediate any compromised endpoints and/or user accounts if any were found during the investigation.

51157 - Honeytoken account activity

A honeytoken account activity was detected.

MITRE ATT&CK® tactics and technique
Investigate

  • Check if the detected activity is suspicious.

  • If the activity is suspicious, investigate the source endpoint from which the activity originated to rule out any compromise.

  • Check additional related activities using the Investigate menu.

Exclusion scenarios

You might be able to mark this detection as an exclusion in these scenarios:

  • This is an exception for a group of users or endpoints.

  • This is an expected activity from a specific source endpoint. In this case, use Exception Manage view to select specific source endpoints to exclude.

  • Activity-based detections for this honeytoken aren't relevant.

Remediate

  • Remediate any compromised endpoints and/or user accounts if any were found during the investigation.

  • If the activity is suspicious, reset the account password.

  • Make sure the selected account should be flagged as honeytoken.

Appendix B: Risk factors

Risk factors negatively affect an entity’s risk score. Each factor is listed with the nature of the risk and how it can be reduced or neutralized.

If a risk shares similar characteristics with MITRE ATT&CK® tactics and/or techniques then these are also listed.

You can disable specific risk factors so that they do not contribute to risk scores, and are no longer added to the risk factor lists. For more info, see Identity Protection Administration.

Account without MFA configured

Topic Details

Description

A user account doesn't have an authentication method that is allowed in the Entra ID authentication policy, making it vulnerable to account takeover attacks.

Recommended actions

Configure and require an MFA method that is allowed in Entra ID authentication policy.

Accounts using DES key only

Topic Details

Description

A user account is configured to encrypt all tickets with DES encryption. An attacker with the ability to obtain a user ticket can crack the user hash more easily.

Recommended actions

Enable strong encryption for all users.

Accounts with privileged SID

Topic Details

Description

An account has a privileged SID in their SID History property. Users with a privileged SID possess higher permissions than their role allows. It is very likely that the privileged SID was added as part of an attack.

MITRE ATT&CK® tactics and techniques

Recommended actions

Remove the privileged SID from the user's SID History and investigate how they obtained this potentially malicious property.

Aged password

Topic Details

Description

The end user’s password has not been changed for more than 6 months. The longer an end user keeps the same password, the greater the risk of the password being cracked by an advanced attack. Even strong passwords can be cracked by brute force methods within three months.

Note: This risk factor is disabled by default. See Manage risk detection.

Recommended actions

Increase the frequency of password changes in the GPO policy.

Association with a risky endpoint

Topic Details

Description

End users regularly access a risky endpoint. A risky endpoint is more vulnerable to attacks, and end users who regularly access risky endpoints are more likely to have to have their credentials compromised or stolen.

Recommended actions

Address the underlying factors that cause the endpoint to be risky. If this is not possible or seriously impacts end users, consider moving the end user to another workstation.

Attack path to a privileged account

Topic Details

Description

An attacker with access to an account, user, or endpoint, can move laterally between endpoints in the network to access an account and eventually acquire permissions to function as a domain administrator. If an account is compromised in this way the entire domain is compromised.

Steps in a Path

For example: A user, StartUserName, has one or more attack paths available to the Privileged account of another user, EndUserName. Possible steps that an attack might take include:

  • Being a local administrator on an endpoint.
  • Having a path or being a local administrator on an endpoint that was recently accessed by a privileged account.
  • Being a local administrator on an endpoint that has another local administrator with the same password as that which belongs to a local administrator of a different endpoint.
  • Being a user who is a direct or indirect member of a Group.

Recommended actions
  • Review the attack path and examine which steps can be resolved and removed.
  • Ensure that privileged accounts only log into protected endpoints.
  • Remove unwanted local administrator privileges

For more info, see How can I resolve an attack path risk in Identity Protection.

Azure access using a legacy protocol

Topic Details

Description

An Azure account is using an application that does not enforce MFA. The user's credentials can be brute-forced from the internet without mitigation. If an application is open for all users, the entire organization might suffer a credentials scanning attack.

Recommended actions

Use only applications with modern authentication and enable MFA for all accounts.

Compromised password

Topic Details

Description

An end user’s password is on a list of passwords (word lists) known to be compromised. This list is usually collected from known password breaches or contains commonly used phrases. Compromised passwords are easy to guess.

Recommended actions

Direct users to change passwords that Identity Protection flags as weak or compromised, and educate users about the risk of using passwords that are prone to dictionary-based attacks.

Duplicated local administrator

Topic Details

Description

Two or more machines were created from the same image and still have the same local administrator username and password.

By compromising one of these machines, an attacker can extract the credentials from the local Security Account Manager (SAM) database and move laterally to other machines by using pass-the-hash or privilege escalation.

Recommended actions

Change the passwords of the cloned local administrators. To easily manage local administrator passwords, consider using Microsoft LAPS or another password management solution.

Duplicated password

Topic Details

Description

Two or more user accounts share the same password.

Using duplicated passwords across multiple accounts can lead to lateral movement and credential stuffing attacks if one account is compromised, resulting in a breach.

Recommended actions

Ensure each account has a unique password.

Endpoint with never changing password

Topic Details

Description

The computer account password is configured to never expire.

Domain-joined machines are required to rotate their password every 30 days. The password should be randomly generated to ensure system integrity from outside breaches. An endpoint with a never-changing password doesn’t change its password regularly and raises further suspicion of a weak and even shared machine password.

Recommended actions
  • Configure computer accounts to rotate passwords and remove passwords that never change.
  • If a machine is unable to rotate the computer account password (for example, Linux), make sure that the computer account is needed and then have a strong password.

Excessive NTLM activity

Topic Details

Description

An account using NTLM to access an unusual number of servers/workstations.

A user accessing machines using NTLM is exposed to the risk of password cracking and NTLM relay.

Recommended actions

If the software performing actions supports Kerberos, make sure that only Kerberos is enabled. You can also do this by disabling NTLM for the account.

GPO exposed local admin password

Topic Details

Description

This endpoint has a local administrator whose password is stored in the Group Policy Preferences in a reversible format. This exposes the password to any domain user.

The endpoint can be compromised by any user in the network by fetching exposed local admin credentials.

Recommended actions

Remove the exposed password from the Group Policy and reset the respective account's password.

GPO exposed password

Topic Details

Description

The account’s password can be extracted by any authenticated account in the domain.

Any rogue end user or malware can acquire and use the account password.

Recommended actions

Remove the password from GPO; there is no valid reason to keep it. If it is used by scripts, change the scripts to use a more secure solution such as Local Administrator Password Solution (LAPS).

Guest account enabled

Topic Details

Description

A user can connect to a machine with a local guest user account, that is without a password.

If the guest account is enabled, any user can connect to the machine and potentially escalate their privileges to become a Local Administrator.

Recommended actions

Disable the guest accounts on all endpoints.

Has certificate template with request agent EKU accessible to users without admin privileges

Topic Details

Description

CA server has at least one certificate template with the Request Agent enhanced key usage (EKU) that is accessible to users without admin privileges which might allow the user that uses that certificate to authenticate as any other user with that certificate.

Recommended actions
  • Based on the certificate name that generated the risk, open the certificate managing tool on the certificate authority (CA) endpoint and revoke the certificate template.
  • Open the certificate managing tool on the CA endpoint and review the permission list for the certificate template. Remove unnecessary permissions if needed.
  • Add restrictions on the certificate authority endpoint settings for the request agent, if needed.
  • On the CA endpoint, review which users already enrolled and used that certificate template.
  • Consider adding CA Certificate manager approval or authorized signatures to the certificate template.

Has risky certificate template with authentication related EKU accessible to users without admin privileges

Topic Details

Description

CA server has at least one certificate template with authentication related enhanced key usage (EKU) that is accessible to users without admin privileges which might allow the user that uses that certificate to authenticate as any other user with that certificate.

Recommended actions
  • Based on the certificate name that generated the risk, open the certificate managing tool on the certificate authority (CA) endpoint and revoke the certificate template.
  • Open the certificate managing tool on the CA endpoint and review the permission list for the certificate template. Remove unnecessary permissions if needed.
  • On the CA endpoint, review which users already enrolled and used that certificate template.
  • Consider adding CA Certificate manager approval or authorized signatures to the certificate template.

Hidden object

Topic Details

Description

Attributes have been set on an account in such a way that it does not appear to Active Directory administrators. An account might be under the control of an attacker who tries to hide their presence from defenders.

Recommended actions

Investigate whether the account was hidden by an administrator for a legitimate reason, or by accident. If so, consider altering the account to make it visible.

If it wasn’t hidden for a legitimate reason, consider disabling or deleting the account.

Inactive account

Topic Details

Description

An account that has not generated any activity for a given time period greater than 21 days.

The account is not monitored by any person who would alert administrators about unusual activity (for example, password change). Also, prolonged inactivity is an indication that the account should be deleted.

Recommended actions
  • Enable the Inactive User Usage policy and require MFA for users who had previously been inactive.
  • Disable the account if possible. If this is not possible, consider adding an authorizer to the account and use a policy with email verification so that the authorizer is informed of all activity in this account.

Inadequate password policy

Topic Details

Description

The password policy for the account allows setting a password that is too short and/or lacks complexity.

Short passwords have relatively low entropy and can be cracked by specialized hardware or even through the use of plain modern CPUs if the password is short enough.

Recommended actions

Make sure the password policy is set to a minimum of 14 characters.

Detections as risk factors

Topic Details

Description

Each detection in which a user is involved is added to the user’s risk factors. The detection is graded according to its severity and number of alerts. In addition, over time, the impact of detections on risk declines, and 30 days after the detection it no longer affects the user’s risk factor.

An end user engaged in anomalous activity (even when not malicious) is at a higher risk of being compromised. In addition, his anomalous activity is more difficult to track and his security posture more difficult to evaluate because of alert fatigue.

Recommended actions

Wait until the detection is over or resolve the incident. Where possible, reduce the unexpected behavior in the network.

Insufficient password rotation

Topic Details

Description

The end user is configured with a password that never expires and the password was not rotated for more than 6 months.

If a password that never expires is compromised, the risk to the network is severe. You might not be able to resolve some consequences.

Recommended actions
  • Define a password expiration period in the GPO for all end users.
  • For those service accounts for which this is not practical, there is no alternative but to assume the associated risk. However, you should closely and frequently monitor the use of these accounts.

Kerberos pre-authentication for TGT is not required

Topic Details

Description

A user account is defined to obtain TGTs (Ticket-Granting Tickets) without Kerberos pre-authentication. This is an uncommon feature of legacy service accounts.

If a password that never expires is compromised, the risk to the network is severe. You might not be able to resolve some consequences.

Recommended actions

Enforce pre-authentication data for all user accounts.

KRBTGT password not changed for 180 days

Topic Details

Description

A KRBTGT service account password hasn’t changed in more than 180 days. An attacker with a Golden Ticket could remain active if the password isn’t changed.

Recommended actions

Change the KRBTGT password every 180 days.

For more information, see KRBTGT account in the Microsoft documentation.

LDAP signing is not required

Topic Details

Description

The Domain controller does not require LDAP Signing for LDAP connections.

When a domain controller does not require LDAP Signing for LDAP connections, it is susceptible to various credential relay attacks, for example NTLM Relay.

Recommended actions

Strictly enforce LDAP Signing on all domain controllers.

LDAPS channel binding is not required

Topic Details

Description

The Domain controller does not require LDAPS Channel Binding for LDAPS connections.

When a domain controller does not require LDAPS channel Binding for LDAPS connections, it is susceptible to various credential relay attacks, for example NTLM Relay.

Recommended actions

Strictly enforce LDAP Channel Binding on all domain controllers.

NTLMv2 compatibility

Topic Details

Description

An endpoint is configured through GPO to respond with NTLMv1 and/or LM responses.

NTLMv1 and/or LM responses are encrypted with a very weak encryption (DES), making the user account password on this endpoint extremely vulnerable.

Recommended actions

Ensure that all endpoints send only NTLMv2 responses. To enforce NTLMv2 responses through GPO, configure the Network security: LAN Manager authentication level security policy setting to one of these options:

  • Send NTLMv2 responses only
  • Send NTLMv2 responses only. Refuse LM
  • Send NTLMv2 responses only. Refuse LM & NTLM

For information on how to configure this setting, see Network security: LAN Manager authentication level in the Microsoft documentation.

Password never expires

Topic Details

Description

The end user’s password is configured to never expire.

If a password that never expires is compromised, the risk to the network is severe and might never be mitigated.

Recommended actions
  • Define a password expiry for all end users in GPO. For those service accounts for which this is not practical, there is no alternative but to assume the attendant risk. However, you should closely and frequently monitor the use of these accounts.
  • Alternatively, define a policy to force human users that Identity Protection determines have compromised passwords to change their passwords. This action is more contextually aware than the previous action.

Poorly protected account with SPN

Topic Details

Description

A user account is defined with a Service Principal Name (SPN). Usually, only computer accounts and service accounts are defined with SPNs.

An account with SPNs is at risk of password cracking with a technique called Kerberoasting when the account has a weak password or when its password policy does not enforce strong passwords.

Recommended actions
  • Remove the SPNs from the user account.
  • Make sure the account has a strong password.
  • Make sure the password policy enforces strong passwords.

Print Spooler Service running

Topic Details

Description

Print Spooler Service is enabled on a machine.

When the Print Spooler Service is enabled on a machine, an attacker can trigger the machine to perform authentication on an arbitrary machine. This authentication can be exploited in various credential relay attacks. For example, NTLM Relay.

Recommended actions

Turn off the Print Spooler Service on any machine with special privileges.

Privileged endpoint account

Topic Details

Description

A computer account with special administrative privileges.

Except for domain controllers, no machines should have any special privileges. If a machine has special privileges, so do their local administrators, which can lead to complex attack paths.

Recommended actions

Remove special privileges from the machines.

Privileged users using non-domain-joined endpoint

Topic Details

Description

Non-domain-joined endpoints are being used by privileged users.

Such endpoints are considered to be at greater risk of exposure to viruses and other malicious software because no group policies, and in many cases no software updates, are applied to these endpoints. Privileged users put themselves and the organization at greater risk by using non-domain-joined endpoints.

Recommended actions

Ensure that privileged users do not use non-domain-joined endpoints.

Risky linked accounts

Topic Details

Description

There is a linked user account that has a risk score that is higher than this entity's score, and has at least medium severity.

Having risky accounts that belong to the same person may put the rest of the linked accounts at risk as well.

Recommended actions

Investigate and remediate the risks on the linked accounts that have a higher risk score.

Shared endpoint

Topic Details

Description

An endpoint is being used by multiple users. The credentials of all the users are stored on the endpoint, and they all have permission to execute code on the endpoint.

Recommended actions

Use personal machines as much as possible.

Shared endpoint used by privileged users

Topic Details

Description

Privileged users are using shared endpoints.

These are endpoints that are used by multiple users with various levels of permissions. This increases the attack surface of shared endpoints. Privileged users put themselves and the organization at greater risk by using shared endpoints.

Recommended actions

Ensure that privileged users do not use shared endpoints.

Shared user

Topic Details

Description

An end user who is using multiple machines. The user’s credentials are present on all the endpoints.

Recommended actions
  • Avoid giving the end user administrative privileges.
  • Reduce, as much as is practical, the number of machines used by a single end user.

SMB signing disabled

Topic Details

Description

An endpoint is configured through GPO to allow unsecure SMB and DCE/RPC connections.

When an endpoint is configured to allow unsecure connections, it is vulnerable to NTLM relay and MiTM attacks that could result in remote code execution.

Recommended actions

Edit the group policies that apply on the endpoint to enforce SMB signing.

Stale account

Topic Details

Description

An account that has not generated any activity for a given time period of more than 3 months.

The account is not monitored by any person who would alert administrators about unusual activity (for example, password change).

Also, prolonged inactivity is an indication that the account should be deleted.

Recommended actions
  • Enable the Inactive User Usage policy and require MFA for accounts which had previously been inactive.
  • Disable the account if possible. If this is not possible, consider adding an authorizer to the account and use a policy with email verification so that the authorizer is informed of all activity in this account.

Stealthy privileges

Topic Details

Description

An account that has special permissions and could be used to elevate a user to have AD protected group privileges.

  • In many cases, stealthy privileges are a byproduct and are therefore not fully understood or managed.
  • User accounts with stealthy privileges are typically easier to compromise and give the attacker an easy way to escalate the privileges.
  • Stealthy admins don’t have AdminSDHolder protection.

Recommended actions

Review the privileges that the user account currently has. If they are required, add the user to an AD protected group. If the privileges are not required, remove them.

For more info, see our knowledge articles:

How to remove Effective Replicator privileges?

How to remove Administrator Password Controller privileges?

How to remove Permissions On Account Controller privileges?

How to remove Administrative Group Controllers privileges?

How to remove Constrained/Unconstrained Account Service Delegation privileges?

How to remove Object-SID History Takeover privileges?

How to remove Privileged Application Controller privileges?

Suspicious SPN

Topic Details

Description

An account has one or more irregular Service Principal Names (SPNs).

These SPNs can be used maliciously in some man-in-the-middle (MITM) attack scenarios.

Recommended actions

Verify if the SPNs are needed, and remove them if not.

Suspicious UPN

Topic Details

Description

The userPrincipalName (Active Directory UPN) field for a user without admin privileges was set to a high privileges username with an invalid UPN format which could indicate suspicious activity.

Recommended actions
  • Review the UPN field for the user without admin privileges.
  • Review which users have the permissions to change the UPN for that user.
  • Change the UPN back to the valid format with the right user name.
  • Check where the users authenticate and if there is any suspicious activity.

Non-domain-joined endpoint used by privileged users

Topic Details

Description

Non-domain-joined endpoints are being used by privileged users.

Such endpoints are considered to be at greater risk of exposure to viruses and other malicious software because no group policies, and in many cases no software updates, are applied to these endpoints. Privileged users put themselves and the organization at greater risk by using non-domain-joined endpoints.

Recommended actions

Ensure that privileged users do not use non-domain-joined endpoints.

Non-domain-joined host

Topic Details

Description

An non-domain-joined host is active on the network but is not registered in the domain and, as such, is not protected by domain policies.

An non-domain-joined host is not monitored by any person and is not being regularly patched by the Windows infrastructure.

Recommended actions
  • Join the host to the domain if possible. Solutions also exist for personal non-Windows machines.
  • Ensure that all hosts are regularly monitored and patched.

Usage of endpoints that have non-privileged local administrator

Topic Details

Description

The risk identifies when a privileged account accesses an endpoint that has a nonprivileged local administrator.

The privileged account logged into an endpoint that has a nonprivileged local administrator, which can be used to compromise this account's credentials.

Recommended actions

Make sure that privileged accounts only use protected machines. For example, PAW.

VPN usage

Topic Details

Description

An end user is connecting to the network over a VPN.

Typically, a VPN user is away from the office with a personal computer in a physically unsafe location where their credentials and equipment are more likely to be compromised.

Note: This risk factor is disabled by default. See Manage risk detection.

Recommended actions

Limit the use of VPNs to as few users as is practical.

Vulnerable OS

Topic Details

Description

An endpoint is running an old version of its operating system that is no longer supported.

An operating system version that is no longer supported does not receive regular software updates and is exposed to known vulnerabilities that are normally and regularly patched by newer operating system versions.

Recommended actions

Limit the use of old versions of operating systems that are no longer supported.

Watched user

Topic Details

Description

The end user is being watched, either manually by the system administrator or automatically by a policy action.

Watched end users are being watched for a reason, and Identity Protection treats these users with greater attention. Note that the reason the user is being watched is sometimes outside the scope of Identity Protection. For example, the end user is under notice.

Recommended actions

Address all the end user’s external risk and then remove the user from the watch list.

Web-based login using a vulnerable device

Topic Details

Description

A user has logged in to Entra ID from a machine that is not updated and is known to have 0-days that can compromise it.

The user's credentials (passwords, tokens, OTPs, cookies) and sensitive data can be compromised along with the insecure endpoint that the user is using.

Recommended actions

Train employees to only use approved machines. Monitor users closely and enforce MFA for these users wherever possible.

Identity Protection Reports

Save, schedule, and review predefined and custom reports.

Overview

The Reports page allows administrators to perform a number of report oriented activities that include:

  • Saving predefined reports.

  • Scheduling the download and distribution of predefined reports.

  • Reviewing a list of saved predefined and custom reports.

Reports can be defined and downloaded immediately, or scheduled for later downloading and distribution. Most reports can be distributed in PDF or CSV formats. Depending on the type of info in a report, it might be limited to one format type though.

To view the Reports page, go to Identity protection > Configure > Reports.


Example of two saved reports on the Reports page.

The Reports page displays the following:

  • Saved Reports list

    The Saved Reports list displays all the reports that are saved and indicates; the reporting period over which data is collected, the output format, the frequency that a report is generated and distributed, and the number of recipients that receive the report.

    Predefined reports appear in the upper part of the list.

    User defined reports appear after the predefined reports.

  • Scheduling Panel

    The Scheduling panel includes fields for choosing a predefined report and then setting the following settings:

    • Reporting period

    • Generation and distribution frequency

    • Output format

    • Recipients

    • The domain on which the report is generated

  • Action menu

    The action menu is located on the right of each report entry in the Saved Reports list.

    The Action menu lets you:

    1. Edit the report scheduling settings

    2. Download the report

    3. Send the report as an email attachment

    4. Delete the report from the list

Scheduling and saving reports

Use the reports scheduling options to define the breadth of information contained in a report, the frequency that a report is generated, the delivery format, and the recipients of the report.

Scheduling options

The table lists and describes the scheduling options.

Field Description

Subject

List of predefined and custom reports.

Reporting period

The period for which data is included in the report.

Choose from:

  • Last 24 hours
  • Last 7 days
  • Last 30 days

Frequency

How often the report is published. Depending on your choice, you can refine the publication frequency where relevant by choosing the day and hour to publish a report.

Choose from:

  • Daily
  • Weekly
  • Monthly

Format

Depending on the report type, you can choose to publish the report in one of the available formats.

Choose from:

  • CSV
  • PDF

Recipients

The email address for anyone who should receive the published report.

The Enter key functions as a separator to include the email address of multiple recipients.

To remove recipients from the recipients list, click the x adjacent to their email address.
Scheduling a report

  1. Go to Identity protection > Configure > Reports.

  2. Select a report Subject.

  3. Select a Reporting Period.

  4. Select a report Format (PDF or CSV).

  5. Configure the report Frequency.

  6. Fill the Recipient email list.

  7. Click Save.

Downloading a report

  1. Go to Identity protection > Configure > Reports.

  2. Select a report Subject.

  3. Select a Reporting Period.

  4. Define the Frequency.

  5. Select a report Format (PDF or CSV).

  6. Click Download.

Predefined reports

Predefined reports include both executive and operational reports, for example:

  • Activity: Account lockout by user/endpoint, NTLM usage, inactive administrators, and unused servers/endpoints reports

  • Incidents: Top incidents, new incidents, top users with incidents, and incidents summary reports

  • Insights: Top risky users, added/disabled/removed computer accounts, and administrative login reports

  • Authorized Accounts: A detailed configuration of all authorized accounts

Custom reports

You can generate custom reports based on the results of Insights and Threat Hunter queries.

  • For Insights you can create custom reports for queries associated with the Privileged, Users, and Endpoint categories.

  • For Threat Hunter you can save custom reports based on any generated query.

Identity Protection System Notifications

Review events about connectors, software updates, and system coverage.

Identity Protection System Notifications

System Notifications displays events that might require your attention. The number of active notifications is also shown in parenthesis.

To display the system notifications, go to Identity protection > Configure > System notifications.

You can filter notifications as follows:

  • All Notifications

  • Connectors

  • Software Update

  • System Coverage

The creation and last update time appears on every notification and the notification remains active for as long as the problem persists. When the problem is resolved, the notification automatically moves to the Resolved Notification area, and the resolution time replaces the last update time.

If the same problem occurs again within the next 24 hours, the same notification is reused. If the same problem occurs more than 24 hours after the last notification, a new notification is opened. Notifications are all managed by the system. You cannot dismiss system notifications manually.

You can mark notifications as read. Read notifications are hidden by default. To show the read notifications, click Show read notifications.

Notification types

Notification Description

{connector name} Connector down. Unable to connect to service

A connector cannot communicate with a third-party IDaaS or MFA provider.

{protocol} inline health-check failed for {DC sensor name}. Sensor IP address: {IP address}

The DC Sensor detected that specific protocol data has not been processed successfully.

If this message does not resolve itself, contact CrowdStrike Support. For US-GOV-1 and US-GOV-2 customers, contact CrowdStrike Support.

The watchdog for {DC sensor name} has triggered policy stop due to metric {metric name}

The DC Sensor Watchdog stopped the policy calculation due to a metric that exceeded a threshold.

This notification is automatically resolved when the DC Sensor Watchdog resumes the policy calculation.

The watchdog for {DC sensor name} has triggered traffic stop due to metric {metric name}

The DC Sensor Watchdog stopped the DC Sensor from collecting and analyzing traffic due to a metric that exceeded a threshold.

This notification is automatically resolved when the DC Sensor Watchdog resumes the traffic digestion.

The watchdog for {DC sensor name} has triggered restart of CS Protocol Analyzer service due to metric {metric name}

The DC Sensor Watchdog restarted the analyzer service due to a metric that exceeded a threshold.

The watchdog for {DC sensor name} has triggered restart of CS Management service due to metric {metric name}

The DC Sensor Watchdog restarted the management service due to a metric that exceeded a threshold.

The watchdog for {DC sensor name} has triggered restart of CS Monitoring service due to metric {metric name}

The DC Sensor Watchdog restarted the monitoring service due to a metric that exceeded a threshold.

Domain {domain name} was removed

A domain is no longer covered by Identity Protection. Sensors were uninstalled or no sensors communicated with Falcon for a week.

Appliance {DC sensor name} connectivity check failed

A sensor has not communicated with the Falcon cloud for a while.

Domain Controller {DC name} is not monitored

A domain controller in your domain is not sending data.

This might cause loss of data of user activities and might disrupt detection and enforcement of traffic.

Domain and connector monitoring

We recommend that you configure the IDP Domain and Connector Monitoring Falcon Foundry application, along with Fusion SOAR workflows, to proactively alert you to connector and domain issues. You can set up the configuration to gain the following benefits:
  • Automated notifications: Send email alerts for unresolved issues
  • Customizable monitoring: Filter by notification type (connector, domain coverage, or both)
  • Flexible scheduling: Run checks hourly or at preferred intervals
  • Comprehensive coverage: Monitor both system notifications and domain controller health
Configuration process
Step 1. Install the Foundry app
  1. Go to Foundry > Foundry > Templates and search for IDP.
  2. Next to the Falcon IdP Domain and Connector Monitoring app, click Deploy.
  3. In the Deploy as a new app dialog, click Deploy again.
    Note: The deployment may take a few minutes.
  4. On the App overview page, click Release.
  5. In the Commit release dialog, set the Change type to Major.
  6. Optional. In the Release notes field, add any notes that you want to be attached to this app release.
  7. Click Release.
  8. After you see the Deployment released successfully notification, click View in app catalog.
  9. On the Falcon IdP Domain and Connector Monitoring app page, click Install now, and then click Save and install.
Step 2. Configure the Fusion SOAR workflow

For more info about Fusion SOAR workflows, see Fusion SOAR.

  1. Go to Next-Gen SIEM > Fusion SOAR > Workflows and click Create workflow.
  2. Select Create workflow from scratch, and then click Next.
  3. In Add trigger, select Scheduled workflow.
  4. Select the time interval that you want for the workflow and click Next.
  5. In the Add next panel or on the workflow canvas, select Action icon.
  6. Search for and select the action Get latest identity system notifications, and then click Next.
    1. In Notification categories, add Domain Controller coverage notifications and Connector notifications.
    2. In duration, select your desired search window.
    3. In Opened notifications, select true if you want unresolved notifications included in the search results, or select false if you only want resolved notifications.
    4. Click Next.
  7. In the Add next panel or on the workflow canvas, select Loop icon.
    1. In Loop type, select For each.
    2. In Loop source, select Events.
    3. Click Next.
  8. In the Add next panel or on the workflow canvas, select Action icon.
  9. Search for and select the action Send email, and then click Next.
    1. In Subject and Message, enter the text that you want to be included in the notification email sent by Falcon.
      Tip: You can also use Insert workflow variable to add workflow variables to your email subject line or body, such as event type or CID.
    2. In Recipients, select the desired recipients of the notification emails.
    3. In Data to include, select the desired data that you want to be included in the email.
    4. Click Next.
    Tip: At this point, this workflow will check for new system notifications every hour and send the recipients an email with your specified email content.
  10. If you also want the workflow to notify you about the status of your domain controllers, hover over the trigger, click down arrow, and select Parallel Action icon.
  11. Search for and select the action Get domain controller sensors details, and then click Next.
    1. In Status, add the domain controller statuses that you want to be aware of, for example, Inactive and Limited functionality.
    2. Click Next.
  12. Repeat steps 7, 8, and 9 to create an email notification for the domain controller status.
  13. Click Save and exit.
    1. Enter a name for the workflow.
    2. Optional. Enter a description for the workflow.
    3. Set Status to On.
  14. Click Save and exit.
IDP system notifications Fusion SOAR workflow

Investigation

Identity Protection Threat Hunter

Proactively search through raw events, detect and identify security events, and investigate security events reported by Falcon.

Identity Protection Threat Hunter

Threat Hunter enables security analysts to proactively search through raw events, detect and identify security events, or further investigate security events reported by the system.

You can create your own search criteria, which you can save for use at a later stage, or you can use a predefined search. You can also modify a predefined search and save it for later use.

To display Threat Hunter, go to Identity protection > Explore > Threat Hunter.

Threat Hunter enables you to define search criteria for events that you want to view using tag-based selection. As you select a tag, other tag options become available. This process continues until no other tags are available in that particular category.

You can select your own search criteria from the following categorical groupings:

Event Types

  • Authentication

  • Service

  • User Account Events

  • Alerts

General

  • Sort Order

  • Time Zone

  • Related to

  • Data Source

Identity

  • Username

  • Group

  • Department

  • OU

  • Azure

  • Types

  • Attributes

  • Privileges

  • Risk Severity

Source endpoint

  • Endpoint Name

  • Group

  • OU

  • Site

  • Geo

  • Attributes

  • Endpoint Classification

  • IP Reputation

  • CIDR/IP

  • Network Type

  • Network Label

  • Risk Severity

Destination

  • Destination Name

  • Group

  • Department

  • OU

  • Type

  • Attributes

  • Privileges

  • Endpoint Classification

  • Risk Severity

By default, search queries return data for the past 24 hours. Beneath the major categories, you can choose a window of time for the data you want to see. Threat hunter comes with preset time values and the ability to define your own by selecting custom.

The major categories are linked using the AND operator. This means that if you select search criteria from more than one category, the results must match those in all selected categories.

A Saved Searches list is next to the time configuration. You can select one of the following predefined searches from this list for easy access to common queries and use cases.

  • Administrative Account Lockouts

  • Privileged Escalations

  • Last Day Failed Authentications

  • Last Day Watched Users Activity

  • Last Day Marked Users Activity

  • Traffic based events with NTLMv1 version

  • Remote Desktop to Domain Controllers

  • Interactive logins for Service Accounts

  • Unencrypted LDAP

To save your search criteria as a custom search, open the Options menu and click Save as custom search.

To clear the selections on the page, click Reset.

After selecting your search criteria, click Hunt to view a list of the events according to your selection.

The date and time that appear in the Date & Time column depend on what you selected in the Time Zone field of the General search settings:

  • Use Browser's Time Zone: The default option. The time zone is retrieved from the browser settings.

  • UTC: Coordinated Universal Time, which is the 24-hour time standard commonly used across the world.

  • Use System Time Zone: The time zone configured in Identity protection > Configure > Settings.

The Destination column shows the event's endpoint. In rare cases, it might show a user account that performs Kerberos authentications on behalf of other services. For example, an exchange service and/or web service can authenticate in front of a service that extends the authentication to the final destination.

  • To export the list of events to CSV, open the Options menu and click Export to CSV.

  • To view additional details about an event, click the event.

  • To view events related to the selected event, click the Show Related Events icon.

Saving custom reports

To save the report as a custom report, open the Options menu, click Save as Custom Report, and fill out the New Custom Report fields.

The report is saved with your selections and added to the Saved Reports list on the Reports page.

Identity Protection Configuration

Identity Protection Administration

Configure MFA, IDaas, Appliances, Domains, Subnets, Settings, and Risk Configurations.

Overview

You can configure these aspects of your Identity Protection environment:

  • MFA connectors: Configure integrations for multi-factor authentication (MFA).

  • IDaaS connectors: Configure integrations for Identity as a Service (IDaaS).

  • OIDC integrations: Configure integrations for OpenID Connect (OIDC).

  • Domain Controller hosts View the traffic inspection status of each DC host.

  • Domains: View the domains monitored by Identity Protection.

  • Subnets: Configure subnets for use in Identity Protection.

  • Settings: Configure miscellaneous parameters.

  • Risk Configuration: View and configure Compromised Password Detection for your network.

Domains

The Domains tab shows the domains in your environment. Go to Identity protection > Configure > Domains.

Domains appear in the tab when the Falcon sensor is installed on at least one DC in the domain.
Tip: If the Falcon sensor is only installed on a read-only DC in the domain, the domain will not be listed in the Domains tab.

Domains that are not being monitored by Identity Protection are identified by a gray Disabled status icon. For more info about enabling Identity Protection on a domain, see Domain management.

When first adding a sensor on a DC from a domain, the relevant row in the domains table displays an orange status icon, which indicates that Identity Protection is initializing the new domain, and is populating the system with entities from it, such as the users and endpoints.View the status of your domains under Administration > Domains.

When initialization completes, the status icon turns green.

If the status icon turns red, there might be an issue communicating with the sensor. For more information, see Domain controller monitoring status.

Domain management

Identity Protection can be enabled on new domains with the Automatically enable Identity Protection on a new domain toggle. If the toggle is disabled, new domains will be added in a disabled status. To manually enable a domain, hover over it and click Enable.

Domain controller monitoring status

On the Domain tab, quickly see how many domain controllers are configured in a domain and how many of them are monitored by Falcon Identity Protection. This ratio is shown in the DC Monitoring column of the Domains table.

To check DC monitoring status:

  1. Select a domain from the list of configured domains.

  2. Click the umbrella icon in the DC Monitoring column to open the [domain name] Monitoring side panel.

Identity Protection updates the monitoring status every 5 minutes. A domain controller is considered as monitored if the sensor is installed and communicating, Authentication traffic inspection is enabled, and a successful health check message is received from it within one hour of each status update. For more info, see Enabling Identity Protection configuration policies.

Sensors usually send messages every minute, however a newly provisioned sensor might not send a message in the first 15 minutes.

The [domain name] Monitoring panel contains the following tabs:

  • Monitored: Lists the domain controllers whose network traffic is monitored by Identity Protection traffic inspection.

  • Not Monitored: Lists the domain controllers whose network traffic is not monitored by Identity Protection traffic inspection. This tab appears only when such domain controllers exist.

  • All: Shows all domain controllers configured in the respective domain.

Domain controllers activity graph

The graph in the Domain Controllers Activity area shows the activity of the domain controllers in the defined domain, plotting time on the X-axis and service requests on the Y-axis.

Filter the information displayed by DC name, Domain, Protocol, or Sites.

The Transaction by list lets you further filter the graph by selecting the transactions you want displayed in a time frame of up to one week. You can select from DC, Domain, or Site.

Domain Controller hosts

The Domain Controller hosts tab contains a table of the DC hosts.

The following columns are displayed for each DC host by default:

  • Hostname

  • Status

  • Status details

  • Domain

  • Sensor version

  • Traffic inspection: Enabled or Disabled

  • Kerberos
  • NTLM

  • Identity configuration policy: Click the policy name to open the policy page in a new tab

The following columns are available but are not displayed by default:
  • OS version
  • Local IP
  • RDP to DC
  • LDAP
  • LDAPS
  • SMB to DC

To edit the columns that are displayed on your Domain controller hosts page, click the Configure table columns button , then select or deselect the columns as needed.

To view a DC host in Host Management, click the vertical ellipsis icon next to the desired DC host.

Subnets

Configure subnets for usage in Identity Protection. These can be used as a condition in policy rules. You can configure a single subnet or a range of subnets as well as their types. For example, you can use this feature to apply more restrictive actions to an activity originating from a Guest WiFi network

Add a subnet

  1. In the CIDR/IP field, enter the subnet’s IP address or range of IP addresses in CIDR format.

    Note: Be sure to enter the IPs internal to your DCs. For example, for a NAT subnet, enter the internal NAT IP.

  2. From the Type list, select the network type of the subnet:

    • NAT: Indicates that the subnet uses network address translation (NAT). Identity Protection does not perform hostname resolution on endpoints in a NAT subnet. Also, those endpoints will not trigger suspicious ticket reuse or unusual use of endpoint alerts. For more info, see Identity-based Incidents, Detections, and Risks.

    • Wifi: Indicates that the subnet is wifi-based. Label your endpoints that use a wifi network, and filter by the network type in Threat Hunter.

    • Internal: Indicates that the subnet is internal. Label your endpoints that use an internal network, and filter by the network type in Threat Hunter.

    • VPN: Indicates that the subnet makes use of a VPN. Label your endpoints that use a VPN connection, and filter by the network type in Threat Hunter.

  3. In Label, enter a descriptive name for the subnet.

  4. Click Add Subnet.

Check distribution of subnet configuration

You can see details of which of your sensors have been updated with the changes you make to subnets, and when.

To view the details of policy rule distribution:

  1. Go to Identity protection > Configuration > Subnets.

  2. In Subnet Distribution, click View distribution status.

  3. In the DC servers panel you can:

    1. Sort a column by clicking the heading.

    2. View details of a domain controller by clicking its name.

    3. Export the results to a comma-separated file by clicking CSV.

    4. View the exact time a domain controller was updated by hovering over the Date Applied value.

MFA connectors

MFA (multi-factor authentication) adds a second layer of security to access requests of on-premises apps, endpoints, or other applications by using a second factor – such as a smartphone, tablet, or smartwatch – to verify the user’s identity through additional mechanisms.

When Identity Protection detects abnormal or risky user behavior based on policy rules, it can automatically apply a security control to challenge the user to provide a second factor. The user engaged in the process can approve, deny, or ignore the request. Unless the end user approves the challenge, an incident will be created and escalated as needed. An audit log is written for every policy match, regardless of whether the end user response is successful or not.

Identity Protection allows integration with external MFA providers to enable sending MFA to the end user. Each vendor supports different authentication factors: push using a mobile app, OTP (one-time password) using a mobile app or hardware token, phone call, SMS, and more.
Note: You might need to add the IP addresses that Falcon uses to make external connections to your third-party service allowlists. See Appendix A: IP addresses used to contact third-party services.

To enable sending MFA requests to end users, configure an integration with the external MFA provider in Identity protection > Configure > Connectors, and enroll users according to the MFA vendor’s specifications. When a new user is enrolled, enabled or disabled, or if a device is changed, the change is registered within 5 minutes.

Additionally, a policy rule must be configured to trigger the request.

Set up the Falcon Identity Verification Dialog

If an end user is enrolled in multiple MFA providers, Identity Protection allows the admin to defer the selection of the provider and factor to the end user, by choosing Any in the connector settings of their policy rules.

The user is presented with the available options by the Falcon Identity Verification Dialog, which is executed on the machine that initiated the authentication, referred to as the source endpoint.

Falcon Identity Verification Dialog requirements

These are the minimum requirements for showing the Falcon Identity Verification Dialog on the end user machine. This is relevant for the Access trigger only:

  • Internet Explorer 9

  • .NET 3.5

  • Any supported Windows OS

  • Windows Server 2008

    Note: If the end user machine is using Windows 7, then .NET 3.5 is sufficient. For Windows 8 and later, .NET 4.6.2 or later is required.
For FIDO2 support, these are the minimum requirements:
  • Falcon sensor for Windows version 7.20 or later
  • Cloud MFA (protocol-based) connector
  • Microsoft Edge or WebView2 Runtime
  • .NET 4.6.2
  • Windows 10 or later
  • Windows server 2022 or later
    Note: FIDO2 is not supported in login scenarios or when the FIDO2 token is not connected to the computer where the dialog is displayed.

To enable the Falcon Identity Verification Dialog for the end user, ensure the following:

  • A Falcon Sensor must be installed on the end user’s computer.

    For more info, see Falcon Sensor for Windows Deployment.

  • Your sensors must be able to perform reverse DNS lookups to your source endpoints so they can be correctly identified during MFA.

  • You must configure your response policies to enable Real Time Response put and run commands on your hosts. For more info, see Real Time Response.
    Note: The Falcon Identity Verification Dialog is executed on endpoints under a built-in, limited access service account named [email protected]. This account appears in Investigate > Search > Advanced event search , in events relating to the use of the Verification Dialog, such as Event_AuthActivityAuditEvent.

  • The endpoint on which the Falcon Identity Verification Dialog appears must be part of a domain monitored by Falcon Identity Protection.

  • The endpoint on which the Falcon Identity Verification Dialog appears needs outbound network access on HTTP port 443 to the CrowdStrike API endpoint for that cloud:

    • US-1: https://api.crowdstrike.com

    • US-2: https://api.us-2.crowdstrike.com

    • EU-1: https://api.eu-1.crowdstrike.com

    • US-GOV-1: https://api.laggar.gcw.crowdstrike.com

    • US-GOV-2: https://api.us-gov-2.crowdstrike.mil

Instant messaging providers
Identity Protection can integrate directly with the following instant messaging providers. All authentication methods are supported.
Microsoft Teams

You can configure Identity Protection to integrate directly with Microsoft Teams.

Integration process

Step 1. Confirm an existing, configured Entra IDaaS connector

The Teams integration requires an existing, configured Entra IDaaS connector. For more info, see Microsoft Entra ID (entity and activity ingestion).

Step 2. Configure the Microsoft Teams SOAR Actions plugin in the CrowdStrike Store

You need to configure a new Microsoft Teams SOAR Actions plugin in the CrowdStrike Store. For more info about how to configure the plugin, see Microsoft Teams SOAR Actions.

Note: You must include an Identity Protection tag in the plugin configuration.
Teams MFA Identity tag

Step 3. Confirm the Identity Protection Microsoft Teams connector

  1. Go to Identity protection > Configure > Connectors .
  2. In the Instant messaging integrations section, confirm that the Microsoft Teams plugin you just configured is displayed with a green circle. For more info, see Microsoft Teams SOAR Actions.
After the connector is added and configured, you can create policy rules that use Microsoft Teams. For more info about setting up a policy, see Verify identity by using MFA.
Note: Your Microsoft Teams MFA policy must use the Access trigger.
Slack

You can configure Identity Protection to integrate directly with Slack.

Note: To support MFA when logging in, the end user must have an email address in your system and have Slack configured on a second device, such as a mobile phone.

Integration process

Step 1. Configure the Slack v2 SOAR plugin in the CrowdStrike Store

You need to configure a new Slack v2 SOAR plugin in the CrowdStrike Store. For more info about how to configure the plugin, see Slack v2 SOAR.

Important: You must set the Use Case field in the store configuration to Identity Protection.

Step 2. Confirm the Identity Protection Slack connector

  1. Go to Identity protection > Configure > Connectors .
  2. In the Instant messaging integrations section, confirm that the Slack plugin you just configured is displayed with a green circle. For more info, see Slack v2 SOAR.

After the connector is added and configured, you can create policy rules that use Slack. For more info about setting up a policy, see Verify identity by using MFA.

Note: Your Slack MFA policy must use the Access trigger.
Cloud-based MFA providers

Identity Protection can integrate directly with a number of cloud-based MFA providers.

Supported cloud-based MFA data connectors

The following table lists the supported MFA data connectors and the authentication methods each of them supports.

Note: Select OTP (One-Time Password) when working with either hardware or software tokens.
Name Supported Authentication Methods

Microsoft Entra MFA

See Microsoft Entra MFA (including Legacy Microsoft Entra MFA)

Identity Protection supports these Entra Cloud MFA factors:

  • Mobile authenticator app (OTP, Push with number matching)
  • SMS messages
  • Phone call
Note: Allows you to choose your factor.
Note: Push with number matching requires the Put and Run options to be enabled within your RTR Response policy.

Legacy Microsoft Entra MFA

See Microsoft Entra MFA (including Legacy Microsoft Entra MFA)

Identity Protection supports these Entra Cloud MFA factors:

  • Mobile authenticator app (OTP, Push)
  • SMS messages
  • Phone call
Note: Relies on the Entra MFA default factor configuration.

CyberArk Identity

Mobile authenticator app (OTP, Push), OATH OTP, phone call, text message (SMS)

Duo

Push, Token, Callback, Hardware Token, SMS Passcode

If you are using DUO MFA with more than one enrolled device, you can choose which of the devices to use for identity verification.

Only the supported verification types will be shown for each device.

Entrust

Entrust Soft Token, Grid Card, One-time Password (Voice and SMS), Software/Hardware Token

ForgeRock

OTP, Push

TOTP-compatible authentication application

Token

RSA Cloud Authentication Service (CAS)

Approve, Authenticate Tokencode, Device Biometrics, Emergency Tokencode, SecureId

Okta Verify

Push, Token, Hardware Token, Callback, Text message (SMS)

If you are using Okta Verify MFA with more than one enrolled device, you can choose which of the devices to use for identity verification.

Only the supported verification types will be shown for each device

OneLogin

OneLogin Protect mobile app, Text message (SMS), Phone call

Symantec

Push, Token

PingID

SMS Passcode, Callback

The mobile application supports Push and Token
Cloud MFA (protocol based) Supported authentication methods depend on third-party provider
Note: If the Falcon Identity Verification Dialog is not available and you choose Any vendor, the system selects the suitable vendor automatically, without user interaction. It is recommended to include at least one MFA method that doesn’t require displaying an on-screen notification (for example, Push). This prevents fallback to fail-mode for impersonator-originated network messages, or where screen notification is disabled.
Microsoft Entra MFA (including Legacy Microsoft Entra MFA)

You can configure Identity Protection to integrate directly with Entra Cloud MFA. If you do not want to connect directly and instead use the NPS extension, see Integrate Cloud Microsoft Entra MFA using NPS extension.

Identity Protection supports these Entra Cloud MFA factors:

  • Mobile authenticator app (OTP, Push with number matching)

  • SMS messages

  • Phone call

Note: Push with number matching requires the Put and Run options to be enabled within your RTR Response policy.

Legacy Identity Protection supports these Entra Cloud MFA factors:

  • Mobile authenticator app (OTP, Push)

  • SMS messages

  • Phone call

Integration process

Step 1. Obtain the tenant domain and assign a secret to the Entra Multi-Factor auth client

You need to obtain the tenant domain from Entra, and also assign a client secret to the Entra Multi-Factor Auth client so that you can integrate it with Identity Protection.

CrowdStrike provides a PowerShell script that displays your tenant domain and assigns a new client secret to the appropriate service principal in Entra. The secret is valid for 2 years.
Note: If necessary, the PowerShell script can be adapted to reduce the client secret validity time period.

Prerequisites

  • The machine on which you run the script must have internet connectivity. The script will ensure you are using a strong cipher for making network connections.

  • You must run Powershell as an administrator to successfully run the script. The script will warn you if you are not running it as an administrator.

  • You will need to enter at least Entra ID Global Administrator credentials when the script connects to Entra ID. You may also need to complete an MFA challenge to authenticate to Entra ID.

Use the Powershell script

  1. In the Falcon console, go to Support and resources > Tool downloads , and download the latest version of the Entra MFA Credential Assignment Script ZIP file.

  2. Extract the Powershell script from the ZIP archive.

  3. On a machine with access to the Entra cloud servers, open Powershell as an administrator, and then set the execution policy to allow the script to run as required:

    Set-ExecutionPolicy Unrestricted

  4. Run the script:

    .\EntraMFACredentialAssignmentScript.ps1
    Note: To run the script, you must have PowerShell v7 or later.

  5. When prompted, enter your Entra ID global administrator credentials.

  6. If requested, complete the MFA challenge.

  7. A successful operation produces this output:

    Tenant Domain              Client Secret
-------------              -------------
example.onmicrosoft.com    4NlmJRM8mahkULIWpWYCAs49SMgyiMx=

    If the script is not successful, check the cs_script_output.txt file for errors. The file is created in the directory from which you executed the script.

  8. Make a note of the tenant domain and the generated client secret. You will use these values in the Tenant Domain and Client Secret fields in the next step.

Step 2. Configure the Entra MFA connector in the Falcon console

  1. In the Falcon console, go to Identity Protection > Configure > Connectors .

  2. From the Select connector menu, in the Cloud MFA category, select Microsoft Entra and then click Add.

  3. In the connector settings, specify the required values:

    • Tenant Domain. Such as example.onmicrosoft.com

    • Client Secret. Such as 4NlmJRM8mahkULIWpWYCAs49SMgyiMx=

  4. In User Identifier, select the attribute that contains the value the MFA provider requires to uniquely identify a user.

    For example, you might have your MFA provider configured to require Entra principal name (Entra UPN). We recommend that you keep the Default setting.

    Note: The possible choices for Entra MFA User Identifier are UPN, Entra UPN, and Email. If you select Entra UPN, an active Entra IDaaS configuration is required.

  5. Click Save.

    The indicator turns green within a minute, indicating that the connection was successfully established.

  6. If you need multiple Entra MFA connectors, repeat Step 2 through Step 5.

    Note: If you have Entra ID IDaaS, you may want to mirror its tenant domain configuration when setting up multiple Entra MFA connectors.
    Note: When configuring an additional connector, set Scope to Per domain or Per Tenant, and enter all Domains or Entra Tenants that the additional connector should cover. All other User Identifiers are covered by the original connector that was configured with Scope set to Default.

After the connector is added and configured, you can create policy rules that use Entra MFA. For more info, see Identity Protection Policy.

CyberArk Identity

The CyberArk Identity Platform provides a range of authentication methods that add a second layer of security to access requests.

Using CyberArk MFA, you can get the protection you need without sacrificing the convenience your users demand. CyberArk MFA makes two-factor authentication easy for both administrators and users.

Prerequisites

Before starting the integration, make sure that the following prerequisites are met:

Integration process

Step 1. Get your Tenant URL and Tenant ID values from CyberArk Identity

  1. Log in to the CyberArk Identity Admin Portal as an administrative user.

  2. Go to Settings > Customization > Tenant URLs, and make a note of your Tenant URL value. For example, abc1234.my.idaptive.app.

  3. Click your username and from the dropdown menu, select About. Make a note of your Tenant ID value. For example abc1234.

    Note: This value is often the same as the first part of your tenant URL.

Step 2. Create an authentication profile in CyberArk Identity

As described by Create authentication profiles in the CyberArk Identity documentation, create an authentication profile that enables the MFA factors supported by Identity Protection.
Important: If you want to configure your authentication profile with multiple MFA factors, you must select all of your desired MFA factor types in the Challenge 1 section. Do not select any MFA factor types in the Challenge 2 section.

Make a note of the name of your authentication profile, for example CrowdStrikeIdentityProtectionPolicy. You will use this value in the CyberArk Policy property when configuring the connector.

The CyberArk Identity connector supports the following factors:

  • Mobile Authenticator

  • Phone call

  • OATH OTP Client

  • Text message (SMS) confirmation code

Note: Identity Protection ignores any factors it does not support, such as QR Code.

Step 3. Create an authentication policy in CyberArk Identity

As described by Create authentication rules in the CyberArk Identity documentation, create an authentication policy that defines the criteria for applying the MFA profile you created earlier.

When creating the authentication policy:

  • We recommend that you specify the authentication profile you created in the previous step as the default profile that is used if no custom conditions match.

  • In Third Party Integration, click Add Challenge Policy.

  • Save the third-party integration policy name to use later in the CyberArk Policy property in Step 5. Configure the CyberArk Identity connector in the Falcon console.
    Note: Be sure to save the third-party integration policy name listed in the Third Party Integration section. This value is different from the authentication profile name displayed in the Default profile field.

Step 4. Create an OAuth 2.0 client and service account in CyberArk Identity

As described by Client Credentials Flow in the CyberArk Identity documentation, create a confidential OAuth 2.0 client web app, and the service account credentials that Identity Protection can use to connect to it.

When creating the client:

  • Make a note of your Application ID value, for example CrowdStrikeIdentityProtectionApp. You will use this value in the CyberArk Application ID property when configuring the connector.

  • Set the Client ID Type to Confidential.

  • Select Must be OAuth Client.

  • When configuring tokens:

    • Set Auth Methods to Client Creds.

    • Ensure Token Lifetime is at least 5 minutes.

  • When configuring scope definitions:

    • Make a note of the Name of your scope definition, for example CrowdStrikeIdentityProtectionScope. You will use this value in the CyberArk Application Scope property when configuring the connector.

    • In Allowed REST APIs, add these values:

      • Security/OnDemandChallenge

      • Security/AdvanceAuthentication

  • When configuring permissions:

    • Add the System Administrator role, and assign these permissions:

      • Identity verification

      • User Management

  • When creating a service account to access the confidential client:

    • Make a note of the Login Name and Suffix values; you will use these values, with an @ symbol in between, in the Client ID property when configuring the connector.

      For example, [email protected].

    • Make a note of the Password value; you will use this value in the Client Secret property when configuring the connector.

    • In the Status section, select Is Service User and Is OAuth confidential client.

    • After creating the service account, add it as a member of the System Administrator role (Core Services > Roles > System Administrator > Members).

Step 5. Configure the CyberArk Identity connector in the Falcon console

  1. In the Falcon console, go to Identity protection > Configure > Connectors .

  2. In the Select connector list, select CyberArk Identity and click Add.

  3. Enter the values you obtained from CyberArk Identity into the following fields:

    • Tenant URL

    • Tenant ID

    • CyberArk Application ID

    • CyberArk Application Scope

    • CyberArk Policy

    • Client ID

    • Client secret

  4. Optionally, in User Identifier, select the attribute that contains the value the MFA provider requires to uniquely identify a user.

    For example, you might have your MFA provider configured to require the email address or principal name.

    We recommend that you keep the Default setting.

  5. Click Save when done.

    The indicator turns green within a minute, indicating the connection was successfully established.

  6. If the indicator does not turn green:

    • Refresh the page.

    • Verify that the hostname is accessible.

    • Verify that all the parameters are entered correctly. If not, re-enter the parameter and click Save.

  7. If you need multiple CyberArk Identity MFA connectors, repeat Step 2 through Step 6.

    Note: When configuring an additional connector, set Scope to Per domain, and enter all Domains that the additional connector should cover. All other Domains are covered by the original connector that was configured with Scope set to Default.

  8. Test the connection by creating an identity verification policy rule for a CyberArk Identity MFA-enrolled user. Make sure to select one of the CyberArk Identity options in the Connector list.

    When attempting to log in to a workstation that is not associated with them, the user should receive an on-screen notification to perform MFA.

    For more information, see Identity Protection Policy.

Duo

Duo Security provides an easy-to-use, secure mobile authentication app, named Duo Mobile, for quick, push notification-based approval to verify your user’s identity.

Users’ Enrollment Duo Security MFA is a cloud service. User enrollment is done by the administrator of the system in a simple, one-time operation.

Prerequisites

Before starting the integration, make sure that the following prerequisites are met:

  • You have a Duo administrator account. If you do not already have one, follow the Getting Started with Duo instructions.

  • Your Active Directory users are synchronized with Duo. If they are not synchronized, proceed as described in the Duo article Synchronizing Users from Active Directory.

  • The relevant users - and their phones, tablets, or hardware tokens - are enrolled in Duo. If you need to enroll them, follow the Duo instructions for Enrolling Users.

  • For new users, the default option in New User Policy must be Require enrollment.

Integration process

  1. Create a new protected application by following the Duo instructions for Protecting Applications. From the list of services that can be protected with Duo (step 2), choose Auth API.

    Note: The policy for unknown users must be defined as Enrolled.

  2. In the Falcon console, go to Identity protection > Configure > Connectors .

  3. In the Select connector list, select DUO connector and click Add.

  4. Copy the following information from DUO: integration key, secret key, API hostname.

  5. Click Save when done.

    The indicator turns green within a minute, indicating the connection was successfully established.

  6. If the indicator does not turn green:

    • Refresh the page

    • Verify that the hostname is accessible

    • Verify that all the parameters are entered correctly. If not, re-enter the parameter and click Save.

  7. If you need multiple Duo MFA connectors, repeat Step 3 through Step 6.

    Note: When configuring an additional connector, set Scope to Per domain, and enter all Domains that the additional connector should cover. All other Domains are covered by the original connector that was configured with Scope set to Default.

  8. Test the DUO connection by creating an identity verification policy rule for a DUO-enrolled user. Make sure to select DUO in the Data Connector list. When attempting to log in to a workstation that is not associated with them, the user must receive an on-screen notification. For more information, see Identity Protection Policy.

Entrust

You can configure Identity Protection to integrate directly with Entrust MFA.

Identity Protection supports these Entrust MFA factors:

  • Entrust Soft Token

  • One-time Password (Voice and SMS)

  • Software/Hardware Token

Integration process

Step 1. Create an Authentication API application in Entrust IDaaS

As described in the Entrust documentation, create an authentication API application that enables the MFA factors supported by Identity Protection. Go to Create an Authentication API application in IDaaS.

Make note of the Application ID, which you will need to initialize the Authentication API.

Step 2. Add a resource rule to your Authentication API application in Entrust IDaaS

  1. On the Complete tab, click Add Resource Rule.

  2. On the Add Resource Rules page and the General Settings tab, click Next.

    Note: Do not select a Group to add.

  3. On the Authentications Conditions tab, configure your resource rule:

    1. Set First Factor to Skip Password.

    2. To allow using these factors in the integration, for Second Factor, select:

      • Entrust Soft Token Push

      • Grid Card

      • One Time Password

      • Software/Hardware Token

  4. Click Submit.


    Second Authentication Factors

Step 3. Note user details in Entrust IDaaS

  1. Go to Members > Users > Select a user. Open the details of a user and note the User Identifier:

    • Email

    • SAM account name

    • SAM account name and domain

    • User principal name


      Personal information

Step 4. Configure the Entrust MFA connector in the Falcon console

  1. In the Falcon console, go to Identity Protection > Configure > Connectors .

  2. From the Select connector menu, in the Cloud MFA category, select Entrust and then click Add.

  3. In Hostname, enter your Entrust account URL.

  4. In Application ID, enter the Application ID you copied from the IDaaS Admin portal.

  5. In User Identifier, select the User Identifier that you noted in Step 3.


    User identifier

  6. Click Save.

  7. If you need multiple Entrust MFA connectors, repeat Step 2 through Step 6.

    Note: When configuring an additional connector, set Scope to Per domain, and enter all Domains that the additional connector should cover. All other Domains are covered by the original connector that was configured with Scope set to Default.

You can now configure rules using the Identity Protection policy and apply MFA using Entrust to the end users.

ForgeRock

You can configure Identity Protection to integrate directly with ForgeRock MFA.

Identity Protection supports these ForgeRock MFA factors:

  • OTP (one-time password)

  • Push

Prerequisites

Before starting the integration, make sure that the following prerequisites are met:

  • You have a ForgeRock administrator account.

  • AD users must be synchronized to both ForgeRock and Falcon Identity Protection.

  • Users must be registered to either push or OTP factors in ForgeRock.

Integration process

To integrate Identity Protection with ForgeRock MFA, follow these steps:

  1. Configure the ForgeRock journey

  2. Configure the ForgeRock MFA connector in the Falcon console

Step 1. Configure the ForgeRock journey

  1. In the ForgeRock tenant, import the example journey. For an example journey, see Appendix B.


    ForgeRock journey

  2. Edit the journey details:

    • Rename the journey, if required.

    • Make sure the Identity Object is set to all users in your realm.

Step 2. Configure the ForgeRock MFA connector in the Falcon console

  1. In the Falcon console, go to Identity Protection > Configure > Connectors .

  2. Add a new Forgerock connector with the following parameters:

    • Access Management URL: the URL to the ForgeRock tenant. Such as https://openam-mytenant.forgeblocks.com/am

    • Access Management Realm: the intended ForgeRock realm. Such as /realms/root/realms/alpha

    • Journey: the journey name configured in Step 1

    • Scope: keep as Default. This field should be used if setting up multiple ForgeRock connectors by mapping the users to different tenants by domain

  3. Click Save to save the connector.

TOTP-compatible authentication application

TOTP-compatible authentication applications implement two-step verification services using the Time-based One-time Password Algorithm (TOTP). Typically, a user installs the TOTP-compatible authentication application on a smartphone. To log in to a service that uses two-factor authentication, the user provides username and password to the service and runs the authentication app. In this scenario, the authentication process is controlled by Identity Protection. The mobile app displays a six-digit one-time password and the user is asked what that password is. The user enters it, thus authenticating the user's identity.

With this kind of two-factor authentication, mere knowledge of username and password is not sufficient to break into a user's account. The attacker also needs knowledge of the shared secret key or physical access to the device running the authentication app.

Prerequisites

  • To be enrolled, a user must have the TOTP-compatible authentication application installed on their device.

Integration process

  1. In the Falcon console, go to Identity protection > Configure > Connectors .

  2. In the Select connector list, select TOTP Authenticator and click Add.

    The data connector is now added and enabled.

  3. Click Enroll Users and select the users you want to enroll in the service.

    An enrollment request event is logged in the timeline of every user that was on the list.

  4. In the Select a user field, specify the user you want to enroll.

  5. Click Send Enrollment Request.

    End users receive an email with a QR code.

  6. Scan the QR code with the TOTP Authenticator application.

    This secret key will be used for all future logins.

  7. Test the TOTP Authenticator connection by creating an identity verification policy rule for an enrolled user. Make sure to select TOTP Authenticator in the Data Connector list.

    When attempting to log in to a workstation that is not associated with them, the user must receive an on-screen notification. For more info, see Identity Protection Policy.

As soon as the end user enters a code, the OK button is enabled. The code is then verified and the user is granted access. If the user verification code is valid, Identity Protection logs the transaction and does not create an Incident, eliminating the need for a security analyst to examine the incident. If the end user fails to enter the correct code or close the dialog, it is logged as an incident, the severity is raised based on the number of occurrences, and it is escalated appropriately.

RSA Cloud Authentication Service (CAS)

RSA CAS helps accelerate business while mitigating identity risk. With multi-factor authentication, access management, identity governance and user lifecycle solutions, it helps to strengthen security, ensure compliance and facilitate business growth.

Prerequisites

Before starting the integration, make sure that the following prerequisites are met:

  • You have an RSA CAS Admin account

  • Generate an Authentication API Key in RSA CAS:

    1. Log in to RSA CAS.

    2. Go to My Account > Company Settings > Authentication API Keys.

    3. Add a new Authentication API Key.

    4. Copy the API key and URL to use when setting up the connector.

  • If the integration will use assurance levels, validate that they are defined correctly in RSA CAS.

Integration process

  1. In the Falcon console, go to Identity protection > Configure > Connectors .

  2. In the Select connector list, select RSA CAS and click Add.

  3. Enter the API Key and URL copied from RSA CAS.

  4. Optionally, in User Identifier, select the attribute that contains the value the MFA provider requires to uniquely identify a user.

    For example, you might have your MFA provider configured to require the email address or principal name.

    We recommend that you keep the Default setting.

  5. Click Save.

    The indicator turns green within a minute, indicating the connection was successfully established.

  6. If you need multiple RSA CAS MFA connectors, repeat Step 2 through Step 5.

    Note: When configuring an additional connector, set Scope to Per domain, and enter all Domains that the additional connector should cover. All other Domains are covered by the original connector that was configured with Scope set to Default.

Use RSA CAS assurance levels in Identity Protection Policy

RSA CAS defines assurance levels as lists of authorization factors (MFA methods) which allow an admin to limit an end user to a subset of the authentication factors when accessing a resource. For example, access to one resource requires push or OTP and access to another resource requires both a push and an OTP. RSA CAS has 3 predefined levels (Low, Medium, High) which can be assigned to policy rules in an Identity Protection policy to trigger this behavior.

To assign an assurance level to a policy rule:

  1. Create a policy rule with the requested trigger.

  2. In the actions menu, select RSA CAS (Any).

  3. Select the correct Assurance Level.

  4. Complete the rule with a condition and additional settings.

Okta Verify

By integrating with Okta’s Adaptive Multi-Factor Authentication, Identity Protection can create an MFA challenge based on risk. Depending on the risk, the policy engine can either approve and auto-resolve the security incident or take a different action such as step up or block the user.

Identity Protection supports these Okta Verify MFA factors:

  • Push notifications

  • One-time passwords (OTP), including hardware tokens

  • Phone calls

  • Text messages (SMS)

Prerequisites

Before starting the integration, make sure that the following prerequisites are met:

  • Your company has an Okta Portal and you know its domain URL.

    You will use this domain URL value when configuring the connector. See Integration process.

  • The users are enrolled in Okta MFA.

    For more information, see Multifactor Authentication (MFA) in the Okta developer documentation.

  • You have added the CrowdStrike IP addresses to the Gateway IPs field of the Okta IP Zone. See Create an IP Zone in the Okta Help Center.

    Add the CrowdStrike proxy IP addresses to the Gateway IPs field of the Okta IP Zone so that your users do not see the geolocation of these servers when performing MFA.

    The IP addresses to add depend on the CrowdStrike cloud region you use. See Appendix A: IP addresses used to contact third-party services.

Integration process

To integrate Identity Protection with Okta Verify, follow these steps:

  1. Create a service account and API key in Okta

  2. Configure the Okta Verify connector in the Falcon console

Step 1. Create a service account and API key in Okta

You need to create a service account and API token in your Okta instance that Identity Protection can use to authenticate to Okta APIs.

API keys in Okta inherit the permissions of the account that creates them. Identity Protection requires that the API key has the Helpdesk Admin permission. You must also temporarily give the Read-only Admin permission to the service account so that it can create the API key.

  1. Log in to the Okta console as an administrator.

    For more information, see Administrator roles and permissions in the Okta developer documentation.

  2. Create a service account for use by Identity Protection.

    • In the Password section, select Set by admin, and create a strong password.

    • Add the following permissions to the service account:

      • Helpdesk Admin

      • Read-only Administrator

        Note: This will be removed in a later step. It is only required to allow the creation of an API key.

        For more information, see Add users manually in the Okta developer documentation.

  3. Log in to the Okta console with the new service account.

  4. Create an API token while logged in with the service account.

    Make a note of the API token value. You will use this value when configuring the connector.

    For more information, see Create an API token in the Okta developer documentation.

  5. Log out of the service account and log back in to the Okta console as an administrator.

  6. Remove the Read-only Administrator permission from the service account.

    Okta updates the API key generated earlier to only have the Helpdesk Admin permission that is required by Identity Protection.

Step 2. Configure the Okta Verify connector in the Falcon console

  1. In the Falcon console, go to Identity protection > Configure > Connectors .

  2. In the Select connector field, select Okta Verify, and then click Add.

  3. In the Okta Verify data connector:

    1. In the Domain field, enter the URL of your organization’s Okta portal.

    2. In the Token field, enter the Okta API token that has Helpdesk Admin permission.

    3. Optionally, in User Identifier, select the attribute that contains the value the MFA provider requires to uniquely identify a user.

      For example, you might have your MFA provider configured to require the email address or principal name.

      We recommend that you keep the Default setting.

  4. If you need multiple Okta Verify MFA connectors, repeat Step 2 through Step 3.

    Note: When configuring an additional connector, set Scope to Per domain, and enter all Domains that the additional connector should cover. All other Domains are covered by the original connector that was configured with Scope set to Default.

After the connector is added and configured, you can create policy rules that use Okta Verify for MFA. For more info, see Identity Protection policy.

OneLogin

OneLogin provides a range of authentication methods that add a second layer of security to access requests.

Protect your organization’s mission-critical assets with policy-based OneLogin MFA.

Prerequisites

  • The users are enrolled in OneLogin MFA and you have created a security policy to enable supported MFA factors.

    For more information, see Add Multi-Factor Authentication in the OneLogin knowledge base.

Integration process

To integrate Identity Protection with OneLogin, follow these steps:

  1. Create API credentials in OneLogin

  2. Configure the OneLogin connector in the Falcon console

Step 1. Create API credentials in OneLogin

As described by Creating an API Credential Pair in the OneLogin Developer documentation, create API credentials that Identity Protection can use to connect to OneLogin.

When creating the credentials:

Step 2. Configure the OneLogin connector in the Falcon console

  1. In the Falcon console, go to Identity protection > Configure > Connectors .

  2. In the Select connector field, select OneLogin, and then click Add.

  3. In the OneLogin data connector:

    1. In the Client ID and Client Secret fields, enter the values obtained when creating API credentials in OneLogin.

  4. Optionally, in User Identifier, select the attribute that contains the value the MFA provider requires to uniquely identify a user.

    For example, you might have your MFA provider configured to require the email address or principal name.

    We recommend that you keep the Default setting.

  5. If you need multiple OneLogin MFA connectors, repeat Step 2 through Step 4.

    Note: When configuring an additional connector, set Scope to Per domain, and enter all Domains that the additional connector should cover. All other Domains are covered by the original connector that was configured with Scope set to Default.

After the connector is added and configured, you can create policy rules that use OneLogin for MFA. For more info, see Identity Protection policy.

Symantec

Symantec VIP Intelligent Authentication protects your network and applications against unauthorized access without altering a legitimate user’s authentication experience. Using a combination of device and behavior profiling, VIP Intelligent Authentication delivers multi-factor authentication to users without requiring hardware or software-based authentication credentials, and enables your organization to defeat attacks designed to steal your organization’s confidential information.

Prerequisites

Symantec VIP integration requires loading a certificate that is used to authenticate communication with the Symantec API (cloud service).

For instructions, see the Symantec article Obtaining the VIP certificate.

Ensure these prerequisites:

  • Use PKCS#12 format

  • Take note of the certificate export password

  • Do not change the certificate name

Integration process

  1. In the Falcon console, go to Identity Protection > Configure > Connectors .

  2. In the Select connector list, select Symantec VIP and click Add.

  3. In the connector settings, upload the certificate file downloaded from Symantec VIP and enter the password.

  4. Optionally, in User Identifier, select the attribute that contains the value the MFA provider requires to uniquely identify a user.

    For example, you might have your MFA provider configured to require the email address or principal name.

    We recommend that you keep the Default setting.

  5. Click Save when done.

    The indicator turns green within a minute, indicating the connection was successfully established.

PingID

PingID is a cloud-based authentication solution that enables users to authenticate to applications by using their phone.

Integration process

  1. Log in to admin.pingone.com.

  2. Go to PingID > Client Integration and download Ping identity properties by clicking Download in the Integrate with PingFederate and other clients section.

  3. In the Falcon console, go to Identity Protection > Configure > Connectors .

  4. In the Select connector list, select MFA > PingID and click Add.

  5. Click pingid properties file and browse for the previously downloaded Ping identity properties file.

  6. Optionally, in User Identifier, select the attribute that contains the value the MFA provider requires to uniquely identify a user.

    For example, you might have your MFA provider configured to require the email address or principal name.

    We recommend that you keep the Default setting.

  7. If you need multiple PingID MFA connectors, repeat Step 3 through Step 6.

    Note: When configuring an additional connector, set Scope to Per domain, and enter all Domains that the additional connector should cover. All other Domains are covered by the original connector that was configured with Scope set to Default.

  8. Use the newly created connector to apply a control to an Identity Protection policy rule. For more info, see Identity Protection policy.

Cloud MFA (protocol based)
You can configure Identity Protection to integrate with any cloud-based MFA provider by using the OIDC protocol connector.
Tip: Unlike the other Falcon MFA connector types, an OIDC protocol connector displays the MFA prompt user experience of the particular MFA provider, rather than the Falcon MFA prompt user experience.

Integration process

In the third-party provider:
  1. Create an OIDC application.
  2. Configure the application to support a passwordless flow.
  3. Configure the redirect URI to <falcon>/api2/id-protect/openid/callback.
    Note: For more info about Microsoft Entra ID setup, see How to deploy cloud MFA using Entra OIDC application in Falcon Identity Protection. For US-GOV-1 and US-GOV-2 customers, see How to deploy cloud MFA using Entra OIDC application in Falcon Identity Protection.
In the Falcon console:
  1. Go to Identity Protection > Configure > Connectors.
  2. In the Select connector list, select Cloud MFA (Protocol Based) > OpenID Connect (OIDC) and click Add.
  3. In the Cloud MFA (protocol based) section, in the Provider Type field, enter the MFA provider product name and click Add.
    Note: The Provider Type is added to the list of provider types that are available to select when you create a new OIDC connector. You can add a new Provider Type at any time.
  4. Click Add new connector. A new OIDC connector row is displayed.
  5. Enter the following values:
    • Provider Type: Select the provider type that you just created or any other provider type that you created earlier.
      Tip: You can create multiple connectors using the same provider type.
    • Metadata URL: Enter the tenant URL that you obtained from the OIDC application that you created.
    • Client ID: Enter the client ID value that you obtained from the OIDC application that you created.
    • Client Secret: Enter the client secret value that you obtained from the OIDC application that you created.
    • User Identifier: Select the desired user identifier method. Selecting Default sets the user identifier as email.
    • Scope: Select Default or per Domain. Selecting per Domain displays the Domain field.
    • Domain: Enter all domains that the connector should cover.
  6. Click Save.
    Note: New third-party MFA providers must be allowed by CrowdStrike. If an error message is displayed when you click Save, contact Support to allow the MFA provider.
On-premises MFA providers

Identity Protection can communicate with MFA providers within your network, such as RADIUS-based servers, by using the CrowdStrike on-premises MFA enablement tool.

This tool acts as an API client of Falcon and communicates with your on-premises MFA provider, acting as a bridge between Identity Protection and your on-premises MFA providers.

Set up the CrowdStrike on-premises MFA enablement tool

To set up the CrowdStrike on-premises MFA enablement tool in your environment and enable MFA through on-premises providers, follow these steps:

  1. Check the prerequisites

  2. Create an API client

  3. Install the CrowdStrike on-premises MFA enablement tool

Prerequisites

Before installing the on-premises MFA enablement tool, ensure your server meets the following requirements:

  • Windows Server 2008 R2 or later

  • .NET Framework 4.5.1 or later

  • Outbound network access on HTTP port 443 to the CrowdStrike API endpoint for your cloud:

    • US-1: https://api.crowdstrike.com

    • US-2: https://api.us-2.crowdstrike.com

    • EU-1: https://api.eu-1.crowdstrike.com

    • US-GOV-1: https://api.laggar.gcw.crowdstrike.com

    • US-GOV-2: https://api.us-gov-2.crowdstrike.mil

  • Administrator access

    Tip: The installer prompts you for admin credentials if your current credentials are insufficient.

Create an API client

Create an API client in Falcon that the CrowdStrike on-premises MFA enablement tool can use for communication.

Add these scopes to the API client:

  • Identity Protection on-premises enablement: read and write

Make a note of the API client ID and secret; you will need them to install the tool.

Install the CrowdStrike on-premises MFA enablement tool interactively

  1. Using the Chrome browser, download the CrowdStrike on-premises MFA enablement tool installer from Support and resources > Resources and tools > Tool downloads .

  2. Run the CrowdStrike on-premises MFA enablement tool installer on a server within the domain. For example, your on-premises MFA server.

  3. Select I accept the license agreement and privacy notice, and then click Next.

  4. Specify the installation folder and click Next.

  5. On the Properties page, specify the following info:

    • Client ID: Specify the ID of the API client you created earlier.

    • Client Secret: Specify the secret of the API client.

    • API URL: Specify the API URL of the Falcon cloud you are using. One of:

      • US-1: https://api.crowdstrike.com

      • US-2: https://api.us-2.crowdstrike.com

      • EU-1: https://api.eu-1.crowdstrike.com

      • US-GOV-1: https://api.laggar.gcw.crowdstrike.com

      • US-GOV-2: https://api.us-gov-2.crowdstrike.mil

    • Proxy host / Proxy port: Optionally specify the host and port of a proxy if it is required to access the API URL or Internet.

  6. Click Next.

  7. On the Ready to Install page, click Install to begin the installation.

  8. To close the installer when done, click Finish.

    The service starts automatically.

Install the CrowdStrike on-premises MFA enablement tool using the command-line

  1. Using the Chrome browser, download the CrowdStrike on-premises MFA enablement tool installer from Support and resources > Resources and tools > Tool downloads .

  2. Open a command prompt using the Run as administrator option.

  3. Run the CrowdStrike on-premises MFA enablement tool installer on a server within the domain, for example your on-premises MFA server:

    msiexec /i CSOnPremiseMFAEnablement-<version>.msi /qn CLIENT_ID=<client_id> CLIENT_SECRET=<client_secret> API_URL=<api_url> PROXY_HOST=<proxy_host> PROXY_PORT=<proxy_port> /L*V "<log_file>"

    The service starts automatically.

Command-line installation options

When you run the installation command, you can use any of these optional flags:

  • /qn: Install silently.

  • /qb: Show only a progress bar and minimal dialog.

  • CLIENT_ID: The ID of the API client you created earlier. See Create an API client.

  • CLIENT_SECRET: The secret of the API client. See Create an API client.

  • API_URL: The API URL of the Falcon cloud you are using. One of:

    • US-1: https://api.crowdstrike.com

    • US-2: https://api.us-2.crowdstrike.com

    • EU-1: https://api.eu-1.crowdstrike.com

    • US-GOV-1: https://api.laggar.gcw.crowdstrike.com

    • US-GOV-2: https://api.us-gov-2.crowdstrike.mil

  • PROXY_HOST: (Optional) The IP address of a proxy if it is required to access the API URL or Internet. For example, 10.159.148.1.

  • PROXY_PORT: (Optional) The port number of a proxy if it is required to access the API URL or Internet. For example, 8080.

  • L*V "<log_file>": (Optional) The file for verbose logging info. This file is located in the same folder as the installer by default. You can specify a different path.

Example of installing silently, with log file output:

msiexec /i CSOnPremiseMFAEnablement-1.1.55-x64.msi /qn CLIENT_ID=8985f876f0571491c CLIENT_SECRET=cef1844308364b API_URL=https://api.crowdstrike.com/ /L*V "CS-MFA-install.log"

Remove the CrowdStrike on-premises MFA enablement tool

To remove the CrowdStrike on-premises MFA enablement tool from your server:

  1. In Windows Server, go to Start > Control Panel.

  2. In the Programs category, click Uninstall a program.

  3. Select CrowdStrike on-premises MFA enablement, and then click Uninstall.

Supported on-premises MFA data connectors

This table lists the supported on-premises MFA data connectors and the authentication methods each of them supports.

Name Supported Authentication Methods

RADIUS-based: Integrate Cloud Microsoft Entra MFA using NPS extension
  • OTP (Mobile App and SMS)
  • Push (Mobile App and callback)

RADIUS-based: Integrate generic RADIUS servers
  • Vendor specific

RSA Authentication Manager (RSA AM)
  • SecurID
RADIUS-based

RADIUS servers each support a variety of MFA vendors for user authentication, and each vendor requires a specific configuration.

Prerequisites

Before starting the integration, make sure that the following prerequisites are met:

  1. You have installed the CrowdStrike on-premises MFA enablement tool within your network.

  2. You know the IP address and/or hostname of your configured RADIUS server.

  3. You have obtained the shared secret that secures communication between your RADIUS server and its clients, if required.

Note: The Fallback Identity Verification Connector configuration does not apply when using RADIUS-based MFA providers, as Identity Protection can’t force the RADIUS server to use a specific MFA type.

Integrate Cloud Microsoft Entra MFA using NPS extension

To prepare for on-premises RADIUS-based Cloud Entra MFA using NPS extension:

  1. Install the Network Policy Server (NPS) extension for Entra ID Multi-Factor Authentication. For more information about installing the extension, see Microsoft's documentation.

  2. In the Network Policy Server console, add the CrowdStrike on-premises MFA enablement tool as a RADIUS client:

    1. Expand RADIUS Clients and Servers, right-click RADIUS Clients, and then click New RADIUS Client.

    2. On the New RADIUS Client page:

      1. Select Enable the RADIUS client.

      2. Enter a Friendly name for the RADIUS client.

      3. Enter the Address (IP or DNS) of the server where you installed the CrowdStrike on-premises MFA enablement tool.

      4. Select Manual to enter your own Shared secret, or select Generate to create one for you.

        Keep the shared secret value safe. You must enter it when configuring the connector in the Falcon console.

      5. Click OK.

        For more information, see Add the Network Access Server as a RADIUS Client in NPS in Microsoft's documentation.

  3. In the Network Policy Server console, create a Connection Request Policy that allows the CrowdStrike on-premises MFA enablement tool to access the RADIUS server:

    1. Expand Policies, right-click Connection Request Policies, and then click New.

    2. On the Specify Connection Request Policy Name and Connection Type page:

      1. Enter a Policy name.

      2. Set the Type of network access server field to Unspecified.

      3. Click Next.

    3. On the Specify Conditions page:

      1. Click Add.

      2. Select Client IPv4 Address, and then click Add.

      3. Enter the IP address of the CrowdStrike on-premises MFA enablement tool, and then click Add.

      4. Click Next.

    4. On the Specify Connection Request Forwarding page:

      1. Click Authentication.

      2. Select Accept users without validating credentials.

      3. Click Next.

    5. On the Configure Settings page:

      1. Add any attributes as required.

      2. Click Next.

    6. Verify your configuration, and then click Finish.

  4. In the Network Policy Server console, create a Network Policy as follows:

    1. Expand Policies, right-click Network Policies, and then click New.

    2. On the Specify Network Policy Name and Connection Type page:

      1. Enter a Policy name.

      2. Set the Type of network access server field to Unspecified.

      3. Click Next.

    3. On the Specify Conditions page:

      1. Click Add.

      2. Select Client IPv4 Address, and then click Add.

      3. Enter the IP address of the CrowdStrike on-premises MFA enablement tool, and then click Add.

      4. Click Next.

    4. Verify your configuration, and then Finish.

To configure the connector:

  1. In the Falcon console, go to Identity Protection > Configure > Connectors.

  2. From the Select connector field, choose RADIUS-based and then click Add.

  3. From the Choose Template field, select Entra (using NPS).

  4. In IP / Host, enter the IP address or the hostname of your NPS server.

  5. Enter values for the Authentication Port (often 1812) and Accounting Port (often 1813).

  6. Optionally, in User Identifier, select the attribute that contains the value the MFA provider requires to uniquely identify a user.

    For example, you might have your MFA provider configured to require the email address or principal name.

    We recommend that you keep the Default setting.

  7. Click Save.

    Note: Due to a limitation of the RADIUS protocol, Identity Protection is not able to show the connectivity status accurately. The status icon is always green.

Integrate generic RADIUS servers

You might need to configure your RADIUS server to accept connections from the CrowdStrike on-premises MFA enablement tool.

Consult your vendor's documentation for information on how to configure client connections.

To configure the connector:

  1. In the Falcon console, go to Identity Protection > Configure > Connectors.

  2. From the Select connector drop-down list, choose RADIUS-based and click Add.

  3. From the RADIUS-based integration options drop-down list, select Generic.

  4. In IP / Host, enter the IP address or the hostname of the RADIUS server.

  5. In RADIUS Shared Secret, enter a shared secret that your RADIUS server might require to authenticate the tool.

  6. Enter values for the Authentication Port (often 1812) and Accounting Port (often 1813).

  7. If the MFA vendor your RADIUS server is using requires additional authentication, enable Prompt for passcode.

  8. Optionally, in User Identifier, select the attribute that contains the value the MFA provider requires to uniquely identify a user.

    For example, you might have your MFA provider configured to require the email address or principal name.

    We recommend that you keep the Default setting.

  9. Click Save.

    Note: Due to a limitation of the RADIUS protocol, Identity Protection is not able to show the connectivity status accurately. The status icon is always green.

RSA Authentication Manager (RSA AM)

Use RSA Authentication Manager (RSA AM) on-premises MFA server to verify identities in Identity Protection policies.

Prerequisites

Before starting the integration, make sure that the following prerequisites are met:

Integration process

Step 1. Import the RSA AM server certificate into the on-premises MFA enablement tool

  1. Download a copy of the root server certificate file from the RSA Authentication Manager administration console.

    For more information, see Download an RSA Authentication Manager Server Certificate in the RSA documentation.

  2. As a local administrator on the endpoint that is running ths on-premises MFA enablement tool:

    • In a command prompt, change directory to C:\Program Files\CrowdStrike Identity Protection\CrowdStrike On-premises MFA Enablement\jre64\bin

      If you did not install the on-premises MFA enablement tool in the default directory, update the path as required.

    • Run the following command:

      keytool -import -trustcacerts -keystore "C:\ProgramData\CrowdStrike Identity Protection\CrowdStrike On-premises MFA Enablement\cacerts_crowdstrike" -storepass changeit -alias <MyAlias> -file "<path/to/rsa_server_certificate.cer>"

      Specify the path to the CER file you downloaded from RSA AM, and specify an alias to help you identify the certificate.

  3. Restart the on-premises MFA enablement tool service to start using the newly imported certificate.

Step 2. Enable the SecurID authentication API in RSA AM

As described by Configure the RSA SecurID Authentication API for Authentication Agents in the RSA documentation, enable the authentication API to allow the on-premises MFA enablement tool to access your RSA AM instance..

Make a note of the API Access Key value. You will use this value in the Authentication API Key property when configuring the connector.

Step 3. Create an authentication agent in RSA AM

As described by Deploying an Authentication Agent that Uses the REST Protocol in the RSA documentation, create an authentication agent to help you identify the source of authentication events when viewing RSA AM logs, and configure the connection port.

Make a note of the Hostname value. You will use this value in the Authentication API Agent Name property when configuring the connector.

Also make a note of the port number the authentication agent will use, often 5555. You will use this value in the Port Number property when configuring the connector.

Step 4. Configure the RSA AM connector in the Falcon console

  1. In the Falcon console, go to Identity Protection > Configure > Connectors.

  2. In the Select connector list, select RSA AM and click Add.

  3. Enter the values you obtained from RSA AM into the following fields:

    • Domain (the domain name that hosts your RSA AM server)

    • Port Number

    • Authentication API Key

    • Authentication API Agent Name

  4. Optionally, in User Identifier, select the attribute that contains the value the MFA provider requires to uniquely identify a user.

    For example, you might have your MFA provider configured to require the email address or principal name.

    We recommend that you keep the Default setting.

  5. Click Save when done.

    The indicator turns green within a minute, indicating the connection was successfully established.

  6. If the indicator does not turn green:

    • Refresh the page

    • Verify that the hostname is accessible

    • Verify that all the parameters are entered correctly. If not, re-enter the parameter and click Save.

  7. Test the connection by creating an identity verification policy rule for a RSA AM MFA-enrolled user. Make sure to select the RSA AM option in the Connector list.

    When attempting to log in to a workstation that is not associated with them, the user should receive an on-screen notification to perform MFA.

    For more information, see Identity Protection Policy.

FalconID MFA

Identity Protection integrates with Falcon for Mobile to provide a phish-resistant multi-factor authentication solution. For more info, see FalconID.

IDaaS connectors

Identity as a Service (IDaaS) is an authentication infrastructure that is built, hosted and managed by a third-party service provider. IDaaS can be thought of as a single sign-on (SSO) for the cloud.

Identity Protection supports the following identity management services:

Microsoft Entra ID (entity and activity ingestion)

Microsoft Entra ID (previously known as Azure AD) was created as part of Microsoft’s effort to make Office 365 and other apps use SSO. It can be integrated with the on-premises AD or serve as an independent directory service for businesses that do not have on-premises presence.

Microsoft synchronizes the data from the on-premises AD and keeps identifiers that help Falcon Identity Protection correlate SSO transactions to the hybrid user accounts. Identity Protection can integrate with Entra ID for multiple tenants.

The following procedure covers the Identity connector for data ingestion. For more info about configuring response actions in Entra, see Integrate with Microsoft Entra ID.

Prerequisites

Before starting the integration, make sure that the following prerequisites are met:

  • You have a paid Microsoft Entra ID license.

    Note: Microsoft Entra ID Free is not supported.
Integration process

To integrate Identity Protection with Microsoft Entra ID, follow these steps for each Azure tenant.

Note: Integrating with multiple Entra ID tenants does not affect the Azure MFA connector. You can only configure a single Azure MFA connector.

Step 1. Create an application in Entra ID and grant it the required permissions

Step 2. Get your Tenant Domain value

Step 3. Get your Application ID and Application Secret values

Step 4. Create a custom role with access to read RBAC properties

Step 5. Configure the Microsoft Entra ID connector in Identity Protection

Step 1. Create an application in Entra ID and grant it the required permissions

Create an application in Entra ID to allow Identity Protection to connect.

  1. In your Azure portal, open the left portal menu, and then click Microsoft Entra ID Active Directory.

  2. On the Microsoft Entra ID Active Directory page, from the Add menu, select App registration.

  3. On the Register an application page:

    1. In Name, enter a friendly name for the application, for example "Identity Protection Connector".

    2. In Supported account types, select Accounts in this organizational directory only (Default Directory only - Single tenant).

    3. In Redirect URI, select Web and then enter https://localhost

    4. Click Register.

      The Azure portal displays the Overview page for your new app.

  4. In the left app menu, click API permissions.

  5. On the API permissions page, click Add a permission.

  6. In the Request API permissions panel, click Microsoft Graph, and then click Application permissions.

  7. Important. In Select permissions:

    1. Type directory, expand Directory and select Directory.Read.All

    2. Type audit, expand AuditLog and select AuditLog.Read.All

  8. Click Add permissions.


    The API permissions required to integrate Identity Protection and Azure AD.

  9. On the API permissions page, click Grant admin consent for {Default Directory}, and then click Yes when prompted to confirm consent.

    Note that Default Directory might have a different name in your environment.

Step 2. Get your Tenant Domain value

You need to get the Tenant Domain value from Entra ID so that you can integrate it into Identity Protection. This is the internal domain configured for the Azure account. Notice that this domain is different from the actual external domain assigned to the account.

For example, your external domain might be example.com, but your tenant domain might be example.onmicrosoft.com.

To get this value from Entra ID:

  1. In your Azure portal, open the left portal menu, and then click Microsoft Entra ID.

  2. On the left menu, click Overview, select the Overview tab, and make a note of the Primary domain value. For example, example.onmicrosoft.com.

    You will use this value as the Tenant Domain during Step 5. Configure the Microsoft Entra ID connector in Identity Protection.

Step 3. Get your Application ID and Application Secret values

You need to get these values from Entra ID so that you can integrate it into Identity Protection.

  • Application ID: The identifier of the application created for this integration

  • Application Secret: The secret key of the application created for this integration

To get these values from Entra ID:

  1. In your Azure portal, open the left portal menu, and then click Microsoft Entra ID.

  2. On the left menu, click App registrations, and then select the application you created earlier. For example, "Identity Protection Connector".

  3. In the left app menu, click Overview.

  4. Make a note of the Application (client) ID value. You will use this value as the Client ID during Step 5. Configure the Microsoft Entra ID connector in Identity Protection.

  5. In the left app menu, click Certificates & secrets.

  6. In Client secrets, click New client secret.

  7. In Description, enter useful notes about the purpose of the secret, for example, "Identity Protection Secret".

  8. In Expires, select the length of time that the client secret is valid for. For example, 6 months.

  9. Click Add.

  10. Make a note of the generated Value. You will use this value as the Application Secret during Step 5. Configure the Microsoft Entra ID connector in Identity Protection.

    Note: Failing to enter the generated Entra ID Value in the Falcon Application Secret field produces the error “Invalid Secret Key”. Be sure to use the Entra ID Value not the Secret ID.
    Entra value

Step 4. Create a custom role with access to read RBAC properties

To display information about Azure RBAC role assignments in Identity Protection, you need to grant the application permission to read the RBAC definitions and assignments.

It is recommended to create a custom role with the minimal permissions to read RBAC properties, and assign it to the application.

  1. In your Azure portal, go to Management groups.

  2. Click Tenant Root Group.

  3. Select Access control (IAM) and then click Roles.

  4. Click Add, and then select Add custom role.

  5. On the Basics tab, enter a name and description for the custom role.

  6. On the Permissions tab, add the following permissions to the custom role:

    • Microsoft.Authorization/roleDefinitions/read

    • Microsoft.Authorization/roleAssignments/read

  7. Click Review + create, check the new custom role, and then click Create.

To assign the custom role to the application you created earlier:

  1. In your Azure portal, go to Management groups.

  2. Click Tenant Root Group.

  3. Select Access control (IAM) and then click Role assignments.

  4. Click Add, and then select Add role assignment.

  5. On the Role tab, select your new custom role.

  6. On the Members tab, click Select members, locate the application you created earlier, for example "Identity Protection Connector", and then click Select.

  7. Click Review + assign, check the new assignment to your app, and then click Review + assign again.

Step 5. Configure the Microsoft Entra ID connector in Identity Protection

  1. In the Falcon console, go to Identity Protection > Configure > Connectors.

  2. From the Select connector menu, in the IDAAS category, select Entra and then click Add.

  3. In the connector settings, specify the values that you obtained from Entra ID:

    1. Tenant Domain. Such as example.onmicrosoft.com

    2. Application ID. Such as b879bb83-3rec-6jdc-9fbf-b3d673895e95

    3. Application Secret. Such as BVZqLdFK1B....rnH8xjDrV9

    4. To collect user and application sign-in activity for the tenant using the API, enable Collect Sign-In data.

      If you are not interested in collecting sign-in based data or did not grant the above mentioned permissions, disable Collect Sign-In data.

  4. Click Save.

    The indicator turns green within a minute, indicating that the connection was successfully established.
    Note: If you see a warning that the Entra connector requires additional permissions, ensure you have completed Step 4. Create a custom role with access to read RBAC properties.
Okta SSO

This feature allows you to extend Identity Protection’s threat detection capabilities to all of your cloud applications protected by Okta, enabling the scenario where Identity Protection correlates SSO activities to the hybrid user accounts.

The following procedure covers the Identity connector for data ingestion. For more info about configuring response actions in Fusion SOAR, see Integrate with Okta for response actions.

Note: Only one Okta SSO connector can be supported per CID.
Prerequisites

Before starting the integration, make sure that the following prerequisites are met:

  • You have created an API token with the Read-Only Admin permission in your Okta instance that Identity Protection can use to authenticate to Okta APIs.

For more information about Okta API tokens and permissions, see these pages in the Okta developer documentation:

Integration process

  1. In the Falcon console, go to Identity Protection > Configure > Connectors.

  2. From the Select Connector field, select Okta and then click Add.

  3. In the Okta data connector:

    1. In the Domain field, enter the URL of your organization’s Okta portal.

    2. In the Token field, enter the Okta API token that has the Read-Only Admin permission.

After the connector is added and configured, Identity Protection automatically ingests data from Okta and begins displaying the cloud-based information.

OIDC integrations

OpenID Connect is an interoperable authentication protocol based on the OAuth 2.0 framework. It simplifies verifying the identity of users by using an Authorization Server to perform authentication and obtain user profile information. In these integrations, Falcon acts as an Authorization Server.

You can use OIDC integrations to add dynamic, risk-based prevention capabilities (allow, step-up authentication, and block) to third party, single sign-on (SSO) providers.

Identity Protection supports the following identity management services:
Device conditions
The Entra ID EAM OIDC integration supports device conditions such as Falcon installed, Source ZTA score, Source groups, Baseline, and more. To use these conditions in an OIDC integration, you must first set up the CrowdStrike browser extension on end user devices by following these steps:
  1. In the Falcon console, go to Host setup and management > Manage endpoints > Browser extension policies .
  2. Make sure you have a policy with Enable automatic installation selected. For more info, see Falcon Browser Extension.
Entra ID EAM

Improve your Microsoft Entra ID security posture with Entra ID external authentication method (EAM) OIDC integration in Falcon. For more info, see Manage an external authentication method in Microsoft Entra ID.

Prerequisites
Before starting the integration, make sure that the following prerequisites are met:
  • Subscription: Falcon Identity Threat Protection
  • Default roles: Falcon Administrator, Identity Protection Administrator
  • CrowdStrike clouds: Available in all clouds
  • Azure license: P1 and above
  • Azure role: Administrator
  • You have an existing Entra ID IDaaS connector. For more info, see ​Microsoft Entra ID (entity and activity ingestion)​.
Integration process

Step 1. Create a Falcon OIDC client for Entra EAM

  1. In the Falcon console, go to Identity protection > Configure > OIDC integrations.
  2. Click Create OIDC client.
  3. In Provider type, select Entra ID.
  4. Enter a client name and the appropriate Redirect URI: Create OIDC client
  5. Click Create.
  6. Click OIDC client details.OIDC integrations
  7. Make a note of the Client ID, Discovery endpoint, and App ID values to enter later during Step 2. Create an Entra ID external authentication method.OIDC client details

Step 2. Create an Entra ID external authentication method

Create an external authentication method in your Entra ID tenant. For more info, see Manage an external authentication method in Microsoft Entra ID.

  1. In your Azure portal, go to Microsoft Entra ID > Security > Manage > Authentication methods, and click Add external method.
  2. Enter the following values:
    • Name: This is displayed to the end user at login.
    • Client ID: Enter the Client ID value that you saved from Falcon earlier.
    • Discovery Endpoint: Enter the Discovery endpoint value that you saved from Falcon earlier.
    • App ID: Enter the App ID value that you saved from Falcon earlier.
  3. In the Enable and target section, set the Enable toggle to On, set the target users to a specific group, and click Save.

Step 3. Configure your Microsoft MFA policy

Configure a Microsoft MFA policy to require users to complete multifactor authentication.
Important: If you already have Microsoft Entra conditional access policies, you do not need to complete the following steps.
  1. In your Azure portal, go to Security > Conditional Access > Policies.
  2. Click New policy and enter a name for the policy.
  3. In the Users section, select Select users and groups.
  4. Choose a group or individual users that you want the policy to apply to and click Select.
    Note: Make sure not to lock yourself out. Leave an Admin account out of this policy. For more info, see Manage emergency access accounts in Microsoft Entra ID.
  5. In the Target resources section, select All resources if you want the policy to apply to all of your cloud apps, or select Select resources and choose the specific cloud apps that you want.
  6. In the Grant section, select Grant access and Require multifactor authentication and click Select.
  7. In the Session section, select Sign-in frequency. For more info about sign-in frequencies, see Conditional Access adaptive session lifetime policies
  8. Set Enable policy to On and click Create.
Okta

Improve your Okta security posture with Okta external authentication method (EAM) OIDC integration in Falcon. For more info, see Okta SSO.

Prerequisites

Before starting the integration, make sure that the following prerequisites are met:

  • Subscription: Falcon Identity Threat Protection
  • Default roles: Falcon Administrator, Identity Protection Administrator
  • CrowdStrike clouds: Available in all clouds
  • Okta role: Okta Administrator
Integration process

Step 1. Create a Falcon OIDC client for Okta

  1. In the Falcon console, go to Identity protection > Configure > OIDC integrations .
  2. Click Create OIDC client.
  3. In Provider type, select Okta.
  4. Enter a client Name.
  5. In Redirect URI, enter https://<tenant name>/oauth2/v1/authorize/callback
  6. Click Create.
  7. Make a note of the Client ID, and Secret values to enter later during Step 2. Create an Identity provider in Okta.
  8. Click Done.
  9. Click the Action menu next to the OIDC client that you just created, and select OIDC client details. Keep this window open to consult during Step 2. Create an Identity provider in Okta.

Step 2. Create an Identity provider in Okta

  1. Log in to the Okta console as an administrator. For more info, see Administrator roles and permissions in the Okta developer documentation.
  2. Go to Security > Identity Providers.
  3. Click Add identity provider and select OpenID connect.
  4. Click Next.
  5. In Configure OpenID Connect IdP, enter the following values:
    • Name: Enter a name for the identity provider.
    • IdP Usage: Select Factor only.
    • Scopes: Select openid.
    • Client ID: Enter the ClientID value that you saved from Falcon earlier.
    • Secret: Enter the Secret value that you saved from Falcon earlier.
    • Application context: Enable Send Okta application context.
    • Endpoints: Enter the URI values from the OIDC client details window in Falcon (Issuer, Authorization endpoint, Token endpoint, JWKS endpoint).
  6. Click Finish.

Step 3. Create an authenticator in Okta

  1. Log in to the Okta console as an administrator. For more info, see Administrator roles and permissions in the Okta developer documentation.
  2. Go to Security > Authenticators.
  3. Click Add authenticator.
  4. In Identity Provider (IdP), select the identity provider that you created earlier.
  5. In Authenticator name, enter the name that you want the end user to see when logging in.
  6. Click Add.
Note: End users must enroll in the identity provider that you just created. For more info, see Authenticator enrollment policies.

Risk Configuration

Use the Risk Configuration page to view and configure Compromised Password Detection for your network.

Manage compromised password detection

The Compromised Password Detection feature identifies passwords on Microsoft AD that the system determines were previously compromised. This detection happens on the Domain Controller, so the passwords never leave the DC.

By default the Compromised Password Detection feature is enabled and set to use all its dictionaries to detect compromised passwords. Disabling this feature clears the set of currently detected Compromised Passwords and prevents the future detection of compromised passwords. If any Compromised Password Detection functionality is disabled, Identity Protection reevaluates the risk value assigned to all affected entities.

You can manage these Compromised Password Detection dictionaries:

  • HaveIBeenPwned dictionary

  • Custom Passphrases dictionary

Manage the HaveIBeenPwned dictionary

The Compromised Password Detection feature integrates the HaveIBeenPwned dictionary that aggregates information about compromised and breached personal data. Identity Protection uses the offline version of the dictionary, so the passwords are not exposed to the Internet.

The ability to include the HaveIBeenPwned verification into a standard password check is enabled by default and can be disabled at any time

Manage the custom passphrases dictionary

You can add words to the Custom Passphrases dictionary. For example, the names of local sports teams. The system uses these words to test the end user’s password strength.

You can increase the volume of passphrases and passwords contained in the Custom Passphrases dictionary by periodically uploading files that contain additional words.

To add words and passphrases to the customized password dictionary:

  1. Prepare a text file (.txt) that contains one word per line. Identity Protection matches the individual words in the file.

  2. Go to Identity protection > Configure > Risk configuration.

  3. In the Compromised Password Detection section, click Edit Configuration Settings.

    The Compromised Password Detection page opens.

  4. In the Custom Passphrases section, select the Active check box to use the Custom Passphrases dictionary.

  5. Click Add Words, browse to the text file, and click Open.

    The file is uploaded and the Custom Passphrases dictionary is incremented with the new words.

    Note: There is no limit on the file size that you can upload to the Custom Passphrases dictionary.

    A confirmation message displays the number of words that were successfully loaded and the total number of words contained in the dictionary is displayed.

Manage risk detection

Identity Protection detects a wide range of potential risks to your organization's security posture and uses them to calculate the risk score for entities.

You can disable specific risk factors so that they do not contribute to risk scores, and are no longer added to the risk factor lists. For example, if you are following NIST recommendations and are enforcing strong passwords in your organization, you could potentially disable detection of the Insufficient Password Rotation risk factor.

Disabling risk factors does not affect related attributes and privileges. For example, disabling the Stealthy Privilege risk factor does not remove the Stealthy Administrators privilege from an entity, it only alters risk score calculations. Similarly, insights that rely on attributes rather than risk factors, such as stale accounts, remain unchanged when disabling a risk factor.

The effects of changing the risk configuration can take a long time to propagate. It could take several days for the Falcon console to fully reflect the updated risk factor list and relevant risk scores.

To disable detection for specific risk factors:

  1. Go to Identity protection > Configure > Risk configuration.


    View both enabled and disabled risks in the Risks Management table.

  2. In Risks Management, disable the Hide enabled switch to see all the available risks factors.

    Tip: Use the search field to filter the list of risk factors.

  3. To disable a risk factor, disable the switch next to its name and click Save.

    A confirmation message appears.

  4. To apply your changes, click Disable Anyway.

Settings

The Settings tab enables you to configure miscellaneous parameters.

Each of these parameters is described in the table below.

Setting Description

Audit Log

Enables you to view the audit log (see Audit Log).

Time Zone

Enables you to set the time zone (see Time Zone).

View Preferences

Enables you to select if you want to sort incidents according to their creation time.

Threat Hunter feed

Enables you to add routine queries for LDAP search events.

Turning this on will significantly increase the total event quantity and could slow down analytics.

MFA Branding

Enables you to customize the logo that appears in the MFA application.

Business Privileges

Enables you to define different business privileges and the impact these privileges have.

You can apply business privileges to users and groups.
Email notifications

The Notifications area enables you to configure what email notifications are sent by Identity Protection. Email notifications are available for all detection types.

Notification emails can contain sensitive identifying information about your environment, such as host names. For security reasons, we recommend using email addresses from only the domains that you control. Using email addresses from domains outside of your control could introduce security risks.

Consider who should receive notifications to support your broader incident-response process. Email notifications can serve as important alerts about suspicious activity and potential attacks.

Configure email notifications

  1. Click Email Notifications.

  2. In the Edit Email Notifications dialog, specify this info:

    • Enable Email Notifications: Select this check box to enable email notifications.

    • Recipients: Specify one or more email addresses that receive the email notifications.

    • CC Recipients: Specify one or more email addresses that are carbon copied on email notifications.

    • Include All: Select this check box to initiate an email notification for all types of detection.

    • Include: Specify the individual detection types that initiate an email notification. This option is not available if Include All is selected.

    • Severity: Specify the severity level the detection must meet to initiate an email notification.

  3. Click Save.

Audit Log

Click View Audit Log to display the audit log, which tracks logins, logouts and configuration changes. You can download a CSV version of the log by clicking CSV. The following audit log events are recorded:

  • 3rd Party API Integration Status Changed

  • A user admin modified exceptions for an alert

  • Advanced Notification Configuration Modified

  • Alert Exceptions Configuration Modified

  • Connector Configuration Added / Deleted / Modified

  • Policy Applied

  • Policy Rule Added / Deleted / Modified

  • Policy Rules Reordered

  • Sensor Activated / Unpaired / Modified

Time Zone

Select the required time zone from the drop-down list in the Time Zone area. This selection affects only Identity Protection system operations, such as reports. It can also affect Threat Hunter search results, if the Time Zone value in the search criteria is set to Use System Time Zone.

Any other date or time that appears in Identity Protection is based on the browser settings.

MFA Branding

You can add your own text and logo to the Falcon Identity Protection MFA notification. This helps to reflect an organization's brand and consequently build improved trust with users.

Required image properties

  • Image size must be 170px by 40px

  • Formatted as PNG

  • Transparent background

Text properties

  • Maximum of 2 lines

  • Maximum of 70 characters per line.

To customize the MFA UI with your brand:

  1. In the MFA Branding section click Upload File.

  2. Browse for and select the image file.

    A green check mark and the message Uploaded is displayed when the file is successfully uploaded.

  3. Enter text in the two text boxes.

  4. Click Save.

To delete a saved image:

  1. Click the Remove trash can to the right of Upload File.

  2. Click Save.

Business Privileges

Use Business Privileges to augment the underlying permissions assigned to your users and groups. For example, perhaps you have a number of users that have admin access to your social media platform, but that platform doesn't use Active Directory permissions. You can add these users to a custom Business Privilege.

Adding users or groups to custom Business Privileges marks those users as privileged. For example, they will show up in Privileged identities. You can also create policy rules that apply to users with a business privilege applied, by using the User privileges condition with the Business Privileged value.

Adding a Business Privilege to an entity that was not already privileged creates a Privileged Escalation event which shows on the entity's timeline, as well as in Threat Hunter.


Adding users to Business Privileges generates an event in their timeline.

You must specify the Impact of a business privilege. The impact represents your assessment of the potential damage that could be caused if the accounts in the business privilege were compromised. Available values are Low, Medium, and High. Higher impact values increase the probability that the severity of an alert involving the business privilege is higher.

Configure business privileges

  1. In the Falcon Console, go to Identity protection > Configure > Settings.

  2. In Business Privileges, enter a Name, select the Impact level, and click Add.

    The business privilege is added to the list.

  3. In the Groups / Users field, enter the user or group to add to the privilege, and then select it from the drop-down that appears.


    Create custom business privileges and add users and groups to them in the Settings tab.

  4. To remove a user or group, click the delete (x) icon.

  5. To change the Impact, select a new value from the list.

  6. To rename a business privilege, enter the new name over the existing value in the Name column.

Note: Changes are automatically saved, there is no need to manually save your changes.

Appendix A: IP addresses used to contact third-party services

When the Falcon Cloud needs to contact a third-party service, such as an Identity as a Service (IDaaS) or multi-factor authentication (MFA) provider, the connection uses one of the following IP addresses, depending on which cloud region you are using:

US-1 US-2 EU-1 US-GOV-1

13.52.92.37

13.52.105.156

13.52.148.107

13.57.124.60

52.8.44.174

52.8.221.60

52.52.20.134

52.52.102.47

54.219.225.112

35.160.117.193

35.166.85.240

34.208.180.103

34.217.230.100

52.35.84.34

52.43.192.139

54.187.8.114

54.187.226.134

54.203.80.119

3.121.4.173

3.121.65.90

3.121.73.151

3.121.94.124

18.185.69.20

18.194.134.179

18.195.129.87

35.156.170.206

52.58.225.44

52.59.122.180

3.73.169.253

18.158.141.230

52.222.67.222

52.222.92.31

52.222.108.104

If necessary, configure the allowlists in your third-party services to accept inbound connections from these IP addresses.

You might also see these IP addresses in the logs of third-party services.

Appendix B: ForgeRock MFA journey example

When integrating with ForgeRock MFA, save the following code snippet as a JSON file and import into ForgeRock as a journey. See Configure the ForgeRock journey.

{
  "trees": {
    "IdP-MFA": {
      "tree": {
        "_id": "IdP-MFA",
        "_rev": "1347757709",
        "identityResource": "managed/alpha_user",
        "entryNodeId": "6c85818b-829a-467c-9cde-b6a73a9aae9f",
        "nodes": {
          "6c85818b-829a-467c-9cde-b6a73a9aae9f": {
            "x": 203,
            "y": 229.015625,
            "connections": {
              "outcome": "873fe4de-977e-4d92-9e42-8a97c80c1186"
            },
            "nodeType": "PageNode",
            "displayName": "Page Node"
          },
          "873fe4de-977e-4d92-9e42-8a97c80c1186": {
            "x": 466,
            "y": 237.015625,
            "connections": {
              "push": "42fe551e-a6eb-4b02-8f3b-5576ee7191c3",
              "otp": "665ad0a0-cba0-479e-b55b-802e1573b13c"
            },
            "nodeType": "ChoiceCollectorNode",
            "displayName": "Auth Method"
          },
          "42fe551e-a6eb-4b02-8f3b-5576ee7191c3": {
            "x": 709,
            "y": 35.015625,
            "connections": {
              "SENT": "815fa9f7-e44a-4d31-af44-77136df24ac8",
              "NOT_REGISTERED": "e301438c-0bd0-429c-ab0c-66126501069a"
            },
            "nodeType": "PushAuthenticationSenderNode",
            "displayName": "Push Sender"
          },
          "665ad0a0-cba0-479e-b55b-802e1573b13c": {
            "x": 703,
            "y": 458.015625,
            "connections": {
              "successOutcome": "70e691a5-1e33-4ac3-a356-e7b6d60d92e0",
              "failureOutcome": "e301438c-0bd0-429c-ab0c-66126501069a",
              "notRegisteredOutcome": "e301438c-0bd0-429c-ab0c-66126501069a"
            },
            "nodeType": "OathTokenVerifierNode",
            "displayName": "OATH Token Verifier"
          },
          "ae41bb71-b20f-4b32-9c58-bdf39fbd8423": {
            "x": 1217,
            "y": 23.015625,
            "connections": {
              "TRUE": "70e691a5-1e33-4ac3-a356-e7b6d60d92e0",
              "FALSE": "e301438c-0bd0-429c-ab0c-66126501069a",
              "WAITING": "815fa9f7-e44a-4d31-af44-77136df24ac8"
            },
            "nodeType": "PushResultVerifierNode",
            "displayName": "Push Result Verifier Node"
          },
          "815fa9f7-e44a-4d31-af44-77136df24ac8": {
            "x": 955,
            "y": 35.015625,
            "connections": {
              "DONE": "ae41bb71-b20f-4b32-9c58-bdf39fbd8423"
            },
            "nodeType": "PushWaitNode",
            "displayName": "Push Wait Node"
          }
        },
        "staticNodes": {
          "startNode": {
            "x": 50,
            "y": 250
          },
          "70e691a5-1e33-4ac3-a356-e7b6d60d92e0": {
            "x": 1593,
            "y": 285
          },
          "e301438c-0bd0-429c-ab0c-66126501069a": {
            "x": 1592,
            "y": 451
          }
        },
        "enabled": true
      },
      "nodes": {
        "6c85818b-829a-467c-9cde-b6a73a9aae9f": {
          "_id": "6c85818b-829a-467c-9cde-b6a73a9aae9f",
          "_rev": "-1603110960",
          "nodes": [
            {
              "_id": "5e6bf0e8-3b73-46be-9439-3378b21d28ef",
              "nodeType": "ValidatedUsernameNode",
              "displayName": "Platform Username"
            }
          ],
          "pageDescription": {},
          "pageHeader": {},
          "_type": {
            "_id": "PageNode",
            "name": "Page Node",
            "collection": true
          },
          "_outcomes": [
            {
              "id": "outcome",
              "displayName": "Outcome"
            }
          ]
        },
        "873fe4de-977e-4d92-9e42-8a97c80c1186": {
          "_id": "873fe4de-977e-4d92-9e42-8a97c80c1186",
          "_rev": "1265893229",
          "defaultChoice": "push",
          "choices": [
            "push",
            "otp"
          ],
          "prompt": "Choose your preferred auth method",
          "_type": {
            "_id": "ChoiceCollectorNode",
            "name": "Choice Collector",
            "collection": true
          },
          "_outcomes": [
            {
              "id": "push",
              "displayName": "push"
            },
            {
              "id": "otp",
              "displayName": "otp"
            }
          ]
        },
        "42fe551e-a6eb-4b02-8f3b-5576ee7191c3": {
          "_id": "42fe551e-a6eb-4b02-8f3b-5576ee7191c3",
          "_rev": "1648942848",
          "contextInfo": false,
          "userMessage": {},
          "pushType": "DEFAULT",
          "customPayload": [],
          "messageTimeout": 300000,
          "mandatory": true,
          "_type": {
            "_id": "PushAuthenticationSenderNode",
            "name": "Push Sender",
            "collection": true
          },
          "_outcomes": [
            {
              "id": "SENT",
              "displayName": "Sent"
            },
            {
              "id": "NOT_REGISTERED",
              "displayName": "Not Registered"
            }
          ]
        },
        "665ad0a0-cba0-479e-b55b-802e1573b13c": {
          "_id": "665ad0a0-cba0-479e-b55b-802e1573b13c",
          "_rev": "-568668431",
          "totpTimeInterval": 30,
          "totpTimeSteps": 2,
          "maximumAllowedClockDrift": 5,
          "totpHashAlgorithm": "HMAC_SHA1",
          "isRecoveryCodeAllowed": false,
          "algorithm": "TOTP",
          "hotpWindowSize": 100,
          "_type": {
            "_id": "OathTokenVerifierNode",
            "name": "OATH Token Verifier",
            "collection": true
          },
          "_outcomes": [
            {
              "id": "successOutcome",
              "displayName": "Success"
            },
            {
              "id": "failureOutcome",
              "displayName": "Failure"
            },
            {
              "id": "notRegisteredOutcome",
              "displayName": "Not registered"
            }
          ]
        },
        "ae41bb71-b20f-4b32-9c58-bdf39fbd8423": {
          "_id": "ae41bb71-b20f-4b32-9c58-bdf39fbd8423",
          "_rev": "876270017",
          "_type": {
            "_id": "PushResultVerifierNode",
            "name": "Push Result Verifier Node",
            "collection": true
          },
          "_outcomes": [
            {
              "id": "TRUE",
              "displayName": "Success"
            },
            {
              "id": "FALSE",
              "displayName": "Failure"
            },
            {
              "id": "EXPIRED",
              "displayName": "Expired"
            },
            {
              "id": "WAITING",
              "displayName": "Waiting"
            }
          ]
        },
        "815fa9f7-e44a-4d31-af44-77136df24ac8": {
          "_id": "815fa9f7-e44a-4d31-af44-77136df24ac8",
          "_rev": "-2033408293",
          "challengeMessage": {},
          "exitMessage": {},
          "waitingMessage": {},
          "secondsToWait": 3,
          "_type": {
            "_id": "PushWaitNode",
            "name": "Push Wait Node",
            "collection": true
          },
          "_outcomes": [
            {
              "id": "DONE",
              "displayName": "Done"
            },
            {
              "id": "EXITED",
              "displayName": "Exit"
            }
          ]
        }
      },
      "innerNodes": {
        "5e6bf0e8-3b73-46be-9439-3378b21d28ef": {
          "_id": "5e6bf0e8-3b73-46be-9439-3378b21d28ef",
          "_rev": "-1312641141",
          "usernameAttribute": "userName",
          "validateInput": false,
          "_type": {
            "_id": "ValidatedUsernameNode",
            "name": "Platform Username",
            "collection": true
          },
          "_outcomes": [
            {
              "id": "outcome",
              "displayName": "Outcome"
            }
          ]
        }
      },
      "scripts": {},
      "emailTemplates": {},
      "socialIdentityProviders": {},
      "themes": [],
      "saml2Entities": {},
      "circlesOfTrust": {}
    }
  }
}

Identity Protection Policy

Define rules that determine what actions to take in response to certain triggers observed in your environment.

Overview

The Policy Rules page is used to define a number of rules that determine what actions to take in response to certain triggers observed in your environment. These triggers can be authentication requests, alerts, or account changes, such as updating your password.

Each rule can have a set of conditions that must be met for the rule to apply. The combination of these rules forms your Identity Protection policy.


Define a number of rules that determine what actions to take in response to certain triggers observed in your environment

Each rule in your policy is made up of the following three components:

  1. Trigger: Defines what invokes the rule.

  2. Conditions: Any number of requirements that must be met for the rule to apply.

  3. Actions: Defines what the rule does when its trigger occurs and all its conditions are met.

Understand triggers

A trigger defines how the security rule is invoked.

There are 5 types of triggers:

  • Access: Triggers when access occurs. For example, accessing a server or connecting to a workstation.

  • Cloud access: Triggers when authenticating to an external authentication method (EAM). For example, accessing Entra ID applications.
  • Federated access: Triggers when authenticating to a federated service. For example, accessing Office 365.
Note: Identity account event and Identity detection triggers are available through Falcon Fusion SOAR workflows. For more info, see Workflow triggers.

Understand conditions

Use conditions to control exactly the circumstances required for a policy rule to be applied. For example, you can include or exclude certain users or endpoints.

There is no limit to the number of conditions that you can apply to a rule. You can also use the same condition twice in a rule. In this case one use of the condition can use Include and the other can use Exclude. They can’t both have the same include or exclude values.

This table lists the different conditions that can be applied to rules, and which triggers they are available to:

Condition Description Access trigger Cloud access trigger Federated access trigger

Access type

Filter based on the access type, such as Authentication, Remote desktop, or Logon.

Note: The Logon trigger should be used for 3rd party RDP clients and interactive console logins such as VMWare console access.

You can also enter custom values to filter by service-related access type:

  • A service class. Filter based on the specified service. For example, cifs
  • A service principal name (SPN). Filter based on access to the specified service, on the specified host. For example, cifs/dc01.example.com

Yes

  

Baseline

Filter based on how a user normally accesses the system, such as User owns or regularly uses the source endpoint.

Yes

  

Yes
Cloud data source Filter based on their cloud data source, which can be any of the following:
  • Okta
  • Entra
   Yes  

Data source

Filter based on federated access that is managed by the specified identity provider, such as PingFederate or AD FS.

  

Yes
DC domain

Filter based on the DC domain.

Note: This condition is only supported for exclusions.

 Yes    

Destination address

Filter destinations based on the hostname of the endpoint, or the hostname if it is a web address.

When the destination is an endpoint, select the endpoint's hostname.

When the destination is a web address, select the hostname part of the URL.

Note: When the destination is a web address, it is only shown in the drop-down list if it is defined as part of an HTTP class SPN in the active directory.

Yes

  

Destination application

Filter destinations based on the application being accessed.

 Yes (Okta only)

Yes

Destination attribute

Filter destinations based on their attributes. The attribute can be any of the following:

  • Marked
  • Watched
  • Disabled
  • Unmanaged
  • Stable
  • Shared

Yes

  
Destination domain

Filter based on the destination domain.

Note: This condition is only supported for exclusions.

 Yes    

Destination group

Filter destinations based on the AD groups they are a member of.

Yes

  

Destination name

Filter destinations based on their name.

Yes

  

Destination OU

Filter destinations based on their organizational unit (OU).

Yes

  

Destination risk severity

Adaptively filter destinations based on their risk severity. Select a range covering one or more of Low, Medium, and High.

Yes

  

Destination role

Filter destinations based on their classified role. The available roles are workstation or server, and any of their sub types.

Note: The destination must not be "in learning".

Yes

  

Destination ZTA score

Filter destinations based on their Zero Trust Assessment (ZTA) score.

Specify a range using values between 1 (insecure) and 100 (secure).

Yes

  

Protocol

Filter based on the protocol type used. Possible values include:

  • Kerberos
  • NTLM
  • NTLMv1
  • NTLMv2
  • LDAP
  • SMB Dialect 1
  • SMB Dialect 2.0
  • SMB Dialect 2.1
  • SMB Dialect 3.0
  • SMB Dialect 3.0.2
  • SMB Dialect 3.1.1

Yes

  

Site

Filter based on the active directory sites on which they occur. Each activity occurs on a specific domain controller, so can be associated with a specific site.

Yes

  

Source attribute

Filter sources based on their attributes. The attribute can be any of the following:

  • Marked
  • Watched
  • Disabled
  • Falcon installed
  • Impersonator
  • Learning user behavior
  • Stale
  • Shared endpoint
  • Unmanaged endpoint

Note: Falcon installed is supported for Windows and macOS hosts that are in a domain that is managed by Identity Protection. Falcon installed is also supported for mobile hosts when using the Cloud access trigger.

Yes

 Yes

Yes

Source country

Filter sources based on the country they are located in.

 Yes

Yes
Source domain

Filter based on the source domain.

Note: This condition is only supported for exclusions.

 Yes Yes Yes

Source group

Filter sources based on their group.

Yes

 Yes

Yes

Source name

Filter sources based on their name.

Yes

 Yes

Yes

Source network label

Filter sources based on their network label.

Yes

 Yes

Yes

Source network type

Filter sources based on properties of the underlying network activity that occurred when the condition was evaluated.

Note: Only applies to the source endpoint.

Yes

 Yes

Yes

Source OU

Filter sources based on their organizational unit (OU).

Yes

 Yes

Yes

Source risk severity

Adaptively filter sources based on their risk severity. Select a range covering one or more of Low, Medium, and High.

Yes

 Yes

Yes

Source role

Filter sources based on their classified role. The available roles are workstation or server and any of their sub types.

Note: Source must not be "in learning".

Yes

 Yes

Yes

Source ZTA score

Filter sources based on their Zero Trust Assessment (ZTA) score.

Specify a range using values between 1 (insecure) and 100 (secure).

Yes

 Yes

Yes

Time

Filter based on time, according to a set of configured attributes, such as:

  • Day of the week
  • All day
  • Hour of the day
  • Time zone

General behavior

  • The default setting for the Time condition is that Monday and All day are selected.
  • The condition requires that at least one day of the week be set.

When selected, All day overrides the hour range options.

Yes

 Yes

Yes

User attribute

Filter users based on their attributes. The attribute can be any of the following:

  • Compromised password
  • Disabled
  • GPO Exposed password
  • Honeytoken
  • In learning
  • Inactive
  • Marked
  • Password never expires
  • Shared user
  • Smart card required
  • Stale
  • Watched

Note: The attribute refers both to a user and a destination but is considered a user attribute. The user is considered to have a session on a destination after they log in to the destination. The session terminates some time after the user logs off from the machine.

Yes

 Yes

Yes

User department

Filter users based on their department.

Yes

 Yes

Yes
User domain

Filter users based on their domain.

Note: This condition is only supported for exclusions.

 Yes Yes Yes

User group

Filter users based on their group.

Yes

 Yes

Yes

User name

Filter users based on their name.

Yes

 Yes

Yes

User OU

Filter users based on their organizational unit (OU).

Yes

 Yes

Yes

User privilege

Filter users based on their privileges. The following are examples of privileged users:

  • Privileged
  • Account Operator
  • Administrator
  • Backup Operator
  • Domain Admin
  • Enterprise Admin
  • Print Operator
  • Replicator
  • Schema Admin
  • Server Operator
  • Built in Administrator
  • Stealthy Administrator
  • Effective Replicator
  • Administrator Password Controller
  • Permissions on Account Controller
  • Administrative Group Controller
  • Business Privileged

Yes

 Yes

Yes

User risk severity

Adaptively filter users based on their Risk severity. Select a range covering one or more of Low, Medium, and High.

Yes

 Yes

Yes

User type

Filter users based on their type, which can be any of the following:

  • Human
  • Programmatic
  • Has authorizer

Yes

 Yes

Yes

Understand actions

The action defines what the rule does when its trigger occurs, and all its conditions are met.

For example, you might want to block the user event that triggered the rule, audit the event, or require that the user performs additional verification.

Note: Policy rules are applied in both in-line and out-of-band deployments, but in out-of-band mode, blocking by default and Fail mode do not apply.

The list of available actions are described below. Note that actions available in a rule are dependent on the trigger used.

Action Description Dependencies

Apply SSO Policy

Okta

Enables you to choose the specific SSO policy applied to the involved users, based on the SSO group policy available in the selected connector.To automatically remove the users from the policy group when the issue is closed (Auto Resolved, Resolved, Acknowledge & Trust), enable the option Unapply SSO Policy in the advanced settings.

Okta

Add to Watch List

Adds the source user to a watch list (the user is marked as watched by the system) and allows the activity to continue.

None.

Audit

Audits the activity, and allows it to continue.

None.

Block

Blocks the activity from continuing.

Requires inline sensors.

Identity Verification

Performs an MFA against the source user (or its authorizer) and based on the result it performs an Audit/Block.
  • Requires inline sensors.
  • The source endpoint must not be classified as an impersonator (unless the trigger is Application Authentication).
  • Requires an MFA connector to be selected, or select Any if you are enrolled for multiple MFA services. For more info, see MFA connectors.

Reset Password

Requires that users change their password when they next log in.

Available in rules that use the Account Event or Alert triggers.
  • Has no effect on accounts that have the Password never expires attribute enabled in Active Directory.

Manage Identity Protection rules

You can manage Identity Protection rules by adding, editing, or duplicating rules. You can also modify the order in which the rules are processed.

You can add a new policy rule from one of the templates provided, or by duplicating an existing policy rule and then editing it with your new requirements. You can also create a rule from scratch.

For more info, see Identity Protection Use Cases.

To manage Identity Protection rules programmatically, see Identity Protection Policy Rules APIs

Create Identity Protection rules

  1. Go to Identity protection > Enforce > Policy rules, and click Add Rule.

  2. In the Rule Name box, enter a name for the rule.

  3. Optionally, select a Template from the list.

    For details of the templates supplied with the application, see Use rule templates.

    The Template drop-down list shows all the predefined templates supplied with the system, as well as other user defined rules that you can use as templates for the new rule you are creating.

  4. From the Trigger drop-down list, select the event that triggers the rule.

    Note: if you selected an existing template, the trigger is determined by that template and cannot be altered.

  5. Click Next.

    The rule details open up for editing.

  6. Modify the following fields as required:

    • Rule Name: Modify the rule name, as required.

    • Action: From the Action drop-down list, select an action.

    • Connector: From the Connector drop-down list, select a connector.

    • Conditions: Modify or delete the conditions, as required. If you want to add new conditions, click Add rule condition. See Add rule conditions.

  7. In the Advanced area, configure the following fields as required. Note that the presence of advanced settings depends on which action the rule performs.

    • Simulation mode: Enable simulation mode to evaluate the effects of the policy rule without risking any disruption to network traffic.

      When Simulation mode is enabled, the Analytics audit log indicates when the policy matched, but was not actually enforced.

      For example, MFA would have been required but was not requested.

      Note: Simulation mode applies to only the policy for which you enable it. All other policy rules are unaffected.

    • Notify: Select this check box if you want to send an email notification on every rule match. To avoid email flooding, it is recommended to only use this feature on rules that are rarely expected to match. Separate multiple recipients using commas.

    • Prompt for user identification: Configure how often you want to prompt for user identification. For more info, see Session Management in the Identity Protection Policy.

      You can select from:

      • Every time

      • Once a session

      • At most once per 4 hours
      • At most once per 8 hours
      • At most once per 12 hours

      • At most once per 24 hours

      • At most once per 7 days

      • At most once per 30 days

      And apply these settings in the context of:

      • User + Source + Destination

      • User + Source

      • User

    • Fail mode: Applies to sensors in Enforcement mode, and allows you to override the default global fail mode settings. For more info, see Fail mode. To override the default settings, select Custom. You can then choose whether to Allow or Block authentication when any of these errors occurs:

      • MFA timeout: a timeout occurred when performing the MFA action

      • User Not Enrolled: could not match the user with an account enrolled with the MFA provider

      • Service Error: an unknown error occurred when attempting the MFA action, for example there may be temporary communication issues, or an internal error occurred in one of the related components. Note: we highly recommend that you set the fail mode for Service Error to Allow. This will ensure business continuity in the case of communication issues with the Falcon Cloud or with the MFA provider.

    • Enable On Screen Notification: Selected by default as this is mandatory when user interaction is required (for example, MFA method selection, one-time password input).

    • Group: Select a group of rules for your new rule, or create a new group. For example, you might want to group all your access rules together in a group.

    • Create alert on any rule match: Select if you want to create an alert, and then select the severity level at which you want to be alerted (High, Medium or Low).

  8. Click Save.

    The rule is saved, and set to Enabled.

  9. To save the changes to your identity protection policy, on the Policy rules page, click Apply All Changes.

Edit Identity Protection rules

You can view a policy’s rule details and also edit a rule by adding more conditions to the rule. You can delete conditions that you have added, but you cannot delete any default conditions, if set.

  1. On the Manage Rules tab of the Policy page, locate the rule whose details you want to edit.

  2. Select the vertical ellipsis icon to the right of a rule, and then click Edit.

    Note: You can also open the Edit Rule page by clicking Edit when you view a rule.

    The Edit Rule page appears.

  3. Modify the rule, as required. For example, add rule conditions.

  4. Click Save.

    The rule is saved, and set to Enabled.

  5. To save the changes to your identity protection policy, on the Policy rules page, click Apply All Changes.

Add rule conditions

You can add new conditions to a rule. Any condition that you add to a rule can be deleted, but you cannot delete any condition that was part of the rule's template.

To edit a policy rule by adding new conditions:

  1. On the Edit Rule page, click Add rule condition.

    A new condition is added to the rule.

  2. Click the arrow to the right of the condition to show a list of available conditions for that rule.

  3. Select the required condition.

  4. Select if you want the condition to Include or Exclude the values you are about to add in the next step.

  5. In the At least one area, click the plus icon on the right of the condition, and add the required details according to the selected condition.

  6. Click Save to save the rule.

    The rule is saved, and set to Enabled.

  7. To save the changes to your identity protection policy, on the Policy rules page, click Apply All Changes.

Delete Identity Protection rules

  1. On the Policy rules page, locate the rule to delete.

  2. Select the vertical ellipsis icon to the right of a rule, and then click Delete.

  3. To save the changes to your identity protection policy, on the Policy rules page, click Apply All Changes.

Duplicate a policy rule

You can copy a policy rule and then modify the copy to create a slightly different rule.

  1. On the Policy rules page, locate the rule whose details you want to duplicate.

  2. Select the vertical ellipsis icon to the right of a rule, and then click Duplicate above or Duplicate below.

    The rule is duplicated and placed above or below the rule you duplicated.

  3. If you want to edit the duplicated rule, select the vertical ellipsis icon to the right of a rule, and then click Edit.

  4. To save the changes to your identity protection policy, on the Policy rules page, click Apply All Changes.

Re-order policy rules

Policy rules are evaluated in the order in which they appear in the Manage Rules tab, from top to bottom.

If you have organized the policy rules into groups, they are evaluated in the order in which the groups appear on the page. Policy rules within the group are evaluated in the order in which they appear in the group.

You can intersperse policies and groups on the page, but the underlying evaluation process remains that policy rules are evaluated from top to bottom (including through groups).

If there are multiple rules with the same trigger, the first rule whose conditions are met is invoked and the others are skipped.

For example, suppose Rule A applies to all users with action "Block" and Rule B applies only to a specific user group with action "Identity Verification", if the connection belongs to that specific user group:

  • If Rule A is first, then it is invoked and the user is blocked. Rule B is skipped.

  • If Rule B is first, then it is invoked and the user is challenged with MFA. Rule A is skipped.

The following procedure specifically describes how to change the order of policy rules in the Manage Rules tab. The same procedure should be applied if you want to change the order of groups on the page and policies within each group.

To move a rule/group to a new position in the list:

  1. On the Policy rules page, locate the policy rule you want to move.

  2. Drag and drop the rule into the new position in the list.

  3. To save the changes to your identity protection policy, on the Policy rules page, click Apply All Changes.

Tip: You can move a rule to the top or bottom of the rule list by selecting the vertical ellipsis icon to the right of a rule, and then clicking Move to top or Move to bottom, as required.
Check distribution of policy rules

You can see details of which of your DC servers have been updated with the changes you make to policy rules, and when.

To view the details of policy rule distribution:

  1. Go to Identity protection > Enforce > Policy rules.

  2. In Rule Distribution, click View Distribution Status.

  3. In the DC Servers panel you can:

    • Sort a column by clicking the heading.

    • View details of a domain controller by clicking its name.

    • Export the results to a comma-separated file by clicking CSV.

    • View the exact time a domain controller was updated by hovering over the Date Applied value.

Configure multi-factor authentication (MFA)

Falcon Identity Protection allows you to enforce MFA as part of your policy rules. You can apply MFA to a number of different triggers, allowing risk-based step-up authentication scenarios.

Important: In order to support enforcement (block, MFA) using the Identity Protection policy for Remote desktop (RDP) to DC, Network Level Authentication (NLA) must be enabled on the domain controllers.

To enable MFA in a policy rule, you must meet these requirements:

  • Have at least one MFA connector configured in Falcon Identity Protection.

  • Have sensors installed on all Domain Controllers in the domain.

  • Have all sensors in Inline mode.

Note: To enable on-screen notifications (including entering one-time passwords) install the Falcon Identity Verification Dialog. For more information, see Set up the Falcon Identity Verification Dialog.

If you’re integrating with Falcon for Mobile to use FalconID for MFA, see FalconID for setup and configuration instructions.

Verify identity by using MFA

Create an Identity Protection policy rule that enforces MFA.

  1. In the Falcon console, go to Identity protection > Enforce > Policy rules , and click Add Rule.

  2. Provide a Rule Name.

  3. From the Trigger menu, select a trigger, and then click Next.

  4. From the Action menu, select Identity Verification.

  5. From the Connector menu, select the MFA connector to use.

    If you select Any, the user is presented with the identity verification dialog, allowing them to choose which of the configured connectors to use for MFA:


    Offering the user a list of enabled MFA options they can use.

  6. Configure the remainder of the policy rule as required, and then click Save.

Delegate MFA to an external Federation integration

Falcon Identity Protection allows external integration applications such as PingFederate to enforce and manage MFA based on Identity Verification recommendations that the CrowdStrike Adapter provides.

To delegate enforcement of MFA you must:

  • Define a policy rule in Falcon Identity Protection to respond to a Federated Access trigger, and return the recommendation to the external integration.

  • Configure an authentication policy in the integrated external application to handle the possible results.

The identity verification results that a CrowdStrike Adapter can provide and the recommended follow up actions are:

Identity Verification Result Description Recommended Action

Fail

An error occurred.

Block

Approve

The CrowdStrike engine suggests allowing access.

Allow

Deny

The CrowdStrike engine suggests blocking the log-in.

Block

Review

The CrowdStrike engine suggests additional scrutiny before providing approval or denial.

Confirm identity using MFA
Define an Identity Protection policy rule that responds to a Federated Access trigger:

  1. In the Falcon console, go to Identity protection > Enforce > Policy rules, and click Add Rule.

  2. Set a meaningful name in the Rule Name text field.

  3. From the Template drop-down menu select None.

  4. From the Trigger drop-down menu select Federated access and then click Next.

  5. From the Action drop-down menu select Identity Verification.

  6. From the Enforced by drop-down menu select External.

  7. Add any conditions for which the rule is enacted and then click Save.

You are now ready to create an authentication rule in your integrated external application to handle the possible results provided by Falcon. For an example, see Configuring PingFederate integration.

Configure policy settings

You can set Falcon Identity Protection to determine the action to take when the primary authentication is successful but the MFA provider is unreachable or the action has timed out.

Tip: For info about how policies work, including host group assignment and policy precedence, see Policies in Falcon.
Settings distribution

You can see details of which of your DC servers have been updated with the changes you make to policy settings, and when.

To view the details of policy settings distribution:

  1. Go to Identity protection > Configure > Policy settings.

  2. In Settings Distribution, click View Distribution Status.

  3. In the DC Servers panel you can:

    • Sort a column by clicking the heading.

    • View details of a domain controller by clicking its name.

    • Export the results to a comma-separated file by clicking CSV.

    • View the exact time a domain controller was updated by hovering over the Date Applied value.

The Settings tab on the Policy page enables you to set the following global rule settings:

  • Fail mode: Defines the actions that Falcon Identity Protection takes when the MFA provider produces errors.

  • Fallback Identity Verification Connector: Enables you to select a connector that supports the Push method. This connector is used as a fallback in case the on-screen notification cannot be displayed or is manually terminated.

  • MFA UI Fallback Timeout: Enables you to set the period of time in which users can respond to the MFA UI before it times out.

Fail mode

Fail mode applies to inline sensors and is the action that Falcon Identity Protection must take when the primary authentication is successful but an error occurs.

You can choose whether to allow or block authentication when any of these errors occurs:

  • MFA timeout: a timeout occurred when performing the MFA action

  • User Or Authorizer Not Enrolled: could not match the user or authorizer with an account enrolled with the MFA provider

  • Service Error: an unknown error occurred when attempting the MFA action, for example there may be temporary communication issues, or an internal error occurred in one of the related components.

    Examples of service errors includes:

    • Communication problems between Identity Protection and the MFA provider

    • Communication problems between the Falcon sensor and the CrowdStrike Cloud. Check that your deployment meets the Networking requirements. For more info, see Networking requirements.

    • Internal errors in the MFA provider. Check the service status of the provider.

    • Internal errors in the Falcon sensor

    • Internal errors in the CrowdStrike Cloud

    Note: We highly recommend that you set the fail mode for Service Error to Allow. This will ensure business continuity in the case of communication issues with the Falcon Cloud or with the MFA provider.

To set the global fail mode for each error type:

  1. In the Falcon console, go to Identity protection > Enforce > Policy settings.

  2. Select Allow or Block independently for each MFA action

  3. Click Apply to save your selection.

You can also specify the fail mode in individual policy rules. The fail mode specified in a rule overrides the global settings above. For information on creating policy rules, see Manage Identity Protection rules.

Fallback identity verification connector

In case the on-screen notification cannot be displayed for some reason (for example, unsupported operating system, or incorrect version of Internet Explorer) or is manually terminated, a connector that supports the Push method can be used for identity verification. To define such a connector, use the Fallback Identity Verification Connector drop-down list. The default setting is None.

Note: To be able to show on-screen notifications, your computer must have Internet Explorer 9 or above.

If you are enrolled for more than one authentication method, you are asked which authentication method you want to use. In order for the fallback identity verification connector to work, you must select Any.

MFA UI Fallback Timeout

The MFA UI Fallback Timeout provides you with the capability to refine the period of time that a user has to respond when prompted for input by the Falcon Identity Verification Dialog. The MFA UI Fallback Timeout period is measured in terms of Seconds and has the following limits:

  • Minimum value = 10 seconds

  • Maximum value = 90 seconds

To set the MFA UI Fallback Timeout period:

  1. In the Falcon console, go to Identity protection > Enforce > Policy settings.

  2. Enter a value in the MFA UI Fallback Timeout text box.

  3. Click Save.

View policy analytics

Every rule is logged to the Analytics tab. By default, only matched rules are shown. You can show the unmatched rules by clicking Show Unmatched Rules (located at the top right of the page).

The Analytics tab includes the following sections:

  • The top section lists the matched rules for the selected time period (selected at the top right of the page). By default, details of all matched rules are listed in the lower section of the page. If you click one of the matched rules in the top section of the page, the details for that rule are displayed in the lower section.

  • The middle section of the page enables you to filter the matched rule details that appear in the lower section of the page.

    Click a link in this area to expose other filter options.

    Click any link in this area to only display the matched rule details for that filter item.

  • The lower section lists details of the matched rules. By default, details of all matched rules are listed, however, you can filter this list as described above. You can download a CSV version of this section by clicking the CSV link.

  • If there are events related to an event in the list, the Show Related Events icon appears when you move your cursor over the event list. Click the Show Related Events icon to display a list of the related events.

You can download the list of related events, by clicking the CSV link.

Tip: Click the Filter icon to open the Threat Hunter page and filter your results.

Use rule templates

You can create rules from two types of templates:

  • Predefined: Represent the most common and recommended scenarios for you to adopt.

  • User defined: Represent existing rules that you can use as a template to create a new rule.

When you first use Falcon Identity Protection there are no user defined templates. After a rule is created and saved, it appears in the User Defined in the Templates list and you can then use it as a template for a new rule.

Each template includes a preset trigger that you cannot change, and conditions that you can change according to your requirements. These predefined triggers cover most access and authentication scenarios and use cases.

The following lists the predefined rule templates. User or Endpoint attributes and roles are predefined according to the rule preset and cannot be changed, added, or removed.

Anomalous authentication

Detects a deviation from the user profile. The rule matches when an account is authenticated to an endpoint not previously associated (regularly used or owned) with the user.

Used to detect when an account is compromised and used on a new endpoint not previously associated with the account. The account owner can be prompted to approve the activity through a push MFA, email, or other methods or blocked.

Trigger: Access

Conditions:

  • Access type: Include "Authentication"

  • Baseline: Exclude "User regularly uses source endpoint"

  • Source: Exclude "VDI Endpoint"

  • Protocol: Include "NTLM" or "Kerberos"

  • User type: Include "Human" or "Has authorizer"

  • User Attribute: Exclude "In learning"

  • Source Attribute: Exclude "Impersonator"

Action: Identity Verification

Anomalous geographic login to Federated applications

Enforces MFA for accounts that log in to Federated applications from an irregular location.

Trigger: Federated Access

Conditions:

  • Baseline: Exclude "User regularly connects from this location"

  • User attribute: Exclude "In learning"

  • User type: Include "Human" or "Has authorizer"

Action: Identity verification (Fail mode set to Block)

Note: Enable On Screen Notification must be enabled.

Application authentication

Enables you to add second factor authentication to any internal corporate application without changes to the application.

For example, you have legacy or home-grown applications that cannot be re-coded to add MFA. You can add MFA when users login without having to make changes to those applications.

Trigger: Access

Conditions:

  • Source name: Required

  • Access type: Include "Authentication"

  • User type: Include "Human" or "Has authorizer"

Action: Identity verification

Block honeytoken activity

Restrict and block all operations from an account that is flagged as honeytoken. Use this template if you flagged honeytoken accounts and you want to ensure no usage of them.

Trigger: Access

Conditions:

  • User attribute: Includes At least one "Honeytoken"

Action: Block

Compromised password detected

Detects passwords that are compromised and requires the user to change the password when they next log in.

Note: The reset password action has no effect on users who have the Password never expires attribute enabled in Active Directory.

You must enable compromised password detection for this rule to function.

Trigger: Account Event

Conditions:

  • Event type: Includes "Compromised password"

  • User type: Includes "Human"

  • User attribute: Excludes "Password never expires"

Action: Reset Password

Inactive user access

Enforces second factor authentication for user accounts that haven’t been used for over 21 days.

For example, a user has been on extended leave but their account is taken over by a rogue user. The account owner or an authorizer can be notified in real time or the activity can be blocked.

Trigger: Access

Conditions:

  • User attribute: Include "Inactive"

  • User type: Include "Human"

  • Source attribute: Excludes "Impersonator"

Action: Identity verification (Fail Mode set to Block)

Privileged user protection from compromised password

Enforces MFA for privileged accounts that use compromised passwords.

Trigger: Access

Conditions:

  • User attribute: include "Compromised password"

  • User privilege: Include "Privileged"

  • User type: Include "Human" or "Has authorizer"

  • Source attribute: Exclude "Impersonator"

Action: Identity verification (Fail mode set to Block)

Note: Enable On Screen Notification must be enabled.

Privileged user secured authentication

Enforces Multi-Factor Authentication for privileged accounts that use the LDAP protocol for authentication. The rule is not enforced when the LDAPS protocol is used.

Trigger: Access

Conditions:

  • User privilege: Include "Privileged"

  • Protocol: Include "LDAP"

  • User type: Include "Human" or "Has authorizer"

  • Source attribute: Exclude "Impersonator"

  • Action: Identity verification (Fail mode set to Block)

Note: Enable On Screen Notification must be enabled.

Privileged users access control

Enables you to control the actions that take place when Privileged Users authenticate or access services on endpoints.

Use this template if you want to strengthen Privileged Users Access Management by adding an additional factor to any authentication of a privileged user.

Trigger: Access

Conditions:

  • User privilege: Include "Privileged"

  • Baseline: Exclude "User owns source endpoint"

  • Protocol: Include "NTLM" or "Kerberos"

  • User attribute: Exclude "In learning"

  • User type: Include "Human" or "Has authorizer"

  • Source attribute: Excludes "Impersonator"

Action: Identity verification

Restrict RDP (programmatic)

Restrict and block Microsoft Remote Desktop operations from an account that is programmatic; for example, a service account.

Trigger: Access

Conditions:

  • Access type: Include "Remote desktop (RDP)"

  • User type: Include "Programmatic"

  • Protocol: Include "NTLM" or "Kerberos"

Action: Block

Restrict workstation authentication (admins)

Helps to enforce best practices where you do not want privileged users' account credentials to be used on workstations that by their nature are more exposed than servers. Servers contain or reduce the level of threat to be revealed or taken over by attacks, such as pass the hash.

Use this template to require that administrators use their credentials on servers only, and prevent administrators from using their privileged account credentials on workstations, as workstations are more prone to malware that can take over their credentials from the system memory or by using a keylogger.

Trigger: Access

Conditions:

  • User privilege: Include "Privileged"

  • User type: Include "Human"

  • Source: Include "Workstation"

  • Baseline: Exclude "User owns the source endpoint"

  • User attribute: Exclude "In learning"

Action: Block

Identity Protection in Fusion SOAR

Create workflows so Falcon automatically takes steps in response to detections and to updates made by users.

Overview

Falcon Identity Protection monitors network traffic to build user behavioral profiles to help identify unusual user behavior. It enables frictionless Zero Trust security with real-time threat prevention and IT policy enforcement through the use of identity, behavioral, and risk analytics. Identity Protection data is available to use with Fusion SOAR workflow triggers, conditions, actions. You can create workflows so Falcon automatically takes steps in response to detections and to updates made by users. For example, you can set workflows to send email notifications or contain source endpoints with Falcon sensors.

For more info, see Identity Protection Overview or Fusion SOAR.

This document shows how to create workflows that use Identity Detection triggers and actions.

Create a workflow based on an Identity Detection trigger

You can set up automated actions that are triggered by identity detections.

Requirements

  • Subscriptions:

    • Falcon Identity Threat Detection or Falcon Identity Threat Protection

  • Roles:

    • Falcon Administrator

    • Workflow Author

Steps

  1. Go to Fusion SOAR > Fusion SOAR > Workflows .

  2. Click Create workflow.

  3. Click Create workflow from scratch and then click Next.

  4. In the Add trigger panel, search for identity.

  5. From the Top results list or the lists after those results, select Detection > Identity Detection.

  6. Click Next.

  7. Optional. In the Add next panel or on the workflow canvas, select Condition icon.

    Select any identity-based detection detail as the condition.

  8. In the Add next panel or on the workflow canvas, select Action icon.

  9. Define the action as desired and click Next.

  10. Click Save and exit.

    • Enter a name for the workflow.
    • Optional. Enter a description for the workflow.
    • Set Status to On.

  11. Click Save and exit.

Create a workflow to send email notifications about identity detections

You can set email notifications for non-information detections and privileged escalations using a workflow playbook. When you customize the playbook, you can send email to different people and include different info depending on the nature of the detection.

Requirements

  • Subscriptions:

    • Falcon Identity Threat Detection or Falcon Identity Threat Protection

  • Roles:

    • Falcon Administrator

    • Workflow Author

Steps

  1. Go to Fusion SOAR > Fusion SOAR > Workflows .

  2. Click Create workflow.

  3. In the Workflow Playbooks section, select the Identity detections email notification playbook, and then click Next.

  4. Click Customize playbook.

    1. Set up emails about non-information detections.

      1. In the Recipients field, specify the email addresses you want to receive emails about the detections.

      2. Optional. In the Data to include field, add or remove data to be sent in the emails.

      3. Click Next.

    2. Set up emails about detections with privilege escalations.

      1. In the Recipients field, specify the email addresses you want to receive emails about the detections.

      2. Optional. In the Data to include field, add or remove data to be sent in the emails.

      3. Click Update playbook.

  5. Click Save and exit.

    • Enter a name for the workflow.
    • Optional. Enter a description for the workflow.
    • Set Status to On.

  6. Click Save and exit.

Create workflows to enforce MFA for users and endpoints involved in EPP detections

You can combine Identity Protection policy rules with Fusion SOAR workflows to increase security. For example, you can add users and endpoints involved in endpoint protection, or EPP, detections to the Identity Protection watchlist and require that they perform multi-factor authentication until the detection is marked as resolved.

Requirements

  • Subscriptions:

    • Falcon Identity Threat Protection

    • Falcon Prevent or Falcon Insight XDR

  • Roles:

    • These roles can create Falcon Identity Protection policy rules:

      • Falcon Administrator

      • Identity Protection Policy Manager

    • These roles have access to Fusion SOAR:

      • Falcon Administrator

      • Workflow Author

Procedure overview
Step 1: Create a Fusion SOAR workflow to add users and endpoints involved in detections to the Identity Protection watchlist

  1. Go to Fusion SOAR > Fusion SOAR > Workflows .

  2. Click Create workflow.

  3. Click Create workflow from scratch and then Next.

  4. In the Add trigger panel, search for epp detection.

  5. From the Top results list or the lists after those results, select Detection > EPP Detection.

  6. Click Next.

    The trigger appears on the workflow canvas.

  7. In the Add next panel or on the workflow canvas, select Sequential Action icon.

  8. In the Add action panel, search for and select the action Add endpoint to watchlist, and then click Next.

  9. Hover over the trigger, click icon, and select Parallel Action icon

  10. In the Add action panel, search for and select the action Add user to watchlist, and then click Next.

  11. Click Save and exit.

    • Enter a name for the workflow.
    • Optional. Enter a description for the workflow.
    • Set Status to On.

  12. Click Save and exit.

    The completed workflow resembles the following:


    Completed workflow to add users to the IDP watchlist.
Tip: To view a list of users on the Identity Protection watchlist, go to Identity protection > Monitor > Users, and then click Watched Users.
Step 2: Create a second workflow to remove users and endpoints from the Identity Protection watchlist when the detection is resolved

  1. Go to Fusion SOAR > Fusion SOAR > Workflows .

  2. Click Create workflow.

    1. Click Create workflow from scratch and then Next.

    2. In the Add trigger panel, search for audit event endpoint.

    3. From the Top results list or the lists after those results, select Audit event > Endpoint detection > Status.

    4. Click Next.

      The Audit event trigger appears on the workflow canvas.

  3. In the Add next panel or on the workflow canvas, select Condition icon.

    1. In Parameter, select Target status.

    2. In Operator, select is equal to.

    3. In Value, select Closed.

    4. Click Next and then Next again.

  4. In the Add next panel or on the workflow canvas, select Action icon.

    1. In the Add action panel, search for and select the action Remove endpoint from watchlist.

    2. Click Next.

  5. Hover over TRUE, click icon, and select Parallel Action icon
  6. In the Add action panel, search for and select the action Remove user from watchlist, and then click Next.

  7. Click Save and exit.

    • Enter a name for the workflow.
    • Optional. Enter a description for the workflow.
    • Set Status to On.

  8. Click Save and exit.

    The completed workflow resembles the following:


    Completed workflow to remove user from IDP watchlist
Tip: To view a list of endpoints on the Identity Protection watchlist, go to Identity protection > Monitor > Custom insights. Click the filter icon and set Attributes to include Watched, and Account Type to include Endpoint, and then click Apply.
Step 3: Create Identity Protection policy rule to enforce MFA for watched users

  1. Go to Identity protection > Enforce > Policy rules .

  2. Click Add Rule.

    1. Enter a meaningful rule name.

    2. In Template, select None.

    3. In Trigger, select Access.

    4. Click Next.

  3. In Action, select Identity Verification.

  4. Click Add rule condition.

    1. In Select condition type, select User attribute.

    2. Click the plus icon, and select Watched.

  5. Click Add rule condition again.

    1. In Select condition type, select User type.

    2. Click the plus icon, and select Human.

    3. Click the plus icon again, and select Has authorizer.

  6. Click Add rule condition a third time.

    1. In Select condition type, select Access type.

    2. Click the plus icon, and select Authentication.

  7. Optional. Add any additional conditions you might require. See Managing identity protection rules.

    The completed rule resembles the following:


    Policy to enforce MFA for watched users.

  8. Click Save.

    The new rule is listed on the Manage Rules tab.

  9. Click Apply All Changes.

Step 4: Create an Identity Protection policy rule to enforce MFA for watched endpoints

  1. Go to Identity protection > Enforce > Policy rules.

  2. Click Add Rule.

    1. Enter a meaningful rule name.

    2. In Template, select None.

    3. In Trigger, select Access.

    4. Click Next.

  3. In Action, select Identity Verification.

  4. Click Add rule condition.

    1. In Select condition type, select Source attribute.

    2. Click the plus icon, and select Watched.

  5. Click Add rule condition again.

    1. In Select condition type, select User type.

    2. Click the plus icon, and select Human.

    3. Click the plus icon again, and select Has authorizer.

  6. Click Add rule condition a third time.

    1. In Select condition type, select Access type.

    2. Click the plus icon, and select Authentication.

  7. Click Add rule condition a fourth time.

    1. In Select condition type, select Source attribute.

    2. Change the include value to exclude.

    3. Click the plus icon, and select Impersonator.

  8. Optional. Add any additional conditions you might require. See Managing identity protection rules.

    The completed rule resembles the following:


    Policy to enforce MFA from watched endpoints.

  9. Click Save. The new rule is listed on the Manage Rules tab.

  10. Click Apply All Changes.

Create a workflow to enforce MFA when an alert is triggered

You can create a workflow to send a multi-factor authentication prompt to users when an alert is triggered. You can also add a condition that targets the workflow to a specific technique.

Requirements

  • Subscriptions:
    • Falcon Identity Threat Protection
    • Falcon Next-Gen SIEM or Falcon Prevent or Falcon Insight XDR
  • Roles:
    • Falcon Administrator
    • Identity Protection Policy Manager
Steps

  1. Go to Fusion SOAR > Fusion SOAR > Workflows .
  2. Click Create workflow.
  3. Click Create workflow from scratch and then click Next.
  4. Click Event and then click Next.
  5. In the Add trigger panel, search for and select Detection > EPP Detection.
  6. Click Next.
  7. In the Add next panel or on the workflow canvas, select Condition icon.
    1. In Parameter, select Technique.
    2. In Operator, select is equal to.
    3. In Value, enter Process Injection.
      Note: You can enter any technique that you want to trigger an MFA for the user or any condition that you want to limit the MFA scope.
    4. Click Next, and then click Next again.
  8. In the Add next panel or on the workflow canvas, select Action icon.
  9. In the Add action panel, search for and select the MFA challenge action.
    1. In User object SID, select User ID.
    2. Optional. In Message, enter the message that will be displayed in the MFA user prompt.
    3. Click Next.
  10. Click Settings .
  11. In the Workflow details panel, enter a Name for the workflow.
  12. Optional. Enter a Description for the workflow.
  13. Click Publish, and then click Publish workflow.
  14. To enable the workflow, set the Status to On.

The completed workflow resembles the following:MFA challenge workflow

Create a workflow to enrich detections with Identity context

You can use information available in Identity Protection as conditions for workflows triggered by detections. This can help you create a more precise automatic response with more confidence based on involved entities' identities.

Requirements
  • Subscriptions:
    • Falcon Identity Threat Detection or Falcon Identity Threat Protection
    • Falcon Prevent or Falcon Insight XDR
  • Roles:
    • Falcon Administrator
    • Workflow Author
Steps
  1. Go to Fusion SOAR > Fusion SOAR > Workflows .
  2. Click Create workflow.
  3. Click Create workflow from scratch and then click Next.

  4. In the Add trigger panel, search for identity.

  5. From the Top results list or the lists after those results, select Detection > Identity Detection.

  6. Click Next.

  7. In the Add next panel or on the workflow canvas, select Action icon.

    1. In the Add action panel, search for and select the Get user identity context action.
    2. In the User name field, select User name.
    3. Click Next.

  8. In the Add next panel or on the workflow canvas, select Action icon.

    1. In the Add action panel, search for and select the Get endpoint identity context action.
    2. In the Endpoint object GUID field, select Source endpoint object GUID.
      Note: You can use different fields based on your trigger data. For example, configure Sensor ID for an Endpoint detection trigger.
    3. Click Next.

  9. Select Condition icon.

    1. In the Condition panel, enter the following details:
      • Parameter: select Endpoint classification
      • Operator: select includes
      • Value: select Server
    2. Click Next.
  10. To add another condition for the involved user, click Add condition line.
    1. In the Condition section, enter the following details:
      • Parameter: select User privileges
      • Operator: select includes
      • Value: select Administrator
    2. Click Next.
  11. To add a third condition for the involved user, click Add condition line again.
    1. In the Condition section, enter the following details:
      • Parameter: select User risk severity
      • Operator: select includes
      • Value: select High
    2. Click Next.
  12. Click Next.

  13. In the Add next panel or on the workflow canvas, select Action icon.

    Note: You can select different actions based on your use case. This example adds the user and the endpoint to the watch list.
    1. In the Add action panel, search for and select the Add endpoint to watchlist action.
    2. In the Endpoint ID field, select Source endpoint object GUID.
    3. Click Next.

  14. Hover over TRUE, click icon, and then select Parallel Action icon.

    1. In the Add action panel, search for and select the Reset Active Directory password action.
    2. In the User GUID field, select User object GUID.
    3. In the User domain field, select AD domain.
    4. Click Next.

  15. Click Save and exit.

    • Enter a name for the workflow.
    • Optional. Enter a description for the workflow.
    • Set Status to On.
  16. Click Save and exit.

    The completed workflow resembles the following:Enricher and reset password workflow

Create a workflow to revoke Entra and Okta sessions and Entra tokens

You can revoke Entra ID refresh tokens and sign in sessions, as well as revoke Okta sessions, when Identity Protection triggers a new detection with medium or higher severity.

Requirements
  • Subscriptions:
    • Falcon Identity Threat Protection
  • Roles:
    • Falcon Administrator
    • Workflow Author
  • CrowdStrike Store plugin:
    • Microsoft Entra ID SOAR Actions plugin
      Note: For more info, see Integrate with Microsoft Entra ID.
    • Okta SOAR Actions plugin
      Note: For more info, see Integrate with Okta for response actions.
Steps
  1. Go to Fusion SOAR > Fusion SOAR > Workflows .
  2. Click Create workflow.
  3. Click Create workflow from scratch and then click Next.

  4. In the Add trigger panel, search for identity.

  5. From the Top results list or the lists after those results, select Detection > Identity Detection.

  6. Click Next.

  7. In the Add next panel or on the workflow canvas, select Condition icon.
    1. In the Parameter field, select Severity.
    2. In the Operator field, select is greater than.
    3. In the Value field, select Low.
    4. Click Next, and then click Next again.

  8. In the Add next panel or on the workflow canvas, select Action icon.

    1. In the Add action panel, search for and select the Get user identity context action.
    2. In the User object SID field, select User object SID.
    3. In the User name field, select User name.
    4. Click Next.

  9. In the Add next panel or on the workflow canvas, select Condition icon.

    1. In the Parameter field, select User Entra Object ID from the Get user identity context section of the list.
    2. In the Operator field, select exists.
    3. Click Next, and then click Next again.

  10. In the Add next panel or on the workflow canvas, select Action icon.

    1. In the Add action panel, search for refresh and select the Entra ID - Revoke Existing Refresh Tokens action.
      Note: The CrowdStrike Store Microsoft Entra ID SOAR Actions plugin must be configured for this action to appear. For more info, see Integrate with Microsoft Entra ID.
    2. In the Config field, select the configuration name that you entered during the Microsoft Entra ID SOAR Actions plugin configuration.
    3. In the Entra User ID field, select User Entra Object ID from the Get user identity context section of the list.
    4. Click Next.

  11. In the Add next panel or on the workflow canvas, select Action icon.

    1. In the Add action panel, search for and select the Add comment to detection action.
    2. In the Comment field, enter the note that you want Falcon to add to the detection when the action was successful. For example, “Existing refresh tokens have been revoked”.
    3. Click Next.

  12. Hover over the last TRUE, click icon, and then select Parallel action icon.

    1. In the Add action panel, search for sign-in and select the Entra ID - Revoke Existing Sign-in Sessions action.
      Note: The CrowdStrike Store Microsoft Entra ID SOAR Actions plugin must be configured in order for this action to appear. For more info, see Integrate with Microsoft Entra ID.
    2. In the Config field, select the configuration name that you entered during the Microsoft Entra ID SOAR Actions plugin configuration.
    3. In the Entra User ID, select User Entra Object ID from the Get user identity context section of the list.
    4. Click Next.

  13. In the Add next panel or on the workflow canvas, select Action icon.

    1. In the Add action panel, search for and select the Add comment to detection action.
    2. In the Comment field, enter the note that you want Falcon to add to the detection when the action was successful. For example, “Existing Entra refresh tokens have been revoked”.
    3. Click Next.
  14. If there are also Okta accounts in your environment, hover over the last condition added, click icon, and then select Else, If Condition icon.
    1. In the Parameter field, select User Okta Object ID from the Get user identity context section of the list.
    2. In the Operator field, select exists.
    3. Click Next, and then click Next again.
    4. In the Add next panel or on the workflow canvas, select Action icon.
      1. In the Add action panel, search for and select the Add comment to detection action.
      2. In the Comment field, enter the note that you want Falcon to add to the detection when the action was successful. For example, “Okta sessions have been revoked”.
      3. Click Next.

  15. Click Save and exit.

    • Enter a name for the workflow.
    • Optional. Enter a description for the workflow.
    • Set Status to On.
  16. Click Save and exit.

    The completed workflow resembles the following:Entra Okta workflow

Falcon Privileged Access

Falcon Privileged Access Overview

Eliminate standing privileges and stop identity-based attacks by enforcing just-in-time access across hybrid environments.

Overview

Just-in-time (JIT) access allows you to manage the entire permission lifecycle by ensuring that users only have access to the permissions they need, for only as long as required, if the user and device remain within the configured parameters of risk. Adopting JIT is an important step in working towards an environment with zero standing privileges, which significantly reduces the identity attack surface and the ability of adversaries to gain privileged access. Falcon Privileged Access JIT supports the following permission types:
  • Entra ID
  • Active Directory (AD) groups

Requirements

  • Subscriptions: Falcon Identity Threat Protection and Falcon Privileged Access
  • System requirements:
    • Entra tenant with P1 or higher license
    • An existing Entra ID IDAAS connector. For more info, see ​​Microsoft Entra ID (entity and activity ingestion)
    • At least one configured JIT trigger:
      • Microsoft Teams trigger: For more info, see Teams trigger requirements
        • A configured Falcon Privileged Access Teams Bot in the CrowdStrike Store
        • For source endpoint conditions (device trust), you need the CrowdStrike browser extension
      • Entra EAM trigger: For more info, see Entra EAM trigger requirements
        • An Entra ID external authentication method (EAM) OIDC integration
        • For source endpoint conditions (device trust), you need the CrowdStrike browser extension
    • To grant Entra ID JIT privileges, you need an existing Microsoft Entra ID SOAR Actions app. For more info, see Just-in-Time Access for Entra ID
    • To grant Active Directory (AD) privileges, you need the Falcon sensor installed on the relevant domain controllers. For more info, see Just-in-Time Access for AD Groups
  • Default roles: Falcon Administrator, Privileged Access Administrator, Privileged Access JIT Policy Manager
  • CrowdStrike clouds: Available in US-1, US-2, and EU-1

Understanding JIT

Falcon Privileged Access delivers real-time, risk-based privileged access control across hybrid environments without requiring manual onboarding of identities or resources. To view all of your JIT policies, go to Privileged access > Just-in-Time access > Policies.

JIT triggers

You can configure your environment to allow end users to submit JIT permission requests through different interfaces or triggers. All of your JIT policies automatically include all of the triggers that you have configured in your environment. The following JIT request triggers are supported:

Microsoft Teams trigger

The Teams trigger allows end users to submit JIT permission requests in Teams by clicking Request permission in the Permission Request bot or view current permissions by clicking List current permissions. Teams displays a notification to end users when permissions are granted or revoked.

The Teams bot also allows end users to self-revoke JIT permissions before the permission duration is reached, if they already completed the task that required elevated permissions.

By default, end users will get notifications when permissions are granted, revoked, and 5 minutes before permissions are revoked. If you would like to turn off the notifications end users get 5 minutes before permissions are revoked, go to Privileged access > Just-in-Time access > Settings.

Teams trigger requirements

To add Teams as a trigger for your end users, you must complete the following requirements:

  • Configure the Falcon Privileged Access Teams Bot in the CrowdStrike Store. Follow the instructions listed in the Falcon Privileged Access Teams Bot.
    Important: If you have multiple Teams tenants, you must configure a separate bot for each tenant.
  • To support source endpoint conditions (device trust), you must also set up the Falcon browser extension on end user devices by following these steps:
    1. In the Falcon console, go to Host setup and management > Manage endpoints > Browser extension policies .
    2. Make sure you have a policy with Enable automatic installation selected. For more info, see Falcon Browser Extension.
Entra EAM trigger

JIT allows end users to assume eligible permissions as part of the Entra EAM login process when they log in through the external authentication method (EAM) integration, following the initial authentication.

Note: If the user is not eligible for any permissions, they will not be prompted by JIT during Entra EAM login.

Entra EAM trigger requirements

To add Entra EAM as a trigger for your end users, you must complete the following requirements:

  • Configure an Entra ID external authentication method (EAM) OIDC integration in Falcon. For more info, see Entra ID EAM
  • To support source endpoint conditions (device trust), you must also set up the CrowdStrike browser extension on end user devices by following these steps:
    1. In the Falcon console, go to Host setup and management > Manage endpoints > Browser extension policies .
    2. Make sure you have a policy with Enable automatic installation selected. For more info, see Falcon Browser Extension.
JIT end user experience

You can configure each JIT policy to provide the appropriate end user experience.

Automatic JIT policy user experience

At Microsoft EAM login, users governed by an automatic JIT policy are automatically granted all of the permissions that they are eligible for. In Teams, the user is granted the permissions that they are eligible for when they click Request permissions.

By-request JIT policy user experience
Users governed by a by-request JIT policy must submit a permission request form to be granted the selected permissions. You can configure the by-request policy to modify the permission request form that end users will see every time they request permission(s):
  • Allow user to choose less time: Adds a field to the elevation request form that lets users specify a shorter amount of time they will be granted the permission than the Maximum permissions duration of the policy.
  • Require justification: Adds a free-form field to the elevation request form in which the user must enter the reason they need the permission(s). The text they enter in the field is available in the JIT event in the JIT Audit Event Log. For more info, see View JIT audit events.

Authorizer JIT requests

Users that don’t have a Teams account, for example AD-only accounts or shared accounts, can also have permissions requested for them by an authorized user. The authorized user must use the Teams trigger to request permissions for another user. The authorizer also chooses the duration the permissions will last.

The JIT request interface displays only the users for which the authorizer has been configured. For more info about authorizer configuration, see Authorizers.

MFA user experience

You can configure any JIT policy to require that the end user completes MFA before the requested permissions are granted by selecting Identity was verified with MFA in the Workflow settings section while creating or editing policy.

By default, end users will be prompted with MFA as part of the JIT flow. The end user can select any MFA connector that you have configured in your environment. To view your list of configured connectors, go to Identity protection > Configure > Connectors .

Fail mode and fallback are set to default in JIT MFA. To configure your default, go to Identity protection > Enforce > Policy settings . For more info, see Configure policy settings..
Important: If an end user is already governed by an Identity verification policy rule, they will not be prompted with MFA by JIT a second time.
Permission sets

Permission sets allow you to seamlessly grant users all of the permissions needed for a given responsibility. This removes the need for the end user to know which permissions are necessary to complete their tasks.

After you define permission sets in the policy wizard that group the technical permissions needed for specific business tasks, end users can select from clearly named permission sets during elevation requests, without needing to understand underlying technical requirements. Users can also request multiple permission sets if their workflow requires it.

For example, instead of users needing to know they require the Entra ID roles User Administrator, Groups Administrator, and Directory Readers to onboard a new employee, they can simply select an Employee Onboarding permission set that contains all these roles. The user focuses on their business need while you ensure the correct technical permissions are granted.

This approach reduces friction in access requests while maintaining security through admin-controlled permission groupings.

Privilege duration and expiration

You can configure JIT policies to grant privileges for the appropriate amount of time, when all conditions specified in the policy are met. By default, you can select a JIT policy duration for any amount of time from 2 minutes up to 3 days.

If you need to create a JIT policy with a duration longer than 3 days, you must first enable Extended policy duration at Privileged access > Just-in-Time access > Settings before creating the policy. Disabling this setting automatically resets all policies with a duration longer than 3 days back to the default 72 hour limit.
Important: We recommend that you use JIT to grant permissions for only short term use. Using JIT to grant permissions for longer than 72 hours introduces similar security risks as having standing permissions.
By default, Falcon JIT does not log users out when their privilege time limit is reached. The privileges are simply no longer available to them when the JIT session duration expires.
Tip: If you would like to log users out when their permissions expire, you can configure a Fusion SOAR workflow using the Revoke existing sign-in sessions action to log users out when their Entra ID JIT privileges expire. For more info about JIT events, see Falcon Privileged Access.
Continuous evaluation

You can also configure a JIT policy to continuously monitor the user and device. If the conditions specified in the policy are no longer met, the granted privileges are revoked within 5 minutes. When creating or editing a JIT policy, select Continuously monitor conditions and revoke if conditions are no longer met in the Workflow settings section.

Note: JIT policies with device trust conditions continuously monitor the device the user used to submit the JIT request. For example, if a user requests JIT privileges using a laptop, but then logs in through a mobile device, and the JIT policy condition is set to “ZTA score is less than a certain amount”, the risk score of the laptop is assessed but not the mobile device.

Monitoring JIT

You can use the FPA overview dashboard to review current JIT policy implementation, track elevation requests to high-risk users, and monitor the usage status across your environment. Go to Privileged access > Just-in-Time access > Dashboard.

FPA overview dashboard

Managing JIT privileges

Create a JIT policy

You can create as many JIT policies as needed to cover all of the user scenarios in your organization. Configure each JIT policy to provide the appropriate permissions for your end users, if they meet your specified conditions. Each JIT policy is limited to a single integration. However, each JIT policy supports all of the triggers that you have configured for end users in your environment. For more info, see JIT triggers.

For each integration’s policy creation process, see:
Edit a JIT policy
Edit any of your JIT policies to make changes such as:
  • Enable a policy that you created earlier
  • Enable or disable a policy to cover a temporary situation
  • Add or remove users from a policy
  • Add or remove conditions from a policy
  • Change the permission duration
  • Change the policy type between automatic and by-request
  1. Go to Privileged access > Just-in-Time access > Policies and click the policy that you want to edit.
  2. In the Policy details info panel, select Edit from the Actions dropdown list.
  3. Make the desired changes to the policy configuration and then click Save policy.
    Tip: To enable or disable a single JIT policy, select or deselect Enable policy. To pause all JIT policies, see Disable JIT.
Note: Alternatively, you can edit a policy connected to a specific JIT audit event. Go to Privileged access > Just-in-Time access > Audit and click Edit policy on its Event details info panel.
Delete a JIT policy
You can delete a JIT policy that you no longer want. Alternatively, you can disable a policy that you might want to use again. For more info, see Edit a JIT policy.
  1. Go to Privileged access > Just-in-Time access > Policies and click the policy that you want to edit.
  2. In the Policy details info panel, select Delete from the Actions dropdown list.
  3. In the Delete policy dialog, click Yes.
Disable JIT

This toggle allows you to pause all currently enabled JIT policies. Disabling JIT prevents end users from obtaining JIT privileges, either automatically or by request. Turning off the toggle restores all policies to their previous state, re-enabling all previously enabled policies while previously disabled policies remain disabled.

Tips:
  • Deleting a policy or disabling JIT does not immediately revoke currently active JIT privileges from end users. The privileges are still revoked when the JIT session duration expires.
  • Disabling JIT prevents the creation of new JIT policies.
  1. Go to Privileged access > Just-in-Time access > Settings.
  2. In the Just-in-time access section, click the toggle and then click Save.
View JIT audit events

With JIT audit events you can review end user requests, their justification, if the permissions were extended or revoked, and when each event happened.

Alternatively, you can query the same JIT events in Event search. For more info about JIT events, see Falcon Privileged Access.

To view a record of JIT policy creation, deletion, and edits, go to Audit logs > Audit logs > Falcon UI .
  1. To view JIT audit events, go to Privileged access > Just-in-Time access > Audit.
  2. Click any event to display the Event details info panel.
    Tip: The Timeline section lists the time and date of other audit log events that are related to the same permission request.

Just-in-Time Access for Entra ID

Secure privileged access to Entra ID resources by dynamically managing role assignments.

Overview

Just-in-Time (JIT) access for Entra ID allows you to secure privileged access to your organization’s Entra ID resources by dynamically managing role and group assignments. Instead of maintaining permanent roles or group membership, users can temporarily elevate their privileges when needed, reducing the attack surface and improving security posture. For more info, see Falcon Privileged Access Overview.

With JIT for Entra ID, end users can:
  • Request temporary access to Entra ID built-in and custom roles and group assignments when needed
  • Automatically receive time-limited role and group assignments based on policy conditions
  • Maintain least-privilege access by default

When Entra ID privileges are granted to the end user through Falcon JIT, they are displayed in Entra ID in the Active assignment tab, with an End time of Permanent. When Entra ID privileges expire, they are no longer displayed in Entra ID, but the role assignment and removal events are displayed in both Microsoft and Falcon audit logs. For more info, see View JIT audit events.

Requirements

For general JIT requirements, see Requirements. In addition, the following items are required for Entra ID policies:
Note: In order to enable JIT for Entra ID, you must add additional permissions to the Falcon SOAR Entra application in the Entra admin console. For more info, see JIT setup for Entra ID.

JIT setup for Entra ID

The connector used by JIT requires role management permission to function for Entra ID policies. To add the needed permission, complete the following steps.
  1. In your Azure portal, open the left portal menu, and then click Microsoft Entra ID.
  2. On the left menu, in the Manage category, click App registrations, and then select your existing Falcon SOAR Entra application. For more info, see Microsoft Entra ID SOAR Actions.
  3. Go to Manage > API permissions.
  4. On the API permissions page, click Add a permission.
  5. In the Request API permissions panel, click Microsoft Graph, and then click Application permissions.
  6. Select the following permission: RoleManagement.ReadWrite.Directory
  7. Click Add permissions.
Note: It can take up to 2 hours for the added permission to take effect.
Note: If you initially set up JIT by adding permissions to your IDAAS connector, that configuration is still supported, but we recommend that you add the role management permission to your Fusion SOAR application. When you switch to a Fusion SOAR configuration, the best practice is to reduce your IDAAS permissions to only those that are necessary. For more info, see Microsoft Entra ID (entity and activity ingestion).

Create a JIT policy for Entra ID

Complete the following steps to create an automatic or by-request JIT policy.
Tip: If you need to create a policy with a permissions duration longer than 3 days, you must first enable Extended policy duration at Privileged access > Just-in-Time access > Settings. Disabling this setting automatically resets all policies with a duration longer than 3 days back to the default 72 hour limit.
Important: We recommend that you use JIT to grant permissions for only short term use. Using JIT to grant permissions for longer than 72 hours introduces similar security risks as having standing permissions.
  1. Go to Privileged access > Just-in-Time access > Policies and click Create new policy.
    Note: Alternatively, you can duplicate any of your existing JIT policies that you would like to use as a starting point. In the desired policy’s Action menu, click Duplicate policy.
  2. Enter a Policy name.
  3. Optional. Enter a Description for the policy.
  4. In Integration, select Microsoft Entra.
  5. In Tenant, select the Microsoft Entra tenant that you want to use for JIT, and then click Next.
  6. In the Configure conditions section, select the conditions the user must meet in order to receive the specified permissions. Use Include or Exclude to tailor the condition to your needs. For example, the user’s Identity Protection risk score must be lower than 7, or the user cannot have a compromised password. To add more than one condition, click Add condition. For more info about available conditions, see Understand conditions.
    Tips:
    • To only grant JIT permissions to users when they log in with trusted devices, you can select source conditions such as Source attribute includes Falcon installed, Source network, Source IP reputation, or you can exclude logins from selected source countries.
    • To ensure the correct users are eligible for the appropriate permissions, you can select user conditions such as User name, User group, or Department. Search for "user" in the Condition field to see all options.
    • You can also use the Time condition to allow users to elevate their permissions only during working hours.
  7. Click Next.
  8. In Configure permissions, define one or more permission sets that users can choose from. Each set requires at least one role or group assignment.
    • Permission set name: Enter a name for the permission set. For by-request JIT policies, the permission set name is displayed to the end user in the elevation request form.
    • Entra roles: Select the permissions to be included in the permission set.
    • Entra groups: Select the Entra groups to be included in the permission set. Entra security groups and M365 groups are available to select.
      Note: You can include roles and groups in a single permission set.
  9. Optional. Click Add another permission set.
  10. Click Next.
  11. In Set elevation settings, select By request or Automatic.
  12. Select the desired Permissions duration. For automatic JIT policies, we recommend that you select the same duration of time as the session timeout length that you defined in your Azure Conditional Access policy.
    Note: This is the amount of time the permission will be granted to the user. The user has to log in again to request or be automatically granted the permission again.
    Note: If you need to create a policy with a permissions duration longer than the default 72 hours, you must first enable Extended policy duration at Privileged access > Just-in-Time access > Settings.
  13. Optional. For By request policies only, select Allow user to choose less time. For more info, see By-request JIT policy user experience.
  14. Optional. For By request policies only, select Require justification. For more info, see By-request JIT policy user experience.
  15. Optional. In the Workflow settings section, select Identity was verified with MFA.
    Tips:
    Important: If an end user is already governed by an Identity verification policy rule, they will not be prompted with MFA by JIT a second time.
  16. Optional. In the Workflow settings section, select Continuously monitor conditions and revoke if conditions are no longer met. If the conditions specified in the policy are no longer met, the granted privileges are revoked within 5 minutes. For more info, see Continuous evaluation.
  17. If you want the policy to be active immediately, make sure Enable policy is selected, and click Save.
    Note: If you want the policy to be disabled automatically on a future date, select Set policy expiration date and enter the date that you want the policy to be disabled.
  18. If you don't want the policy to be active immediately, deselect Enable policy, and click Save.
    Note: To enable a policy at a later time, you can edit the policy any time after you create and save it. For more info, see Edit a JIT policy.

Just-in-Time Access for AD Groups

Secure privileged access to on-premises AD resources by dynamically managing group memberships.

Overview

Just-in-Time (JIT) access for Active Directory (AD) groups allows you to secure privileged access to your organization’s on-premises AD resources by dynamically managing group memberships. Instead of maintaining permanent access, users can temporarily elevate their privileges when needed, reducing the attack surface and improving security posture. For more info, see Falcon Privileged Access Overview.

With JIT for AD groups, end users can:
  • Request temporary access to AD security groups when needed
  • Automatically receive time-limited group memberships based on policy conditions
  • Access on-premises resources and applications that rely on AD group membership
  • Maintain least-privilege access by default
Note: AD group membership is assigned immediately upon a successful JIT request on the primary DC, and then replicated to all DCs upon Microsoft setup or configuration.

Requirements

For general JIT requirements, see Requirements. In addition, the following items are required for AD group policies:
  • Falcon sensor for Windows version 7.25 or later must be installed on the domain controller

Create a JIT policy for AD groups

Complete the following steps to create an automatic or by-request JIT policy.
Tip: If you need to create a policy with a permissions duration longer than 3 days, you must first enable Extended policy duration at Privileged access > Just-in-Time access > Settings. Disabling this setting automatically resets all policies with a duration longer than 3 days back to the default 72 hour limit.
Important: We recommend that you use JIT to grant permissions for only short term use. Using JIT to grant permissions for longer than 72 hours introduces similar security risks as having standing permissions.
  1. Go to Privileged access > Just-in-Time access > Policies and click Create new policy.
    Note: Alternatively, you can duplicate any of your existing JIT policies that you would like to use as a starting point. In the desired policy’s Action menu, click Duplicate policy.
  2. Enter a Policy name.
  3. Optional. Enter a Description for the policy.
  4. In Integration, select Active Directory.
  5. In Domain, select the domain that you want the policy to apply to, and then click Next.
  6. In the Configure conditions section, select the conditions the user must meet in order to receive the specified permissions. Use Include or Exclude to tailor the condition to your needs. For example, the user’s Identity Protection risk score must be lower than 7, or the user cannot have a compromised password. To add more than one condition, click Add condition. For more info about available conditions, see Understand conditions.
    Tips:
    • To only grant JIT permissions to users when they log in with trusted devices, you can select source conditions such as Source attribute includes Falcon installed, Source network, Source IP reputation, or you can exclude logins from selected source countries.
    • To ensure the correct users are eligible for the appropriate permissions, you can select user conditions such as User name, User group, or Department. Search for "user" in the Condition field to see all options.
    • You can also use the Time condition to allow users to elevate their permissions only during working hours.
  7. Click Next.
  8. In Configure permissions, define one or more permission sets that users can choose from. Each set requires at least one role or group assignment.
    • Permission set name: Enter a name for the permission set. For by-request JIT policies, the permission set name is displayed to the end user in the elevation request form.
    • AD groups: Select the AD groups to be included in the permission set.
  9. Optional. Click Add another permission set.
  10. Click Next.
  11. In Set elevation settings, select By request or Automatic.
  12. Select the desired Permissions duration. For automatic JIT policies, we recommend that you select the same duration of time as the session timeout length that you defined in your Azure Conditional Access policy.
    Note: This is the amount of time the permission will be granted to the user. The user has to log in again to request or be automatically granted the permission again.
    Note: If you need to create a policy with a permissions duration longer than the default 72 hours, you must first enable Extended policy duration at Privileged access > Just-in-Time access > Settings.
  13. Optional. For By request policies only, select Allow user to choose less time. For more info, see By-request JIT policy user experience.
  14. Optional. For By request policies only, select Require justification. For more info, see By-request JIT policy user experience.
  15. Optional. In the Workflow settings section, select Identity was verified with MFA.
    Tips:
    Important: If an end user is already governed by an Identity verification policy rule, they will not be prompted with MFA by JIT a second time.
  16. Optional. In the Workflow settings section, select Continuously monitor conditions and revoke if conditions are no longer met. If the conditions specified in the policy are no longer met, the granted privileges are revoked within 5 minutes. For more info, see Continuous evaluation.
  17. If you want the policy to be active immediately, make sure Enable policy is selected, and click Save.
    Note: If you want the policy to be disabled automatically on a future date, select Set policy expiration date and enter the date that you want the policy to be disabled.
  18. If you don't want the policy to be active immediately, deselect Enable policy, and click Save.
    Note: To enable a policy at a later time, you can edit the policy any time after you create and save it. For more info, see Edit a JIT policy.

Falcon Privileged Access in Fusion SOAR

Create workflows so Falcon automatically takes action to manage JIT privilege assignments.

Overview

Just-in-time (JIT) access allows you to manage the entire permission lifecycle by ensuring that users only have access to the permissions they need, for only as long as required, if the user and device remain within the configured parameters of risk. You can create Fusion SOAR workflows to revoke JIT permissions when a critical alert or any specified Fusion trigger occurs. For example, you can set a Fusion workflow to revoke all JIT permissions from any user that triggers an identity detection.

For more info, see Falcon Privileged Access Overview or Fusion SOAR.

This document shows how to create workflows that use Falcon Privileged Access actions.

Create a workflow to revoke active JIT permission assignments

You can set up automated actions to revoke active JIT permission assignments.

Requirements

  • Subscriptions:
    • Falcon Identity Threat Protection and Falcon Privileged Access
  • Default roles:
    • Falcon Administrator
    • Workflow Author
Steps

  1. Go to Fusion SOAR > Fusion SOAR > Workflows.
  2. Click Create workflow.
  3. Click Create workflow from scratch and then click Next.
  4. In the Add trigger panel, select the desired trigger, for example Detection > Identity Detection.
  5. Click Next.
  6. In the Add next panel or on the workflow canvas, select Action icon.
  7. In the Add action panel, search for and select Revoke JIT permission assignments.
    Note: The Revoke JIT permission assignments action revokes all assigned JIT permissions from the affected user. If you have the Teams trigger configured, the user will receive a notification in Teams when permissions are revoked.
    Note: A JIT audit event is created every time permissions are revoked by the workflow. For more info, see View JIT audit events.
  8. On the Configure tab, in the User name field, select the option that is appropriate for the workflow trigger.
    Tip: For the Detection > Identity Detection trigger, selecting User name from the drop down means the workflow will revoke all JIT permissions from any user that triggers an identity detection.
  9. Click Next.
  10. Click Settings .
  11. In the Workflow details panel, enter a Name for the workflow.
  12. Optional. Enter a Description for the workflow.
  13. Click Publish, and then click Publish workflow.
  14. To enable the workflow, set the Status to On.

Identity Protection Integration

Integrating Identity Protection with AD FS

Integrate with your Active Directory Federation Services (AD FS) environment to enable the same conditional controls for use by your federated services.

Overview

Falcon Identity Protection eliminates insider threat and security breaches by continuously preempting threats based on identity behavior and risk. It applies conditional, adaptive access controls on any network resource, including access to file shares, services, domain logins, and any application.

Integrating Falcon Identity Protection into your Active Directory Federation Services (AD FS) environment enables the same exact conditional controls for use by your federated services, whether they are accessed by using a web browser or desktop applications, including Office 365. This also includes additional applications that are configured for single sign-on (SSO) by using AD FS.

Requirements

  • AD FS v4.0

  • Windows Server 2016

  • .NET Framework 4.5.2 or later must be installed

Note: Falcon Identity Protection supports applications that integrate with AD FS through SAML.

Falcon Identity Protection integration with AD FS

CrowdStrike provides the Falcon Identity Protection AD FS Adapter, which integrates with AD FS to add the Falcon Cloud as a secondary authentication provider to the AD FS farm.


The AD FS Adapter connects the Falcon Cloud as a secondary authentication provider to the AD FS farm nodes.

Each time a user attempts to authenticate using AD FS, the Falcon Identity Protection policy engine is called. Falcon Identity Protection evaluates the authentication based on the defined policy. If required by a policy rule, an authentication can be blocked or MFA enforced, as shown below:


CrowdStrike enforcing MFA when accessing an application.
Note: You must have a Falcon Identity Threat Protection subscription, and integrate with an MFA provider to configure these types of policy rule.

Configure Falcon Identity Protection for AD FS integration

To configure Falcon Identity Protection for AD FS integration, you must:

  1. Create an API client that AD FS will use to authenticate to Falcon Identity Protection.

  2. Ensure that AD FS can successfully connect and access the Falcon Cloud.

Create an API client

Create an API client to allow the AD FS authentication adapter to authenticate to the Falcon Platform. You need to provide the client ID and secret when installing the AS FS adapter.

  1. In the Falcon console, go to Support and resources > Resources and tools > API clients and keys .

  2. Click Create API client.

  3. Complete the form:

    1. Client Name (required)

    2. Description (optional)

    3. API Scopes (required):

      1. Identity Protection Enforcement: Read / Write.

      2. Identity Protection Health: Read

  4. To complete the configuration and display the client ID and secret, click Add.

Important: Record your client secret somewhere safe. After the credential window is closed, the secret is no longer visible.

For more information, see API clients.

Allow AD FS to access Falcon Identity Protection

Configure your network to allow the AD FS instance to communicate with Falcon Identity Protection using HTTPS on port 443.

Trust the Falcon Platform Certificate Authority (CA) certificates

Your AD FS instance must trust the certificate authority CrowdStrike uses to digitally sign certificates and enable secure connections.

If necessary, download the following Digicert certificate chains, and import them to the trust store on your AD FS instance:

Set up the Identity Protection AD FS Adapter

This section describes how to download, install, and configure the Identity Protection AD FS Adapter.

Install the Identity Protection AD FS Adapter
Important: First, perform the following steps on each secondary node. Then, perform the steps on the primary node.

To install the AD FS authentication adapter:

  1. Go to Support and resources > Resources and tools > Tool downloads , and download the Falcon Identity Protection AD FS Adapter MSI file: CrowdStrike.AdfsAuthenticationAdapterInstaller.msi

  2. Run the installer.

When installing on the primary node, complete the following additional steps:

  1. In the configuration dialog, complete the fields as follows:

    • CrowdStrike Falcon API URL: The URL of the CrowdStrike API gateway.

      • US-1: https://api.crowdstrike.com

      • US-2: https://api.us-2.crowdstrike.com

      • EU-1: https://api.eu-1.crowdstrike.com

      • US-GOV-1: https://api.laggar.gcw.crowdstrike.com

      • US-GOV-2: https://api.us-gov-2.crowdstrike.mil

    • API Client ID: The ID of the API client the adapter uses to authenticate to Falcon. See Create an API client.

    • API Client Secret: The client secret of the API client the adapter uses to authenticate to Falcon.

    • Proxy Host: (Optional) The IP address or FQDN of the proxy connection, if required.

    • Proxy Port: (Optional) The port number of the proxy connection, if required.

    • Bypass CrowdStrike on Error: Enable to allow unconditional access in situations when Falcon Identity Protection cannot be contacted.

  2. Click Apply Configuration.

  3. Restart the Active Directory Federation Service on the primary node.

Note: After you restart service on the primary node, the configuration is applied on all nodes.
Enable the AD FS Authentication Adapter

After installing the AD FS Authentication Adapter on each AD FS node, you must enable the integration by completing the following steps on the primary node only:

  1. In the AD FS administration console on the primary node, go to AD FS > Service > Authentication Methods > Multi-factor Authentication Methods, and click Edit.

  2. On the Multi-factor tab, enable CrowdStrike AD FS Integration.

  3. Choose or create an MFA policy for your federated applications to use.

    We recommend the built-in ​Permit everyone and require MFA​ authentication policy.

    This option delegates policy management to Falcon Identity Protection. Note that this doesn’t imply that every authentication will require MFA. It merely delegates the decision to Falcon Identity Protection.

  4. Repeat the following steps for each application federated through AD FS:

    1. Go to AD FS > Relying Party Trusts, and select the federated application.

      For example, Microsoft Office 365 Identity Platform.

    2. In the Actions pane, click Edit Access Control Policy.

    3. On the Issuance Authorization Rules tab, click Use access control policy.

    4. Select the policy you chose or created in the previous step.

      For example, ​Permit everyone and require MFA.

    5. Click OK.

AD FS is now configured to delegate authentication decisions to Falcon Identity Protection policy rules, which should use the Federated Access trigger. For more information, see Identity Protection Policy.

Modify the AD FS Authentication Adapter Configuration

Use the configuration dialog on the primary node to modify the AD FS Authentication Adapter Configuration:

  1. On the primary node, go to ​Start > CrowdStrike AD FS Integration, and then click AD FS Integration Configuration​.

  2. In the Configuration window, modify the fields as required and click Apply Configuration.

  3. Restart the Active Directory Federation Service on ALL nodes, as follows.

    1. First, restart the primary node.

    2. Wait for AD FS configuration sync - the default is every 5 minutes

    3. Restart all secondary nodes.

Integrating Identity Protection with PingFederate

Add Falcons risk and behavioral-based conditional access to client applications and use multi-factor authentication alongside your PingFederate deployment.

Overview

This guide is for IT and security personnel who want to add Falcon Identity Protection's risk and behavioral-based conditional access to client applications and use multi-factor authentication alongside their PingFederate deployment.

CrowdStrike provides the Falcon Identity Protection PingFederate Adapter, which you can integrate into a PingFederate deployment. This adapter allows PingFederate to communicate with Falcon Identity Protection to provide conditional access to federated applications and endpoints.

Requirements

  • A functional PingFederate environment, version 7 or later

  • At least one adapter to use as the primary form of authentication: for example, the HTML Form Adapter

Configure Falcon Identity Protection for integration

To integrate PingFederate with the Falcon platform, you must create an API client and ensure that your PingFederate instance can communicate with the Falcon platform.

Create an API client

Create an API client to allow PingFederate to authenticate to the Falcon platform:

  1. In the Falcon console, go to Support and resources > Resources and tools > API clients and keys.

  2. Click Create API client.

  3. Complete the form:

    1. Client Name (required)

    2. Description (optional)

    3. API Scopes (required):

      1. Identity Protection Enforcement: Read / Write.

      2. Identity Protection Health: Read

  4. To complete the configuration and display the client ID and secret, click Add.

Note: Record your client secret somewhere safe. After the credential window is closed, the secret is no longer visible.

For more information, see Managing your API clients.

Allow PingFederate to access Falcon Identity Protection

Ensure your network allows your PingFederate instance to communicate with the base URL of the Falcon platform's API gateway, using HTTPS on port 443.

The examples in this guide use the API gateway base URL for US-1: api.crowdstrike.com

If you use another CrowdStrike cloud environment, substitute your cloud's base URL:

  • US-2: https://api.us-2.crowdstrike.com

  • EU-1: https://api.eu-1.crowdstrike.com

  • US-GOV-1: https://api.laggar.gcw.crowdstrike.com

  • US-GOV-2: https://api.us-gov-2.crowdstrike.mil

Trust the Falcon platform Certificate Authority (CA) certificates

Your PingFederate instance must trust the certificate authority CrowdStrike uses to digitally sign certificates and enable secure connections.

If necessary, download the following Digicert certificate chains and import them to your PingFederate instance:

Configure PingFederate for integration

To integrate PingFederate with the Falcon platform, you must deploy and configure the adapter in your PingFederate instance. You can then create policies in PingFederate to invoke the Identity Protection adapter, which can allow, block, or force multi-factor authentication (MFA) on a federated login.

Deploy the adapter in PingFederate

High-level steps:

  1. Download and install the adapter

  2. Set up the adapter in PingFederate

Download and install the PingFederate adapter

This section describes how to download the adapter and install it in a PingFederate instance.

  1. In the Falcon console, go to Support and resources > Resources and tools > Tool downloads, and download the PingFederate adapter ZIP file:

    pf-crowdstrike-integration-kit-<version>.zip

  2. Expand the downloaded ZIP file.

  3. Stop the PingFederate instance.

  4. Copy the pf-crowdstrike-integration-kit-<version>.jar file to:

    <pingfederate-install>/pingfederate/server/default/deploy/

  5. Copy the following HTML files to <pingfederate-install>/pingfederate/server/default/conf/template/

    • crowdStrikeMfaUI.html

    • crowdStrikeNextState.html

  6. Start the PingFederate instance.

Set up the adapter in PingFederate

This section explains how to use the PingFederate administration console to configure PingFederate to recognize and use the adapter.

  1. In the PingFederate administration console, go to Identity Providers > Application Integration, and then click Adapters.

  2. Click Create New Instance.

  3. On the Type tab, specify the following parameters, and then click Next:

    1. Instance Name: The name for the instance

    2. Instance ID: A unique instance ID. This can be the same as the Instance Name.

    3. Type: CrowdStrike Identity Protection Adapter <version>

    4. Parent Instance: None

  4. On the Adapter tab, specify the following parameters, and then click Next:

    • API URL: The URL of the Falcon platform API gateway

      • US-1: https://api.crowdstrike.com

      • US-2: https://api.us-2.crowdstrike.com

      • EU-1: https://api.eu-1.crowdstrike.com

      • US-GOV-1: https://api.laggar.gcw.crowdstrike.com

      • US-GOV-2: https://api.us-gov-2.crowdstrike.mil

    • API Client ID: The ID of the API client the adapter uses to authenticate to Falcon

    • API Secret ID: The client secret of the API client the adapter uses to authenticate to Falcon

    • Proxy host: (Optional) The IP address or FQDN of the proxy connection, if required

    • Proxy port: (Optional) The port number of the proxy connection, if required

    • Fail Mode: The required system response in situations when Falcon Identity Protection cannot be contacted

  5. On the Extended Contract tab, click Next.

  6. On the Adapter Attributes tab, enable the Pseudonym checkbox, and then click Next.

  7. On the Summary tab, review the adapter configuration, and then click Done.

  8. To complete the configuration, click Save.

Configure PingFederate integration

Falcon Identity Protection integrates with PingFederate in two operation modes:

  • Enforcement by Falcon : Delegate authentication decisions to Falcon Identity Protection policy rules, which might include requiring multi-factor authentication (MFA), also enforced by Falcon.

  • External enforcement : Falcon returns one of three possible recommendations to PingFederate—approve, deny, or review—to help it make authentication decisions.

Note: You can configure PingFederate to send data to the Falcon platform but not enforce any policies. To do so, In the PingFederate administration console, go to Identity Providers > Application Integration, and then click Adapters and select your adapter. On the Adapter tab, click Show Advanced Fields, and then enable Out of Band Mode. Data from PingFederate will still be available in Threat Hunter, but it will not be subject to any policies.
Configure enforcement by Falcon

In this operation mode, Falcon is responsible for both making authentication decisions and, if necessary, prompting for MFA.

Enable enforcement by Falcon in an Identity Protection policy rule:

  1. In the Falcon console, go to Identity protection > Enforce > Policy rules.

  2. Click Add Rule.

  3. Provide a Rule Name.

  4. From the Trigger menu, select Federated access, and then click Next.

  5. From the Enforced By menu, select CrowdStrike.

  6. Configure the policy rule as required, and then click Save.

Falcon returns either fail or success to PingFederate.

Configure PingFederate to handle the two possible outcomes, as required:

  1. In the PingFederate administration console, go to Identity Providers > Authentication Policies, and then click Policies.

  2. Open an existing authentication policy or create a new one.

  3. In the Policy area, scroll through the policy tree, identify the location, and select an adapter instance.

  4. Map the Username to the adapter instance:

    1. Under the adapter instance, click Options.

    2. In the Options dialog box, from the Source list, select a previous authentication source that collects the Username.

    3. From the Attribute list, select Username, and then click Done.

  5. Configure each of the Fail and Success policy paths.

  6. To complete the authentication policy, click Done.

Configure external enforcement

To enable external enforcement in an Identity Protection policy rule, see Configuring external authentication.

When using external enforcement, Falcon returns one of three possible outcome recommendations to PingFederate: approve, deny, or review.

Configure PingFederate as described in Configuring enforcement by Falcon. Additionally, set the adapter to expose these possible outcomes:

  1. In your PingFederate policy, under the PingFederate Adapter instance, click Rules to map each adapter result to a PingFederate result value.

  2. Configure policy paths for each of the possible outcomes returned by the adapter.

  3. Click Done.

Get host information from PingFederate
The PingFederate adapter has access to the endpoint IP address and tries to resolve the host name from the IP. The adapter only succeeds in resolving the endpoint’s host name, making it visible in Threat Hunter and applicable in the Identity Protection policy rules, under the following conditions:
  • The endpoint has an internal IP. For example, it connects from inside the organization.
  • Reverse DNS lookup on the endpoint’s IP returns a host name. For example, the endpoint IP has a PTR record configured in the DNS.
  • If there is any type of proxy used inside the network, then it must pass the X-Forwarded-For header.

Troubleshooting

Enable debug logging from the Identity Protection adapter

PingFederate adapters write their logs remotely to the server by default.

To use local files, add the Logger and RollingFile blocks shown below to the <pingfederate-install>/pingfederate/server/default/conf/log4j2.xml file.

Logger block:

<Logger name="com.pingidentity.adapter.idp.crowdstrike" 
    level="INFO" additivity="false">
    <AppenderRef ref="CROWDSTRIKEFILE"/>
</Logger>

RollingFile block:

<!-- Log -->
<RollingFile name="CROWDSTRIKEFILE"
   fileName="${sys:pf.log.dir}/crowdstrikeIdpAdapter.log" 
   filePattern="${sys:pf.log.dir}/crowdstrikeIdpAdapter.log.%i"
   ignoreExceptions="false">  
   <PatternLayout>
      <pattern>%d %-5p[%t][%c{1}] %m%n</pattern>   
   </PatternLayout> 
   <Policies>     
      <SizeBasedTriggeringPolicy size="10000 KB" />
      <OnStartupTriggeringPolicy />
   </Policies>
   <DefaultRolloverStrategy max="10" /> 
</RollingFile>

FalconID

FalconID

Set up and configure FalconID.

Overview

FalconID is a phish-resistant multi-factor authentication (MFA) solution that uses the Fast Identity Online 2 (FIDO2) authentication standard. FalconID works together with Falcon for Mobile and Identity Protection to provide a seamless, end-to-end MFA experience.

Requirements

Requires all of these subscriptions:

  • Falcon Identity Threat Protection

  • FalconID

Sensor:

  • Android: Falcon for Mobile Android sensor version 2025.22.4190000 and later

  • iOS: Falcon for Mobile iOS sensor version 2025.11.x and later

Operating system support:

  • Android version 14 and later

  • iOS version 18 and later

Default roles:

  • To configure Identity Protection policies, you need one of these roles:

    • Falcon Administrator

    • Identity Protection Policy Manager

  • To configure OIDC integrations, you need one of these roles:

    • Falcon Administrator

    • Identity Protection Administrator

  • To manage Falcon for Mobile enrollment, you need one of these roles:

    • Falcon Administrator

    • Mobile Admin

CrowdStrike clouds: Available in US-1, US-2, and EU-1

How FalconID works

FalconID is installed and enrolled on end users' devices with the Falcon for Mobile sensor. Manage FalconID users through Identity Protection in the Falcon console.

During enrollment with FalconID, users are prompted to create a passkey. This passkey is bound to the device and is stored in the device’s secure, trusted execution environment. Passkeys are inherently phish-resistant and allow users to authenticate to your organization’s resources with the same methods used to unlock a device, such as Face ID, Touch ID, or a passcode.

When users attempt to authenticate, whether from their mobile devices or workstations, they’re prompted to approve and complete authentication with FalconID using the CrowdStrike Falcon app on their mobile devices.

Understanding the CrowdStrike Falcon app capabilities

The CrowdStrike Falcon app delivers a complete security solution and includes the following:

  • FalconID, a phish-resistant multi-factor authentication using FIDO2 Passkeys

  • Falcon for Mobile, which continuously monitors and protects your devices

  • Device Trust, which leverages Falcon Identity Protection to help you make real-time conditional access decisions using identity and workload context

This integrated approach means that you're not just proving who you are, but you're proving you're using a secure and trusted device.

A graphic that shows the overall authentication workflow and the relationship between FalconID, Falcon for Mobile, and Falcon Identity Protection

FalconID passkey and enrollment considerations

Consider these points when enrolling users with FalconID:

  • FalconID requires that the device’s lock screen is configured.

  • FalconID needs to be enabled as an autofill credential provider. If the user disables the credential provider in the device’s OS settings after enrollment, they’ll be prompted to enable it again before they can use FalconID.

  • Only one passkey can be created per device. This passkey isn’t synced to the cloud. If a device is lost or stolen, or the passkey is otherwise inaccessible, the user must re-enroll their device using a new enrollment email.

  • If a user removes the lock screen, which deletes the biometrics or passcode, the passkey becomes invalid. For Android devices, it's not possible to recover the passkey even if the lock screen is enabled again, and those users must re-enroll their devices using a new enrollment email.

  • FalconID supports up to two devices per user.

  • If Android users want to use biometrics for their passkey, the Android device must have a BIOMETRIC_STRONG (Class 3) hardware sensor.

FalconID network considerations

If a device is network contained, whether manually through Host Management or automatically during a detected man-in-the-middle attack, FalconID is disabled. Users can’t authenticate with FalconID until containment is lifted.

For more info about network containment, see Network containment for mobile hosts.

Setting up FalconID

This workflow describes the high-level steps to set up and use FalconID:

  1. In Identity Protection, add the FalconID connector. This connector is preconfigured and is ready to use as soon as it’s added.

  2. Configure access policy rules that use the FalconID connector.

  3. Send emails to users inviting them to enroll with FalconID.

  4. Users follow the instructions in the email to create a passkey and complete enrollment using the CrowdStrike Falcon app on their devices.

Users are then ready to authenticate with FalconID.

Before you begin

Before you can set up FalconID, you must deploy Falcon for Mobile to your mobile devices.

For full deployment instructions, see:

  • Deploying Falcon for Mobile to Android Devices

  • Deploying Falcon for Mobile to iOS Devices

If you’re using Microsoft Entra, you must configure the OIDC integration in Identity Protection. For more info, see Entra ID EAM.

Configure Identity Protection to use FalconID

Add the FalconID connector and configure access policy rules.

Add the FalconID connector

The FalconID connector is based on the Cloud MFA OIDC connector. This connector is preconfigured and is ready to use after being added.

  1. Go to Identity protection > Configure > Connectors .
  2. From the Select connector menu, select FalconID and click Add.
Create a policy rule for FalconID

Configure an access policy rule that uses the FalconID connector.

  1. Go to Identity protection > Enforce > Policy rules .

  2. Click Add rule.

  3. Enter a rule name.

  4. From the Trigger dropdown list, select the access type. If you’re using Microsoft Entra, select Cloud access. Otherwise, select Access.

  5. Click Next.

  6. From the Action dropdown list, select Identity Verification.

  7. From the Connector dropdown list, select CrowdStrike FalconID (OIDC).

    Note: If you’ve enabled other connectors and you want users to select which method to use when prompted for authentication, select Any.

  8. Configure other rule settings as needed. For more info about how to configure Identity Protection policy rules, see Identity Protection Policy.

  9. Click Save.

Enroll users with FalconID

Use the Falcon console to send invitation emails to users. Users follow the instructions in the email to enroll their devices with FalconID.

FalconID supports up to two devices per user.

View FalconID users and enrollment status

The FalconID page displays details about FalconID users and their enrollment status, whether pending, active (enrolled), or expired. Each entry shows info about the user and device, including the user risk severity and device ZTA score. You can also filter entries by criteria such as the enrollment status or the expiration date.

To view and manage invitations, go to Identity protection > Configure > FalconID .

Send invitation emails to users

Provide email addresses manually or by uploading a TXT or CSV file.

  • The domain of the email addresses must match the domain you have registered for Falcon. This domain can be from these options:

  • When uploading email addresses in a TXT file, use one email address per line. Use Unix or macOS format, not MS-DOS or classic Mac OS.

  • The enrollment link and the QR code in each invitation is single-use. If a user has two devices, they need an invitation for each device. You must repeat the workflow to send an invitation and either re-enter their email address or upload another TXT or CSV file with the address.

To send invitation emails, complete these steps:

  1. Go to Identity protection > Configure > FalconID .

  2. Click Invite employees.

  3. Select one of these options:

    • Upload file: Click Select file and open the TXT or CSV file containing users’ email addresses.

    • Manually add addresses: Enter the email addresses.

  4. Select the enrollment code expiration date.

    If a user doesn’t enroll within the specified time frame, they’ll need a new invitation email.

  5. Click Send Invites.

    If any email addresses are entered incorrectly or don’t match the domain registered with Falcon, select whether to fix the email address or to send only to valid addresses.


    The check addresses workflow displaying invalid email addresses

    • Fix email addresses: Go back to correct email addresses that were entered manually or upload a new TXT or CSV file.

    • Send to valid addresses only: Ignore incorrect email addresses and send invites only to emails with a status of Ready to send.

      Tip: If needed, you can take note of any problematic addresses, send invitations to valid email addresses only, and then send invitations to those individuals later.
Reinvite users

If a user’s invitation has a pending or expired status, you can send a new invitation email.

  1. Go to Identity protection > Configure > FalconID .

  2. Select one of these options:

    • To send a new individual invite, click the Actions menu for the email address and select Reinvite enrollment.

    • To resend new invites in bulk, select one or more email addresses and click Reinvite enrollment.

  3. Select the expiration date.

  4. Click Reinvite.

Delete invitations

If you need to unenroll a user from FalconID, you can delete their invitation.

If a user no longer has access to their passkey, such as in the event of a lost or stolen device, it’s not possible to recover the passkey. You must unenroll the user and send a new enrollment email. The user must then complete enrollment on their device, including creating a new passkey, to continue using FalconID.

  1. Go to Identity protection > Configure > FalconID .

  2. Select one of these options:

    • To delete an individual invite, click the Actions menu for the email address and select Delete enrollment.

    • To delete in bulk, select one or more email addresses in the list and click Delete selected enrollments.

  3. Confirm the deletion.

Complete enrollment on a mobile device

Users follow the instructions in the invitation email and the CrowdStrike Falcon app to set up a passkey and enroll the device.

  1. Open the CrowdStrike Falcon app on the mobile device.

  2. Open the enrollment email and select one of these options:

    • Open the Enroll now link in the email.

    • In the Crowdstrike Falcon app, scan the QR code.

      1. For iOS, tap FalconID, or for Android, tap the navigation menu and tap FalconID.

      2. Tap Scan QR code.

      3. Scan the QR code in the email.

  3. Follow the on-screen instructions to create a passkey and enroll the device.

FalconID authentication

When users are prompted to authenticate, they can authenticate directly with the Sign in with passkey option or authenticate indirectly with the Verify manually option. In some cases, FalconID can automatically select the most secure and appropriate authentication method on behalf of the user.

Direct authentication, which uses FIDO2, is recommended whenever possible. FIDO2 performs domain checks to prevent phishing and uses Bluetooth for cross-device authentication. For example, if a user attempts to authenticate from a desktop endpoint, FIDO2 lets FalconID ensure that the mobile device running Falcon for Mobile is in physical proximity to the desktop endpoint.

In the following cases, users might need to use indirect authentication by selecting the option to verify manually:

  • If Bluetooth isn’t available, such as when authenticating from a virtual machine with Bluetooth restrictions

  • If the Identity Protection policy rule uses the Cloud access trigger and the app the user is authenticating to is an Android, Windows, macOS, or Linux app

  • If the Identity Protection policy rule uses the Access trigger and the user is connecting to a remote server through RDP

When authenticating indirectly, FalconID prompts users to approve the incoming authentication request before they use their passkey. FalconID displays details about the request, such as the website and source location, which provides the user context about whether the request is legitimate.

Example authentication workflows

The following examples show the authentication workflow in different situations and configurations.

Example workflow: Cross-device direct authentication

The following example describes cross-device direct authentication from a desktop endpoint using a QR code. In this case, the Identity Protection policy rule’s condition is set to Cloud access to use Microsoft Entra and the rule’s connector is set to FalconID.

  1. In your desktop endpoint, open the app you want to authenticate to.

  2. Sign in to the app.

  3. When prompted to verify your identity, click Approve with FalconID.

    The prompt from Microsoft to verify your identity

  4. Click Sign in with passkey.

    The prompt from CrowdStrike to sign in with passkey

  5. When prompted on the desktop endpoint, click Use a phone, tablet, or security key.

    Note: On Linux endpoints, you might need to manually enable Bluetooth to use this option.

    The prompt to use a saved passkey

  6. Use your phone to scan the QR code that appears.

    A sample QR code for authentication

  7. When prompted, tap the option to continue or to use your passkey, and then follow the on-screen prompts to authenticate with your passkey.

    The following example screenshot shows authenticating with Face ID on an iOS device.

    The prompt to use Face ID

Example workflow: Cross-device indirect authentication

The following example describes cross-device indirect authentication from a desktop endpoint with Microsoft Entra. In this case, the Identity Protection policy rule’s condition is set to Cloud access and the rule’s connector is set to FalconID.

  1. In your desktop endpoint, open the app you want to authenticate to.

  2. Sign in to the app.

  3. When prompted to verify your identity, tap Approve with FalconID.

    The prompt from Microsoft to verify your identity

  4. Tap Verify manually.

    The prompt from CrowdStrike to verify manually

  5. Open the CrowdStrike Falcon app and go to FalconID.

    • For Android, tap the navigation menu and tap FalconID.

    • For iOS, tap FalconID.

  6. Tap Approve.

  7. Tap the option to continue or to use your passkey, and then follow the on-screen prompts to authenticate with your passkey.

    The following example screenshot shows authenticating with Face ID on an iOS device.

    The prompt to use Face ID

Example workflow: Same-device direct authentication

The following example describes same-device direct authentication with Microsoft Entra. In this case, the Identity Protection policy rule’s condition is set to Cloud access and the rule’s connector is set to Any.

  1. On your mobile device, open the app you want to authenticate to.

  2. Sign in to the app.

  3. When prompted to verify your identity, click Approve with FalconID.

    The prompt from Microsoft to verify your identity

  4. When prompted to choose the authentication method, click Sign in with FalconID.

    The prompt to choose the authentication method

  5. Click Sign in with passkey.

    The prompt from CrowdStrike to sign in with passkey

  6. When prompted, tap the option to continue or to use your passkey, and then follow the on-screen prompts to authenticate with your passkey.

    The following example screenshot shows authenticating with your fingerprint for an Android device.

    The prompt to touch the fingerprint sensor

Example workflow: Same-device indirect authentication

The following example describes same-device direct authentication with Microsoft Entra. In this case, the Identity Protection policy rule’s condition is set to Cloud access and the rule’s connector is set to FalconID.

  1. On your mobile device, open the app you want to authenticate to.

  2. Sign in to the app.

  3. When prompted to verify your identity, tap Approve with FalconID.

    The prompt from Microsoft to verify your identity

  4. Tap Verify manually.

    The prompt from CrowdStrike to verify manually

  5. When prompted, open the CrowdStrike Falcon app and go to Falcon ID.

    • For Android, tap the navigation menu and tap FalconID.

    • For iOS, tap FalconID.

  6. Tap Approve.

  7. Tap the option to continue or to use your passkey, and then follow the on-screen prompts to authenticate with your passkey.

    The following example screenshot shows authenticating with your fingerprint for an iOS device.

    The prompt to use Touch ID

View FalconID audit log entries

See authentication attempts in the Identity Protection audit log at Identity protection > Enforce > Policy analytics . The Status column contains these statuses for FalconID:

  • Approved (CrowdStrike FalconID - OIDC)

  • Denied (CrowdStrike FalconID - OIDC)

  • Timed out (CrowdStrike FalconID - OIDC)