• Chapter 1. Installing and Configuring Windows Server 2003
  • software development Company Server 2003
  • Chapter 1. Installing and Configuring Windows Server 2003
  • New Features in Windows Server 2003
  • Best Practices
  • Moving Forward
  • Version Comparisons
  • Hardware Recommendations
  • Installation Checklist
  • Functional Overview of Windows Server 2003 Setup
  • Installing Windows Server 2003
  • Post Setup Configurations
  • Functional Description of the Windows Server 2003 Boot Process
  • Correcting Common Setup Problems
  • Chapter 2. Performing Upgrades and Automated Installations
  • New Features in Windows Server 2003
  • NT4 Upgrade Functional Overview
  • Upgrading an NT4 or Windows 2000 Server
  • Automating Windows Server 2003 Deployments
  • Moving Forward
  • Chapter 3. Adding Hardware
  • New Features in Windows Server 2003
  • Functional Description of Windows Server 2003 Architecture
  • Overview of Windows Server 2003 Plug and Play
  • Installing and Configuring Devices
  • Troubleshooting New Devices
  • Moving Forward
  • Chapter 4. Managing NetBIOS Name Resolution
  • New Features in Windows Server 2003
  • Moving Forward
  • Overview of Windows Server 2003 Networking
  • Name Resolution and Network Services
  • Network Diagnostic Utilities
  • Resolving NetBIOS Names Using Broadcasts
  • Resolving NetBIOS Names Using Lmhosts
  • Resolving NetBIOS Names Using WINS
  • Managing WINS
  • Disabling NetBIOS-over-TCP/IP Name Resolution
  • Chapter 5. Managing DNS
  • New Features in Windows Server 2003
  • Configuring a Caching-Only Server
  • Configuring a DNS Server to Use a Forwarder
  • Managing Dynamic DNS
  • Configuring Advanced DNS Server Parameters
  • Examining Zones with Nslookup
  • Command-Line Management of DNS
  • Configuring DHCP to Support DNS
  • Moving Forward
  • Overview of DNS Domain Structure
  • Functional Description of DNS Query Handling
  • Designing DNS Domains
  • Active Directory Integration
  • Configuring DNS Clients
  • Installing and Configuring DNS Servers
  • Configuring Secondary DNS Servers
  • Integrating DNS Zones into Active Directory
  • Chapter 6. Understanding Active Directory Services
  • New Features in Windows Server 2003
  • Active Directory Support Files
  • Active Directory Utilities
  • Bulk Imports and Exports
  • Moving Forward
  • Limitations of Classic NT Security
  • Directory Service Components
  • Brief History of Directory Services
  • X.500 Overview
  • LDAP Information Model
  • LDAP Namespace Structure
  • Active Directory Namespace Structure
  • Active Directory Schema
  • Chapter 7. Managing Active Directory Replication
  • New Features in Windows Server 2003
  • Replication Overview
  • Detailed Replication Transaction Descriptions
  • Designing Site Architectures
  • Configuring Inter-site Replication
  • Controlling Replication Parameters
  • Special Replication Operations
  • Troubleshooting Replication Problems
  • Moving Forward
  • Chapter 8. Designing Windows Server 2003 Domains
  • New Features in Windows Server 2003
  • Design Objectives
  • DNS and Active Directory Namespaces
  • Domain Design Strategies
  • Strategies for OU Design
  • Flexible Single Master Operations
  • Domain Controller Placement
  • Moving Forward
  • Chapter 9. Deploying Windows Server 2003 Domains
  • New Features in Windows Server 2003
  • Preparing for an NT Domain Upgrade
  • In-Place Upgrade of an NT4 Domain
  • In-Place Upgrade of a Windows 2000 Forest
  • Migrating from NT and Windows 2000 Domains to Windows Server 2003
  • Additional Domain Operations
  • Moving Forward
  • Chapter 10. Active Directory Maintenance
  • New Features in Windows Server 2003
  • Loss of a DNS Server
  • Loss of a Domain Controller
  • Loss of Key Replication Components
  • Backing Up the Directory
  • Performing Directory Maintenance
  • Moving Forward
  • Chapter 11. Understanding Network Access Security and Kerberos
  • New Features in Windows Server 2003
  • Windows Server 2003 Security Architecture
  • Security Components
  • Password Security
  • Authentication
  • Analysis of Kerberos Transactions
  • MITv5 Kerberos Interoperability
  • Security Auditing
  • Moving Forward
  • Chapter 12. Managing Group Policies
  • New Features in Windows Server 2003
  • Group Policy Operational Overview
  • Managing Individual Group Policy Types
  • Moving Forward
  • Chapter 13. Managing Active Directory Security
  • New Features in Windows Server 2003
  • Overview of Active Directory Security
  • Using Groups to Manage Active Directory Objects
  • Service Accounts
  • Using the Secondary Logon Service and RunAs
  • Using WMI for Active Directory Event Notification
  • Moving Forward
  • Chapter 14. Configuring Data Storage
  • New Features in Windows Server 2003
  • Functional Description of Windows Server 2003 Data Storage
  • Performing Disk Operations on IA32 Systems
  • Recovering Failed Fault Tolerant Disks
  • Working with GPT Disks
  • Moving Forward
  • Chapter 15. Managing File Systems
  • New Features in Windows Server 2003
  • Overview of Windows Server 2003 File Systems
  • NTFS Attributes
  • Link Tracking Service
  • Reparse Points
  • File System Recovery and Fault Tolerance
  • Quotas
  • File System Operations
  • Moving Forward
  • Chapter 16. Managing Shared Resources
  • New Features in Windows Server 2003
  • Functional Description of Windows Resource Sharing
  • Configuring File Sharing
  • Connecting to Shared Folders
  • Resource Sharing Using the Distributed File System (Dfs)
  • Printer Sharing
  • Configuring Windows Server 2003 Clients to Print
  • Managing Print Services
  • Moving Forward
  • Chapter 17. Managing File Encryption
  • New Features in Windows Server 2003
  • File Encryption Functional Description
  • Certificate Management
  • Encrypted File Recovery
  • Encrypting Server-Based Files
  • EFS File Transactions and WebDAV
  • Special EFS Guidelines
  • EFS Procedures
  • Moving Forward
  • Chapter 18. Managing a Public Key Infrastructure
  • New Features in Windows Server 2003
  • Moving Forward
  • PKI Goals
  • Cryptographic Elements in Windows Server 2003
  • Public/Private Key Services
  • Certificates
  • Certification Authorities
  • Certificate Enrollment
  • Key Archival and Recovery
  • Command-Line PKI Tools
  • Chapter 19. Managing the User Operating Environment
  • New Features in Windows Server 2003
  • Side-by-Side Assemblies
  • User State Migration
  • Managing Folder Redirection
  • Creating and Managing Home Directories
  • Managing Offline Files
  • Managing Servers via Remote Desktop
  • Moving Forward
  • Chapter 20. Managing Remote Access and Internet Routing
  • New Features in Windows Server 2003
  • Configuring a Network Bridge
  • Configuring Virtual Private Network Connections
  • Configuring Internet Authentication Services (IAS)
  • Moving Forward
  • Functional Description of WAN Device Support
  • PPP Authentication
  • NT4 RAS Servers and Active Directory Domains
  • Deploying Smart Cards for Remote Access
  • Installing and Configuring Modems
  • Configuring a Remote Access Server
  • Configuring a Demand-Dial Router
  • Configuring an Internet Gateway Using NAT
  • Chapter 21. Recovering from System Failures
  • New Features in Windows Server 2003
  • Functional Description Ntbackup
  • Backup and Restore Operations
  • Recovering from Blue Screen Stops
  • Using Emergency Management Services (EMS)
  • Using Safe Mode
  • Restoring Functionality with the Last Known Good Configuration
  • Recovery Console
  • Moving Forward
  • Who Should Read This Book
  • Who This Book Is Not For
  • Conventions
  • Acknowledgments
  • About the Author
  • About the Technical Reviewers
  • Index
  • Index A
  • Index B
  • Index C
  • Index D
  • Index E
  • Index F
  • Index G
  • Index H
  • Index I
  • Index J
  • Index K
  • Index L
  • Index M
  • Index N
  • Index O
  • Index P
  • Index Q
  • Index R
  • Index S
  • Index SYMBOL
  • Index T
  • Index U
  • Index V
  • Index W
  • Index X
  • Index Z
  • Preface
  • Previous Section Next Section

    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.

    Figure 11.1. Local Security Authority functional diagram.


    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


    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.

    Registry Tip: Security Packages

    The list of security support providers is located in HKLM | System | CurrentControlSet | Control | SecurityProviders.

    Control parameters for the LSA and its security support providers are contained in HKLM | System | CurrentControlSet | Control | LSA.

    Windows provides discrete security for objects such as NTFS files/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.

      Previous Section Next Section