Security System Components

[Previous] [Next]

Here are some of the components and databases that implement Windows 2000 security:

• Security reference monitor (SRM) A component in the Windows 2000 executive (\Winnt\System32\Ntoskrnl.exe) that is responsible for performing security access checks on objects, manipulating privileges (user rights), and generating any resulting security audit messages.
• Local security authority subsystem (Lsass) A user-mode process running the image \Winnt\System32\Lsass.exe that is responsible for the local system security policy (such as which users are allowed to log on to the machine, password policies, privileges granted to users and groups, and the system security auditing settings), user authentication, and sending security audit messages to the Event Log. The local security authority service (Lsasrv—\Winnt\System32\Lsasrv.dll), a library that Lsass loads, implements most of this functionality.
• Lsass policy database A database that contains the local system security policy settings. This database is stored in the registry under HKLM\SECURITY. It includes such information as what domains are entrusted to authenticate logon attempts, who has permission to access the system and how (interactive, network, and service logons), who is assigned which privileges, and what kind of security auditing is to be performed. The Lsass policy database also stores "secrets" that include logon information used for cached domain logons and Win32 service user-account logons. (See Chapter 5 for more information on Win32 services.)
• Security Accounts Manager (SAM) service A set of subroutines responsible for managing the database that contains the usernames and groups defined on the local machine. The SAM service, which is implemented as \Winnt\System32\Samsrv.dll, runs in the Lsass process.
• SAM database A database that contains the defined local users and groups, along with their passwords and other attributes. This database is stored in the registry under HKLM\SAM.
• Active Directory A directory service that contains a database that stores information about objects in a domain. A domain is a collection of computers and their associated security groups that are managed as a single entity. Active Directory stores information about the objects in the domain, including users, groups, and computers. Password information and privileges for domain users and groups are stored in Active Directory, which is replicated across the computers that are designated as domain controllers of the domain. The Active Directory server, implemented as \Winnt\System32\Ntdsa.dll, runs in the Lsass process.
• Authentication packages DLLs that run in the context of the Lsass process and that implement Windows 2000 authentication policy. An authentication DLL is responsible for checking whether a given username and password match, and if so, returning to the Lsass information detailing the user's security identity.
• Logon process (Winlogon) A user-mode process running \Winnt\System32\Winlogon.exe that is responsible for responding to the SAS and for managing interactive logon sessions. Winlogon creates a user's shell (user-interface) process when the user logs on, for example.
• Graphical Identification and Authentication (GINA) A user-mode DLL that runs in the Winlogon process and that Winlogon uses to obtain a user's name and password or smart card PIN. The standard GINA is \Winnt\System32\Msgina.dll.
• Net Logon service (Netlogon) A Win32 service (\Winnt\System32\Netlogon.dll) that runs inside Lsass and responds to Microsoft LAN Manager 2 Windows NT (pre-Windows 2000) network logon requests. Authentication is handled as local logons are, by sending them to Lsass for verification. Netlogon also has a locator service built into it for locating domain controllers.
• Kernel Security Device Driver (KSecDD) A kernel-mode library of functions that implement the local procedure call (LPC) interfaces that other kernel-mode security components, including the Encrypting File System (EFS), use to communicate with Lsass in user mode. KSecDD is located in \Winnt\System32\Drivers\Ksecdd.sys.

Figure 8-1 shows the relationships among some of these components and the databases they manage.

Figure 8-1 Windows 2000 security components

The SRM, which runs in kernel mode, and Lsass, which runs in user mode, communicate using the LPC facility described in Chapter 3. During system initialization, the SRM creates a port, named SeRmCommandPort, to which Lsass connects. When the Lsass process starts, it creates an LPC port named SeLsaCommandPort. The SRM connects to this port, resulting in the creation of private communication ports. The SRM creates a shared memory section for messages longer than 256 bytes, passing a handle in the connect call. Once the SRM and Lsass connect to each other during system initialization, they no longer listen on their respective connect ports. Therefore, a later user process has no way to connect successfully to either of these ports for malicious purposes—the connect request will never complete.

Figure 8-2 shows the communication paths as they exist after system initialization.

Figure 8-2 Communication between the SRM and Lsass