If you manage a large-scale environment, you already know that stale and inactive user accounts are a massive security liability. They expand your attack surface, complicate compliance audits, and are prime targets for account takeover (ATO) attacks.
While most organizations have policies to suspend accounts after 90 days of inactivity, enforcing that policy is often a tedious, manual chore involving exporting CSVs, running PowerShell scripts, and chasing down managers for approval.
Recently, we built a fully automated, zero-touch pipeline using Google SecOps (Chronicle) SOAR to handle this entire lifecycle natively. Here is a breakdown of the use case and how we engineered the integration to detect, warn, and suspend dormant accounts via Azure Active Directory.
The Use Case:
We needed a way to continuously monitor user login activity and take tiered actions based on how long an account has been dormant. Instead of just pulling the plug at 90 days, we wanted the system to proactively warn the user, escalate to their manager if ignored, and finally suspend the account—all without a human analyst ever touching the ticket.
Because Google SecOps already ingests all our authentication telemetry, we decided to use it as the brain for this automation.
How the Integration Works
The solution is split into two main components: a custom Python-based ingestion connector and a conditional SOAR playbook.
1. The Detection Engine (Custom IDE Connector)
Instead of waiting for an external system to push alerts, we built a custom Python connector in the SecOps IDE that proactively hunts for inactive users.
-
The UDM Search: Once a day, the connector securely authenticates using a GCP Service Account and queries the
udmSearchAPI forUSER_LOGINevents across the last 90 days. -
Pagination & Processing: To handle enterprise-scale log volumes, the Python script uses API pagination to pull the data, processing the events locally to find the absolute latest login timestamp for every unique email address.
-
Threshold Calculation: The script calculates the days inactive for each user. If a user breaches our baseline threshold (e.g., 30 days), the connector generates a custom Alert and pushes it to the SOAR case wall: "Inactive User Detected: user@domain.com".
2. The Playbook (Enrichment & Tiered Response)
Once the case hits the board, our "Stale Account Management" playbook automatically triggers and executes the following workflow:
-
Entity Extraction & Enrichment: The SOAR Ontology engine extracts the user's email from the raw log. The playbook then queries Azure Active Directory to pull the user's fresh profile data, including their display name and their direct manager's contact information.
-
Conditional Routing: The playbook looks at the exact number of days the account has been inactive (calculated by our custom connector) and routes the case down one of four branches: (tune this if not applicable to your org)
-
Under 30 Days (Warning/False Positive): The case is immediately closed. This catches any users who logged in right at the threshold.
-
30 - 59 Days (User Warning): The playbook dynamically emails the user, warning them that their account is flagged for review due to inactivity.
-
60 - 89 Days (Manager Escalation): The playbook emails the user's direct manager (using the enriched Azure AD data), notifying them that their direct report's account is approaching the suspension threshold.
-
90+ Days (Auto-Suspension): The playbook executes an Azure AD command to officially disable the user's account, then closes the SecOps case as a "True Positive."
-
The Impact
By combining the raw querying power of the Chronicle API with the orchestration capabilities of SecOps SOAR, we completely eliminated the manual toil associated with stale account management.
The security team no longer has to track spreadsheets or send warning emails. The attack surface shrinks automatically, and users/managers are kept perfectly in the loop.
The Code