MBSA to use the local fil

Q Alternatively, you can point MBSA to the local SUS server. (Shown earlier in Figure 5-13.) In this case, MBSA will audit the patch status of scanned machines against your approved list of updates on the SUS server. No access to the Internet will be required.

Consider how running MBSA on a domain controller differs from running MBSA on a member server:

Q It is not recommended that you run MBSA on a domain controller. However, in smaller environments—especially those using Small Business Server (SBS)—you can do so.

Q Updating SBS to Small Business Server Service Pack 1 will prevent errors that can be encountered by using MBSA on the SBS computer. Specifically, it addresses error messages related to restricting anonymous configuration.

Q MBSA reports the use of services such as Remote Access Connection Man-ager, SMTP, and the World Wide Web Publishing Service as perhaps unnecessary. Yet they are part of many SBS installations. Administrators will need to be counseled not to disable these services if they are being used.

Q MBSA might report that the IIS Lockdown tool has not been used. Because SBS also runs Exchange Server, administrators must be counseled on the proper use of IIS Lockdown on Exchange Server computers.

Requirements for MBSA Scanning

MBSA can scan the local computer and other computers on the network. Requirements vary depending on the nature of the scan. Table 5-3 lists and compares the requirements. In the table, the Local Scan Only column indicates that a scan of the local computer only will be performed. The To Remotely Scan column lists the requirements for a computer that will scan other computers on the network. The Remotely Scanned column provides the requirements for computers that will be remotely scanned.

How to Audit Patching Status Using MBSA

You can use MBSA as a graphical user interface (GUI)-based program that produces HTML reports to be viewed in the browser. In this case, each report represents the status of a single computer and is stored on the scanning computer. To obtain a more useful report, use the command-line version of MBSA, import the text file into a spreadsheet or database, and then produce reports. These reports will indicate which systems need to be patched and which patches are missing. An additional use of the reports is finding weaknesses in the design or implementation of your patching process. If, for example, no patches are being applied, the computer might not be properly pointing to a SUS server or some network issue might be preventing the computer from accessing the SUS server.

Q Use SUS and client logs to troubleshoot patch installation and patch down-loads.

Q Use MBSA notes and Knowledge Base articles to investigate specific patch issues.

Q Use the Resource Kit tool Gpresult, the Resultant Set of Policy tool, and the Group Policy Management Console tool to determine whether problems with Group Policy are interfering with the update process.

Q Use normal network troubleshooting efforts to determine whether network issues are part of the problem.

A Patch Management Equation

How can you really tell whether all approved patches have been installed? MBSA reports patches that need to be installed but does not provide a list of patches that have been installed. You could assume that by simply subtracting this list of "need to be applied patches" from the list of approved patches, you will create a list of patches that have been applied. In most cases, this assumption is correct. However, you should spot check this equation to verify that your assumption is correct.

To verify that your list of patches that have been applied is complete, enumerate installed patches by using the Windows Management Instrumentation Service.

Enumerate patches, and compare the list of patches applied to the list of approved patches for the computer. If patches are missing, you should determine why. If patches are missing, the list should match the list generated by MBSA. If it does not, you should try to figure out why.

A simple equation that expresses the result you should have for any single computer is: approved patches = MBSA list of not installed patches + enumerated list of patches determined by using the script. You might need to adjust this equation to account for the application of a cumulative patch. Because you can install cumulative patches instead of multiple patches, cumulative patches can confuse the issue of determining which patches have been applied.

Designing GPOs

Q Consider that a typical patching schedule operates on a daily basis. Do you need to apply critical patches sooner? Create a temporary GPO for rapid patch installation. The temporary GPO can change the Configure Automatic Updates policy to an earlier time and also can automatically download and install the patch. The GPO can be linked to the domain or organizational unit when critical patches need to be distributed fast, and then unlinked to allow the normal GPO patch application to be used. Once the computers affected by the GPO refresh their policies, the new, approved, critical patch will download and be installed.

Q Prepare for failure. Sooner or later a SUS server will fail. If more than one SUS server exists, use a temporary site GPO to point clients to an alternative SUS server. The temporary GPO must have a higher priority than the GPO that normally points clients to the local SUS server. When the local SUS server is operational again, remove the temporary GPO and clients will begin using the local SUS server after the next policy refresh. This policy can be used, for example, to point clients of a child SUS server to the parent SUS server should the child SUS server fail.

Practice: Designing GPOs

In this practice, you will design GPOs for a fictitious organization and explain why you made the decisions that you made. Read the scenario and then answer the question that follows. If you are unable to answer the question, review the lesson materials and try the question again. You can find an answer to the question in the "Questions and Answers" section at the end of the chapter.

Chapter Summary

