Exam Objectives in this Chapter:
1.1 Configure security templates.
1.1.1 Configure registry and file system permissions. 1.1.2 Configure account policies.
1.1.3 Configure audit policies.
1.1.4 Configure user rights assignment. 1.1.5 Configure security options. 1.1.6 Configure system services. 1.1.7 Configure restricted groups. 1.1.8 Configure event logs.
1.2 Deploy security templates. Deployment methods include using Group Policy and scripting.
; Summary of Exam Objectives ; Exam Objectives Fast Track
; Exam Objectives Frequently Asked Questions ; Self Test
Introduction
Security in Windows 2000 is no simple thing; however, it is manageable if taken one step at a time, starting from the bottom up.To that end, in this chapter we look at the first line of defense in making your Windows 2000 network more secure: security tem- plates and Group Policy.This chapter covers a lot of ground, so fasten your seat belts and get ready for the ride! Let’s take a look at the topics covered in this chapter:
■ A review of the Windows 2000 Active Directory provides the starting point for this chapter and this book. Although this is a security book, not an Active Directory one, a solid Active Directory foundation is required to efficiently administer a Windows 2000 network. Simply put, Active Directory makes Windows 2000 tick, and Windows 2000 relies on Active Directory for all types of things.
■ We next examine the basic security tools at your disposal—those that ship with Windows 2000, those that can be found in the Windows 2000 Server Resource Kit, and those that you can get elsewhere.
■ Next, we examine how security is configured via templates and Group Policy by taking an item-by-item approach. Each configurable item is presented along with its default setting and usage.
■ Once you’ve gotten your security configured, you will of course want to deploy it, so we walk through the various methods of deploying your security templates and security configurations.
■ Lastly, we analyze your security settings using several tools available to you.
Windows 2000 Active Directory Review
In November 1996, Microsoft delivered the first preview of Active Directory for devel- opers at the Professional Developers Conference held in Long Beach, California. At the time, it was merely the directory service that was shipped with Windows NT 5.0, and the preview included many other Windows NT 5.0 features. Many changes have taken place since then. For one,Windows NT 5.0 was renamed Windows 2000, and then it was officially released to the public in February 2000, over three years after its original preview to developers.The change of the name from Windows NT 5.0 to Windows 2000 was a surface change only.Windows 2000 inherits the NT technology legacy from previous versions.
T
ESTD
AYT
IPAlthough we spend several pages here presenting (and reviewing) Active Directory, don’t get “wrapped around the axle” about the nitty-gritty of Active Directory. This exam is focused on working with security in Windows 2000, and for that you must know Active Directory. Don’t worry about being asked very specific questions dealing with the ins and outs of Active Directory; that is the realm of the 70-217 exam.
Introduction to Directory Services
It would be tough to claim that Active Directory is the first directory service ever cre- ated. In fact, directory services have been available in a variety of network operating systems (NOSs). Novell’s NetWare has used the Novell Directory Service (NDS) for quite some time now. Directory services are used primarily for organizing, locating, and managing network information.
People use directory services without even knowing they are doing so. Because it is used to translate server names to Internet Protocol (IP) addresses, the Domain Name System (DNS) is the most widely used directory service in the world. DNS is rather “usage specific,” meaning that it organizes only a limited amount of information about network hosts. DNS stores data about servers, their IP addresses, and services that they offer to the network. Although this is pretty much the extent of DNS, other directory services do not have the same limitations. A directory service can organize all sorts of information about a network. Usually, this information falls into the following categories:
■ Network resources Servers, printers, and other devices on a network.
■ Network services Capabilities on the network such as file storage, printing, and e-mail.
■ Network users and groups Identifiers for users on a network and for groups of users.
As you can see, a directory service organizes the pieces of a network, enabling a way to create relationships between the pieces.The relationships between these pieces are what make the directory service so powerful. For example, in DNS, a DNS client computer can query a DNS server to find out the IP address of a server that it wants to contact.The DNS server receives a hostname query and returns the IP address in short order. More complex relationships can be created in more complex directory services, such as providing access to network resources and services for users who log on as well as providing a controlled security framework for the entire network.
History of the Windows Directory Service
In the not-too-distant past, networks were server centric. Each server had its own secu- rity system, which consisted of user accounts, group accounts, and network resources. The server would associate those user accounts to the files, directories, printers, and other services or resources that it had to offer.These associations had a value such that one person could have more access to one network resource than another person, simply due to the rights assigned to user and group accounts. In a way, this server-cen- tric system was one of the first directory services, but one for which the scope existed only on a single server.
Networks first popped up in the military as a method to share data quickly across great distances.They offered a major advantage in times of war. Money was one of the main reasons that networking became prevalent in businesses. Hard drives were
extremely expensive, as were printers. Many of the first corporate networks sprang up out of a need to share printers and precious hard-drive space among multiple com- puters. Soon, these servers’ hard drives filled up.They ran out of printer ports. At some point, another server would be added to the network to allow further storage of shared files or to add new printers.
Once an administrator established a server to share files and printers, the adminis- trator was faced with an issue—how to protect sensitive files and printers from unau- thorized users while allowing use of the remaining files and printers. In some cases, the administrator wanted to allow some users limited access to a file or a printer. Access rights were added to the system, and users were given specific logon IDs.The server could then easily share files and printers with the correct users, depending on the administrator’s configuration.
When a network contained more than one server, administration became difficult. If a user needed to access files or printers residing on two or more servers, that user needed to know how to access each specific server. In addition, the user needed a sepa- rate logon ID and password for each server. Some administrators used naming conven- tions to ensure that a user did not need to have more than one unique logon ID.
Sometimes a network had multiple administrators with different naming conven- tions, providing users with two or more unique logon IDs. For administrators, it was difficult to keep passwords synchronized, since each server might have a different timing mechanism to enforce password changes. For users, the end result in a multiserver envi- ronment was a convoluted and difficult process of remembering the location of
resources, remembering the correct logon ID, and remembering the correct current password—all merely to be able to access resources on the network.
Network operating systems soon developed a variety of ways to use a single logon ID and password to access multiple servers. For example, Microsoft Windows NT used a
domain architecture. An NT domain is a group of Windows NT servers that participate in a single security system listing users, groups, and network resources. It consists of a primary domain controller (PDC), any number of backup domain controllers (BDCs), and any number of member servers and client computers.
The PDC is the security manager of the domain. BDCs maintain a read-only copy of the security database, and the PDC remains the single point of change control. Member servers and client computers contact the domain controller (DC) to access network resources. Because of their membership, a PDC or a BDC in the domain can use the security database to authenticate users to access resources. A member server can use the security database by querying a PDC or BDC.The basic Windows NT domain model is shown in Figure 1.1.
The Windows NT domain was a security boundary, which means that if you needed to separate one security set from another, you needed to have more than one domain. Using trust relationships, you could have multiple domains. A trust relationship is established between two domains. In order to enable users of domain A to access the resources such as the files and printers of domain B, domain B must trust domain A. Drawn in a diagram, this trust relationship is shown as an arrow pointing from the trusting domain to the trusted domain. Microsoft defined various models for a multiple domain structure using Windows NT:
■ Master Domain model All resource domains trust a single Master Domain that contains all user accounts.This scenario is depicted in Figure 1.2.
Figure 1.1 A Basic Windows NT Domain
PDC BDC BDC BDC BDC Client Client Client Client Client User User User User User User Network Printer Network Printer Member Server Member Server Member Server Member Server User User
■ Multiple Master Domain model All resource domains trust all Master Domains. Master Domains contain user accounts. Each Master Domain trusts all other Master Domains.
■ Single Domain model There is only a single domain that contains all users and resources.There is no trust relationship with other domains.
■ Complete Trust model All domains trust each other, regardless of whether they contain users, resources, or both.
Windows NT domains contain the rudimentary elements of a directory service. They enable multiple servers to look up information and use it for authenticating users and granting those users access to network resources. Although a domain is effective as a security model for a small or medium-sized organization, it does not have some of the features that a directory service can offer.
Figure 1.2 A Multimaster Windows NT Domain
BDC BDC Network
Printer NetworkPrinter Member Server Member Server Member Server PDC BDC BDC BDC BDC Client Client Client Client Client User User User User User User Network Printer Network Printer Member Server Member Server Member Server Member Server User User BDC BDC Network
Printer NetworkPrinter Member Server
Member Server Member Server
An NT domain structure is flat rather than hierarchical like most directory services, which means security cannot be applied at different levels. Since each domain is its own administrative area, the only way to implement distributed administration is to have multiple domains. Legacy NT domains require a significant amount of traffic between clients and the PDC or a BDC.These domains also require the security database to be copied from a PDC to the BDCs on a periodic basis.
This traffic overhead is undesirable over wide area network (WAN) links that might have a limited amount of bandwidth available or that are costly to transmit traffic across.To reduce this overhead, multiple domains can be created such that no domain spans a WAN link.Trust relationships between multiple domains become cumbersome as more domains are added. As a result, trade-offs can be made between WAN perfor- mance or administrative needs and domain structures.
The directory services architecture of Windows 2000 was redesigned from the ground up to eliminate the limitations and difficulties found in the Windows NT direc- tory services implementation. Use of the X.500 standard as the basis of Active
Directory and implementation of the Lightweight Directory Access Protocol (LDAP) not only ensures that Windows 2000 Active Directory is more robust and user friendly but that it also uses existing and well-known standards that allow it to interact with other directory services and a variety of applications.
Comparing Active Directory to the Windows NT implementation of directory ser- vices, it is easy to see that Active Directory offers fully distributed administration via an efficient database that is distributed throughout the network to prevent WAN overhead issues. Let’s examine Active Directory in more detail now so we can get a better idea of how it works to not only make using Windows 2000 easier but also to make Windows more secure.
Active Directory Architecture
Active Directory is not automatically part of the Windows 2000 Server installation pro- cess, although the capability is available should you need it.When a Windows 2000 Server (any version) is installed as a new install, by default it becomes a member server of a workgroup or domain. (Upgrades are handled differently if a Windows NT PDC or BDC is being upgraded to Windows 2000. In the case of upgrades of an NT PDC or BDC, the installer is prompted to upgrade the domain to Active Directory. If that did not occur, all information from the former domain would be lost.)
Member servers use a security architecture identical to that of the Windows 2000 Professional client workstations, in which they have a flat file local database with a set of local users and groups.This does not allow other servers or workstations to share in that security database. In fact, it hearkens back to the days of a server-centric network.The flat file database allows local users and groups, as well as shared local files and printers, in
a server-centric model. Only when a member server or client workstation joins an Active Directory domain can it participate in Active Directory.When a client worksta- tion or member server joins a domain, that server-centric local database remains. However, if a member server is upgraded to a DC, the local database is removed. When a Windows 2000 server joins an Active Directory domain as a member server, it can communicate with any DC for Active Directory security information. Domains are configured as top-level containers in a tree structure that is created through trust relationships and that uses DNS naming.
Domains sharing a contiguous DNS namespace are organized into domain trees. In a contiguous namespace, the domains are linked via the DNS names. For example, a domain named open.com and its subdomain named way.open.com are part of the same contiguous namespace. However, a domain named closed.com is not part of that con- tiguous namespace and, in fact, forms the basis for another domain tree.There can be multiple domains in Active Directory, either with or without contiguous namespaces. Multiple domains with different namespaces that participate in a single Active Directory commonly are considered a forest of multiple domain trees, as depicted in Figure 1.3. However, it is important to note that a domain on its own can be its own forest.
Figure 1.3 The Windows 2000 Active Directory Domain Model with Forests, Trees, and Organizational Units
open.com closed.com
way.open.com
really.way.open.com Two-way transitive trust
between root domains
Two-way transitive trust between parent
E
XAMW
ARNINGBear in mind that although Windows 2000 Active Directory uses the standard DNS namespace, the top-level domain is ignored. In the case of our example domain open.com and its child domain way.open.com, both part of one con- tiguous namespace. The top-level domain, .com in this case, is ignored by Active Directory due to the way that Microsoft has implemented DNS in Active Directory. The top level of the domain (and the domain name) in this case would be open.
Internal to each domain, Active Directory provides Organizational Units (OUs) to create a tree structure.The OU tree is unique to each domain and completely config- urable by an administrator.Within the OU containers, Active Directory enables the administrator to create objects that represent user accounts, network services, and resources such as users, groups, workstations, and printers.The result is a logical struc- ture that can be scaled to any enterprise of any size and organizational formation.
Security is of great concern to companies that connect their private networks to the Internet or to external partners using an extranet solution.The hierarchical struc- ture in Active Directory is a perfect basis for a flexible security service. Active Directory can secure objects using services such as Public Key Infrastructure (PKI) and can even extend to smartcard technologies.The security protocol named after the dog that guards the gates to Hades in Greek mythology, Kerberos, is used for trust relationships and is the default authentication protocol in Active Directory. LDAP can be used over Secure Sockets Layer (SSL), which extends Active Directory security into the Internet.
Some of these types of services integrate as objects, such as PKI certificates, in the authentication process using smartcard technologies and in extended properties of account objects so that they can support extra security requirements. In addition, you can find extensive security administration capabilities in Group Policies implemented within Active Directory.
The Active Directory architecture enables it to become the central authority for authentication and access control to the entire network and even the Internet. Before we move into the topic of using Active Directory to control security in our network, we first need to delve a little deeper into the basics of Active Directory, examining the logical and physical structures of Active Directory as well as the basic Active Directory objects.