Windows 2000 Security Gains

R. Franklin Smith

Article from Windows 2000 Magazine

On This Page

Microsoft Exploits the Windows NT Security Architecture
Evolution from Windows NT
Security Design Goals
Active Directory
CryptoAPI
Certificate Server
Authentication Services
Encryption
Advanced Security

Microsoft Exploits the Windows NT Security Architecture

Many of the Microsoft Windows® 2000 new features relate to security. When you look at the new features such as Kerberos, Active Directory® directory service, and integrated support for public key infrastructure (PKI), you might think Microsoft replaced most of the security architecture of Microsoft Windows NT®. In fact, Microsoft has exploited many features of the Windows NT original security architecture. Even with Kerberos, Active Directory, and PKI, the core of Windows 2000 security builds on the Windows NT 4.0 infrastructure.

Microsoft designed the Windows NT 4.0 security architecture for extensibility, with well-defined boundaries between modules and several APIs that let you plug in function (e.g., encryption or authentication services) without affecting the rest of the operating system. In this article, I provide an update on the Windows 2000 security architecture. First, I explain how Windows 2000 security evolved from Windows NT 4.0, the problems with Windows NT 4.0 that Windows 2000 addresses, and other design goals with which Microsoft intends to make Windows 2000 the operating system for e-commerce. Then, I look at each component of the architecture and how it fits into the big picture.

Evolution from Windows NT

To understand the Windows 2000 security architecture, you need to go back to Windows NT 4.0, which Microsoft designed to solve several common LAN problems. Windows NT 4.0 provides one network logon (for all Windows systems, at least) and somewhat centralized administration through domains.

Microsoft designed the Graphical Identification and Authentication (GINA) component, the notification packages, and the Cryptographic Service Provider (CSP) component in Windows NT 4.0 for extensibility. The GINA is responsible for accepting user credentials at logon. To accommodate other logon needs, such as displaying the last time a user logged on or single sign-on (SSO), you could implement your own GINA. For example, Novell implemented a custom GINA for intraNetWare for Windows NT.

Notification packages are DLL plug-ins that let you capture new passwords for synchronization with other environments to enforce rules and make passwords hard to guess. Microsoft File and Print Services for NetWare (FPNW) was an early user of a notification package.

The CSP interface lets applications outsource their cryptographic needs to the operating system. As new cryptographic standards emerge or users deploy the application beyond the United States, the application will use the appropriate cryptographic method without affecting its implementation. You can even replace core components such as the SAM because of the well-defined interfaces between each component. Novell replaced core components with Novell Directory Services (NDS) for Windows NT, which provided tight integration of NDS and Windows NT. For more information about NDS, see William Wong, "Novell's NDS for NT," April 1998.

So, Windows NT 4.0 laid a solid foundation for security, but as administrators pressed Windows NT into enterprise service, they recognized several inadequacies. No distributed SSO was available without cumbersome add-on products. Many of the Windows NT security holes stemmed from backward compatibility with LAN Manager. Delegation (the ability to assign limited administrative privileges for a limited set of accounts to another user) was woefully inadequate. For instance, you couldn't give Help desk personnel the right to reset passwords on user accounts without making them full administrators. You couldn't properly model your organizational hierarchy and administrative structure with flat Windows NT domains. Windows NT 4.0 had several other scalability problems, such as the number of users that a domain could manage. Windows NT 4.0 provided no place to put application-specific information about user accounts. The Windows NT PKI functionality (rudimentary at best) was limited to Web environments and some support for Microsoft Exchange Server-based communications, but PKI's functionality wasn't fully integrated.

Security Design Goals

Microsoft designed Windows 2000 with several goals in mind to address the shortcomings of Windows NT 4.0, and the company is positioning the new operating system as the ultimate enabler for e-commerce. First, Microsoft designed Windows 2000 for improved security. Microsoft replaced Windows NT LAN Manager (NTLM) network authentication with Kerberos to address NTLM vulnerabilities. You can use the Windows 2000 support for PKI to eliminate the risks inherent to passwords, and you can use smart cards to mitigate the risks of private keys. Physical access to hard disks has been a growing problem, especially with the theft of laptops. In response, Microsoft has developed the new Encrypting File System (EFS) in Windows 2000.

