PREEMPTIVE_OS_LOOKUPACCOUNTSID is recorded while a thread calls the Windows LookupAccountSid function, which translates a security identifier (SID) into an account name. For domain accounts that translation can leave the server entirely and query a domain controller, so each call inherits your AD infrastructure’s latency.
The classic T-SQL trigger is SUSER_SNAME() with an explicit SID argument, which maps straight onto this API.
Is It a Problem?
Occasional lookups are routine. It becomes a real bottleneck in one well-worn pattern: code calling SUSER_SNAME(sid) in a loop, per row or per execution, with each call round-tripping to a DC. In one reported case this was the top wait on an instance because every lookup crossed the Atlantic to a remote domain controller. Auditing queries, security reports, and metadata sweeps over sys.server_principals are the usual suspects.
Long average waits also implicate the AD side: slow or distant DCs make every lookup expensive regardless of call frequency.
Common Causes
SUSER_SNAME(sid)(or similar SID translation) called at high frequency in application or audit code.- Slow, overloaded, or geographically remote domain controllers.
- DNS or site configuration steering lookups to the wrong DC.
- Security tooling sweeping large numbers of SIDs.
What To Do
- Find the calling code: catch sessions in this wait via
sys.dm_exec_requestsand look for SID translation in the SQL text. - Fix the pattern: translate SIDs once and cache or join the result, instead of calling per row.
- If per-call latency is the issue, hand the evidence to the infrastructure team;
nltest /dsgetdc:shows which DC the server actually uses. - For audit reports, consider persisting name mappings on a schedule rather than resolving live.
How To See It
Rank it against everything else with Get-WaitStatistics, and read it alongside PREEMPTIVE_OS_AUTHENTICATIONOPS; both are AD latency meters.
Part of the SQL Server Wait Types Library.
Related deep dive: SOS_SCHEDULER_YIELD Wait Type.
Leave a Reply