SQL Server Magazine

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.

   Prev. page   [1] 2     next page