Many of Windows 2000's (Win2K's) new features relate to security. When you look at the new features such as Kerberos, Active Directory (AD), and integrated support for public key infrastructure (PKI), you might think Microsoft replaced most of the security architecture of Windows NT. In fact, Microsoft has exploited many features of NT's original security architecture. Even with Kerberos, AD, and PKI, the core of Win2K security builds on NT 4.0's infrastructure.
Microsoft designed the NT 4.0 security architecture for extensibility, with well-defined boundaries between modules and several APIs that let you plug in functionality (e.g., encryption, authentication services) without affecting the rest of the OS. In this article, I provide an update on the Win2K security architecture. First, I explain how Win2K's security evolved from NT 4.0, the problems with NT 4.0 that Win2K addresses, and other design goals with which Microsoft intends to make Win2K the OS for e-commerce. Then, I look at each component of the architecture and how it fits into the big picture.
Evolution from NT
To understand the Win2K security architecture, you need to go back to NT 4.0, which Microsoft designed to solve several common LAN problems. 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 password change notification packages, and the Cryptographic Service Provider (CSP) component in NT for extensibility. 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 can implement your own GINA. For example, Novell implemented a custom GINA for intraNetWare for NT.
Password change 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 OS. 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 NT, which provides tight integration of NDS and NT. For more information about NDS, see William Wong, "Novell's NDS for NT," April 1998.
So, NT 4.0 laid a solid foundation for security, but as administrators pressed NT into enterprise service, they recognized several inadequacies. No distributed SSO was available without cumbersome add-on products. Many of NT's 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 NT domains. NT 4.0 had several other scalability problems, such as the number of users that a domain could manage. NT 4.0 provided no place to put application-specific information about user accounts. NT's PKI functionality (rudimentary at best) was limited to Web environments and some support for Microsoft Exchange Server-based communications, but NT's PKI functionality wasn't fully integrated.
Security Design Goals
Microsoft designed Win2K with several goals in mind to address NT's shortcomings, and the company is positioning the new OS as the ultimate enabler for e-commerce. First, Microsoft designed Win2K for improved security. Microsoft added Kerberos network authentication to address NT LAN Manager (NTLM) authentication vulnerabilities. You can use Win2K's 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 Win2K.
Second, Win2K 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. Win2K uses standards such as Lightweight Directory Access Protocol (LDAP), Kerberos, Public Key Cryptography Standards (PKCS), PC and smart card integration (PC/SC), DNS, and IP Security (IPSec), instead of proprietary technologies such as NTLM, the SAM, WINS, and PPTP (which Win2K will support for backward compatibility). Win2K's use of standards automatically makes it more interoperable and lets you replace Microsoft components with best of breed solutions as necessary.
Third, Microsoft needed to provide a platform that would reduce application development costs. Microsoft started to provide such capability in NT with the Security Support Provider Interface (SSPI) and CryptoAPI. Win2K's APIs let developers reuse services (e.g., cryptographic services) that the OS 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 Win2K beyond Microsoft's imagination or ability. Microsoft is also trying to make its server more mission-critical and enterprise-ready. AD will be more scalable and reliable through its support for partitioned directories and multimaster replication. The hierarchical 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, Win2K has support for PKI throughout the OS that includes smart card logon, PKI-based Web access, Virtual Private Networking, EFS, email, and Authenticode. Win2K supports these components through its distributed security services, including AD 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.
AD
AD is Win2K's flagship component and addresses NT 4.0's directory problems of scalability, extensibility, administration, and openness. 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 Win2K, one AD domain can contain more than a million objects and doesn't require a PDC in most cases. 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 NT object called a site, which is related to IP subnets. Sites let you separate domains (which are usually based on organizational boundaries) from geographic boundaries.
Administration is much more powerful with AD. To begin with, you now can organize users and computers into a hierarchy that matches your true organizational structure. Within a domain, organizational units (OUs) 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.
Win2K lets you replace problematic WINS and broadcast name resolution NetBIOS with dynamic DNS (DDNS). You can store the DNS database in AD and base it on the AD domain hierarchy. Although much of NT 4.0 was extensible, the directory wasn't. NT 4.0 required developers to handle application-specific user properties and the location of application services.
With AD, developers can add new objects and new properties to existing objects, instead of maintaining a separate application directory. (Note that AD isn't appropriate for storing data that changes often.) AD 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 Win2K's 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 basic NT 4.0 domain models (e.g., complete trust, master domain).
AD's access methods, LDAP and Active Directory Service Interfaces (ADSI), and its hierarchical structure give AD an open architecture and let you integrate it with other directory-enabled OSs and applications. As Figure 1 shows, AD has a symbiotic relationship with the rest of the OS. Win2K uses AD as the data store for account and policy information and uses AD's hierarchy to control the flow of policy inheritance. AD relies on the OS to authenticate and control access to AD's objects.
CryptoAPI
CryptoAPI is as fundamental a component of the Win2K security architecture as AD is. The goal of CryptoAPI is to provide one-stop shopping for low-level cryptographic services to all applications and other components of the OS using installable cryptographic service providers, as Figure 2 shows. These CSPs provide key generation, signatures, encryption, hashing, and certificate services through a standard interface. CryptoAPI is similar to the intent of ODBC in which an application can access many different databases through the same ODBC interface.
CryptoAPI supports Win2K's 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.
CryptoAPI has been around since NT 4.0, but in Win2K, 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 CryptoAPI uses X.509v3 and PKCS standards, developers can use it to manage certificates in Win2K's native certificate store, in AD, and in other third-party Certificate Authorities (CAs).
Certificate Server
Certificate Server has also been around since 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 Microsoft 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 Win2K, Certificate Server's name changes slightly to Certificate Services. Certificate Services is more powerful and better integrated into the rest of the OS. 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 AD to store and publish certificates. Using AD, 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 Win2K, with pieces of its NT 4.0 forbearer moving to other components. Microsoft added Certificate Services' certificate management functions to CryptoAPI. Microsoft moved Certificate Services' default certificate data store to AD. 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 the 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.
Regardless of the protocol, authentication is based on credentials stored in AD. No need exists for users to have an NTLM account and a Kerberos account. AD associations that map elements of a certificate to the proper AD user object accomplish PKI-based authentication. Applications can use the SSPI directly or through authenticated remote procedure call (RPC) and Distributed Component Object Model (DCOM).
Another major authentication issue is the replacement of NTLM, which is NT 4.0's vulnerable authentication protocol, which uses password hashes stored in the SAM. Win2K will still support NTLM for compatibility with NT. When you use Win2K systems in a workgroup, NTLM authentication will continue to use credentials in the NT SAM. Alternatively, connecting from an NT system to a Win2K server in an AD domain doesn't invoke the SAM; Win2K will validate you against NTLM hashes stored in your AD user object. The important news here is that if you upgrade your NT systems and install the new AD client for Windows 9x systems, you can get risky NTLM authentication off your network because Kerberos is the default authentication protocol for Win2K. Kerberos is more secure than NTLM, and Kerberos is an industry standard that will help you get closer to SSO. 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.
Encryption
Two areas in which you can protect crucial data only with encryption are on disk and on the network. In NT 4.0, intruders can easily eavesdrop on network data by using sniffers or can copy data from disks by using direct access tools such as Systems Internals' NTFSDOS utility. Win2K's 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," http://www.winntmag.com/articles, InstantDoc ID 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 OS handles the encryption.
EFS integrates with Win2K's PKI and supports 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 area in which Microsoft might back off on the planned functionality in the first release. So, look for limited support for encryption algorithms other than Data Encryption Standard X (DESX) and limited or no smart card support for storing EFS private keys.
To protect data across the network, with complete transparency to the user and the application, Win2K 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 modifying it. IPSec is a solid Internet protocol with plenty of industry backing.
Microsoft integrated IPSec well, making it easy to deploy and manage. The AD 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 AD.
Advanced Security
The Win2K security architecture is a daunting undertaking of technology and integration. Microsoft uses proven design concepts such as industry standards, protocols, modularity, abstraction, and omnipresent support for PKI to uphold the company's Win2K goals to provide security, openness, mission-critical strength, support for e-business, and reduction of application costs.
Microsoft uses AD throughout the OS and will use AD in future releases of BackOffice as the central data store for directory and policy-related information. I think Win2K's design is Microsoft's best example of analyzing business needs and responding to user requirements. Let's hope that Microsoft's implementation of Win2K is the company's best example of quality to date.