Second, Windows 2000 relies heavily on industry standards and protocols. Microsoft is learning that corporations can't and won't give up all other environments and that sometimes the industry has already produced a better standard. Thus, Microsoft appears to have looked for the best standard or protocol for each area of interaction between components. Windows 2000 uses standards such as Lightweight Directory Access Protocol (LDAP), Kerberos, Public Key Cryptography Standards (PKCS), PC and smart card integration (PC/SC), X.500, DNS, and IP Security (IPSec), instead of proprietary technologies such as NTLM, the SAM, WINS, and PPTP (which Windows 2000 will support for backward compatability). The Windows 2000 use of standards automatically makes it more interoperable and enables you to replace Microsoft components with best of breed solutions as necessary.

Third, Microsoft needed to provide a platform that reduced application development costs. Microsoft started to provide such capability in Windows NT 4.0 with Security Support Provider Interface (SSPI) and the CryptoAPI. The Windows 2000 APIs let developers reuse services (e.g., cryptographic services) that the operating system provides. Abstracting applications from the provider also protects the applications from obsolescence. You can update and enhance provider components as technology progresses without affecting the application. For example, an application that uses the CSP can quickly take advantage of the next standard encryption algorithm.

The API paradigm also facilitates the development and implementation of third-party solutions that take Windows 2000 beyond Microsoft's imagination or ability. Microsoft is also trying to make its server more mission-critical and enterprise-ready. Active Directory will be more scalable and reliable through its support for partitioned directories and multimaster replication. The X.500-based directory structure and Group Policy Editor (GPE) promise to give user accounts and system configuration some manageability that scales higher than the department level.

Finally, to answer the challenge of e-commerce, Windows 2000 has support for PKI throughout the operating system that includes smart card logon, PKI-based Web access, Virtual Private Networking, EFS, email, and Authenticode. Windows 2000 supports these components through its distributed security services, including Active Directory directory services, cryptographic services, Certificate Services, authentication services, secure transport protocols, EFS, and smart cards. Let's look at each of these components in more depth.

Active Directory

Active Directory is the Windows 2000 flagship component and addresses the Windows NT 4.0 directory problems of scalability, extensibility, administration, and openness. Windows NT 4.0 didn't scale well for large organizations because it limited domains to 20,000 users and the PDCs and BDCs used one-to-many replication. In Windows 2000, one Active Directory domain can contain a million objects and doesn't require a PDC. Changes recorded on any domain controller replicate to the rest. You can tune this multimaster replication as necessary to provide performance and safeguard bandwidth for geographically dispersed organizations. To accomplish this task, you use a new Windows NT object called sites, which are related to IP subnets. Sites let you separate domains (which are usually based on organizational boundaries) from geographic boundaries.

Figure 1: Active Directory Relationship to the Operating System

Administration is much more powerful with Active Directory. To begin with, you now can organize users and computers into a hierarchy that matches your true organizational structure. Within a domain, organizational units provide this structure. Domains are no longer peers and can have parent and child domains (except for the root domain, which has no parent). You can also assign individual administrative privileges at any level.

Windows 2000 lets you replace problematic WINS and broadcast name resolution NetBIOS with dynamic DNS. You can store the DNS database in Active Directory and base it on the Active Directory domain hierarchy. Although much of Windows NT 4.0 was extensible, the directory wasn't. Windows NT 4.0 required developers to handle application-specific user properties and the location of application services.

