Why does Get-ADPrincipalGroupMembership trigger a SeLoadDriverPrivilege audit failure?
Asked by
MellowCedar42
When I run Get-ADPrincipalGroupMembership from a workstation, it fails with "An unspecified error has occurred." At the same time, the Windows Security log records an audit failure involving SeLoadDriverPrivilege. The cmdlet should be performing Active Directory or Global Catalog lookups, not loading kernel drivers, so I'm trying to understand whether this privilege is genuinely required or whether the audit entry is an unrelated side effect. Other AD tools work with our existing permissions, and this command used to work before recent security changes. I also tested different domain controllers and ports: the Global Catalog returns "The operation is not supported on Global Catalog port," while port 389 falls back to the unspecified error.
Answers
Try running it from a non-elevated RSAT or management workstation and explicitly target a known-good domain controller. For example: Get-ADPrincipalGroupMembership someuser -Server dc01.example.com. If that works, investigate DC discovery, ADWS, Global Catalog selection, or the particular session the module is using rather than granting SeLoadDriverPrivilege.
Reply to this answer
SeLoadDriverPrivilege almost certainly isn’t a real requirement of this cmdlet. The audit entry may be coming from an underlying WMI, ADWS, or security-context operation rather than from the command actually trying to load a driver. Check the session with whoami /priv and compare a filtered or elevated token, but treat the privilege audit as a possible red herring.
QuartzHarbor5: That was my suspicion too—the denial appears even when the command returns a different error, which makes it look more like a backend or session-side event than a direct dependency.
Reply to this answer
If the cmdlet remains unreliable, an LDAP-based lookup through ADSI Searcher can avoid this particular AD module path and may perform better for repeated queries. Still, I wouldn’t grant SeLoadDriverPrivilege just to make Get-ADPrincipalGroupMembership work; first compare the affected account’s token, ADWS health, and the DC handling the request.
Reply to this answer
Add your answer
Answers are reviewed before publication.
NimbusCrayon63: The Global Catalog port is not suitable for this cmdlet, so use a regular LDAP endpoint or a specific DC instead. A GC test returning “operation not supported” is expected for some AD operations.