改造win2008登录认证，使支持动态口令统一认证

It's Day Two of our series of Windows Server 2008 posts.  Only twenty-five more days to go till the big launch.  Today's topics are Startup Processes and Delayed Automatic Start for System Services.

In previous versions of Windows, during system boot, the Session Manager process (SMSS.EXE) would start the Client-Server Runtime Subsystem (CSRSS.EXE), and the logon process (WINLOGON.EXE).  The Winlogon process would then launch the Local Security Authority Subsystem Service, better known as LSASS.EXE and the Service Control Manager (SERVICES.EXE).  The user logged into the console would be logged into Session 0, which is the shared session used by system processes.  One security risk was that if a poorly written Windows service running in Session 0 displayed a user interface on the interactive console, malware could attack the window using windows messages and possibly gain administrative privileges to the system.

To address these potential issues, several system processes were redesigned for Windows Vista and Windows Server 2008.  SMSS.EXE is still the first user-mode process created during the boot process as in previous versions.  The change is that now SMSS.EXE launches a second instance of itself to configure Session 0, which is dedicated to system processes.  The instance of SMSS.EXE dedicated to Session 0 launches the Windows Startup Application (WININIT.EXE) as well as an instance of CSRSS.EXE for Session 0, after which it exits.  WININIT.EXE continues the startup process by starting SERVICES.EXE and LSASS.EXE as well as a new process, the Local Session Manager (LSM.EXE) which manages Terminal Server connections for the machine.

In parallel with the creation of Session 0, a Console session is also initialized.  The initial instance of SMSS.EXE creates a new instance of itself to configure the Console session - just as it did with Session 0.  The new instance of SMSS.EXE starts an instance of CSRSS.EXE and WINLOGON.EXE for the Console session in preparation for user logon.  WINLOGON.EXE then launches the Logon User Interface Host (LOGONUI.EXE) which presents the Windows Security screen prompting the user to press CTRL+ALT+DELETE to log on.

A quick note here about the Winlogon process.  In previous versions of Windows, WINLOGON.EXE loaded the Graphical Identification and Authentication DLL (GINA) specified in the registry to display a logon UI prompting users for their credentials.  Windows Vista and Windows Server 2008 do not use the GINA, instead there is a new Credential Provider architecture in place.  WINLOGON.EXE launches LOGONUI.EXE to load the credential providers that are configured in the following registry key:  HKLM\Software\Microsoft\Windows NT\CurrentVersion\Authentication\Credential Providers.  LogonUI can host multiple credential providers concurrently and managers the UI displayed to users.  Credential Providers may also specify custom elements to display on the logon screen.  Once the user credentials have been passed to WINLOGON.EXE by LOGONUI.EXE, the LOGONUI.EXE process exits.

When a user attempts to log on to the system, the initial instance of SMSS.EXE creates a new instance of itself to configure the new session just as it did for Session 0 and the Console session.  This new instance of SMSS.EXE starts a CSRSS.EXE process and a WINLOGON.EXE process for the new session.  WINLOGON.EXE starts LOGONUI.EXE to present the logon screen to the user.  This may seem as though it would cause unnecessary overhead on a system, and on a client system, it does not provide any noticeable advantage.  However, on Windows Server 2008 Terminal Server systems, multiple instances of SMSS.EXE can run concurrently - providing faster logons for multiple users.

Let's move on to take a quick look at another new feature of Windows Vista and Windows Server 2008 - Delayed Automatic Start for System Services.  To address the problem of the growing number of services set to start automatically and the subsequent negative impact on boot performance, there is a new start type for services that do not need to start early in the boot process - the Delayed start.  This allows a service to still start automatically, but with the added advantage that boot performance is improved.  Services set to start as Delayed will start shortly after boot.

So how does this work?  The Service Control Manager starts services that are configured for delayed automatic start after all of the automatic-start threads have finished starting.  The Service Control manager also sets the priority of the initial thread for these delayed services to THREAD_PRIORITY_LOWEST.  This causes all of the disk I/O performed by the thread to be very low priority.  Once a service finishes initializing, the priority is set back to normal by the Service Control Manager.  The combination of the delayed start, low CPU and memory priority, as well as the background disk priority greatly reduce the interference with the user's logon.  Many Windows services, including the Background Intelligent Transfer Service (BITS), Windows Update Client, andWindowsMediaCenter, use this new start type to help improve logon performance after a system boot.  To configure a service for delayed automatic start, you can create a REG_DWORD value called DelayedAutoStart in the service's configuration registry key under HKLM\SYSTEM\CurrentControlSet\Services.

That brings us to the end of Day Two.  Tomorrow we will take a look at Service Hardening, which is quite a lengthy topic.  Until next time ...