This lesson will look at how security is integrated into the Windows 2000 architecture. Knowing how security integrates into the Windows 2000 architecture will assist you in designing security for your Windows 2000 network.
After this lesson, you will be able to
- Discuss how security services are integrated into the Windows 2000 architecture
Estimated lesson time: 45 minutes
The Windows 2000 operating system provides two processor access modes to ensure that applications are unable to directly access hardware and system code. Applications generally run in what is known as user mode and operating system functions run in kernel mode.
The separation of the Windows 2000 architecture into user mode and kernel mode ensures that a runaway user process is unable to corrupt lower-level system drivers that are located in kernel mode. All access to kernel mode is protected. When a user application needs to make a request to system services located in kernel mode, the request must be made through an application programming interface (API). The API will then forward any necessary requests to the required services in kernel mode.
Security in Windows 2000 is split between user mode and kernel mode. In user mode the security subsystem is the actual subsystem where Active Directory directory service runs. In kernel mode the security reference monitor enforces the security rules of the security subsystem. The actual enforcement of security takes place in kernel mode, where user intervention can't occur (see Figure 1.2).
The integration of Active Directory within the security subsystem ensures that distributed security can exist in a Windows 2000 network. Because Active Directory is located in the security subsystem, you can protect all access by a combination of three elements:
- The security principal proving identity and authorization
- The validation that the security principal has the necessary permissions to perform the task
Figure 1.2 Security within the Windows 2000 architecture
The security subsystem performs the authorization by passing the request to the security reference monitor in kernel mode in order to compare the request to the discretionary access control list (DACL) of the object that's being connected to. The DACL contains access control entries (ACEs) that define the permissions assigned to security principals for the object. Each ACE defines a security principal and the permissions that are assigned to that security principal for the object.
Security Subsystem Components
The security subsystem runs within the security context of the local security authority (LSA) process. This process is split between user mode and kernel mode. The components within the local security authority process include:
- Netlogon service (Netlogon.dll). The Netlogon service maintains a computer's secure channel to a domain controller in its domain. The Netlogon service passes credentials to the domain controller through a secure channel and returns an access token populated with security identifiers and user rights for the security principal.
In mixed mode, the Netlogon service is responsible for the replication of Active Directory data to any Windows NT backup domain controllers that exist in the domain. (Unless otherwise noted, "Windows NT" refers to versions 3.51 and 4.0.)
- NTLM authentication protocol (Msv1_0.dll). NTLM is used to authenticate clients that are unable to use Kerberos authentication. This includes Windows 95, Windows 98, and Windows NT computers.
- Secure Sockets Layer (SSL) authentication protocol (Schannel.dll). SSL provides encryption services to transported data at the application layer. All data that's passed through the encrypted channel is protected against inspection on the network. To use SSL, the application must be coded to recognize and implement SSL.
- Kerberos v5 authentication protocol (Kerberos.dll). Kerberos v5 is the default authentication protocol used by Windows 2000. Kerberos authentication is based on the use of ticket-granting tickets (TGTs) and service tickets.
You'll find a more detailed discussion of the Kerberos v5 protocol in Chapter 3, "Designing Authenticationfor a Microsoft Windows 2000 Network."
- Kerberos Key Distribution Center (KDC) service (Kdcsvc.dll). The KDC service is responsible for issuing TGTs to clients when they initially authenticate with the network. A TGT is then used for subsequent requests to acquire service tickets to provide authentication of the requesting client.
- LSA server service (Lsasrv.dll). The LSA server service enforces all defined security policies within Active Directory.
- Security Accounts Manager (SAM) (Samsrv.dll). The SAM is used on non-domain controllers for the storage of local security accounts. The SAM also enforces all locally stored policies.
- Directory Service module (ntdsa.dll). The Directory Service module supports replication between Windows 2000 domain controllers, all Lightweight Directory Access Protocol (LDAP) access to Active Directory and management of naming contexts stored in Active Directory. The naming contexts include the domain naming context, the configuration naming context, and the schema naming context.
- Multiple Authentication Provider (Secur32.dll). This Security Support Provider (SSP) supports all security packages available on the system. The security packages include the Kerberos, Windows NT LAN Manager (NTLM), Secure channel, and Distributed Password Authentication (DPA) packages.
The LSA maintains all local security information for a Windows 2000–based computer. The LSA provides the following functionality:
- It allows users to authenticate interactively with the Windows 2000–based computer.
- It generates an access token for the security principal during the authentication process. The access token contains the security identifiers (SIDs) for the user account and all groups that contain the user account as a member.
If the user account or group account was previously a member of a different domain, the sIDHistory attribute is also included in the user's access token. This allows the user to access any resources that contain the previous SID in the object's DACL.
- It manages local security policy. This includes all security policies that have been defined for the local computer. These settings may be overridden if any Group Policies are defined at the site, domain, or organizational unit (OU) level in Active Directory.
- It manages audit policy and settings. This includes writing the alert to the correct event log when an audit alert is generated by the security reference monitor in kernel mode.
- It builds a list of trusted domains that are provided to populate the Log On To drop-down list in the Windows 2000 authentication dialog box.
- It determines which users have been assigned privileges.
- It reads the system access control lists (SACL) for each object to determine what security auditing has been defined for the object.
- It determines what user rights have been assigned to a security principal and ensures that a security principal can't perform tasks they don't have the necessary rights for.
- It manages memory quotes for the usage of both paged and nonpaged memory usage.
Windows 2000 Security Protocols
Windows 2000 allows multiple network security protocols to provide authentication services. This ensures the maximum compatibility for network clients. These clients can include Microsoft clients from previous operating systems as well as foreign clients, such as UNIX clients. Supporting multiple security protocols ensures maximum secure access to a Windows 2000 network. You aren't forced to use a specific security protocol.
Windows 2000 supports four different security protocols, as shown in Figure 1.3.
Figure 1.3 Windows 2000 supports multiple security protocols
- Windows NT LAN Manager (NTLM). Used by Windows NT, Windows 95, and Windows 98 clients with the Directory Services client installed. NTLM is used for pass-through network authentication, local account authentication for Windows 2000 Professional and Windows 2000 member servers, and access to previous Microsoft operating systems. The NTLM security provider uses the MSV1_0 authentication service and the Netlogon service to provide client authentication and authorization.
- Kerberos v5. The default security protocol for Windows 2000–based computers. Kerberos provides mutual authentication of client and server, better performance, and support for delegation. The Kerberos security provider uses the Key Distribution Center (KDC) service on a domain controller and Active Directory for obtaining TGTs and service tickets.
- Distributed Password Authentication (DPA). A shared secret authentication protocol used by Internet membership organizations such as MSN. DPA is part of Microsoft Commercial Internet System (MCIS) services and allows you to use a single account and password to connect to all Internet sites that are a member of the same Internet membership organization. DPA uses the MCIS security services (known as the membership service) for membership authentication and server-specific access information.
- Secure channel (SChannel) services. Provide the ability to authenticate using public key–based protocols such as SSL and Transport Layer Security (TLS). If you use a public key infrastructure (PKI), these protocols can provide authentication of both client and servers in a distributed network. Within Windows 2000, you can deploy a public key infrastructure using Certificate Services to establish Certification Authorities (CAs). These CAs are responsible for issuing digital certificates that will be used for authentication.
The Security Support Provider Interface (SSPI)
The Security Support Provider Interface (SSPI) prevents applications from determining what Windows 2000 security protocols are used to authenticate the security principal. The SSPI communicates with a Win32 API based on the Generic Security Service Application Program Interface (GSSAPI) and provides similar interface abstraction for security context management.
The GSSAPI is defined in Request for Comment (RFC) 1508, "Generic Security Services Application Program Interface." All definitions of standard Transmission Control Protocol/Internet Protocol (TCP/IP)–based protocols and services are defined in RFCs. You can find RFCs by going to www.rfc-editor.org/rfc.html and searching for the RFC number.
When the security protocol has been concealed, applications don't have to be coded to specifically support each of the network security protocols. The application only needs to call SSPI routines directly or use connection management protocols provided by Remote Procedure Calls (RPCs) or Distributed Component Object Model (DCOM) processes to authenticate.
This lesson examined the Windows 2000 security services model. It provided an overview of the Windows 2000 security subsystem components, the functionality of the LSA, Windows 2000 security protocols, and the SSPI.
You don't have to understand how security is implemented in Windows 2000 in order to design security. But it's useful to know how the security functions interact with the Windows 2000 operating system. Knowing the Windows 2000 security services helps you design Windows 2000 security solutions.