Planning Distributed Security
C H A P T E R 1 1
Planning Distributed Security
A security plan is an essential component of your Microsoft
2000 deployment plan. Representatives of many of your deployment subteams will be involved in this task. This chapter guides you through a strategy for planning distributed security in your Windows 2000 network. It outlines the primary objectives for a distributed security plan and introduces the security features of Windows 2000.
This chapter puts into context the important factors to consider in order to use
Microsoft Windows 2000 security effectively. However, distributed computer security is a fairly complex topic that you will need to research further.
In This Chapter
Developing a Network Security Plan 381
Authenticating All User Access 388
Applying Access Control 396
Establishing Trust Relationships 402
Enabling Data Protection 406
Setting Uniform Security Policies 412
Deploying Secure Applications 421
Managing Administration 426
Planning Task List for Distributed Security 430
380 Part 3 Active Directory Infrastructure
This chapter will help you develop the following planning documents:
Security Risk Analysis
Security Group Descriptions and Associated Policies
Network Logon and Authentication Strategies
Information Security Strategies
Related Information in the Resource Kit
For more information about distributed security, see the Microsoft
2000 Server Resource Kit Distributed Systems Guide.
For more information about security groups, see “Designing the Active
Directory Structure” in this book.
For more information about public key infrastructure, see “Planning Your
Public Key Infrastructure” in this book.
Chapter 11 Planning Distributed Security 381
Developing a Network Security Plan
Distributed security involves the coordination of many security functions on a computer network to implement an overall security policy. Distributed security enables users to log on to appropriate computer systems, find the information they need, and use it. Much of the information on computer networks is available for anyone to read, but only a small group of people are allowed to update it. If the information is sensitive or private, only authorized individuals or groups are allowed to read the files. Protection and privacy of information transferred over public telephone networks, the Internet, and even segments of internal company networks are also a concern.
Although security technologies are some of the most advanced technologies, security itself combines those technologies with good business and social practices. No matter how advanced and well implemented the technology is, it is only as good as the methods used in employing and managing it.
Your security deployment team develops the network security plan. The network security deployment plan describes how you use the features of Windows 2000 distributed security to deploy distributed security and information security solutions.
A typical security plan includes sections like those shown in Table 11.1.
Table 11.1 Sections in a Security Plan
Sections in the Plan Description
Enumerates the types of security hazards that affect your enterprise.
Describes the general security strategies necessary to meet the risks.
Public key infrastructure policies
Includes your plans for deploying certification authorities for internal and external security features.
Security group descriptions Includes descriptions of security groups and their relationship to one another. This section maps group policies to security groups.
Network logon and authentication strategies
Information security strategies
Includes how you configure security Group Policy settings, such as network password policies.
Includes authentication strategies for logging on to the network and for using remote access and smart card to log on.
Includes how you implement information security solutions, such as secure e-mail and secure Web communications.
Includes policies for delegation of administrative tasks and monitoring of audit logs to detect suspicious activity.
382 Part 3 Active Directory Infrastructure
Your network security deployment plan can contain more sections than these; however, these are suggested as a minimum. Additionally, your organization might need more than one security plan. How many plans you have depends on the scope of your deployment. An international organization might need separate plans for each of its major subdivisions or locations, whereas, a regional organization might need only one plan. Organizations with distinct policies for different user groups might need a network security plan for each group.
Test and revise your network security plans by using test labs that represent the computing environments for your organization. Also, conduct pilot programs to further test and refine your network security plans.
Before this chapter examines the security features of Windows 2000, it is a good idea to review the types of network security problems that an IT manager faces. Table 11.2 describes several types of security risks and provides a common basis for the subsequent discussion of security features, strategies, and technologies. Creating a list similar to this in your security plan demonstrates the complexity of security problems you face and will help you establish a set of standard labels for each category of risk.
Table 11.2 Types of Security Risks in an Organization
The intruder discovers the user name and password of a valid user. This can occur by a variety of methods, both social and technical.
An unauthorized user pretends to be a valid user. For example, a user assumes the IP address of a trusted system and uses it to gain the access rights that are granted to the impersonated device or system.
The intruder records a network exchange between a user and a server and plays it back at a later time to impersonate the user.
If data is moved across the network as plaintext, unauthorized persons can monitor and capture the data.
The intruder causes network data to be modified or corrupted.
Unencrypted network financial transactions are vulnerable to manipulation. Viruses can corrupt network data.
Network-based business and financial transactions are compromised if the recipient of the transaction cannot be certain who sent the message.
Application-specific viruses could exploit the macro language of sophisticated documents and spreadsheets.
Chapter 11 Planning Distributed Security 383
Table 11.3 Types of Security Risks in an Organization (continued)
Security Risk Description
Denial of service
Malicious mobile code
Misuse of privileges
The intruder floods a server with requests that consume system resources and either crash the server or prevent useful work from being done. Crashing the server sometimes provides opportunities to penetrate the system.
This term refers to malicious code running as an autoexecuted ActiveX
control or Java Applet uploaded from the
Internet on a Web server.
An administrator of a computing system knowingly or mistakenly uses full privileges over the operating system to obtain private data.
Trojan horse This is a general term for a malicious program that masquerades as a desirable and harmless utility.
Social engineering attack Sometimes breaking into a network is as simple as calling new employees, telling them you are from the IT department, and asking them to verify their password for your records.
The following concepts are useful in describing distributed security strategies under
Windows 2000. You might also find it useful to include them in your security plan to familiarize readers with distributed security.
Windows 2000 security is based on a simple model of authentication and authorization that uses Microsoft
Active Directory ™ directory service.
Authentication identifies the user when the user logs on and when the user makes network connections to services. Once identified, the user is authorized access to a specific set of network resources based on permissions. Authorization takes place through the mechanism of access control, using access control lists (ACLs) that define permissions on file systems, network file and print shares, and entries in Active
In Windows 2000, a domain is a collection of network objects, such as user accounts, groups, and computers, that share a common directory database with respect to security. A domain identifies a security authority and forms a boundary of security with consistent internal policies and explicit security relationships to other domains.
384 Part 3 Active Directory Infrastructure
A trust is a logical relationship established between domains to allow pass-through authentication in which a trusting domain honors the logon authentications of a trusted domain. The term transitive trust refers to authentication across a chain of trust relationships. In Windows 2000, trust relationships support authentication across domains by using Kerberos v5 protocol and NTLM authentication for backward compatibility.
Security policy settings define the security behavior of the system. Through the use of
Group Policy objects in Active Directory, administrators can centrally apply explicit security profiles to various classes of computers in the enterprise. For example,
Windows 2000 comes with a default Group Policy object called Default Domain
Controllers Policy that governs the security behavior of domain controllers.
Security Configuration and Analysis
Security Configuration and Analysis, a feature of Windows 2000, offers the ability to compare the security settings of a computer to a standard template, view the results, and resolve any discrepancies revealed by the analysis. You can also import a security template into a Group Policy object and apply that security profile to many computers at once. Windows 2000 contains several predefined security templates appropriate to various levels of security and to different types of clients and servers on the network.
Symmetric Key Encryption
Also called secret key encryption, symmetric key encryption uses the same key to encrypt and decrypt the data. It provides rapid processing of data and is used in many forms of data encryption for networks and file systems.
Public Key Encryption
Public key encryption has two keys, one public and one private. Either key can encrypt data that can only be decrypted by the other key. This technology opens up numerous security strategies and is the basis for several Windows 2000 security features. These features are dependent on a public key infrastructure (PKI). For more information about PKI, see “Planning Your Public Key Infrastructure” in this book.
Chapter 11 Planning Distributed Security 385
Authentication confirms the identity of any user trying to log on to a domain or to access network resources. Windows 2000 authentication enables single sign-on to all network resources. With single sign-on, a user can log on to the client computer once, using a single password or smart card, and authenticate to any computer in the domain. Authentication in Windows 2000 is implemented by using Kerberos v5 protocol, NTLM authentication, or the Windows NT logon feature to
Windows NT 4.0 domains.
Users dislike having to authenticate separately to multiple network servers and applications. A user might have to provide separate passwords to log on to the local computer, to access a file or print server, to send an e-mail, to use a database, and so forth. Different servers can demand a change of password at different intervals, often with no reuse permitted; so a typical user might be required to remember half a dozen passwords. Not only is authentication tedious for the user, but at some point, users begin to write down a list of current passwords. In this way, a multiple-authentication network can become vulnerable to identity interception.
The single sign-on strategy makes a user authenticate interactively once and then permits authenticated sign-on to other network applications and devices. These subsequent authentication events are transparent to the user.
Two-factor authentication requires users to present a physical object that encodes their identities plus a password. The most common example of two-factor authentication is the automated teller machine (ATM) card that requires a personal identification number (PIN).
Biometric identification is another form of two-factor authentication. A special device scans the user’s handprint, thumbprint, iris, retina, or voiceprint in place of an access card. Then the user enters the equivalent of a password. This approach is expensive but it makes identity interception and masquerading very difficult.
For business enterprises, the emerging two-factor technology is the smart card. This card is not much larger than an ATM card and is physically carried by the user. It contains a chip that stores a digital certificate and the user’s private key. The user enters a password or PIN after inserting the card into a card reader at the client computer. Because the private key is carried on a chip in the user’s pocket, it is very hard for a network intruder to steal. Windows 2000 directly supports smart card authentication.
386 Part 3 Active Directory Infrastructure
Access control is the model for implementing authorization. After a user has authenticated to a domain and attempts to access a resource, such as a network file, the type of operation permitted is determined by the permissions that are attached to the resource, such as read-only or read/write. Access control in Windows 2000 is implemented by using object-specific ACLs. You can view an ACL on the Security tab of the property sheet of a file or folder. The list contains the names of user groups that have access to the object.
Ensuring data integrity means to protect data against malicious or accidental modification. For stored data, this means that only authorized users can edit, overwrite, or delete the data. On a network, this means that a data packet must contain a digital signature so that tampering with the packet can be detected by the recipient computer.
A strategy of data confidentiality means to encrypt data before it passes through the network and to decrypt it afterward. This strategy prevents data from being read by someone eavesdropping on the network (data interception). A packet of nonencrypted data that is transmitted across a network can be easily viewed from any computer on the network by using a packet-sniffing program downloaded from the Internet.
There are two parts to a nonrepudiation strategy. The first is to establish that a message was sent by a specific user, who cannot disavow it. The second part is to ensure that the message could not have been sent by anyone masquerading as the user.
This is another application for public key infrastructure. The user’s private key is used to place a digital signature on the message. If the recipient can read the message using the sender’s public key, then the message could have been sent only by that specific user and no one else.
This strategy requires that code downloaded from the Internet be signed with the digital signature of a trusted software publisher. You can configure Web browsers to avoid running unsigned code. Note that software signing proves that the code is authentic, meaning it has not been tampered with after publication. It does not guarantee that the code is safe to run. You have to decide which software publishers to trust. (The digital signature on the executable file is another example of public key infrastructure.)
Chapter 11 Planning Distributed Security 387
Auditing user account management as well as access to important network resources is an important security policy. Auditing leaves a trail of network operations, showing what was attempted and by whom. Not only does this help to detect intrusion, but the logs become legal evidence if the intruder is caught and prosecuted. Finally, finding and deleting or modifying the audit logs poses an additional time-consuming task for the sophisticated intruder, making detection and intervention easier.
It goes without saying that a critical enterprise network services network needs to reside in locked facilities. If intruders can sit down at the network server console, they might be able to take control of the network server. If critical network servers are not physically secure, a disgruntled employee can damage your hardware by using a simple, old-fashioned tool, such as a hammer. Your data is also open to physical attack: every novice user knows how to press the delete key. Damage from such intrusions can result in just as much loss of data and downtime as you can have from a more sophisticated, external attack to your network. Attacks on the network do not have to be sophisticated to be effective.
The best defense against a social engineering attack is to educate your users about keeping their passwords confidential and secure. Business policies about distribution of critical information need to be clearly stated. Publish a security policy and require everyone to follow it. One way to educate is by example: make sure that your IT professionals protect their passwords and that they encourage users to protect theirs too.
Distributed Security Strategies
Distributed security refers to the logical security features that operate primarily within the enterprise network. There are seven primary security strategies to pursue in making your network resources secure.
Authenticate all user access to system resources.
Apply appropriate access control to all resources.
Establish appropriate trust relationships between multiple domains.
Enable data protection for sensitive data.
Set uniform security policies.
388 Part 3 Active Directory Infrastructure
Deploy secure applications.
Manage security administration.
Make these seven themes central to your distributed security plan. In the pages that follow, you will find an in-depth discussion of each strategy.
Authenticating All User Access
To provide security for your Windows 2000 network, you must provide access for legitimate users but screen out intruders who are trying to break in. This means you must set up your security features to authenticate all user access to system resources.
Authentication strategies set the level of protection against intruders trying to steal identities or impersonate users.
In Windows 2000, authentication for domain users is based on user accounts in Active
Directory. Administrators manage these accounts using the Active Directory Users and Computers snap-in to the Microsoft Management Console (MMC). User accounts can be organized into containers called “organization units” that reflect the design of your Active Directory namespace. The default location for user accounts is the Users folder of this snap-in.
When a new user joins the organization, the administrator creates only a single account for that user rather than having to create half a dozen or more separate accounts on different servers and application databases. With the domain authentication service integrated with the enterprise directory, the single user account is also a directory entry for global address book information, as well as providing access to all network services. The user can log on at different client computers or laptops in the domain using only one password.
Windows 2000 automatically supports single sign-on for users within a domain forest.
Domain trust relationships in the forest are bidirectional by default, so authentication in one domain is sufficient for referral or pass-through authentication to resources in other domains in the forest. The user logs on interactively at the beginning of a session, after which network security protocols (Kerberos v5 protocol, NTLM, and
Secure Sockets Layer/Transport Layer Security) transparently prove the user’s identity to all requested network services.
Windows 2000 optionally supports logging on with smart cards for strong authentication. The smart card is an identification card carried by the user that is used for interactive logon instead of a password. It can also be used for remote dial-up network connections and as a place to store public key certificates used for Secure
Sockets Layer (SSL) client authentication or secure e-mail.
Chapter 11 Planning Distributed Security 389
Authentication is not limited to users. Computers and services are also authenticated when they make network connections to other servers. For example, Windows 2000– based servers and client computers connect to their domain’s Active Directory for policy information during startup. They authenticate to Active Directory and download computer policy from Active Directory before any user can log on to that computer. Computers and services also prove their identity to clients that request mutual authentication. Mutual authentication prevents an intruder from adding another computer as an imposter between the client and the real network server.
Computers and services can be “trusted for delegation,” which means services can make other network connections “on behalf of” a user without knowing the user’s password. The user must already have a mutually authenticated network connection to the service before the service can make a new network connection to another computer for that user. This is useful for multitier applications designed to use single sign-on capabilities across multiple computers. This feature is particularly useful in the context of an Encrypting File System (EFS) running on a file server. To use a service to delegate a network connection, use the Active Directory Users and
Computers MMC snap-in. Then select the Trust computer for delegation check box on the property sheet.
Be sure to address these considerations and best practices when planning your authentication policies.
The simplest way to defend against brute force or dictionary password cracking tools is to establish and enforce long, complex passwords. Windows 2000 lets you set policy to govern the complexity, length, lifetime, and reusability of user passwords. A complex password has ten or more characters, including upper and lowercase, punctuation, and numerals. An example of a complex password is:
Smart cards provide much stronger authentication than passwords, but they also involve extra overhead. Smart cards require configuration of the Microsoft Certificate
Services, smart card reader devices, and the smart cards themselves. For more information about deploying smart cards, see “Smart Card Logon” later in this chapter and “Planning Your Public Key Infrastructure” in this book.
Note that third-party vendors offer a variety of security products to provide two-factor authentication, including “security tokens” and biometric accessories. These accessories use extensible features of the Windows 2000 graphical logon user interface to provide alternate methods of user authentication.
390 Part 3 Active Directory Infrastructure
“Trust computer for delegation” is a very powerful capability. It is not enabled by default and requires Domain Administrator privileges to enable for specific computers or service accounts. Computers or accounts that are trusted for delegation need to be under restricted access to prevent introduction of Trojan horse programs that would misuse the capability of making network connections on behalf of users.
Some accounts might be too sensitive to permit delegation, even by a trusted server.
You can set individual user accounts so that they cannot be delegated, even if the service is trusted for delegation. To use this feature, go to the Active Directory Users and Computers MMC snap-in and open the property sheet for the account. Look for the Account is sensitive and cannot be delegated check box on the Account tab of the property sheet.
Kerberos Authentication and Trust
The Kerberos authentication protocol is a technology for single sign-on to network resources. Windows 2000 uses the Kerberos v5 protocol to provide fast, single signon to network services within a domain, and to services residing in trusted domains.
Kerberos protocol verifies both the identity of the user and of the network services, providing mutual authentication.
How Kerberos Authentication Works
When a user enters domain credentials (by user name and password or smart card logon), Windows 2000 locates an Active Directory server and Kerberos authentication service. The Kerberos service issues a “ticket” to the user. This is a temporary certificate containing information that identifies the user to network servers. After the initial interactive logon, the first Kerberos ticket is used to request other Kerberos tickets to log on to subsequent network services. This process is complex and involves mutual authentication of the user and the server to one another, but it is completely transparent to the user. (For more information about Kerberos v5 authentication, see
Windows 2000 Server Help.)
Kerberos authentication reduces the number of passwords a user needs to remember, and thereby reduces the risk of identity interception. Trust relationships between domains in a forest extend the scope of Kerberos authentication to a wide range of network resources.
Chapter 11 Planning Distributed Security 391
Implementing Kerberos Authentication
There are no prerequisites for implementing Kerberos authentication. The Kerberos protocol is used pervasively in Windows 2000. You do not need to install or initiate it.
Kerberos security policy parameters can be set in the Group Policy snap-in to MMC.
Within a Group Policy object, the Kerberos settings are located under Account
Group Policy object
These settings must be used only by qualified administrators who are familiar with the
Considerations about Kerberos Security
To reap the full benefits of the enhanced performance and security of Kerberos authentication, consider deploying Kerberos sign in as the only network logon protocol in your enterprise. Windows 2000 implements the IETF standard version of
Kerberos v5 authentication protocol for cross-platform interoperability. For example, users on UNIX systems can use Kerberos credentials to log on to UNIX systems and to securely connect to Windows 2000 services for applications that are enabled by
Kerberos authentication. Enterprise networks that already use Kerberos authentication based on UNIX realms can create trust relationships with Windows 2000 domains and integrate Windows 2000 authorization for UNIX accounts using Kerberos name mapping.
Note that computers on a Kerberos-authenticated network typically must have their time settings synchronized with a common time service within five minutes, or authentication fails. Windows 2000 computers automatically update the current time using the domain controller as a network time service. Domain controllers use the primary domain controller for the domain as the authoritative time service. Even if the current time is different on computers within a domain, or across domains,
Windows 2000 automatically handles clock differences to avoid logon problems.
When using transitive trust between domains in a forest, the Kerberos service searches for a trust path between the domains to create a cross-domain referral. In large trees it might be more efficient to establish cross-links of bidirectional trusts between domains where there is a high degree of cross-domain interaction. This permits faster authentication by giving the Kerberos protocol “shortcuts” to follow when generating the referral message.
392 Part 3 Active Directory Infrastructure
Kerberos authentication uses transparent transitive trust among domains in a forest, but it cannot authenticate between domains in separate forests. To use a resource in a separate forest, the user has to provide credentials that are valid for logging on to a domain in that forest. Alternatively, if a one-way trust relationship exists, applications will use NTLM authentication, if the security policy permits.
Windows 2000 still maintains compatibility with the NTLM authentication protocol to support compatibility with previous versions of Microsoft operating systems. You can continue to use NTLM for Microsoft
NT 4.0 Server, and Windows NT 4.0 Workstation clients.
NTLM authentication is also used on Windows 2000 by applications designed for previous versions of Windows NT that specifically request NTLM security.
Smart Card Logon
Windows 2000 supports optional smart card authentication. Smart cards provide a very secure means of user authentication, interactive logon, code signing, and secure e-mail. However, deploying and maintaining a smart card program requires additional resources and costs.
How Smart Cards Work
The smart card contains a chip that stores the user’s private key, logon information, and public key certificate for various purposes. The user inserts the card into a smart card reader attached to the computer. The user then types in a personal identification number (PIN) when requested.
Smart cards provide tamper-resistant authentication through onboard private key storage. The private key is used in turn to provide other forms of security related to digital signatures and encryption.
Smart cards directly implement a two-factor authentication policy, and indirectly permit data confidentiality, data integrity, and nonrepudiation for multiple applications, including domain logon, secure mail, and secure Web access.
Prerequisites for Implementing Smart Cards
Smart cards rely on the public key infrastructure (PKI) of Windows 2000. For more information about PKI, see “Planning Your Public Key Infrastructure” in this book.
Chapter 11 Planning Distributed Security 393
How to Implement Smart Cards
In addition to PKI and the cards themselves, each computer needs a smart-card reader.
Set up at least one computer as a smart-card enrollment station, and authorize at least one user to operate it. This does not require special hardware beyond a smart card reader, but the user who operates the enrollment station needs to be issued an
Enrollment Agent certificate.
For detailed procedures on implementing smart cards, see Windows 2000 Server
Considerations about Smart Cards
You need an enterprise certification authority rather than a stand-alone or third-party certification authority to support smart card logon to Windows 2000 domains.
Microsoft supports industry standard Personal Computer/Smart Card (PC/SC)– compliant smart cards and readers and provides drivers for commercially available
Plug and Play smart card readers. Smart card logon is supported for Windows 2000
Professional, Windows 2000 Server, and Windows 2000 Advanced Server systems.
The security benefits of using smart cards are realized as more users of the enterprise become able to use smart cards for domain authentication, remote dial-up network access, and other applications.
Microsoft Windows 2000 does not support non-PC/SC-compliant or non–Plug and
Play smart card readers. Some manufacturers might provide drivers for non–Plug and
Play smart card readers that work with Windows 2000; nevertheless, it is recommended that you purchase only Plug and Play PC/SC-compliant smart card readers.
Smart cards can be combined with employee card keys and identification badges to support multiple uses per card.
The overall cost of administering the smart card program depends on several factors, including:
The number of users enrolled in the smart card program and their location.
Your practices for issuing smart cards to users, including the requirements for verifying user identities. For example, will you require users to simply present a valid personal identification card or will you require a background investigation? Your policies affect the level of security provided as well the actual cost.
394 Part 3 Active Directory Infrastructure
Your practices for users who lose or misplace their smart cards. For example, will you issue temporary smart cards, authorize temporary alternate logon to the network, or make users go home to retrieve their smart cards? Your policies affect how much worker time is lost and how much help desk support is needed.
Your network security deployment plan needs to describe the network logon and authentication methods you use. Include the following information in your security plan:
Identify network logon and authentication strategies you want to deploy.
Describe smart card deployment considerations and issues.
Describe PKI certificate services required to support smart cards.
Routing and Remote Access is the service that lets remote users connect to your local network by phone. This section deals only with the remote access security features of
Routing and Remote Access. Remote access by its nature is an invitation to intruders; so Windows 2000 provides multiple security features to permit authorized access while limiting opportunities for mischief.
How Remote Access Works
A client dials a remote access server on your network. The client is granted access to the network if:
The request matches one of the remote access policies defined for the server.
The user’s account is enabled for remote access.
Client/server authentication succeeds.
After the client has been identified and authorized, access to the network can be limited to specific servers, subnets, and protocol types, depending on the remote access profile of the client. Otherwise, all services typically available to a user connected to a local area network (including file and print sharing, Web server access, and messaging) are enabled by means of the remote access connection.
Remote Access Policies
Windows 2000–based servers are governed by security policies that determine their remote access behavior. These policies establish whether a server accepts requests for remote access and, if so, during what hours of what days, what protocols are used, and what types of authentication are required.
Chapter 11 Planning Distributed Security 395
You define remote access policies by using the Computer Management snap-in to
MMC. You define the policy in the Remote Access Policies node:
Computer Management (local)
Services and Applications
Routing and Remote Access
Remote Access Policies
Right-click a policy in the console tree and select Properties. A remote access policy is defined as a rule with conditions and actions. If the conditions are met, the action is taken. For example, if the time of day is appropriate for remote access, if the requested protocol is permitted, and if the requested port type is available, then access is granted. If granted, remote access is limited by the access profile of the policy. Click
Edit Profile to view the available profile options.
How to Enable Remote Access
To enable remote access for a user, open the Active Directory Users and Computers snap-in to MMC. Right-click a user, and select Properties. Select the Dial-In tab in the property sheet.
For more information about remote access and installing and configuring the remote access server, see Windows 2000 Server Help. For more information about remote access authentication, see “Remote Access Server” in the Microsoft
Server Resource Kit Internetworking Guide.
Considerations About Remote Access
Granting remote access permission to a user is ineffective if there is no appropriate remote access policy in place for the remote access server.
Windows 2000 supports the following authentication options for remote access:
Standard Point-to-Point Protocol (PPP) challenge and response authentication methods based on user name and passwords.
Standard PPP authentication methods offer limited security.
Custom Extensible Authentication Protocol (EAP) authentication methods.
EAP modules can be developed or provided by third parties to extend the authentication capabilities of PPP. For example, you can use EAP to provide stronger authentication using token cards, smart cards, biometric hardware, or one-time password systems.
396 Part 3 Active Directory Infrastructure
EAP Transport Layer Security (EAP-TLS) authentication based on digital certificates and smart cards.
EAP-TLS provides strong authentication. Users’ credentials are stored on tamper-proof smart cards. You can issue each user one smart card to use for all logon needs.
It is recommended that your network security plan include strategies for remote access and authentication, including the following information:
Logon authentication strategies to be used.
Remote access strategies by using Routing and Remote Access and virtual private networks.
Certificate services needed to support user logon authentication by digital certificates.
Process and strategies to enroll users for logon authentication certificates and remote access.
Whether to use callback with remote access, to help eliminate impersonation attacks.
Applying Access Control
After a user logs on, the user is authorized to access various network resources, such as file servers and printers that grant permissions to Authenticated Users. Make certain you restrict a user’s view of network resources to the devices, services, and directories that are job related. This limits the damage that an intruder can do by impersonating a legitimate user.
Access to network resources is based on permissions. Permissions identify users and groups who are allowed to perform specific actions by using specific resources. For example, the Accounting Group has read/write permission to access files in the
Accounting Reports folder. The Auditor Group has read-only access to files in the
Accounting Reports folder.
Permissions are enabled by using the ACL associated with each resource. You can find the ACL on the Security tab of the property sheet. An ACL is a list of the security groups (and rarely the individuals) who have access to that resource.
Security groups are the most efficient way to manage permissions. You can assign permissions to individuals; but in most cases, it is easier to grant permissions to a group and then add or remove users as members of the group.
Chapter 11 Planning Distributed Security 397
Windows 2000 has a security group called “Everyone” which appears on networkshare ACLs by default when they are created. To restrict access to network shares, you must remove the Everyone group and substitute a more appropriate group or groups. Do not assume the default permissions for a resource are necessarily appropriate permissions.
File system permissions by default are granted to a security group called Users. Any user authenticated to the domain is in the group called Authenticated Users, which is also a member of Users. Look at what the resource is used for and determine the appropriate policy. Some resources are public while others need to be available to specific sets of people. Sometimes a large group has read-only permission to a file or directory, and a smaller group has read/write permission.
Access Control Lists
ACLs describe the groups and individuals who have access to specific objects in
Windows 2000. The individuals and security groups are defined in the Active
Directory Users and Computers snap-in to MMC. Many types of Windows 2000 objects have associated ACLs, including all Active Directory objects, local NTFS files and folders, the registry, and printers. The granularity of ACLs is so fine that you can even place security access restrictions on individual fonts.
How ACLs Work
Access control lists implement usage restriction strategies. Windows 2000 offers a very fine degree of security control over access to a wide variety of objects. To give a group access to an object, you add the group to the ACL of the object. Then you can adjust the specific permissions that the group can exercise over the object. In terms of a local file folder, for example, the available permissions for a group begin with read,
write, modify, and delete, but those are only the first four of thirteen available permissions.
Prerequisites for Implementing ACLs
Access control lists are pervasive throughout Windows 2000. The only prerequisite is that ACLs are lists of security groups and users. You must define the groups that describe your organization project teams or business roles before adding them to the
How to Implement ACLs
The access control list for an object is generally found in the Security tab of the property sheet. This tab shows the list of groups that have access to this object, plus a summary of the permissions enjoyed by each group. There is an Advanced button that displays the group permissions in detail so that users can use more advanced features for granting permissions, such as defining access inheritance options.
398 Part 3 Active Directory Infrastructure
For example, to view the access control list for a printer, click Start, and then point to
Settings. Point to the folder that contains Control Panel, and then click Printers.
Right-click a printer and select Properties. The access control list for that printer is in the Security tab.
To see the access control list for a local file folder, open My Computer and use
Explore to navigate to the folder. Right-click the folder. Point to Properties, and click the Security tab.
To view the access control list of an organizational unit (folder) in the Active
Directory Users and Computers MMC snap-in, you must open the View menu and select Advanced Features. Otherwise, the Security tab is not visible in the
Properties dialog box.
For additional information about access control and ACLs, open Windows 2000
Server Help and click the Index tab. Scroll to Access Control. There are many related topics in the index because ACLs are available throughout the product.
Windows 2000 allows you to organize users and other domain objects into groups for easy administration of access permissions. Defining your security groups is a major task for your distributed security plan.
The Windows 2000 security groups let you assign the same security permissions to large numbers of users in one operation. This ensures consistent security permissions across all members of a group. Using security groups to assign permissions means the access control on resources remains fairly static and easy to control and audit. Users who need access are added or removed from the appropriate security groups as needed, and the access control lists change infrequently.
How Security Groups Work
Windows 2000 Active Directory supports security groups and distribution groups.
The security groups can have security permissions associated with them and can also function as mailing lists. The distribution groups are used for mailing lists only. They have no security function.
When you create a new user, you can add the user to an existing security group to completely define the user’s permissions and access limits. Changing a permission for the group affects all users in the group. Windows 2000 comes with several predefined security groups, and it is easy to create your own.
Chapter 11 Planning Distributed Security 399
Security Group Types
Windows 2000 supports four types of security groups, differentiated by scope:
Domain local groups are best used for granting access rights to resources such as file systems or printers that are located on any computer in the domain where common access permissions are required. The advantage of domain local groups used to protect resources is that members of the domain local groups can come from both inside the same domain and outside the domain.
Typically, resource servers are in domains that have trust to one or more
Master User Domains, or what are known as account domains. (A domain local group can be used to grant access to resources on any computer only in native mode domains. In mixed mode, domain local groups must be on domain controllers only.)
Global groups are used for combining users who share a common access profile based on job function or business role. Typically, organizations use global groups for all groups where membership is expected to change frequently. These groups can only have as members user accounts defined in the same domain as the global group. Global groups can be nested to allow for overlapping access needs or to scale for very large group structures. The most convenient way to grant access to global groups is by making the global group a member of a resource group that is granted access permissions to a set of related project resources.
Universal groups are used in larger, multidomain organizations where there is a need to grant access to similar groups of accounts defined in multiple domains. It is better to use global groups as members of universal groups to reduce overall replication traffic from changes to universal group membership.
Users can be added and removed from the corresponding global group within their account domains and a small number of global groups are the direct members of the universal group. Universal groups are easily granted access by making them a member of a domain local group used to grant access permissions to resources.
Universal groups are used only in multiple domain trees or forests that have a global catalog. A Windows 2000 domain must be in native mode to use universal groups. A domain model that has only a single domain does not need or support universal groups.
Computer local groups are security groups that are specific to a computer and are not recognized elsewhere in the domain. If a member server is a file server and hosts 100 gigabytes (GB) of data on multiple shares, you can use a local server group for administrative tasks performed directly on that computer or for defining local access permission groups.
400 Part 3 Active Directory Infrastructure
Default Permissions of Security Groups
For member servers and client computers, the default Windows 2000 access control permissions provide the following levels of security:
Members of the Everyone and Users groups (normal users) do not have broad read/write permission as in Windows NT 4.0. These users have read-only permission to most parts of the system and read/write permission only in their own profile folders. Users cannot install applications that require modification to system directories nor can they perform administrative tasks.
Members of the Power Users group have all the access permissions that Users and Power Users had in Windows NT 4.0. Power Users have read/write permission to other parts of the system in addition to their own profile folders.
Power users can install applications and perform many administrative tasks.
Members of the Administrators group have the same level of rights and permissions as they did for Windows NT 4.0.
For servers configured as domain controllers, the default Windows 2000 security groups provide the following security:
Members of the Everyone and Users groups do not have broad read/write permission as in Windows NT 4.0. Normal users have read-only permission to most parts of the system and read/write permission in their own profile folders.
However, normal users can only access domain controllers over the network
— interactive logon to domain controllers is not granted to users as in
Windows NT 4.0.
Members of the Account Operators, Server Operators, and Print Operators groups have the same access permissions as in Windows NT 4.0.
Members of the Administrators group have total control of the system as in
Windows NT 4.0.
Prerequisites for Implementing Security Groups
Security groups are a built-in feature of Active Directory. No special installation or prerequisite is required.
Implementing Security Groups
To create new users and place them in Security groups, use the Active Directory Users and Computers snap-in of MMC. For more information about creating new users, see
Windows 2000 Server Help.
Considerations About Security Groups
When designing potential security groups, a good strategy is for project or resource owners to define their own local groups based on required access permissions, and to delegate the ability to manage the group memberships, which itself is a permission of groups. This strategy allows the resource owners or project leads to manage access by updating the appropriate group.
Chapter 11 Planning Distributed Security 401
A security group is composed of people who have similar roles in the department or in the enterprise. The group is often named after the role, such as the Windows 2000 built-in groups for Account Operators, Administrators, and Backup Operators.
Personnel who naturally belong on the same project or department mailing list probably belong in the same security group in Active Directory. Windows 2000 security groups have a secondary role as mailing lists, so this analogy is not a coincidence.
Using groups that correspond to project teams or responsibilities is an effective way to grant access appropriately. Everyone in a department needs access to the department printers. The engineers on a software project need access to the common source directories. These are natural groups.
Note that the system has to determine all of a user’s universal and global group affiliations at logon time. When a user is a member of many groups, this has some impact on performance while the system determines all the group memberships.
There is an upper limit on the number of groups a user can enroll in. For an individual user operating in a single domain, the total sum of universal, global, domain local, and local computer groups cannot exceed 1,000 groups. The user is not strictly limited to
1,000 groups, however, because the limit applies from the point of view of an individual domain. In a multiple domain model, a user could hypothetically be a member of 500 universal and global groups in their account domain, in 400 domain local groups in one resource domain, in 400 domain local groups in another resource domain, in 50 local groups in one server, and 100 local groups on another server. For most practical purposes, the 1,000-group limit is very generous.
Use nested groups to make it easier to manage group membership for large groups. (A large group might have 5,000 members in it.) Do not list every employee individually in your whole-company group. The whole-company group will be easier to administer if defined as the group that contains your department groups. The department groups can be nested within the whole-company group.
This is especially important if your whole-company group is a universal group. An organization with a single local area network (LAN) site can use universal groups with no performance degradation. However, an organization with a wide area network
(WAN) needs to consider the impact of frequent changes to universal group membership on replication traffic across links between sites. If a universal group contains only other groups as members, it does not change very often and replication traffic is essentially nothing. A universal group containing thousands of individual users is likely to require frequent updates across multiple WAN links as each change replicates to all Global Catalog servers in the enterprise. Defining universal groups as groups of groups reduces this network activity.
You might find that your Windows 2000 Server does not permit nested groups.
Windows 2000 Server initially operates in mixed mode, which means that
Windows 2000 and Windows NT 4.0 Servers can interoperate in the same network.
Mixed mode places some restrictions on security groups. When all servers have been upgraded to Windows 2000, you can switch to native mode. This is a one-way transition that enables advanced features such as nesting of security groups.
402 Part 3 Active Directory Infrastructure
For a specific computer, the users in the local administrator security group have full rights and permissions for that computer. When a Windows 2000 computer is joined to a domain, the Domain Administrators group is added as a member of the local administrator group. Local users of the computer generally do not need to be members of the administrators group. The full-privilege administrator group must be used for local administration activities, such as changing the system configuration.
Your network security deployment plan describes your strategies for security groups.
Include the following information in your deployment plan:
Identify the universal and global security groups you want to create in addition to the built-in groups.
Identify membership requirements for universal, global, and local security groups, including the built-in groups.
Security Groups and Replication Conflicts
If administrators at two different two domain controllers in different site change group membership simultaneously, one of the changes might be lost. This situation can occur only if you are making group membership changes faster than the system can replicate them. When an administrator adds or removes members from a group, the entire group membership is replicated, not just the changed members. If two administrators change group membership on two different domain controllers and replication takes place on the second domain controller before the first domain controller completes replication, only one of the changes remain after the Active
Directory resolves the replication conflict. The other change is lost. As a result, a user might unexpectedly retain access to a resource.
One way to minimize this problem is to use nested groups. Create site-specific groups and make them members of a parent group that will be used to grant or deny access to a resource. Administrators in a site can then change the membership of a site-specific group and not lose changes as long the membership of the site-specific group is not updated on multiple domain controllers faster than intra-site replication can complete.
Also, if you delegate responsibility for group membership changes to one administrator per site, all changes will be made on a single domain controller and no replication conflicts will occur.
Within a single Active Directory site, the amount of time it takes for a change to reach all of the domain controllers will increase as the number of domain controllers increases with a maximum latency of approximately three times the replicator notify pause interval. Generally, replication will finish quickly within a single site. Replication between two or more Active Directory sites generally takes longer, and is dependent on the replication schedule configured by the administrator as well as whether or not the administrator configures inter-site replicator notifications.
To avoid this situation completely, make all group membership changes on a single domain controller. This will prevent changes from being lost due to replication conflicts. For more information about both the multimaster conflict resolution policy for Active Directory and how to configure Active Directory to minimize replication latency, see “Active Directory Replication” in the Microsoft Windows Server
Resource Kit Distributed Systems Guide.
Chapter 11 Planning Distributed Security 403
Establishing Trust Relationships
Your distributed security plan needs to take into consideration the proposed structure of your domains, trees of domains, forests, and non–Windows 2000 Servers. Although
Windows 2000 establishes default trust relationships automatically, your plan needs to address what domains need to be part of the domain forest and what domains might require explicit trusts for your network.
For Windows 2000 computers in the same forest, account authentication between domains is enabled by two-way, transitive trusts. The transitive trust relationship is automatically established when a new domain is joined to a domain tree. A trust relationship is defined by a secret key that is shared by both domains and that gets updated on a regular basis. Trust relationships are used by the Kerberos v5 authentication when clients and servers are in separate domains in the forest. The trust secret key is used by the Kerberos service to create a referral ticket to the trusting domain. NTLM authentication also uses trust relationships for pass-through authentication. Pass-through authentication uses the trust link secret key to establish a secure channel between domains. In Windows 2000, NTLM authentication also supports transitive trust if the domains are in native mode.
A domain trust is a useful way to allow users from a trusted domain to access services in a trusting domain. If all users and services can be managed in a single enterprise domain, there is no need for trust relationships. However, there are several advantages to creating separate domains. Domains are a useful way to separate the scope of responsibility of the domain administrators. Each administrator is responsible for the users and resources within a domain. Domains are also the scope for security policy settings, such as account policies. Most trust relationships in a Windows 2000 forest are implicit two-way transitive trusts that require no planning. It is the external trust relationships to Windows NT 4.0 domains, or other Windows 2000 domains in a separate forest, that need to be mentioned in your plan.
How Trust Relationships Work
All domain trust relationships have only two domains in the relationship: the trusting domain and the trusted domain. A domain trust relationship is characterized by whether it is:
A one-way trust is a single trust relationship, where domain A trusts domain B. All one-way relationships are nontransitive. Authentication requests can only be passed from the trusting domain to the trusted domain. This means that if domain A has a one-way trust with domain B and domain B has a one-way trust with domain C, domain A does not have a trust relationship with domain C.
404 Part 3 Active Directory Infrastructure
A Windows 2000 domain can establish a one-way trust with:
Windows 2000 domains in a different forest
Windows NT 4.0 domains
MIT Kerberos v5 realms
Since all Windows 2000 domains in a forest are automatically linked by transitive trusts, it is generally not necessary to create one-way trusts between all
Windows 2000 domains in the same forest.
All domain trusts within a Windows 2000 forest are two-way transitive trusts.
Transitive trusts are always two-way: both domains in the relationship trust each other. Each time you create a new child domain, a two-way transitive trust relationship is created between the parent and new child domain. In this way, transitive trust relationships flow upward through the domain tree as it is formed, creating transitive trusts between all domains in the domain tree.
Each time you create a new domain tree in a forest, a two-way transitive trust relationship is created between the forest root domain and the new domain (the root of the new domain tree). In this way, transitive trust relationships flow through all domains in the forest. Authentication requests follow these trust paths, so accounts from any domain in the forest can be authenticated at any other domain in the forest.
You can also explicitly (manually) create transitive trusts between Windows 2000 domains on different branches of the same domain tree or in different trees of a forest.
These cross-linked trust relations can be used to shorten the trust path in large and complex domain trees or forests. These explicit trusts need to be provided for in your distributed security plan.
A nontransitive trust is bounded by the two domains in the trust relationship and does not flow to any other domains in the forest. You must explicitly create nontransitive trusts. Nontransitive trusts are one-way by default, although you can also create a twoway relationship by creating two one-way trusts. All trust relationships established between domains that are not in the same forest are nontransitive.
Transitive trusts can only exist between Windows 2000 domains in the same forest.
In summary, nontransitive domain trusts are the only form of trust relationship possible between:
A Windows 2000 domain and a Windows NT domain.
A Windows 2000 domain in one forest and a Windows 2000 domain in another forest.
A Windows 2000 domain and an MIT Kerberos v5 realm.
Chapter 11 Planning Distributed Security 405
Prerequisites for Implementing Trusts
There are no specific prerequisites for trusts except to understand that trusts are links between domains. You need to set up at least two domains before you can define a trust relationship.
How to Implement Trusts
To set up explicit trusts among domains in a forest, open MMC snap-in for Active
Directory Domains and Trusts. Right-click a domain and open the property sheet.
Select the Trusts tab. This tab allows you to add, edit, or delete trust relationships between the selected domain and others in the same forest.
Considerations About Trusts
Mixed mode domains (where Windows NT 4.0 backup domain controllers are temporarily combined with a Windows 2000 primary domain controller during network upgrades) implement trust relationships in a manner consistent with
Windows NT 4.0 domains for Windows NT 4.0 Workstations and Servers. In other words, all trust relationships required for Windows NT 4.0 Workstations and Servers are still needed for mixed mode domains. Native mode domains (where all servers are running Windows 2000) support transitive trust.
Domain administrators of any domain in the forest have the potential to take ownership and modify any information in the Configuration container of Active
Directory. These changes will be available and replicate to all domain controllers in the forest. Therefore, for any domain that is joined to the forest, you must consider that the domain administrator of that domain is trusted as an equal to any other domain administrator.
Domains where the domain administrators are not fully or equally trusted can be handled in two ways. The first is to set up an explicit one-way trust (or external trust) to that domain. In this way, users logging on to the suspect domain do not have automatic access to the rest of the forest.
To control this situation with a finer degree of granularity, consider collapsing the resources of the suspect domain into an organizational unit (Active Directory folder) of a domain under the control of a trusted administrator. Remove the separate domain altogether. The administrator of the suspect domain can be delegated only the appropriate degree of control over the computers and local groups that are the administrator’s domain resources.
406 Part 3 Active Directory Infrastructure
Enabling Data Protection
Information security strategies protect data on your servers and client computers, and also conceal and protect packets traversing insecure networks. Your distributed security plan needs to identify which information must be protected in the event computer equipment is lost or stolen. Also, types of network traffic that are sensitive or private and need to be protected from network sniffers must be included in the plan.
To keep network data packets confidential, you can use Internet Protocol security
(IPSec) to encrypt network traffic among some or all of your servers. IPSec provides the ability to set up authenticated and encrypted network connections between two computers. For example, you could configure your e-mail server to require secure communication with clients and thereby prevent a packet sniffer from reading e-mail messages between the clients and the server. IPSec is ideal for protecting data from existing applications that were not designed with security in mind.
Network and Dial-up Connections (remote access) always protect network data transmitted over the Internet or public phone lines. Remote access uses a virtual private network that uses the PPTP or LT2P tunneling protocol over IPSec.
Encrypting File System
The Windows 2000 Encrypting File System (EFS) lets a user encrypt designated files or folders on a local computer for added protection of data stored locally. EFS automatically decrypts the file for use and reencrypts the file when it is saved. No one can read these files except the user who encrypted the file and an administrator with an EFS Recovery certificate. Since the encryption mechanism is built into the file system, its operation is transparent to the user and extremely difficult to attack.
EFS is particularly useful for protecting data on a computer that might be physically stolen, such as a laptop. You can configure EFS on laptops to ensure that all business information is encrypted in users’ document folders. Encryption protects information even if someone bypasses EFS and uses low-level disk utilities to try to read information.
Chapter 11 Planning Distributed Security 407
EFS is intended primarily for protection of user files on the disk of the local NTFS file system. As you move away from this model (remote drives, multiple users, editing encrypted files) there are numerous exceptions and special conditions to be aware of.
How EFS Works
EFS encrypts a file using a symmetric encryption key unique to each file. Then it encrypts the encryption key as well, using the public key from the file owner’s EFS certificate. Since the file owner is the only person with access to the private key, that person is the only one who can decrypt the key, and therefore the file.
There is also provision for the original encryption key to be encrypted using the public key of an administrator’s EFS File Recovery certificate. The private key from that certificate can be used to recover the file in an emergency. It is highly recommended that an organization establish a recovery agent.
Even if the file can be stolen, over the network or physically, it cannot be decrypted without first logging on the network as the appropriate user. Since it cannot be read, it cannot be surreptitiously modified. EFS addresses an aspect of a policy of data confidentiality.
Prerequisites for Implementing EFS
To implement EFS, a public key infrastructure must be in place and at least one administrator must have an EFS Data Recovery certificate so the file can be decrypted if anything happens to the original author. The author of the file must have an EFS certificate. The files and folders to be encrypted must be stored on the version of
NTFS included with Windows 2000.
How to Implement EFS
Open Windows Explorer and right-click a folder or a file. Select Properties. On the
General tab, click Advanced. Then select the Encrypt Contents to Secure Data check box. The contents of the file, or of all the files in the selected folder, are now encrypted until you clear the check box.
For more information about best practices for encrypting file systems, see the
Windows 2000 Server Help. See also “Encrypting File System” in the Microsoft
2000 Server Resource Kit Distributed Systems Guide.
Considerations About EFS
EFS is only supported for the version of NTFS used in Windows 2000. It does not work with any other file system, including previous versions of NTFS.
408 Part 3 Active Directory Infrastructure
EFS can be used to store sensitive data securely on shared servers to allow for normal data management (backup). The servers must be well protected and must be “Trusted for Delegation.” EFS services will “impersonate” the EFS user and make other network connections on their behalf when encrypting and decrypting files.
EFS uses a Data Recovery policy that enables an authorized data recovery agent to decrypt encrypted files. EFS requires at least one recovery agent. Recovery agents can use EFS to recover encrypted files if users leave the organization or lose their encryption credentials. You need to plan to deploy the PKI components and issue one or more certificates for EFS data recovery. These certificates need to be securely stored offline so they cannot be compromised. EFS can generate its own certificates for EFS users and EFS recovery agents. By default, EFS issues EFS Recovery certificates to the Domain Administrator account as the recovery agent for the domain.
For stand-alone computers that are not joined to a domain, EFS issues EFS Recovery certificates to the local Administrator user account as the recovery agent for that computer. Many organizations might want to designate other EFS recovery agents to centrally administer the EFS recovery program. For example, you can create organizational units for groups of computers and designate specific recovery agent accounts to manage EFS recovery for specific organizational units.
You can deploy Microsoft Certificate Services to issue certificates to EFS recovery agents and EFS users. When certificate services are available online, EFS uses the certificate services to generate EFS certificates.
Note that because cluster services do not support reparse points on shared storage,
EFS cannot be used if the file server is actually a Windows cluster.
Include strategies for EFS and EFS recovery in your network security deployment plan. EFS strategies might include the following information:
File system strategies for laptops and other computers.
EFS recovery agents.
Recommended EFS recovery process.
Recommended EFS recovery agent private key management and archive process.
Certificate services needed to support EFS recovery certificates.
Chapter 11 Planning Distributed Security 409
Windows 2000 incorporates Internet Protocol security (IPSec) for data protection of network traffic. IPSec is a suite of protocols that allow secure, encrypted communication between two computers over an insecure network. The encryption is applied at the IP network layer, which means that it is transparent to most applications that use specific protocols for network communication. IPSec provides end-to-end security, meaning that the IP packets are encrypted by the sending computer, are unreadable en route, and can be decrypted only by the recipient computer. Due to a special algorithm for generating the same shared encryption key at both ends of the connection, the key does not need to be passed over the network.
How IPSec Works
IPSec has many intricate components and options that are worthy of detailed study; but at a high level the process operates in this manner:
1. An application on Computer A generates outbound packets to send to
Computer B across the network.
2. Inside TCP/IP, the IPSec driver compares the outbound packets against IPSec filters, checking to see if the packets need to be secured. The filters are associated with a filter action in IPSec security rules. Many IPSec security rules can be inside one IPSec policy that is assigned to a computer.
3. If a matched filter has to a negotiate security action, Computer A begins security negotiations with Computer B, using a protocol called the “Internet
Key Exchange” (IKE). The two computers exchange identity credentials according to the authentication method specified in the security rule.
Authentication methods could be Kerberos authentication, public key certificates, or a preshared key value (much like a password). The IKE negotiation establishes two types of agreements, called “security associations,” between the two computers. One type (called the “phase I IKE SA”) specifies how the two computers trust each other and protects their negotiation. The other type is an agreement on how to protect a particular type of application communication. This consists of two SAs (called “phase II IPSec SAs”) that specify security methods and keys for each direction of communication. IKE automatically creates and refreshes a shared, secret key for each SA. The secret key is created independently at both ends without being transmitted across the network.
410 Part 3 Active Directory Infrastructure
4. The IPSec driver on Computer A signs the outgoing packets for integrity, and optionally encrypts them for confidentially using the methods agreed upon during the negotiation. It transmits the secured packets to Computer B.
Firewalls, routers, and servers along the network path from Computer A to
Computer B do not require IPSec. They simply pass along the packets in the usual manner.
5. The IPSec driver on Computer B checks the packets for integrity and decrypts their content if necessary. It then transfers the packets to the receiving application.
IPSec provides security against data manipulation, data interception, and replay attacks.
IPSec is important to strategies of data confidentiality, data integrity, and nonrepudiation.
Prerequisites for Implementing IPSec
The computers in your network need to have an IPSec security policy defined that is appropriate for your network security strategy and for the type of network communication that they perform. Computers in the same domain might be organized into groups with IP security policy applied to the groups. Computers in different domains might have complementary IPSec security policies to support secure network communications.
How to Implement IPSec
You can view the default IP security policies in the Group Policy snap-in to MMC.
The policies are listed under IP Security Policies on Active Directory, or under IP
Security Policies (Local Computer):
Group Policy object
IP Security Policies on Active Directory
You can also view IPSec policies by using the IP Security Policy Management snap-in to MMC. Each IP Security policy contains security rules that determine when and how traffic is protected. Right-click a policy and select Properties. The Rules tab lists the policy rules. Rules can be further decomposed into filter lists, filter actions, and additional properties.
For more information about Internet Protocol security, see the Windows 2000 Server
Help. See also “Internet Protocol Security” in the Microsoft
Resource Kit TCP/IP Core Networking Guide.
Chapter 11 Planning Distributed Security 411
Considerations for IPSec
IPSec provides encryption of outgoing and incoming packets, but at a cost of additional CPU utilization when encryption is performed by the operating system. For many deployments, the clients and servers might have considerable CPU resources available, so that IPSec encryption will not have a noticeable impact on performance.
For servers supporting many simultaneous network connections or servers that transmit large volumes of data to other servers, the additional cost of encryption is significant. For this reason, you need to test IPSec using simulated network traffic before you deploy it. Testing is also important if you are using a third-party hardware or software product to provide IP security.
Windows 2000 provides device interfaces to allow hardware acceleration of IPSec per-packet encryption by intelligent network cards. Network card vendors might provide several versions of client and server cards, and might not support all combinations of IPSec security methods. Consult the product documentation for each card to be sure that it supports the security methods and the number of connections you expect in your deployment.
You can define Internet Protocol security (IPSec) policies for each domain or organizational unit. You can also define local IPSec policy on computers that do not have domain IPSec policy assigned to them. You can configure IPSec policies to:
Specify the levels of authentication and confidentiality required between IPSec clients.
Specify the lowest security level at which communications are allowed to occur between IPSec-aware clients.
Allow or prevent communications with non-IPSec-aware clients.
Require all communications to be encrypted for confidentiality or you can allow communications in plaintext.
Consider using IPSec to provide security for the following applications:
Peer-to-peer communications over your organization’s intranet, such as legal department or executive committee communications.
Client-server communications to protect sensitive (confidential) information stored on servers. For file share points that require user access controls, consider using IPSec to ensure that other network users cannot see the data as it is being communicated.
412 Part 3 Active Directory Infrastructure
Remote access (dial-up or virtual private network) communications. (For virtual private networks using IPSec with L2TP, remember to set up Group
Policy to permit autoenrollment for IPSec computer certificates. For detailed information about computer certificates for L2TP over IPSec VPN connections, see Windows 2000 Help.)
Secure router-to-router WAN communications.
Consider the following strategies for IPSec in your network security deployment plan:
Identify clients and servers to use IPSec communications.
Identify whether client authentication is based on Kerberos trust or digital certificates.
Describe how each computer will initially receive the proper IPSec policy and will continue to receive policy updates.
Describe the security rules inside each IPSec policy. Consider how certificate services are needed to support client authentication by digital certificates.
Describe enrollment process and strategies to enroll computers for IPSec certificates.
Setting Uniform Security Policies
Uniform security policies allow consistent security settings to be applied and enforced on classes of computers in the enterprise, such as the domain controller class. This is a simple matter of creating an organizational unit, a folder in Active Directory, collecting appropriate computer account objects into the organizational unit, and then applying a Group Policy object to the organizational unit. The security policies specified in the Group Policy are then enforced automatically and consistently on all the computers represented by the computer accounts in the OU.
Windows 2000 comes with a selection of default Group Policy objects that are automatically applied to new domains and to domain controllers. There is also a selection of security templates representing different levels of security for various types of enterprise computers. A template can be used to create a Group Policy for a group of computers or to critique the security settings on a specific computer.
Note that the present discussion is confined to the security settings of Group Policy.
When you apply a Group Policy to an organizational unit, many policies unrelated to security are also included. For a broader discussion of this mechanism, see
Windows 2000 Help and “Defining Client Administration and Configuration
Standards” in this book.
Chapter 11 Planning Distributed Security 413
A Group Policy object contains an extensive profile of security permissions that apply primarily to the security settings of a domain or a computer (rather than to users). A single Group Policy object can be applied to all of the computers in an organizational unit. Group Policy gets applied when the individual computer starts up, and periodically is refreshed if changes are made without restarting.
How Group Policy Works
Group Policy objects are associated with domains and organizational units (folders) in the Active Directory Users and Computers snap-in to MMC. The permissions granted by the Group Policy are applied to the computers stored in that folder. Group Policy can also be applied to sites using the Active Directory Sites and Services snap-in.
Group Policy settings are inherited from parent folders to child folders, which might in turn have their own Group Policy objects. A single folder could have more than one
Group Policy object assigned to it. For more information on Group Policy precedence and how conflicts are resolved among multiple policy objects, see Windows 2000
Group Policy is the complementary component to security groups. Group Policy lets you apply a single security profile to multiple computers. It enforces consistency and provides easy administration.
Group Policy objects contain permissions and parameters that implement multiple types of security strategies.
Prerequisites for Implementing Group Policy
Group Policy is a feature of the Windows 2000 Active Directory. Active Directory must be installed on a server before you can edit and apply Group Policy objects.
How to Implement Group Policy
To view a sample organizational unit and its associated Group Policy, open the Active
Directory Users and Computers MMC snap-in and right-click the Domain
Controllers OU. Open the property sheet and click the Group Policy tab. Select the
Default Domain Controllers Policy and click Edit. This opens the Group Policy snap-in to MMC. In this module, navigate to the Security Settings container:
Group Policy object
414 Part 3 Active Directory Infrastructure
Under Security Settings there are nine subdirectories of security policy settings.
These nine groups are briefly described later in this chapter.
Implementing Group Policy consists of creating a new Group Policy object (or modifying an existing one), enabling appropriate settings within the object, and then linking the Group Policy object to an organizational unit that contains computers in the domain.
Considerations About Group Policy
Create organizational units to contain computers with similar roles in the enterprise.
Use one organizational unit for your domain controllers. Create another one for application servers. Another organizational unit could contain all your client computers. Apply a single Group Policy object to each of these groups to implement consistent security settings.
It is recommended that you minimize the number of Group Policy objects that apply to users and computers. Do this first, because each computer and user Group Policy object must be downloaded to a computer during startup and to user profiles at user logon time. Multiple Group Policy objects increase computer startup and user logon time. Second, applying multiple Group Policy objects can create policy conflicts that are difficult to troubleshoot.
In general, Group Policy can be passed down from parent to child sites, domains and organizational units. If you have assigned a specific Group Policy to a high level parent, that Group Policy applies to all organizational units beneath the parent, including the user and computer objects in each container. For more information on inheritance of Group Policy settings, see “Defining Client Administration and
Configuration Standards” in this book.
Security templates (described later in this chapter) could be useful to you as models of security settings appropriate to different types of Group Policy.
Your network security deployment plan needs to describe significant policy choices for each policy category and subcategory. You can include the following information in your security plan:
Identify Group Policy settings you want to change from the default settings.
Describe all issues related to changing settings for Group Policy.
Describe special security requirements and how you can configure Group
Policy to meet the special requirements.
Chapter 11 Planning Distributed Security 415
Group Policy Security Settings
These are the nine types of Group Policy security features mentioned previously in this chapter. They are containers located in the Security Settings node of a Group
Policy object. They include:
Public Key Policies
Internet Protocol Security Policies on Active Directory
Some of the policy areas apply only to the scope of a domain, that is, the policy settings are domain-wide. Account policies, for example, apply uniformly to all user accounts in the domain. You cannot define different account policies for different organizational units in the same domain.
Of the security policy areas, Account policies and Public Key policies have domainwide scope. All other policy areas can be specified at level of the organizational unit.
Account policies are the first subcategory of Security Settings. The Account policies include the following:
You can modify password policy to meet your organization’s security needs. For example, you can specify minimum password length and maximum password age. You can also require complex passwords and prevent users from reusing passwords or simple variations of passwords.
Account Lockout Policy
You can force users to be locked out after a specified number of failed logon attempts. You can also specify the period of time that accounts are frozen.
Kerberos Authentication Policy
You can modify the default Kerberos settings for each domain. For example, you can set the maximum lifetime of a user ticket.
416 Part 3 Active Directory Infrastructure
The policies you choose affect the level of help desk support required for users as well as the vulnerability of your network to security breaches and attacks. For example, specifying a restrictive account lockout policy increases the potential for denial of service attacks, and setting a restrictive password policy results in increased help desk calls from users who cannot log on to the network.
In addition, specifying restrictive password policy can actually reduce the security of the network. For example, if you require passwords longer than seven characters, most users have difficulty remembering them. They might write their passwords down and leave them where an intruder can easily find them.
Local Computer Policies
The second subcategory of Security Settings is Local Computer policies. Local
Computer policies include the following:
Windows 2000 can record a range of security event types, from a system-wide event, such as a user logging on, to an attempt by a particular user to read a specific file. Both successful and unsuccessful attempts to perform an action can be recorded.
User Rights Assignment
You can control the rights assigned to user accounts and security groups for local computers. You can specify users and security groups who have rights to perform a variety of tasks affecting security. For example, you can control who can access computers from the network, who can log on locally, or who can shut down the system. You can specify who has rights to perform critical administrative tasks on the computer, such as backing up and restoring files and directories, taking ownership of files and objects, and forcing shutdown from a remote system.
You can control a wide variety of security options for local computers. For example, you can specify policies that force users to log off when logon hours expire, disable CTRL+ALT+DEL for logon (to force smart card logon), and force computers to halt if unable to audit.
Event Log Policies
You can use Event Log policies to control the settings of the application, system, and security event logs on local computers. For example, you can specify maximum log sizes, how long logged events are maintained, and log retention methods.
Chapter 11 Planning Distributed Security 417
Restricted Groups Policies
You can define Restricted groups policies to manage and enforce the membership of built-in or user-defined groups that have special rights and permissions. Restricted
Groups policies contain a list of members of specific groups whose membership are defined centrally as part of the security policy. Enforcement of Restricted Groups automatically sets any computer local group membership to match the membership list settings defined in the policy. Changes to group membership by the local computer administrator are overwritten by the Restricted Groups policy defined in Active
Restricted Groups can be used to manage membership in the built-in groups. Built-in groups include local groups such as Administrators, Power Users, Print Operators, and Server Operators, as well as global groups such as Domain Administrators. You can add groups that you consider sensitive or privileged to the Restricted Groups list, along with their membership information. This allows you to enforce the membership of these groups by policy and not allow local variations on each computer.
Systems Services Policies
System services offer a mechanism for potential exploitation by intruders, who can take over the service or use the service as an entry point to gain access to computers and network resources. For example, an intruder can try to exploit weaknesses in a running Web server to gain access to a computer’s operating system or files. You can use Systems Services policies to:
Specify the startup mode for Windows 2000 services (manual or automatic) or to disable services.
For example, you can configure system services to prevent unnecessary services from running. This provides maximum security for special servers such as domain controllers, DNS servers, proxy servers, remote access servers, and certification authority servers.
Specify rights and permissions granted to system services when they run.
For example, you can configure system services to operate with minimum rights and permissions to limit the scope of potential damage caused by intruders who try to exploit the service.
Refine security auditing levels for system services.
You can specify the type of events to be logged for both failed and successful events. For example, when auditing is enabled, you can refine auditing to monitor for inappropriate actions taken by running services.
418 Part 3 Active Directory Infrastructure
You can use registry policies to configure security and control security auditing for registry keys and their subkeys. For example, to ensure that only administrators can change certain information in the registry, you can use registry policies to grant administrators full control over registry keys and their subkeys and to grant read-only permission to other users. You can also use registry policies to prevent certain users from viewing portions of the registry.
You can use registry policies to audit user activity in the registry of the computer when auditing is enabled. You can specify which users and which user events are logged for both failed and successful events.
File System Policies
You can use File System policies to configure security for files and folders and control security auditing of files and folders. For example, to ensure that only administrators can modify system files and folders, you can use File System policies to grant administrators full control over system files and folders and to grant read-only permission to other users. You can also use File System policies to prevent certain users from viewing files and folders.
You can use File System policies to audit user activity affecting files and folders when auditing is enabled. You can specify which users and which user events are logged for both failed and successful events.
Public Key Policies
This subdivision of security settings lets you add a new Encrypted Data Recovery
Agent and set up Automatic Certificate Requests. You can also manage your lists of trusted Certification Authorities.
IP Security Policies on Active Directory
The policies in this section tell the server how to respond to a request for IPSec communications. The server might require secure communication, permit secure communication, or communicate without using IPSec. The predefined policies are not intended for immediate use. They provide examples of behavior for testing purposes.
Network security administrators need to carefully design and assign their own custom
IPSec policy to computers.
Chapter 11 Planning Distributed Security 419
Windows 2000 provides a set of security templates for your use in setting up your network environment. A security template is a profile of security settings thought to be appropriate to a specific level of security on a Windows 2000 domain controller, server, or client computer. For example, the hisecdc template contains settings appropriate to a highly secure domain controller.
You can import a security profile into a Group Policy object and apply it to a class of computers. You can also import the template into a personal database and use it to examine and configure the security policy of a local computer.
How Security Templates Work
Security templates provide standard security settings to use as a model for your security policies. They help you troubleshoot computers whose security policies are not in compliance with policy or are unknown. Security templates are inactive until imported into a Group Policy object or the Security Configuration and Analysis snapin to MMC.
Prerequisites for Implementing Security
Security templates are a standard feature of Windows 2000. There are no prerequisites for using them.
How to Implement Security Templates
You can edit security templates in the Security Templates snap-in to MMC.
You can use the Security Configuration and Analysis MMC snap-in to import and export templates, and to compare a template to the security settings of the local computer. If you want, you can use this MMC snap-in to configure the computer to match the template.
To import a security template into a Group Policy object, open the Group Policy snapin to MMC. Right-click the Security Settings container and select the Import Policy option. This brings up a selection of security templates to import.
For more information about using security templates and predefined templates, see
Windows 2000 Server Help.
Considerations About Security Templates
The default clean-install permissions for Windows 2000 provide a significant increase in security over previous versions of Windows NT. This default, clean-install security, is defined by the access permissions granted to three groups: Users, Power Users, and
420 Part 3 Active Directory Infrastructure
By default, Users have an appropriate access-control policy for nonadministrative system use; Power Users are backward compatible with Windows NT 4.0 Users; and
Administrators are all-powerful. Therefore, securing a Windows 2000 system is largely a matter of defining what group the users belong to.
If your site runs only applications that are compatible with the Windows 2000 application specification, then it is possible to make all users be members of the Users group and thus achieve maximum access control security without sacrificing application functionality. If your site runs applications that are not compliant with the
Windows 2000 application specification, it is likely that users will need to be Power
Users in order to have the privileges necessary to run the noncompliant applications.
Thus, before considering the use of additional security templates, it is imperative that you define the level of access (User, Power User, or Administrator) that users need in order to successfully run the applications that must be supported.
Once this has been defined, the security templates can be used as follows:
The Basic security templates apply the Windows 2000 default access control settings previously described. The Basic templates can be applied to a
Windows NT computer that has been upgraded to Windows 2000. This will bring the upgraded computer in line with the new Windows 2000 default security settings that are applied only to clean-installed computers. The Basic templates can also be used to revert back to the defaults after making any undesirable changes.
Some customers might not want their users to be Power Users in order to run applications that are not compliant with the Windows 2000 application specification. They might not want this because Power Users have additional capabilities (such as the ability to create shares) that go beyond the more liberal access control settings necessary to run legacy applications. For customers who do not want their end users to be Power Users, the Compatible template “opens up” the default access control policy for the Users group in a manner that is consistent with the requirements of most legacy applications. For example, Microsoft
SR1 runs successfully as a Power User, or as a User under the Compatible configuration. However, Office 97 does not run successfully as a clean-installed User.
Note that Microsoft
Office 2000 runs successfully as a clean-installed User because it is compliant with the Windows 2000 application specification. A computer that is configured with the Compatible template must not be considered a secure installation.
Chapter 11 Planning Distributed Security 421
The Secure template modifies settings (such as password policy, audit policy, and registry values) that are less likely to have an impact on application functionality and more of an impact on the operational behavior of the operating system and its network protocols. The Secure template provides recommendations that are distinct from the default access control policy that has been defined. The Secure template does not modify any ACLs, but it does remove all members of the Power Users group.
The High Secure template increases the security defined by several of the parameters in the secure template. For example, while the Secure template might enable SMB Packet Signing, the High Secure template would require
SMB packet signing. While the Secure template might warn on the installation of unsigned drivers, the High Secure template blocks the installation of unsigned drivers.
In short, the High Secure template configures many operational parameters to their extreme values without regard for performance, operational ease of use, or connectivity with clients using third-party or earlier versions of NTLM. Like the
Secure template, the High Secure template also removes all members of the Power
In summary, use of the security templates must be considered with respect to the default access control policy required by the installed base of applications and the communication requirements of other networked systems. Since the templates modify operating system settings, they must not be applied without passing proper quality assurance measures.
Deploying Secure Applications
It is not enough to set up distributed security and then just go back to business as usual. A secure enterprise network needs software that has been designed with security features in mind. The archetype of a security-blind application is one that transmits passwords across the network in the clear. A secure environment needs secure applications.
When evaluating software for your enterprise, look for applications designed with security-enabled features. Look for integration with single sign-on capabilities for authenticated network connections, and the ability to run properly in secured computer configurations. The software need not require administrator privileges if it is not an administrator tool or utility.
The Application Specification for Windows 2000 defines the technical requirements that an application must meet to earn the Certified for Microsoft Windows logo. The document identifies the minimum requirement areas that secure applications must support:
Run on secured Windows 2000 servers.
422 Part 3 Active Directory Infrastructure
Single sign-on by using the Kerberos authentication for establishing network connections.
Use impersonation of the client to support consistent Windows 2000 access control mechanisms using permissions and security groups.
Application services run by using service accounts rather than a local system
(which has full system privileges).
These requirements are a minimum. It is also important to deploy applications that are well engineered and to avoid buffer overflow or other weaknesses for an intruder to exploit.
One approach is to require that application components be digitally signed.
Authenticode™, through Microsoft
Internet Explorer, lets users identify who published a software component and verify that no one tampered with it before downloading it from the Internet.
Also, regularly remind users not to run programs directly from e-mail attachments if they are unfamiliar with the sources or if they are not expecting to receive e-mail from the source.
Authenticode and Software Signing
Software downloaded from the Internet to users’ computers can contain unauthorized programs or viruses intended to cause damage or provide clandestine network access to intruders. As networks become more interconnected, the threat of malicious software and viruses has extended to the intranet.
How Authenticode Works
To counter this growing threat, Microsoft developed Authenticode ™ technology to enable developers to digitally sign software using standard X.509 public key certificates. Users can verify the publisher of digitally signed software as well as verify that the software has not been tampered with, because the publisher signed the code.
You can use Microsoft Certificate Services to issue digital signing certificates to your internal developers. Your developers can use signing certificates to sign software before they distribute it on the intranet. To protect your network from malicious programs and viruses, you need to also consider establishing policies that prevent users from downloading and running unsigned software from both the intranet and the
Chapter 11 Planning Distributed Security 423
For software distributed on the Internet, most users are more likely to trust software signed by certificates issued by a reputable commercial certification authority. Using commercial certification authorities also removes the liability placed on your organization from assuming the responsibilities of a commercial certification authority for external software distribution. Therefore, if you distribute software on the Internet, you need to consider obtaining the services of a commercial certification authority to issue digital signing certificates to your external software developers.
Implementing Authenticode Screening
You can enable Authenticode-based screening of downloaded software in Internet
Explorer by doing the following: on the Tools menu, point to Internet Options, and click the Security tab. Higher levels of security set from this tab screen software components for trusted digital signatures.
You can take control of these Internet Explorer security settings through Group Policy
(described previously in this chapter). Open the Group Policy snap-in to MMC and navigate to the Internet Explorer container:
Group Policy object
Internet Explorer policies permit you to lock down security settings so that users cannot change them, and to require that all downloaded components have trusted signatures.
Considerations for Authenticode and Software
Strategies for software signing in your deployment plan might include the following information:
Internal and external groups that need the capability to sign software.
Strategies for signing software for internal distribution.
Strategies for signing software for external distribution.
Certification authority deployment and trust management needed to support software signing strategies.
Process and strategies to enroll users as software signers.
Education to inform users not to run unsigned or untrusted components.
424 Part 3 Active Directory Infrastructure
In today’s enterprise, e-mail messages containing sensitive personal information and proprietary business information are routinely sent over nonsecure portions of the intranet or even the Internet. Espionage agents or hackers can easily intercept plaintext e-mail messages. Furthermore, someone with malicious intent can easily intercept and modify e-mail messages en route, or forge the IP address of an e-mail sender and send false messages.
Many of today’s secure e-mail solutions, such as Microsoft Exchange Server are based on the open Secure/Multipurpose Internet Mail Extensions (S/MIME) standard.
Using open standards is important if you want to provide interoperability among thirdparty secure e-mail applications used by business partners, vendors, and customers.
How Secure E-mail Works
Secure e-mail systems based on S/MIME use industry standard X.509 digital certificates and public key technology to provide e-mail security between senders and recipients of e-mail messages. Secure e-mail systems typically provide the following security functions:
Senders can digitally sign e-mail messages to provide data integrity.
Recipients can verify the identity of the message sender and verify that the message has not been tampered with en route.
Senders cannot repudiate signed messages because only the sender has possession of the signing credentials.
Senders can encrypt e-mail messages to provide confidential communications.
Intended recipients can decrypt the message using private credentials, but others cannot decrypt and read the message.
Administrators can centrally store users’ private credentials in a secure database. If a user’s private credentials are lost or damaged, administrators can retrieve the private credentials necessary to decrypt messages.
Considerations for Secure E-mail
To address strategies for secure e-mail, consider including the following information in your deployment plan:
Secure e-mail server and client applications to be used.
E-mail servers and user groups needing upgrade or migration to secure e-mail.
General policies for using secure e-mail in the organization.
Chapter 11 Planning Distributed Security 425
Encryption technology to be used, including international export restrictions and limitations.
Certificate services needed to support secure e-mail.
Enrollment process and strategies to enroll users in the secure e-mail program.
Key recovery database backup capabilities and recommended backup and restore practices.
Key recovery capabilities and recommended general recovery practices.
Secure Web Sites and Communications
The Web site and browser have become the central mechanisms for open information exchange and collaboration on organizational intranets as well as on the Internet.
However, standard Web protocols such as Hypertext Transfer Protocol (HTTP) provide limited security. You can configure most Web servers to provide directory and file level security based on user names and passwords. You can also provide Web security by programming solutions using the Common Gateway Interface (CGI) or
Active Server Pages (ASP). However, these traditional methods of providing Web security are proving less and less adequate as attacks against Web servers become more frequent and sophisticated.
You can use Internet Information Services (IIS), included with Windows 2000 Server, to provide high levels of security for Web sites and communications using standardsbased secure communications protocols and standard X.509 certificates. You can provide the following security for Web sites and communications:
Authenticate users and establish secure channels for confidential encrypted communications using the Secure Sockets Layer (SSL) and Transport Layer
Security (TLS) protocols.
Authenticate users and establish secure channels for confidential encrypted financial transactions using the Server Gated Cryptography (SGC) protocol.
Map user certificates to network user accounts to authenticate users and control user rights and permissions for Web resources based on users’ possession of valid certificates issued by a trusted certification authority.
Considerations for Secure Web Sites
Consider including the following information in your deployment plan:
Web sites and user groups to upgrade or migrate to secure Web sites.
Strategies for using SSL or TLS to secure Web communications between clients and Web servers.
Strategies for using certificate mapping to control user rights and permissions to Web site resources.
426 Part 3 Active Directory Infrastructure
Certification authority deployment needed to support Web sites.
Enrollment process and strategies to enroll users in the secure Web sites program.
Some of the policies in your security plan will involve the daily duties of your IT department staff. Windows 2000 supports delegation of administrative permissions, allowing specific personnel limited rights to administer their own groups and files.
Windows 2000 also supports audit logs of system activity, with a fine degree of granularity about which types of events will be logged and in what context.
It is also extremely important that your plan describes how you intend to protect your domain administrator accounts from penetration by an intruder. It is recommended that you set up your domain account policies to require all accounts to use a long and complex password that cannot be easily cracked. This is common sense but it needs to be explicitly stated in your plan.
It is not as obvious that security will be compromised if too many people know the administrator password. The administrator of the root domain of a domain tree is also automatically a member of the Schema Administrators group and the Enterprise
Administrators group. This is a highly privileged account where an intruder can do unlimited damage. Your plan needs to state that access to this account is limited to a very small number of trusted personnel.
The domain administrator account must be used only for tasks that require administrator privileges. It must never be left logged on and unattended. Encourage your administrator staff to use a second, unprivileged account for nonadministrative activities (reading e-mail, Web browsing, and so on).
Server consoles used for domain administration must be physically secured so that only authorized personnel have access to them. Your security plan needs to state this and list the personnel who might use the consoles. It is not as obvious that users of the
Administrator account must never log on to client computers managed by someone who is not equally trusted. The other client computer administrator might introduce other code on that computer that will unknowingly exploit the administrator privileges.
Chapter 11 Planning Distributed Security 427
The delegation of administrative tasks is a practical necessity in a Windows 2000 enterprise environment. It is common to delegate authority not only to members of the
IT group but to human resources personnel and various managers for tasks related to their duties. Delegation distributes the administrator’s workload without granting sweeping privileges to every assistant. This is an expression of the security concept of
“principle of least privilege,” that is, granting only the permissions necessary for the task.
Through various means, Windows 2000 allows you to delegate to groups or individuals a prescribed degree of control over a limited set of objects. The only prerequisite is that the appropriate delegation elements (users, groups, Group Policy objects, files, directories, and so forth) must be in place before delegation can be performed.
Windows 2000 supports delegation of administrative authority through various features, including those listed in the following sections. (Note that some tasks require domain administrator privileges and cannot be delegated.)
Security Groups, Group Policy, and Access
These features are described previously in this chapter, and form the mechanisms for the features described in the following paragraphs.
Built-in Security Groups
Windows 2000 has predefined security groups with special permissions already delegated to each group. Open the Active Directory Users and Computers snap-in to
MMC. On the View menu, select Advanced Features. The predefined security groups are in the Builtin and Users folders.
To directly delegate control of one of these groups, open the property sheet of the group and click the Security tab. Add the group’s manager to the access control list and check the appropriate privileges.
Delegation of Control Wizard
Open the Active Directory Sites and Services snap-in to MMC. Right-click an organizational unit and select Delegate Control. This wizard sets up user group permissions to administer specific sites and services. An example would be the right to create new remote access accounts.
428 Part 3 Active Directory Infrastructure
Delegate Administration Wizard
Open the Active Directory Users and Computers snap-in to MMC. Right-click an organizational unit and select Delegate Control. This wizard sets up user group permissions to administer organizational units containing computers and user groups.
An example would be the delegated right to create new user accounts.
Delegating Control of Group Policy Objects
Delegating administration via Group Policy involves the following three tasks, which can be performed together or separately, as your situation requires:
Managing Group Policy links for a site, domain, or organizational unit.
Creating Group Policy objects.
Editing Group Policy objects.
These tasks are described in more depth in “Defining Client Administration and
Configuration Standards” in this book.
Auditing and security logging of network activity are important safeguards.
Windows 2000 enables you to monitor a wide variety of events that can be used to track the activities of an intruder. The log file entries can serve as legal evidence after the intruder has been identified.
How Auditing Works
You can specify that an audit entry is to be written to the security event log whenever certain actions are performed or files are accessed. The audit entry shows the action performed, the user who performed it, and the date and time of the action. You can audit both successful and failed attempts at actions, so the audit trail can show who performed actions on the network and who tried to perform actions that are not permitted. You can view the security log in the Event Viewer.
If the security log is examined regularly, it makes it possible to detect some types of attacks before they succeed, such as password attacks. After a break-in, the security log can help you determine how the intruder entered and what they did.
Audit logging is a policy in its own right. Recording security events is a form of intrusion detection.
Chapter 11 Planning Distributed Security 429
Prerequisites for Implementing the Audit
There is nothing to install or purchase. You do have to configure your Group Policy settings to enable auditing. You also must enable auditing for the general areas or specific items you want to track.
How to Implement the Audit Function
Security auditing is not enabled by default. You have to activate the types of auditing you require by using the Group Policy snap-in to MMC.
Group Policy object
Categories of auditable events include: account logon events, account management, directory service access, logon events, object access, policy change, privilege use, process tracking, and system events. Note that auditing policies are subject to policy inheritance, and the policies you set on your local computer could be overshadowed by policies set for the domain as a whole.
Once you have set up your auditing policies, you can descend to a fine degree of granularity by enabling specific types of auditing messages for individual objects. For example, to enable auditing for a file directory, right-click the appropriate folder in
Windows Explorer. Point to Properties, and click the Security tab. Click Advanced, and then select the Auditing tab in the Advanced Properties dialog box. This displays the list of auditable events available for the folder. In the case of file directories, auditing settings could be optionally applied to contained files and subdirectories.
View the audit messages in the Security Log node of the Event Viewer.
For more information about auditing security events, see Windows 2000 Help.
Considerations About Auditing
Generating a security log has implications for disk space on your server. You can set the Event Viewer to overwrite log entries that are more than “n” days old, or you can configure the server to stop running when the security log is full. For more information about halting the computer when the security log is full, see
Windows 2000 Help.
Note that the auditing features for directories and files described here require an
NTFS file system.
430 Part 3 Active Directory Infrastructure
Monitor firewall servers and critical servers that are internal to the firewall to detect suspicious activity. You also need to monitor servers that are external to the firewall even though they are considered nonsecure, because they provide a doorway into your enterprise.
Table 11.3 lists various events that you need to audit, as well as the specific security threat that the audit event monitors.
Table 11.3 Security Audit Threat Detection Policies
Failure audit for logon/logoff.
Success audit for logon/logoff.
Success audit for user rights, user and group management, security change policies, restart, shutdown, and system events.
Success and failure audit for file-access and object-access events. File Manager success and failure audit of read/write access by suspect users or groups for the sensitive files.
Success and failure audit for file-access printers and object-access events. Print Manager success and failure audit of print access by suspect users or groups for the printers.
Success and failure write access auditing for program files (.exe and .dll extensions). Success and failure auditing for process tracking. Run suspect programs; examine security log for unexpected attempts to modify program files or create unexpected processes. Run only when actively monitoring the system log.
Random password hack
Stolen password break-in
Misuse of privileges
Improper access to sensitive files
Improper access to printers
Planning Task List for Distributed Security
To develop your network security deployment plan, complete the tasks listed in
Table 11.4 Security Planning Task List
Identify the security risks that apply to your network. Tabulate and explain them in the plan.
Provide background material on security concepts and vocabulary to orient the reader of your plan.
Location in Chapter
Chapter 11 Planning Distributed Security 431
Table 11.4 Security Planning Task List (continued)
Introduce and explain the security strategies that address the risks in your plan.
Ensure that all access to network resources requires authentication using domain accounts.
Determine what part of the user community needs to use strong authentication for interactive or remote access login.
Define the password length, change interval, and complexity requirements for domain user accounts and develop a plan to communicate these requirements to the user community.
Define your organization policy to eliminate transmission of clear text passwords on any network and develop a strategy to enable single sign on or protect password transmission.
Identify a plan to deploy public key security for smart card logon if strong authentication meets your security objectives.
Describe your policy for enabling remote access for users.
Develop a plan to communicate remote access procedures, including connection methods, to general user community.
Identify how your organization currently uses groups and establish conventions for group names and how group types are used.
Describe the top-level security groups you intend to use for broad security access to enterprise-wide resources. These are likely to be your enterprise universal groups.
Describe your access control policies with specific reference to how security groups are used in a consistent manner.
Define the procedures for creating new groups and who has responsibility to manage group membership.
Determine which existing domains belong in the forest, and which domains use external trust relationships.
Describe your domains, domain trees, and forests, and explicitly state the trust relationships among them.
Define a policy for identifying and managing sensitive or confidential information and your requirements to protect sensitive data.
Identify network data servers that provide sensitive data that might require network data protection to prevent eavesdropping.
Develop a deployment plan for using IPSec for protection data for remote access or for accessing sensitive application data servers.
Location in Chapter
Smart Card Logon
432 Part 3 Active Directory Infrastructure
Table 11.4 Security Planning Task List (continued)
If using EFS, describe your Data Recovery Policy, including the role of Recovery Agent in your organization.
If using EFS, describe the procedures you plan to use to implement data recovery process and verify that the process works for your organization.
If using IPSec, identify the scenarios for how it will be used in your network and understand the performance implications.
Define domain-wide account policies and communicate those policies and guidelines to the user community.
Determine the local security policy requirements for different categories of systems on the network, such as desktops, file and print servers, e-mail servers. Define the Group Policy security settings appropriate to each category.
Define application servers where specific security templates can be used to manage security settings and consider managing them through Group Policy.
Apply appropriate security templates for systems that upgrade from Windows NT 4.0 instead of a clean install.
Use security templates as a means of describing the level of security you intend to implement for different classes of computers.
Develop a test plan to verify your common business applications run correctly under properly configured secure systems.
Define what additional applications are needed that provide enhanced security features to meet your organization security objectives.
State the levels of security you require for downloaded code.
Deploy internal procedures for implementing code signing for all in-house developed software that is publicly distributed.
State your policies for securing the Administrator account and the administration consoles.
Identify the situations where you plan to delegate administrator control for specific tasks.
Identify your policies regarding auditing, including staffing.
Location in Chapter
* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project