PREEMPTIVE_OS_LOGONUSER is recorded when a thread calls the Windows LogonUser function, which authenticates a set of credentials and produces a logon token. SQL Server needs it wherever it must become another Windows identity: Agent proxies running job steps under credentials, linked servers mapped to specific Windows accounts, and other credential-object usage.
Each call is an authentication round trip, so it inherits your domain infrastructure’s latency.
Is It a Problem?
Not at normal volumes; occasional token creation is cheap when AD is healthy. It earns attention when it grows in count (something is authenticating credential-mapped identities at high frequency, per-job-step or worse) or in average duration (the domain controllers answering slowly, the same story as PREEMPTIVE_OS_AUTHENTICATIONOPS).
High-frequency LogonUser traffic is also worth knowing about from a security-audit angle; it means stored credentials are in active use.
Common Causes
- Agent proxies executing many job steps under credential objects.
- Linked servers with explicit credential mappings authenticating per connection.
- Slow or distant domain controllers stretching each call.
What To Do
- Inventory the credential users: Agent proxies (
msdb.dbo.sysproxies) and linked server mappings (sys.linked_logins). - Reduce per-call churn where volume is the issue: fewer, longer job steps under one proxy beat many tiny ones.
- For duration problems, hand the AD latency evidence to the infrastructure team, as with the other authentication waits.
How To See It
Rank it against everything else with Get-WaitStatistics, alongside the other PREEMPTIVE_OS_ authentication family members.
PREEMPTIVE_OS_LOGONUSER is background noise on a healthy instance. If you are chasing a real problem, start with the waits that actually cost you time.
- The waits that usually matter, ranked, with what each one is telling you.
- Performance & Troubleshooting, the scripts and guides for this part of the stack.
Leave a Reply