A site is a set of IP subnets connected by a highly reliable and fast link (usually a LAN). Site structure mirrors the location of user communities. Sites have two main roles: to facilitate authentication and the replication of data between sites. Active Directory replicates information in two ways: intrasite (within a site) and intersite (between sites).

For optimum network response time and application availability, place at least one domain controller in each site or two domain controllers in each domain.

Intersite replication is replication that occurs between sites.

A site link is a logical, transitive connection between two or more sites that mirrors the network links and allows replication to occur.

Bridgehead servers are the contact point for exchange of directory information between sites. When two sites are connected by a site link, the KCC automatically selects bridgehead servers. You can designate bridgehead servers manually, called "preferred" bridgehead servers.

A site link bridge is the linking of more than two sites for replication using the same transport. When more than two sites are linked for replication and use the same transport, by default, all of the site links are "bridged" in terms of cost, assuming the site links have common sites. If site link transitivity is enabled, which it is by default, creating a site link bridge has no effect. Therefore, it is seldom necessary to create site link bridges.

A global catalog server is a domain controller that stores a full copy of all objects in the directory for its host domain and a partial copy of all objects for all other domains in the forest. For optimum network response time and application availability, designate at least one domain controller in each site as the global catalog server. To optimize replication in a multiple site environment, you might need to consider adding global catalogs for specific sites.

Universal group membership caching, a new feature in Windows Server 2003, allows a site that does not contain a global catalog server to be configured to cache universal group memberships for users who log on to the domain controller in the site.

An application directory partition is a directory partition that is replicated only to specific domain controllers running Windows Server 2003. Application directory partitions are usually created by the applications that use them to store and repli¬cate data.

Replmon.exe: Active Directory Replication Monitor, Repadmin.exe: Replication Diagnostics Tool, and Dsastat.exe are provided for monitoring and troubleshooting replication. To use these tools, you must first install the Windows Support Tools on your computer.

You can use several methods to determine the operations master role