With Active Directory, developers can add new objects and new properties to existing objects, instead of maintaining a separate application directory. (Note that Active Directory isn't appropriate for storing data that changes often.) Active Directory even lets you publish resources such as shared folders in such a way that users don't need to know the physical location of the server. You can also move an application from one server to another without users knowing it. This granularity of control and the Windows 2000 domain support of transitive trust (i.e., if domain A trusts domain B and domain B trusts domain C, then domain A trusts domain C) eliminate the need for crude Windows NT 4.0 domain models (e.g., complete trust and master domain).

Figure 2: CryptoAPI: One-Stop Shopping for Cryptographic Services

The Active Directory access methods, LDAP and Active Directory Service Interfaces (ADSI), and its X.500-based structure give Active Directory an open architecture and let it integrate with other directory-enabled operating systems and applications. As Figure 1 shows, Active Directory has a symbiotic relationship with the rest of the operating system. Windows 2000 uses Active Directory as the data store for account and policy information and uses the Active Directory hierarchy to control the flow of policy inheritance. Active Directory relies on the operating system to authenticate and control access to the Active Directory objects.

CryptoAPI

The CryptoAPI is as fundamental a component of the Windows 2000 security architecture as Active Directory is. The goal of the CryptoAPI is to provide one-stop shopping for low-level cryptographic services to all applications and other components of the operating system using installable cryptographic service providers, as Figure 2 shows. These CSPs provide key generation, signatures, encryption, hashing, and certificate services through a standard interface. The CryptoAPI is similar to the intent of ODBC in which an application can access many different databases through the same ODBC interface.

The CryptoAPI supports the Windows 2000 high-level design goal of reducing application development costs in three ways. First, developers don't need to implement cryptographic code. Second, developers can develop an application once that can use different cryptographic standards and protocols. Third, as encryption changes, developers don't need to redesign applications.

The CryptoAPI has been around since Windows NT 4.0, but in Windows 2000, the CryptoAPI has important new features for supporting PKI. For example, developers can request and publish certificates and Certificate Revocation Lists (CRLs) and build certification paths when a server application needs to know whether a certificate is valid. Because the CryptoAPI uses X.509v3 and PKCS standards, developers can use it to manage certificates in the Windows 2000 native certificate store, in Active Directory, and in other third-party Certification Authorities (CAs).

Certificate Server

Certificate Server has also been around since Windows NT 4.0 and has provided the basic functionality of a CA for requesting, issuing, publishing, and managing certificates. Certificate Server offered Authenticode authentication and Secure MIME (S/MIME) integration for Exchange Server, but Microsoft geared Certificate Server mostly for public-key-based client authentication to Internet Information Server (IIS). Administrators had to manually edit text files to control Certificate Server's configuration. Certificate Server lacked management features important to enterprise usage of PKI, such as tools to customize certificate types and policy settings and support for only two-level CA hierarchies (inadequate for large-scale PKI deployment).

In Windows 2000, Certificate Server's name changes slightly to Certificate Services. Certificate Services is more powerful and better integrated into the rest of the operating system. The Microsoft Management Console (MMC) snap-ins provide GUI tools for both the client side and the server side. Although Certificate Services can maintain its standalone data store, for full enterprise functionality, Certificate Services uses Active Directory to store and publish certificates. By using Active Directory, you can easily map certificates to users and leverage the management features of GPE to control for whom, by whom, and for what purposes Certificate Services issues certificates. Finally, Certificate Services now supports multilevel hierarchies.

As you can see in Figure 3, Certificate Services becomes much thinner in Windows 2000, with pieces of its Windows NT 4.0 forbearer moving to other components. Microsoft added Certificate Services' certificate management functions to the CryptoAPI. Microsoft moved Certificate Services' default certificate data store to Active Directory. Because Certificate Services accesses its certificate store through the CryptoAPI, Certificate Services can publish certificates in other third-party directories.

Authentication Services

The SSPI provides authentication services through another API. Client/server applications need to authenticate the client to the server and sometimes the server to the client. SSPI lends abstraction advantages, which are analogous to the CSP interface, to client/server applications. Figure 4 shows how SSPI isolates applications from the details of network security protocols, reduces the application-level code needed to support multiple authentication protocols, and supports authentication based on shared-secret or public-key protocols.

Figure 4: SSPI's Role in Authentication Services

Regardless of the protocol, authentication is based on credentials stored in Active Directory. No need exists for users to have an NTLM account and a Kerberos account. Active Directory associations that map elements of a certificate to the proper Active Directory user object accomplish PKI-based authentication. Applications can use SSPI directly or through authenticated remote procedure call (RPC) and Distributed Component Object Model (DCOM).

Another major authentication issue is the replacement of NTLM. NTLM is the Windows NT 4.0 vulnerable authentication protocol that uses password hashes stored in the SAM. Windows 2000 will still support NTLM for compatibility with Windows NT. When using Windows 2000 systems in a workgroup, NTLM authentication will continue to use credentials in the Windows NT SAM. Alternatively, connecting from a Windows NT system to a Windows 2000 server in an Active Directory domain doesn't invoke the SAM; Windows 2000 will validate you against NTLM hashes stored in your Active Directory user object. The important news here is that if you upgrade your Windows NT systems and install the new Active Directory client for Windows 9x systems, you can get risky NTLM authentication off your network because Kerberos is the default authentication protocol for Windows 2000. Kerberos is more secure than NTLM, and Kerberos is an industry standard that will help you get closer to single sign-on. Finally, Kerberos addresses problems that have plagued NTLM—in particular, the slowness and lack of impersonation functionality for multitier server applications. For more information about Kerberos, see Jan De Clercq, "Kerberos in Win2K," October 1999.

Figure 5: IPSec's Place in the Windows 2000 Architecture

Encryption

Two areas in which you can protect crucial data only with encryption are on disk and on the network. In Windows NT 4.0, intruders can easily eavesdrop on network data using sniffers or can copy data from disks using direct access tools such as Systems Internals' NTFSDOS utility. The Windows 2000 EFS lets you encrypt files at the file-system level by simply selecting a check box. (For more information about EFS, see Zubair Ahmad, "Windows 2000 EFS," https://www.winntmag.com/articles, InstantDoc 5006.) EFS handles encryption and decryption with complete transparency to the user and the application program. You can protect any application's data because the operating system handles the encryption.

EFS integrates with the Windows 2000 PKI and has support for data recovery in case the user's private key is lost or unavailable. EFS will be a nice enhancement for laptop users because these systems are vulnerable to theft. However, EFS is one of the areas in which Microsoft is backing off on the planned functionality, so look for limited support for encryption algorithms other than Data Encryption Standard (DES) and limited or no smart card support for storing EFS private keys in the first release.

To protect data across the network, with complete transparency to the user and the application, Windows 2000 uses IPSec, as Figure 5 shows. IPSec provides authentication, confidentiality, data integrity, and filtering for TCP/IP traffic. IPSec's implementation is below the application protocol layer and lets you secure communications for any application without modification. IPSec is a solid Internet protocol with plenty of industry backing.

Microsoft integrated IPSec well, making it easy to deploy and manage. Active Directory stores IPSec policy, and you control IPSec through GPE. In addition to obvious VPN capabilities, you can secure network communication within your enterprise. For example, you can require authentication of traffic within your R&D department, encryption of communication between R&D and other departments, and no connections between R&D and the Internet. Even though these requirements might affect many systems, you can manage everything centrally through Active Directory.

Advanced Security

The Windows 2000 security architecture is a daunting undertaking of technology and integration. Proven design concepts such as industry standard protocols, modularity, abstraction, and omnipresent support for PKI uphold Microsoft's Windows 2000 goals of security, openness, reduction of application costs, mission-critical strength, and support for e-business.

Microsoft uses Active Directory throughout the operating system and in future releases of Microsoft BackOffice® as the central data store for directory and policy-related information. To date, I think the Windows 2000 design is Microsoft's best example of analyzing business needs and responding to user requirements. Let's hope the implementation is Microsoft's best example of quality to date.

About the Author

R. Franklin Smith, president of Monterey Technology Group, provides Windows NT security training and consulting. You can reach him at rsmith@montereytechgroup.com.

We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as-is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages. All prices for products mentioned in this document are subject to change without notice.

International rights = English Only

Click to subscribe