Ease of use and security don't easily coexist. Microsoft has created easy-to-use software, but widespread Internet use challenges the company to make its software secure enough to connect to a public network. Over the past few years, Microsoft has made serious efforts to meet this challenge. Windows 2000 networks use Kerberos, a proven open security standard; improve security management with Group Policy Objects (GPOs) and the Microsoft Management Console (MMC) Security Configuration tool set; extend support for tunneling protocols, such as Layer 2 Tunneling Protocol (L2TP) and IP Security (IPSec); and offer a granular access-control model. Windows .NET Server and the Windows XP (formerly code-named Whistler) client products enhance security yet further. I used .NET Server beta 2 and XP Professional beta 2 to preview the new and improved features that will make your Windows-based networks more secure.
Enhancing the Security Experience
The requirement that users of Win2K and earlier OSs reenter their credentials whenever they access resources from an untrusted Internet or intranet server can be frustrating. That frustration increases for users who have multiple credentials—for example, additional user ID and password credentials, Microsoft Passport credentials, smart cardbased private key credentials.
Administrators might cope with the same frustration when they need to use different credentials for different administrative tasks. Although application-specific solutions (e.g., Microsoft Internet Explorer's—IE's—credential-caching mechanism) exist, Microsoft integrates a universal solution into the .NET Server and XP Pro (as well as XP Home Edition) OSs: Credential Manager, a client-based single sign-on (SSO) solution that uses an intelligent credential-caching mechanism.
Credential Manager keeps user credentials in a client-side credential store. A user needs to enter only his or her "primary credentials" (i.e., the credentials that the user submits to log on locally or to a domain) to unlock his or her credential store and access the resources (i.e., targets) to which those credentials apply. A target can be a DNS name, NetBIOS name, or HTTP address and can contain wildcards (e.g., *.compaq.com). A set of credentials in a credential-target map can take one of three forms: a user ID and password, a user ID and a certificate and private key, or a set of Passport credentials. Certificate and private keybased credentials can be stored on a hard disk or on a smart card. Because the credential store is part of a user's profile, the store supports roaming. The Data Protection API (DPAPI) secures access to the store's content. (To disable client-side credential storage, administrators can select the Network Access: do not allow credential manager to save passports or credentials for domain authentication setting in the Windows Settings\Security Settings\Local Policies\Security Options GPO container.)
You can access credential-target maps through .NET Server's Control Panel Windows Key Ring applet, XP's Control Panel User Accounts applet, and from the Common Credential Collection dialog box. The Windows Key Ring and User Accounts applets let you view and modify the credential store's credential-target mappings and their properties, as Figure 1 shows. The Common Credential Collection dialog box pops up when the OS detects that it can't use the primary credentials to access a particular target. The dialog box prompts the user for alternative credentials and asks whether to add the credentials to the credential store.
Protecting User Resources
Because many clients are almost continuously connected to the Internet, .NET Server, XP Pro, and XP Home Edition include personal firewalls, called Internet Connection Firewalls. XP Pro and .NET Server also enhance Encrypting File System (EFS) support.
The personal firewall is Microsoft's response to user demands for control over what comes into and goes out of their machines. The Internet Connection Firewall augments but doesn't replace Windows NT's inbound TCP/IP packet filtering capabilities—you can still set packet filtering options on a connection's TCP/IP Properties page. To enable the Internet Connection Firewall, open a network connection's Properties page, then select Secure my Internet connection on the Advanced tab. Click Settings to access the Advanced Settings pane, which Figure 2, page 50, shows. From this pane, you can select logging options, choose which Internet Control Message Protocol (ICMP) messages to allow, and select the services and programs to make available over the Internet. The Internet Connection Firewall is available for LAN, dial-up, and VPN connections.
An important new capability for .NET Server's and XP Pro's EFS is file-sharing support for encrypted files. To share a file you've encrypted, open the file's Properties page, then click Advanced, Details and select the users with whom you want to share the file. Behind the scenes, Windows adds these users' accounts to the file's EFS metadata. Like Win2K, XP Pro and .NET Server store EFS metadata in the NTFS file system. EFS file sharing uses NTFS 5.0 (NTFS5), so you can share encrypted files that reside on both Win2K and .NET Server NTFS5 volumes. However, you can set EFS file sharing only at the file level, not at the folder level: The feature doesn't support inheritance of EFS file-sharing metadata.
Another of .NET Server's and XP Pro's enhancements integrates EFS with WWW Distributed Authoring and Versioning (WebDAV). The DAV extensions to the HTTP protocol let you use HTTP to exchange file metadata—EFS metadata, in .NET Server's and XP Pro's cases. Thanks to this integration of EFS and WebDAV, you can set up shared Web folders that contain EFS-encrypted files and, more important, you can transport the data securely across an HTTP connection. (For more information about WebDAV, visit the WebDAV Resources Web site's FAQs at http://www.webdav.org/other/faq.html.)
Making Windows SAFER
Microsoft software has been the preferred target of some infamous Trojan horses and viruses. To tackle the problem of unknown—and possibly malicious—code, XP Pro and .NET Server include a software-restriction policy feature, code-named SAFER. SAFER software-restriction policies are tightly integrated with the XP Pro and .NET Server OSs. However, you can't enforce them on earlier servers and clients, which simply ignore the SAFER policy settings.
SAFER classifies all code as either trusted or untrusted. Trusted code can be executed; untrusted code can't. No code stored on your XP Pro or .NET Server system can hide from SAFER policies—no matter where that code comes from and no matter who or what (i.e., a user, a machine, or a service) executes it.
Software-restriction policies are a powerful mechanism. For example, you can use SAFER policies to prohibit an administrator from starting a Telnet session from a particular server, restrict user access to Solitaire, and prohibit the execution of ActiveX controls that Microsoft hasn't signed. In large environments, such as that of a terminal services application service provider, you can use SAFER policies to limit the applications available to different users.
.NET Server incorporates SAFER policy definitions into GPO settings; to enforce software-restriction policies, administrators need to define the corresponding GPO settings. As with any GPO, you can configure software-restriction policies at the user and machine GPO levels.
To define a software-restriction policy, you first need to select one of two default security levels: Unrestricted (meaning the account can run any piece of code if the account has the appropriate access rights) and Disallowed (meaning the account can't run any code no matter what the account access rights are). You locate and define these security levels in the Security Levels GPO container. If you are an administrator who knows little about the software your users run, I recommend that you choose the Disallowed security level.
After you set the default security level, you can use additional rules to refine it, as Figure 3 shows. These rules can have four parameters: the person or organization that signs the code, the code's hash thumbprint, the Internet zone of the Web site from which the code was downloaded, and the file system or URL path to the code.
To troubleshoot software-restriction policies, use the classic GPO logging options and the Microsoft Windows .NET Server Resource Kit's gpresult.exe tool. You can also call on .NET Server's Resultant Set of Policies (RSoP) tool. The RSoP tool lets you simulate the results of particular GPO settings.
Investing in PKI Support
.NET Server adds major new features to the original NT 4.0 Option Pack public key infrastructure (PKI) software. Perhaps .NET Server's biggest PKI enhancement is the inclusion of the CAPICOM DLL.
CAPICOM lets application developers relatively easily add strong public keybased security to PKI-enabled applications. CAPICOM exposes the CryptoAPI (CAPI) functions and procedures. C++ programs and Visual Basic (VB) scripts, and even Active Server Pages (ASP)based Web applications can call on CAPICOM to generate and validate digital signatures, encrypt and decrypt data, and manipulate the certificate store. For more information about CAPICOM, see the Windows Platform software development kit's (SDK's) Security and Cryptography documentation, available online at http://msdn.microsoft.com/library.
From the infrastructure point of view, .NET Server's most useful PKI enhancements are its support for cross-certification and qualified subordination, its inclusion of editable certificate templates and a key recovery service, and its extended support for smart cards.
Unlike a hierarchical Certificate Authority (CA) trust model, .NET Server's cross-certification trust model lets CAs simultaneously be root and subordinate CAs. Cross-certification extends Win2K's certificate trust list (CTL) and is crucial when different companies and organizations doing business together use certificates. Thanks to cross-certification, two organizations that trust different CAs can set up a PKI trust agreement and enable certificate trust between their PKI users.
Qualified subordination lets you restrict trusts—including cross-certificationbased CA trust relationships—between different CAs. You can use .NET Server's qualified subordination features to define fine-grain certificate policies (CPs) for any type of certificate issued within your enterprise or to external partners. For compatibility with earlier clients, cross-certification and qualified subordination require you to install special code on these clients. (At the time of this writing, Microsoft hadn't yet released this code.)
You use .NET Server's editable certificate templates, called Version 2 templates, to enable qualified subordination. .NET Server still supports Win2K's uneditable Version 1 templates. You can also copy a Version 1 template's contents to a Version 2 template, from which you can then edit those contents. The MMC Certificate Templates snap-in lets you modify existing Version 2 certificate templates, as Figure 4 shows, and create new ones. Certificate extensions, certificate lifetimes, autoenrollment settings, and key archival policy are among the template settings that you can modify.
.NET Server's central key recovery service integrates key recovery services for different PKI-enabled applications with the CA database. Before .NET Server, key recovery was possible only for EFS and Secure MIME. S/MIME and Microsoft Exchange Server use a centralized solution based on Key Management Server (KMS), but the next major service pack for Exchange 2000 Server will adopt .NET Server's key recovery service. EFS will continue to use its decentralized NTFS-based key recovery system.
XP Pro and .NET Server also resolve some of Win2K's smart cardrelated problems. Win2K offers administrators only limited uses for smart cards. In .NET Server, administrators can use smart cards to run DCPROMO, execute Net and Runas commands, as Figure 5, page 54, shows, and use terminal services to remotely administer machines. Thanks to the new Runas /smartcard switch, you'll be able to provide credentials from your smart card.
I advise you to play around with the new PKI features: They're worth learning about. PKI support features are the .NET Server security enhancement in which Microsoft invested the most effort. The new PKI features could bring PKI and PKI-enabled applications to the masses.
Improving Security Management
To please the people who perform day-to-day OS security management, .NET Server includes new features that will make administrators' lives easier. Among the enhancements to the ACL Editor's GUI, the Advanced view includes the Effective permissions tab, which Figure 6, page 54, shows. Administrators can use this tab to view the cumulative permissions (including inherited permissions) granted to a particular group or user. The Advanced view's Permissions tab includes a new Inherited from column that lists the parent objects of inherited permissions.
.NET Server also extends the Windows Management Instrumentation (WMI) interface's systems management capabilities. WMI is Microsoft's implementation of the Web-Based Enterprise Management (WBEM) systems management standard.
Understanding this technology is important for those administrators who are involved in systems management. .NET Server lets you access the Security Configuration tool set through WMI. Also, .NET Server's WMI namespace includes trust objects, which make writing custom trust management and monitoring programs easy and efficient.
Security Under the Hood
XP Pro's and .NET Server's less visible security enhancements are no less important than the new OSs' high-profile improvements. XP Pro and .NET Server contain two new accounts that don't use passwords: the Local Service account and the Network Service account. Microsoft's goal for these accounts is to limit use of the local System account. Because the local System account password changes automatically and at regular intervals, administrators often use that account as the security identity for applications and services. However, the fact that the local System account has extensive local system privileges makes this practice dangerous: If an intruder manages to access the application or service, your entire system can be compromised. To reduce this vulnerability, .XP Pro's and NET Server's two new accounts have regular user privileges. To access nonlocal resources, the Local Service account uses an anonymous security context; the Network Service account uses the local machine account.
XP Pro and .NET Server also include several important cryptographic changes. First, Microsoft claims that XP Pro and .NET Server drastically enhance Windows' Secure Sockets Layer (SSL) performance (although little proof is available yet). Second, XP Pro's and .NET Server's EFS implementations support Triple DES (3DES). Third, XP Pro and .NET Server use a new authentication protocol called Digest authentication. Digest authentication is a challenge-responsebased authentication protocol defined as part of the HTTP 1.1 specification. Although Digest authentication has been available as an authentication provider for Microsoft Internet Information Services (IIS) 5.0, the protocol wasn't embedded in the OS's Security Support Provider Interface (SSPI) as a true Security Support Provider (SSP). For more information about Digest authentication, see the Internet Engineering Task Force (IETF) Request for Comments (RFC) 2617, "HTTP Authentication: Basic and Digest Access Authentication," at http://www.ietf.org/rfc/rfc2617.txt.
Finally, Microsoft plans to include some major trust and interforest authentication enhancements in .NET Server. Because of Active Directory's (AD's) design constraints, Win2K uses Kerberos only in specific interforest authentication scenarios. In Win2K, a Kerberos-based interactive logon between two forests is possible only when a direct trust relationship exists between the two domains, and transitive cross-forest trust relationships won't work. .NET Server supports true Kerberos-based interforest authentication and transitive trust relationships. To define trust relationships, .NET Server provides a new Trust Wizard. .NET Server also supports trust qualification to let you define SID validity constraints for certain trust relationships.
Toward a More Secure OS
To emphasize its ambitions for Windows security, Microsoft will submit XP Pro and .NET Server code for a formal security evaluation. The National Institute of Standards and Technology's (NIST's) Common Criteria define the evaluation process. (For information about the Common Criteria information security standards, go to the Common Criteria Web site at http://www.commoncriteria.org.) XP Pro's and .NET Server's security enhancements are impressive—but only the future will tell how much credibility the new OSs will earn in the security arena.
