How Secondary Logon Enabled Admin Rights in Windows XP

In Windows XP, the Secondary Logon service (seclogon) provided the foundational mechanism for running applications with administrative privileges from non-administrative user accounts. By powering the built-in "Run as" feature and the command-line utility runas.exe, this service allowed users to authenticate as an administrator and launch specific programs with elevated security tokens, eliminating the need to log off and switch entire desktop sessions.

The Purpose of Secondary Logon in Windows XP

Windows XP was designed before the introduction of User Account Control (UAC). In default configurations, most users operated under full administrative accounts to avoid permission issues. For environments practicing the principle of least privilege, users operated under restricted accounts. When administrative intervention was necessary—such as running Microsoft Management Console (mmc.exe) snap-ins or installer packages—Windows XP required an in-session elevation tool. The Secondary Logon service provided this capability natively.

Architecture and Service Privileges

The Secondary Logon service ran as a hosted service within an instance of svchost.exe under the NT AUTHORITY\SYSTEM (LocalSystem) security context. Because LocalSystem holds the most powerful privilege set on the local machine—including SeAssignPrimaryTokenPrivilege, SeIncreaseQuotaPrivilege, and SeTcbPrivilege—it had the necessary operating system rights to generate process tokens and assign them to newly created processes.

How Elevation Occurred

When an end user selected "Run as..." by right-clicking an executable or ran runas /user:Administrator <program>, the elevation workflow proceeded through the following stages:

  1. Invocation and Credential Capture: The user supplied target credentials (username and password) along with the command path to be executed.
  2. RPC Communication: The local client process communicated with the seclogon service via an internal Remote Procedure Call (RPC) or Local Procedure Call (LPC) interface.
  3. Authentication and Token Generation: Running as LocalSystem, seclogon.dll invoked internal logon APIs (such as LogonUserW). The Local Security Authority Subsystem Service (LSASS) authenticated the provided credentials against the local Security Accounts Manager (SAM) or an Active Directory domain controller. Upon successful authentication, LSASS created a logon session and generated a new primary security token. This token contained the Security Identifiers (SIDs) and privileges associated with the administrative account, specifically including the local Administrators group SID (S-1-5-32-544).
  4. Desktop and Window Station Assignment: To display the elevated application on the calling user's screen, the service configured the process to interact with the current interactive window station (WinSta0) and desktop (Default).
  5. Process Creation: The service called functions such as CreateProcessWithLogonW (or CreateProcessAsUserW). The target process was spawned with the administrative token attached as its primary access token.

Once launched, the secondary application operated with the full rights of the specified administrative user, allowing system-level configurations to be altered while the caller's main desktop shell (explorer.exe) remained restricted.