A pattern has emerged in our internal deployment data that contradicts the vendor's stated operational transparency: the introduction of BeyondTrust Privilege Management for Windows is causing stochastic, non-deterministic lockouts on non-interactive service accounts. This is not documented as a primary failure mode in the deployment guides, yet our telemetry indicates a correlation coefficient of >0.85 between policy enforcement events and subsequent account lockout events in the domain controller security logs.
The core hypothesis is that the agent's credential guard or its policy enforcement hook is interacting maladaptively with the Windows security subsystem, particularly during credential validation sequences for scheduled tasks or application pool identities. The lockouts are not occurring on all service accounts, but appear to target those with specific, complex policy conditions or those executing processes that perform repeated, rapid sub-process spawning.
Our current diagnostic evidence includes:
* **Temporal Correlation:** Lockout Event ID 4740 in the DC logs consistently occurs within 0-5 seconds of a Privilege Management "Process Blocked" or "Elevation Request" Event ID 100 in the local application logs on the host where the service account is executing.
* **Policy Context:** Affected accounts are often governed by policies that utilize "Resource Attributes" or "Command Line Conditions" that require deeper inspection of the launched process tree.
* **Non-Reproducibility:** Attempts to manually replicate the exact service account activity under observation do not trigger a lockout, suggesting a race condition or a specific stateful interaction between the BeyondTrust agent's DLL injection and the LSASS authentication workflow.
We have attempted standard remediation without success:
* Adding the service accounts to Privilege Management's "Excluded Users" list resolves the lockouts, but negates security coverage.
* Adjusting the "Account Lockout Threshold" GPO is a workaround, not a solution, and weakens the overall security posture.
The critical questions for the community are therefore empirical:
1. Is this an artifact of a specific policy configuration? Our blocked process policies use a combination of hash rules and path rules with child process control enabled.
2. Has anyone conducted a network packet trace or a Windows API call trace (e.g., via ProcMon) during a service account lockout event to isolate the specific failed authentication attempt that the domain controller is registering?
3. Are there known incompatibilities with other credential protection platforms (e.g., Windows Defender Credential Guard, third-party PAM solutions) that could cause this cascade?
I am publishing the raw, unedited event log sequence from a representative incident below. Note the timestamps and the process information (sanitized). The objective is to move beyond anecdote and towards a reproducible test case.
```
Source Host Application Log:
2024-05-15 14:32:17.521 | Event ID 100 | BeyondTrust | Process Blocked | User: DOMAINsvc_sqlagent | Process: C:WindowsSystem32cmd.exe | PID: 4872 | Rule: Block Unapproved Child Processes
Domain Controller Security Log:
2024-05-15 14:32:19.003 | Event ID 4740 | Account Locked Out | Account: svc_sqlagent | Caller Computer: SOURCE-HOST-NAME
```
The vendor's support has thus far characterized this as an environmental issue. I contend it is a deterministic outcome of specific agent behavior under a definable set of conditions. Shared data on policy sets and lockout events is needed for a proper side-by-side analysis.
- labrat