Refactor group exclusion checks to use Authz API (Resolves AD nesting limitations and SAMR Error 5 blocks)
Overview & Symptoms
Currently, CCredential::CheckExcludedAccount relies on legacy NetApi32 functions (NetUserGetGroups and NetUserGetLocalGroups) to verify if a user belongs to an excluded group. This architecture is causing two distinct issues in production environments:
- Active Directory Nesting Limitations: The current implementation fails to accurately parse and evaluate complex, nested Active Directory group structures.
- Access Denied (Error 5) Blocks: Modern security baselines actively block remote SAM queries (specifically via the GPO: Network access: Restrict clients allowed to make remote calls to SAM). Because the legacy NetApi calls rely on the SAM Remote Protocol (SAMR), the local system's implicit outbound RPC calls to the Domain Controller are rejected. This causes
NetUserGetLocalGroups to fail with Error 5 (Access Denied).
Root Cause
Both issues stem from relying on direct, network-dependent SAMR queries during the pre-authentication phase. The legacy API is unequipped to handle nested AD structures offline and triggers security blocks when attempting to resolve them over the network.
Proposed Solution
Deprecate the use of NetUserGetGroups and NetUserGetLocalGroups. Overhaul the group evaluation logic to use the modern Windows Authz API framework.
By translating the user and target groups into SIDs locally and generating a simulated client context via AuthzInitializeContextFromSid and AuthzGetInformationFromContext:
- We natively inherit Windows' ability to evaluate complex and nested group memberships.
- We bypass the restricted SAMR network endpoints entirely, preventing Error 5 blocks in hardened environments.
Acceptance Criteria
Refactor group exclusion checks to use Authz API (Resolves AD nesting limitations and SAMR Error 5 blocks)
Overview & Symptoms
Currently,
CCredential::CheckExcludedAccountrelies on legacy NetApi32 functions (NetUserGetGroupsandNetUserGetLocalGroups) to verify if a user belongs to an excluded group. This architecture is causing two distinct issues in production environments:NetUserGetLocalGroupsto fail with Error 5 (Access Denied).Root Cause
Both issues stem from relying on direct, network-dependent SAMR queries during the pre-authentication phase. The legacy API is unequipped to handle nested AD structures offline and triggers security blocks when attempting to resolve them over the network.
Proposed Solution
Deprecate the use of
NetUserGetGroupsandNetUserGetLocalGroups. Overhaul the group evaluation logic to use the modern Windows Authz API framework.By translating the user and target groups into SIDs locally and generating a simulated client context via
AuthzInitializeContextFromSidandAuthzGetInformationFromContext:Acceptance Criteria
NetUserGetGroupsandNetUserGetLocalGroupsare completely removed from the exclusion check logic.