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.
3 Answers
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.
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.
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.
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.
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.