How Windows Boots

...and how you should do your testing.

© 2012 Dennis Leeuw dleeuw at made-it dot com
License: GPLv2 or later

Index

    1. Introduction
      2.
    2. Boot Loader
      3.
    3. Kernel Boot
      4.
    4. User Logon
      5.
    5. Testing Windows Logons
      6.
    6. Resources
      7.

Introduction

After the hardware has been initialized by the BIOS, the control is handed over to the boot loader, which loads the operating system. After that the following steps follow:

  1. Boot loader: NTLDR
  2. Operating System: ntoskrnl.exe
  3. Authenticate User: winlogon.exe

Boot Loader

  1. NTLDR
    1. switches the processor from real-mode to 32 bit protected mode
    2. loads boot.ini
    3. Gives you a boot choice if needed
    4. Starts ntdetect.com which detects hardware information that is passed on to ntoskrnl.exe
    5. runs: ntoskrnl.exe

Kernel Boot

  1. ntoskrnl.exe
  2. hal.dll
  3. kdcom.dll
  4. bootvid.dll (Windows logo)
  5. Start the Remote Procedure Call (RPC) service (rpcss.exe)
  6. Start the Multiple UNC Provider (MUP) service (mup.sys)
  7. Apply computer settings by processing the Group Policies for this system
  8. Run startup scripts for this system
  9. The last task is to start the Session Manager (smss.exe).
    1. Starts Autochk which mounts the drives
    2. Makes sure the graphical environment is started (win32k.sys)
    3. It executes winlogon.exe

User Logon

winlogon.exe handles the services that deal with the system logon. It starts services.exe (the Service Control Manager), lsass.exe (the Local Security Authority) and handles the Ctrl+Alt+Del key press. The GINA (Graphical Identification and Authentication) DLL generates the logon dialog box.

  1. The provided credentials are handed over by GINA to the LSA, which checkes them against a local SAM, Domain Controller SAM or Active Directory.
    1. If it succeeds the system continues, where winlogon.exe initializes security and authentication components while the SCM initializes auto-load services and drivers.
    2. If it failes, the credentials are cheched against the localy stored cache
      1. If it succeeds the system continues
      2. If it fails, access is denied and the login dialog is provided again.

NOTE: After a succesful domain logon, the logon credentials are cached on the logon station. This means that later a user can logon to the station with the same credentials in the absence of a domain controller! Which is a powerful solution if you want to work on work related documents while traveling, but it important to remember when you are testing new systems. It might happen that you are logged in through cached credentials and not through the new server you just installed. The credentials are cached in the registry under HKLM\Security\Cache. By default this happens for the last 10 users, so clean this registry when testing. More information can be found at http://moyix.blogspot.com/2008/02/cached-domain-credentials.html.

After you are logged in, the following happens:

  1. The system checks if there is a profile on the server (User Manager for Domains)
    1. If the profile is found it is loaded
    2. If the profile is not found or there is no server, check if there is a local (cached) profile with that name
      1. If there is, load it
      2. If there is not, check if there is a Default User on the [netlogon] share of the validating server
        1. If there is: copy it to the local machine as the new profile, and load it
        2. If there is not: copy the Default User of the local system, and load it
  2. FIXME home should be mapped somewhere
  3. Apply Group Policies for this user (ntconfig.pol or config.pol)
  4. Run logon scripts for this user (logon.bat)
  5. Playing logon sound

NOTE: In SAMBA, if a [homes] share is present and a request is recieved for [username], SAMBA tries to figure out if a user with "username" exists. If the user is present a share is created with the path set to the home-directory of this user and the user is connected to that share.

Testing Windows Logons

The fact that Windows caches credentials and stores a local copy of the Profile it might mean that during testing you are actually testing the cache instead of the new setup. To prevent this from happening this section gives you a procedure for dealing with this:

  1. Initial setup:
    1. Create a test account in LDAP (and Kerberos if used)
    2. Login on a machine that is part of the domain
    3. Change the background image/color
    4. Log out
  2. The test
    1. Log in as administrator
    2. Remove the profile of the test user
    3. Remove all NL$?? caches from HKey_Local_Machine\Security\Cache
    4. Shutdown the computer
    5. Boot the computer
    6. Log in as the test user
  3. Clean up
    1. Log in as administrator
    2. Remove the profile of the test user
    3. Remove the profile from server
    4. Remove the NL$1 cache from HKey_Local_Machine\Security\Cache
    5. Remove account from LDAP

Resources