Security in a Windows .NET Server Network

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 card­based 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 key­based 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.)

   Previous  [1]  2  3  Next