holders of the forest and domain. For example, you can query these roles using the Replication Monitor (Replmon.exe), Netdom, and Ntdsutil. You can also use the Windows Script Host (WSH) to query the Active Directory Services Interface (ADSI) to find the operations masters, as documented in Microsoft Knowledge Base article 235617, "How to Find the FSMO Role Owners Using ADSI and WSH" (available from http://support.microsoft.com).

Practice: Viewing and Transferring Operations Master Role Assignments

In this practice, you manage operations master role assignments.

Note To complete this practice, you must have successfully completed the practice in Lesson 1.

Exercise 1: Viewing Operations Master Role Assignments

In this exercise, you view operations master role assignments.

To view operations master role assignments

1.      Log on to Server 1 and Server2 as Administrator.

2.      Use the procedure provided earlier in this lesson to view the RID master, the PDC

emulator, and the infrastructure master role assignments for the contoso.com

domain.

3.      Use the procedure provided earlier in this lesson to view the domain naming mas¬

ter role assignment for the contoso.com domain.

4.      Use the procedure provided earlier in this lesson to view the schema master role

assignment for the contoso.com domain.

Exercise 2: Transferring an Operations Master Role Assignment

In this exercise, you transfer the domain naming master role assignment from Serverl to Server2.

To transfer an operations master role assignment

1. Use the procedure provided earlier in this lesson to transfer the domain naming master role assignment from Serverl (contoso.com domain) to Server2 (chi.contoso.com domain).

2.      When you have finished viewing the domain naming master role assignment on

Server2, transfer the domain naming master role assignment back to Server 1.

3.      Demote Server2 so it becomes a member server for the contoso.com domain and

the cbi.contoso.com domain no longer exists.

Modifying Domain User Account Properties

A set of default properties is associated with each domain user account that you create. For domain user accounts, these account properties equate to object attributes. You can use the properties that you define for a domain user account to search for users in the directory, or the properties can be used in other applications as object attributes. For this reason, you should provide detailed definitions for each domain user account that you create. For example, if a user knows a person's last name and wants to find the person's telephone number, the user can use the last name to search for the telephone number.

The tabs in the Properties dialog box for a user, shown in Figure 7-5, contain information about each user account. Table 7-5 describes the tabs in the Properties dialog box.

Documents the user's first name, initials, last name, display name, description, office location, telephone number(s), e-mail address, and Web page(s)

Documents the user's street address, post office box, city, state or province, ZIP code or postal code, and country or region

Documents the user's account properties, including user logon name, logon hours, computers permitted to log on to, account options, and account expiration

Sets a profile path, logon script path, and home folder

Documents the user's home, pager, mobile, fax, and Internet Protocol (IP) telephone numbers, and contains space for notes

Documents the user's title, department, company, manager, and direct reports

Configures Terminal Services remote control settings Configures the Terminal Services user profile

Documents the COM+ partition set of which the user is a member

Documents the list of X. 509 certificates for the user account

Documents the groups to which the user belongs Documents the dial-in properties for the user Configures the Terminal Services startup environment

Sets the Terminal Services timeout and reconnection settings

Documents the fully qualified domain name (FQDN), object class, create and modified dates, the original update sequence number (USN), and the current USN Sets permissions on the user object

Seizing Operations Master Roles

To seize an operations master role is to move it without the cooperation of its current owner. You seize an operations master role assignment when a server that is holding a role fails and you do not intend to restore it. The operations master role assignment is seized (reassigned) to a domain controller you select to act as a standby operations master. Some operations master roles are crucial to the operation of your network. Others can be unavailable for quite some time before their absence becomes a problem. Generally, you will notice that a single master operations role holder is unavailable when you try to perform some function controlled by the particular operations master.

Before seizing the operations master role, determine the cause and expected duration of the computer or network failure. If the cause is a networking problem or a server failure that will be resolved soon, wait for the role holder to become available again. If the domain controller that currently holds the role has failed, you must determine if it can be recovered and brought back online. You must also determine which domain controller can effectively serve as a standby operations master. In general, seizing an operations master role is a drastic step that should be considered only if the current operations master will never be available again. The decision depends upon the role and how long the particular role holder will be unavailable. The impact of various role holder failures is discussed in the following topics.

The process for managing administrative risk is as follows:

1.      Recognize the vulnerabilities introduced by network administration.

2.      Establish security boundaries. Understanding the security boundaries provided by

the operating system is essential in determining the scope of authority that administrators have. In addition to understanding where these boundaries are, you must

also understand when to apply them. To do so, you need to know the key concepts of isolation and autonomy as they relate to service administration and data

administration.

3.      Reduce the administration attack surface. Reducing the attack surface is a sound

security design principle that can be applied to any part of your security design. If

you can reduce the number of things that can be attacked or the avenues that can

be used to attack them, the network will be more secure. Reducing the attack surface can take many forms, but one of the easiest things to do is to eliminate things

that are not needed. To reduce the ability of attackers to use administrative

accounts and channels to attack networks, reduce the number of things in total

that administrators must manage and reduce or partition the scope of their management by delegating authority. While these actions are also examples of least

privilege, they illustrate a reduction in the attack surface quite nicely. If the administrator's account were to be compromised, the attacker would have less ability to

do damage because the surface or range of things that can be attacked has been

reduced.

4.      Evaluate and carefully judge your administrators. The people who are trusted

"with the administration of your network must be trustworthy. Although you can

limit authority, every bit of authority can be used to destroy important parts of

your systems and data. In addition, at some point, someone must have absolute

authority to keep systems running, correct errors introduced by others, trouble-

shoot problems, and so on. Checking the backgrounds of potential administrators

and repeating the process periodically is crucial to the survival of your information

systems.

5.      Monitor and audit administrative work. Administrators are people: they make

mistakes, they have needs and desires, they face temptations, and they are as

likely to want to harm systems as any other employee. The difference is that

administrators have the power and authority to harm systems easily.  Often

because an administrator has unlimited privileges, an attacker with administrative

credentials or a malicious administrator can prevent operations from being audited

or can delete the audit record of his activity by deleting the security log.

The following topics provide the information and guidelines you need to complete most of these tasks.

Note Evaluating the trustworthiness of administrators is beyond the scope of this book, but it must be done. It is a topic for the legal and human resources departments of your organization to pursue. You can, however, protect your network from untrustworthy administrators by ensuring sound security principles are practiced, by designing an Active Directory infrastructure that meets your autonomy and isolation needs, and by auditing the actions of administrators. Auditing is discussed in Chapter 9.

Specifies attributes to be returned from search. This option is used only if the comparison option /t is set to FALSE. Valid option values are: LDAPattributes, which displays any LDAP attribute; ObjectCloss, which specifies that no attributes be displayed; auto, which specifies that only attributes replicated to the global catalog be displayed; and All, which specifies that all attributes con-tained in an object be displayed.

The user name to use for the query.

Password for authenticating the user name. Must be used with the /u parameter.

The domain to use for authenticating the user name. Must be used with the /u parameter.

Troubleshooting Active Directory Replication

Some of the common problems you might encounter with Active Directory replication include the following:

•       New users are not recognized.

•       Directory information is out-of-date.

•       Service requests are not handled in a timely fashion.

•       Domain controllers are unavailable.

Active Directory Replication Troubleshooting Scenarios

Table 5-5 describes some Active Directory replication troubleshooting scenarios. Table 5-5   Active Directory Replication Troubleshooting Scenarios

Cause

Solution

Problem Replication of directory information has stopped.

Create a site link from the current site to a site that is connected to the rest of the sites in the network.

The sites containing the clients and domain controllers are not connected by site links to domain controllers in other sites in the network, resulting in a failure to exchange directory information between sites.

Problem: Replication of directory information has slowed but not stopped.