Decoding Azure AD Event ID 30036: A Deep Dive into Password Protection Mysteries

By /

Listen to this Post

Featured Image

Introduction

Azure Active Directory (Azure AD) Password Protection is a critical security feature that prevents users from setting weak or commonly used passwords. However, undocumented Event IDs like 30036 can create confusion for security teams. This article explores the technical nuances of Event ID 30036, its triggers, and actionable steps for incident response.

Learning Objectives

  • Understand the context and significance of Event ID 30036 in Azure AD Password Protection.
  • Learn how to analyze and respond to this event in security logs.
  • Discover tools and commands to troubleshoot Azure AD password policies effectively.

1. Event ID 30036: What We Know

Verified Command (PowerShell):

Get-WinEvent -LogName "Microsoft-AzureADPasswordProtection-DCAgent/Admin" | Where-Object {$_.Id -eq 30036}

Step-by-Step Guide:

  1. Run the above PowerShell command on a Domain Controller to filter logs for Event ID 30036.
  2. The output will show instances where password validation failed due to Azure AD’s banned password policy.

3. Key fields to examine:

  • MatchType: Indicates whether the password matched a global or custom banned list.
  • RuleName: Specifies the rule that triggered the rejection (if available).

Why It Matters:

This event often appears when a user’s password fails compliance checks, but Microsoft’s documentation lacks clarity on specific triggers like fuzzy matching or threshold scoring.

2. Cross-Referencing with Event ID 30026

Verified Command (Windows Event Log):

wevtutil qe "Microsoft-AzureADPasswordProtection-DCAgent/Admin" /q:"[System[(EventID=30026)]]" /f:text

Step-by-Step Guide:

  1. Compare Event ID 30036 with the well-documented 30026, which occurs when passwords match Microsoft’s global banned list.

2. Differences:

  • 30026: Explicit banned password match.
  • 30036: May indicate a broader policy violation (e.g., insufficient complexity).

Actionable Insight:

If 30036 appears without 30026, investigate custom password policies or third-party integrations affecting validation.

  1. Enabling Debug Logging for Azure AD Password Protection

Verified Command (Registry Edit):

reg add "HKLM\SYSTEM\CurrentControlSet\Services\AzureADPasswordProtectionDCAgent" /v "DebugLogging" /t REG_DWORD /d 1 /f

Step-by-Step Guide:

  1. Enable debug logging via the registry key above.

2. Restart the Azure AD Password Protection service:

Restart-Service AzureADPasswordProtectionDCAgent

3. Check logs at:

C:\Program Files\Azure AD Password Protection DC Agent\Logs

Why It Matters:

Debug logs provide granular details about password validation failures, including shadow rules not visible in standard events.

4. Querying Azure AD Audit Logs for Context

Verified Command (Microsoft Graph API):

GET https://graph.microsoft.com/v1.0/auditLogs/directoryAudits?$filter=activityDisplayName eq 'Change password'

Step-by-Step Guide:

  1. Use the Microsoft Graph API to correlate Event ID 30036 with Azure AD audit logs.

2. Look for:

  • User ID: Identify affected accounts.
  • IP Address: Detect brute-force attempts or suspicious locations.

Pro Tip:

Combine this with Azure Sentinel queries for SIEM integration:

SecurityEvent | where EventID == 30036 | project TimeGenerated, AccountName, Computer

5. Mitigating False Positives in Password Policies

Verified Command (Azure AD PowerShell):

Set-AzureADMSPasswordProtectionPolicy -BannedPasswordCheckOnPremisesMode "Audit"

Step-by-Step Guide:

  1. Switch policy mode to Audit to log failures without blocking users.

2. Analyze logs to refine custom banned passwords:

Get-AzureADMSPasswordProtectionPolicy | fl BannedPasswordCustomList

Key Takeaway:

Audit mode helps distinguish legitimate policy violations from false positives before enforcing strict blocks.

What Undercode Say

  • Key Takeaway 1: Event ID 30036 is likely a catch-all for password policy violations beyond explicit banned lists, but Microsoft’s opaque documentation complicates incident response.
  • Key Takeaway 2: Proactive logging (debug mode, Graph API) and cross-referencing with 30026 are critical for accurate analysis.

Analysis:

The lack of documentation around Event ID 30036 reflects a broader gap in Azure AD’s transparency. Security teams must rely on community insights (like Nathan McNulty’s findings) and empirical testing to fill these gaps. As Azure AD evolves, expect more Event IDs to emerge—documenting them collaboratively will be essential.

Prediction

Future Azure AD updates may formalize Event ID 30036’s role, but until then, organizations should:
1. Monitor: Alert on 30036 to track policy violations.
2. Correlate: Pair with SIEM rules to distinguish attacks from policy noise.
3. Contribute: Share findings with Microsoft to improve documentation.

Final Thought:

Mysteries like Event ID 30036 underscore the importance of community-driven security research in cloud environments.

IT/Security Reporter URL:

Reported By: Kadiri Lahari3 – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅

Join Our Cyber World:

💬 Whatsapp | 💬 Telegram

Related Posts: