Inside Windows Server 1002003 [Electronic resources] نسخه متنی

Windows Server 2003 Security Architecture

It pays to have a solid map in your mind of how the various components of the Windows Server 2003 security system work together. This helps you design a secure system and diagnose problems when they arise. Figure 11.1 shows the major components of the security system, called the

Local Security Authority , or LSA.

Here are a few items of note in the figure:

• Authentication is achieved via password-based transactions involving Kerberos or classic NT LanMan (NTLM) Challenge-Response. The security system also directly supports third-party mechanisms that do not rely on passwords, such as smart cards, and permits add-on mechanisms such as biometrics.




• Authorization is achieved by protecting resources with special data structures called

  security descriptors that identify who can access a resource and what they can do. All processes are identified by

  access tokens that define the security context of the user.




• Auditing is handled by special functions in the security system designed to log access to secured objects.

The LSA consists of kernel-mode services running as part of the Windows Executive and user-mode services that control client/server processes such as interactive logon and granting network access permissions. The user-mode security services in the LSA are contained in two executables: the

Local

Security Authority Subsystem , or LSASS, and Winlogon. LSASS hosts the following processes:

• Kerberos KDC.
  This service provides Kerberos authentication and ticket granting services. It uses Active Directory to store security credentials.




• NTLM security support provider.
  This service provides classic NT authentication and security management. It supports all downlevel clients and those modern Windows clients that are not members of a domain.




• Security Account Manager.
  This service is responsible for obtaining user credentials from the Security Account Manager (SAM) database in response to requests from the legacy NTLM provider.




• Netlogon.
  This service supports classic NT authentication by handling pass-through authentication from downlevel clients. Netlogon is not used to support Kerberos transactions. On Active Directory-based domain controllers, Netlogon is responsible for registering DNS records.




• IPSec.
  This service manages IP Security (IPSec) connection policies and IPSec Internet Key Exchange (IKE).




• Protected Storage.
  This service is responsible for encrypting and safely storing certificates associated with the PKI subsystem.

LSA Components

When you buy a stereo at Best Buy or Circuit City, you engage in a series of transactions with the sales clerk. The clerk takes your credit card, runs it through a machine that checks it against a database somewhere in the world, obtains your signature to document the sale, and bundles up your purchase for transport.

If you flowchart the little formalities of this purchase, you would identify the standard security elements: authentication, authorization, and auditing. Any one of these elements could be performed differently without affecting the others. For instance, if you present a check rather than a credit card, the authentication steps would expand to include a look at your driver's license.

When you access secure resources on a server, you encounter a similar set of security transactions. The services that manage these transactions are called

packages. There are two package types:

authentication packages and

security packages.

Authentication Packages

As you might expect, an authentication package verifies your identity. Microsoft provides two authentication packages:

• Kerberos.
  A three-way authentication mechanism where a server uses a secret key issued by a trusted source to verify the identity of a client.




• MSV1_0.
  The legacy NT authentication package. This is often called a challenge-response authentication because it involves the transfer of an encrypted random number called a

  challenge . Windows Server 2003 supports LanMan (LM) Challenge-Response for DOS-origin clients (Windows 3.11, Windows 9x, and ME) and NT LanMan (NTLM) Challenge-Response for both NT clients and modern Windows clients that are not members of a domain.

Classic Security Databases

NTLM authentication stores security information in the Registry inside three databases:

• Builtin.
  This database contains the two default user accounts, Administrator and Guest, along with various default groups such as Domain Users for domains and Power User for workstations and standalone servers. The Administrator and Guest accounts cannot be deleted but they can be renamed. Builtin groups have special operating system privileges. They cannot be deleted or renamed. The Builtin accounts are contained in the SAM Registry hive.




• Security Account Manager (SAM).
  This database contains local user and group accounts. In classic NT, the SAM on a primary domain controller (PDC) defines the security entities in a domain. The SAM database is contained in the SAM Registry hive.




• LSA.
  This database contains the password rules, system policies, and trust accounts for the computer. The LSA database is contained in the Security Registry hive. This hive also contains a copy of the SAM database.

When you upgrade a classic PDC to Windows Server 2003, most of the contents of the Registry databases are migrated into Active Directory. System privileges and user rights defined by policies in the classic LSA database are replaced by a set of group policies stored in the Secedit.sdb database in \Windows\Security\Database.

Security Packages

A security package contains the protocols and features needed to manage credentials access, protect data, and secure message streams between clients and servers.

Security packages are also called a

Security Support Providers , or SSPs. Applications that consume security services are not required to know the eccentricities of these providers. A single interface called the

Security Support Provider Interface , or SSPI, abstracts the functions of the security providers. This is similar, in concept, to the way Open Database Connectivity (ODBC) abstracts access to databases and Network Device Interface Specification (NDIS) abstracts access to network cards.

Microsoft provides the following security packages in Windows Server 2003:

• Kerberos.
  Kerberos occupies a special position because it acts as both an authentication package and a security package. As a security package, it supports access by applications that are coded to present Kerberos tickets when they attempt access to resources. These are called

  Kerberized applications. An example would be the CIFS/SMB network file system service in Windows Server 2003 and Windows 2000. (SMB stands for Server Message Block, the command language used by Windows networking. CIFS stands for Common Internet File System, another term for SMB.)




• NTLM.
  This package supports connections by downlevel Windows clients and standalone Windows Server 2003, XP, and Windows 2000 machines.




• Digest.
  This is Microsoft's implementation of RFC 2617, "HTTP Authentication: Basic and Digest Access Authentication." The Digest package also includes support for the Digest authentication included in the

  Simple Authentication and Security Layer (SASL) protocol as defined in RFC 2831, "Using Digest Authentication as a SASL Mechanism." The new version of the Digest package in Windows Server 2003 permits using the MD4 password hash to encrypt the challenge, eliminating the need for reversible passwords.




• Schannel .
  This package contains the security protocols necessary to support private, protected web communications. This package contains the following security protocols: Transport Layer Security (TLS), Secure Sockets Layer (SSL), and Private Communications Technology (PCT).




• Negotiate.
  This pseudo-provider does not actually contain security protocols. Instead, it permits a client to discover the available security packages and to decide which one to use. For example, a Kerberized application calling Negotiate would be passed on to the Kerberos package.

In addition to the main security packages, Windows includes the following packages that are not included in Figure 11.1:

• Standard Digest authentication




• Clear text password authentication




• Distributed Password Authentication (for MSN support)




• Old-style MSN authentication

Winlogon

LSA needs some mechanism for obtaining logon credentials from users. The executable responsible for obtaining these credentials is Winlogon. You call up the services of Winlogon when you press Ctrl+Alt+Del, also known as the

Secure Attention Sequence (SAS) .

This brings up a Security window, also controlled by Winlogon. If you have not yet logged on, the security window presents you with a place to enter your logon credentials. If you have already logged on, the Security window presents you with the option to logoff, shutdown, lock the computer, change your password, or open the Task Manager.

The windows presented by Winlogon come from a DLL called

Graphical Identification and Authentication (GINA). Independent software vendors (ISVs) can write replacements or enhancements to the GINA to capture their own credentials. For example, Novell's Netware client installs a custom GINA that collects additional logon credentials for Novell Directory Services.

Security Reference Monitor (SRM)

If you think of a domain or a server as a castle that has authentication packages as gatekeepers, the Security Reference Monitor would be a contingent of bodyguards that protect individuals within the castle.

Windows provides discrete security for objects such as NTFS /image/library/english/10220_folders, Registry keys, Active Directory objects, printers, services, and kernel processes. It does so by linking each object to a special data structure called a

security descriptor . The security descriptor contains an

access control list , or ACL, that identifies the users, computers, and groups that are allowed access or denied access to the object.

When a user logs on, the LSASS builds an

access token that represents the user to the security system. This token contains the user's security ID (SID) along with the SID for any groups that have the user as a member and a variety of security policy settings such as logon expiration time and password complexity requirements.

When a process owned by the user tries to touch a secure object, the Security Reference Monitor compares the SIDs in the security descriptor with the SIDs in the user's access token and derives a set of access permissions for the user.

Access tokens, like politics, are always local. They do not accompany users around the network. When a user connects to a server, the LSASS on that server must build a local access token representing the user so it can attach the token to the user's processes. The LSASS obtains the information it needs to build this local access token in one of two ways:

• For Kerberos authentication, it gets the information from the Authorization Data field inside the Kerberos session ticket presented by the client.




• For NTLM authentication, it gets the information from a domain controller as part of a pass-through authentication transaction.

It's important that the information used to build the access token be protected. If a bad guy could hijack an access token or otherwise compromise the mechanism that builds the access token, it doesn't matter if the authentication system is bulletproof; the bad guy still gets access.

Overview of LSA Operation

Let's pause here for a moment and take quick look at the cast of characters we've seen so far and how they fit into the three A's of authentication, authorization, and auditing:

1. Winlogon collects logon credentials from the user.

2. LSASS takes these credentials and uses them to validate the user's identity with the help of Kerberos or NTLM (via MSV1_0). This is the authentication stage.

3. LSASS builds an access token that defines the user's access permissions and system privileges.

4. The Security Reference Monitor (SRM) compares this token to the access control list (ACL) in an object's security descriptor to decide whether to give access to the user. This is the authorization stage.

5. Finally, LSASS and SRM work together to monitor access to security objects and build reports that record any or all of those access events. This is the auditing stage.

Now let's examine the fine points of these security components with an eye towards configuration options and potential vulnerabilities.