Monthly Archives: May 2010

Establishing Account and Password Requirements for Information Security

Just as authentication can be made more robust by selecting more secure authentication protocols, the process can also be improved by strengthening password controls. The first criteria for establishing secure account and password requirements is to not treat the development of an account policy as a trivial activity. Configuring the policy is a trivial activity; determining how to best secure an organization using these settings is not. Without implementing a proper account and password policy, your attempt to secure access to information resources will be futile.

After this lesson, you will be able to

•       Describe the process for establishing account and password requirements for information security.

•       Describe the qualities of strong passwords and password policies.

•       Describe the password policies available for Windows Server 2003-based networks.

•       Explain the technical controls for password policies and their limitations.

•       Determine organizational climate and information sensitivity.

•       Describe options for managing the need for multiple policies.

•       Design a strong password policy.

•       Explain the considerations for deciding to design an account lockout policy.

•       Design an account lockout policy.

•       Recommend alternatives to password-based authentication.

Estimated lesson time: 45 minutes

The Process: Establishing Account and Password Requirements for Information

Follow this process to establish account and password requirements:

1. Design a strong password policy. This includes the following steps:

a. Make sure you understand the qualities of a strong password policy and the password policies that you can use in Windows Server 2003-based networks. These characteristics are implemented using technical controls, training, and enforcement.

Designing a Logical Authentication Strategy

b.      Identify the technical controls available for password policies, and review their

limitations. To design a strong password policy, the designer must under¬

stand how to use the technical controls that are available in Windows Server

2003 and how these controls need to be supported. It is crucial that you don't

just fill in the settings in the interface but that you take into account the realities of the workplace. The design should support the technical controls.

c.      Determine the climate of the organization and the sensitivity of the information the policy will protect. Security experts agree that a password policy must

be created, but there is great disagreement about how that policy should be

set. Part of your job is to determine the appropriate policy for the organization at hand. This involves more than just understanding technical issues such

as how to make a complex password or that longer passwords are harder to

crack. You must also examine the culture of the organization, its tolerance for

risk, and the nature of the data it protects.

d.      Identify the need, if any, for more than one password policy and how this can

be managed.

e.      Review password policy guidelines, and design the password policy.

2.      Decide whether you want an account lockout policy, and if you clo, design it. An

account lockout policy is a technical control that can block account access.

3.      Be aware of alternatives to password-based authentication and be ready to make

recommendations. Password-based authentication will always be subject to the

weaknesses of human memory and misunderstanding. Strong password policies

are often obviated by human practices such as writing down passwords in obvious

places, and it is difficult to convince all employees to construct strong passwords

and not to share them. Therefore, it is imperative that you be aware of and ready

to recommend alternatives to password authentication.

The rest of this lesson teaches the key elements of this process.

Create a negotiation rule

1. In the Policy dialog box, click General and then click Settings to locate and adjust the Key Exchange Settings.

2.      In the Key Exchange Settings dialog box, click Methods.

The Key Exchange Settings page is the location for changing master key generation particulars.

3.      In the Key Exchange Security Methods dialog box, select the fourth (last) default

security method (shown in Figure 3-15) and click Remove. Select both the third

and second method in turn and remove them as well. One method remains

Key Exchange Security Methods

Protect identities dunig authentication with these securty

method*,

Note Removing three of the security methods reduces the opportunities for connection.

Only a client that can negotiate 3DES and SHA1 using DiffieHellman group 2 can negotiate a     connection. The DiffieHellman group could also be changed to high, but this would limit connections to Windows Server 2003 computers only.        :

4.      Click OK twice to return to the General page, and then select the Rules page.

5.      Make sure the Use Add Wizard check box is selected, and click Add to add a rule.

6.      At the welcome page, click Next.

7.      On the Tunnel Endpoint page, click Next.

This policy will not use a tunnel.

8.      Leave the All Network Connections option selected on the Network Type page,

and click Next.

This policy will remain effective no matter where the connection is coming from.

9.      On the IP Filter List page, click Add to add a filter list.

10.   Enter Negotiate as the name of the filter list, and enter a description.

11.   Select the Use Add Wizard option, and click Add to add a filter.

12.   On the Filter Wizard welcome page, click Next.

13-   Enter a description for the filter, and click Next.

14. On the IP Traffic Source page, from the Source Address list, select A Specific IP Subnet and select a range of IP addresses. Enter the address 192.168.5.0 and the subnet mask of 255.255.255.0 (as shown in Figure 3-17), and then click Next.

15.   For the IP Traffic Destination, select A Specific IP Address and enter the IP address

for the file server. Then click Next.

16.   Select the IP protocol type (in this case, TCP), and then click Next.

17.   Select the To This Port option, enter 135, and then click Next. Click Finish.

18.   Click OK to return to the IP Filter List page in the wizard.

19- Repeats steps 11 through 18 for each TCP port. Repeat using UDP as the protocol type.

20. Select the New filter list, Negotiate, and then click Next.

Select authentication

Complete the following steps to select authentication:

1.      Click the default Require Security Filter action, and click Next.

2.      Select Kerberos for the authentication method, click Next, and then click Finish.

3.      Click OK to complete the rule, and then click OK.

Authentication times out.

MCSA Self-Paced Training Kit (Exam 70-290)

Announcing an all-new MCSA/MCSE Training Kit designed to help maximize your performance on 70-290 Exam, a core exam for the new Windows Server 2003 certification. This kit packs the tools and features that exam candidates want most—including in-depth, self-paced training based on final exam content; rigorous, objective-by-objective review; exam tips from expert, exam-certified authors; and a robust testing suite. It also provides real-world scenarios, case study examples, and troubleshooting labs for skills and expertise that you can apply to the job. Focusing on account and resource management in a Windows Server 2003 environment, this official study guide covers topics such as managing physical and logical devices; users, computers, and groups; access and permissions; the server environment; and disaster recovery services. Ace your exam preparation and ramp up quickly on Windows Server 2003 by working at your own pace through the lessons, hands-on exercises, and practice tests. The flexible, best-of-class test engine on CD features 300 practice questions and pre-assessment and post-assessment capabilities. Choose timed or untimed testing mode, generate random tests, or focus on discrete objectives or chapters, and get detailed explanations for right and wrong answers—including pointers back to the book for further study. You also get a 120-day evaluation version of Windows Server 2003 and a 15 percent exam discount voucher—making this kit an exceptional value and a great career investment.

Monitoring and Troubleshooting Replication

In order to maintain an effective replication configuration, you must be able to monitor and troubleshoot Active Directory replication. Monitoring and troubleshooting replication involves using the Replmon.exe: Active Directory Replication Monitor graphical tool and the Repadmin.exe: Replication Diagnostics Tool and Dsastat.exe command-line tools to handle replication-related issues.

After this lesson, you will be able to

•       Explain the purpose of the Replmon.exe: Active Directory Replication Monitor graphical

tool

•       Use Replmon to perform various replication monitoring and troubleshooting tasks

•       Explain the purpose of the Repadmin.exe: Replication Diagnostics Tool command-line

tool

•       Use Repadmin to perform various replication monitoring and troubleshooting tasks

•       Explain the purpose of the Dsastat.exe command-line tool

•       Use Dsastat.exe to perform various monitoring and troubleshooting tasks

Estimated lesson time: 40 minutes

Monitoring and Troubleshooting Replication

As an administrator, it will likely be your task to monitor and troubleshoot Active Directory replication. Windows Support Tools provide the following tools for monitoring and troubleshooting replication:

•       Replmon.exe: Active Directory Replication Monitor

•       Repadmin.exe: Replication Diagnostics Tool

•       Dsastat.exe

Replmon.exe: Active Directory Replication Monitor

The Active Directory Replication Monitor (Replmon) enables administrators to view the low-level status of Active Directory replication, force synchronization between domain controllers, view the topology in a graphical format, and monitor the status and performance of domain controller replication.

Replmon must be installed on a computer running Windows Server 2003. The computer can be a domain controller, member server, member workstation, or stand-alone computer. In addition, Replmon can be used to monitor domain controllers from different forests simultaneously.

Note To use Replmon, you must first install the Windows Support Tools on your computer. You can find the complete installation procedure in Chapter 2, "Administering Active Directory."

To start Replmon, complete the following steps:

1.      Click Start, point to Command Prompt, type replmon, and then press Enter.

2.      In the console tree, right-click Monitored Servers, and select Add Monitored

Server.

3.      On the Add Monitored Server Wizard page, select Add The Server Explicitly By

Name, and then click Next.

4.      On the Add Server To Monitor page, type the name of the server you want to

monitor in the Enter The Name Of The Server To Monitor Explicitly box, and then

click Finish.

5.      In the Active Directory Replication Monitor window, shown in Figure 5-21, the

server you chose for monitoring appears in the console tree. You can now monitor

replication processes for this server.

Status as ol: V27/2003 4:24:46 PM » Direct Replication Partner Data «

Servei is current through Property Update LJSN: 12559

The last replication attempt was successful. This took place at. 1/

Guidelines for Determining Resource Needs

The next step in assessing resources and designing network segmentation is determining resource needs. Review and document which resources need to be accessed by whom so that you can make an informed decision about which resources should be further protected. Guidelines for determining resource needs are as follows:

•       Use the same principles for determining overall resource needs as you do

for determining who should have access to a single server. That is,

employees should not be able to access anything that is not necessary to their

jobs; partners should not be able to access anything not specifically designated as

available to them; and the public should be limited to information the organization

wants them to have.

•       Express logical barriers via the acquisition and management of physical

controls. The decisions about what hardware, software, or other protection is

needed, as well as when and where it is needed, depend on the resource that

needs protection and where it must be placed. For example, the root Certification

Authority computer for the organization should be protected by many physical

borders—that is, placing it in a vault, taking it offline, restricting access to it to a

limited number of employees, and placing its keys in a security physical device. On

the other hand, ordinary printers should be conveniently located in rooms on

every floor.

Guidelines for Classifying Data

After you have determined resource needs, you are ready to begin classifying data. Follow these guidelines for classifying data:

•       Investigate and document exactly what the terms public data and private data

mean for your organization. When you clearly understand these terms, the need

for separating the internal network into areas of trust might become more obvious,

and the need for stronger protection on the natural borders between company and

public and between company and partner might become more distinct. For example, Tailspin Toys might want current product information to be available to the

public to encourage them to buy its products, but the company does not want to

expose information on any unique manufacturing processes, customer lists, material sources, financial information, employee data, and so forth. A bank or a hospital will have information that must be made public by law, as well as strict

regulations on how it must control access to other information.

•       Identify and catalog data by its level of sensitivity. This guideline supports the

development of boundary controls that match data classification levels. For example, data classified as public data can be placed on a public Web site. On the Web

site, you will provide controls to protect the data from unauthorized modification

3-6       Chapter 3    Designing the Network Infrastructure for Physical Security

(maintain its integrity), to protect the Web server itself from damage (by means of denial of service attacks, defacement, physical harm, deletion of site information and controls, and so on), and to protect internal sites from being compromised.

•       Document the current location of the resources.

•       Document who requires access to the resources and when they require that

access. Some people will require access to all resources all the time. Some will

require access to some resources all the time. Others will require no access to any

of the resources at any time. You must know these things to grant access only

where and when it is needed.

•       Document what logical infrastructure is necessary to support them.  Documenting

such dependencies allows appropriate consideration to be made—and there's

often more than one choice. It's far better to be aware of the issues and make an

informed decision than to simply put up a border device and find out later that

domain clients cannot connect to a domain controller or other resource.

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.

Installed and to validate the entire update process

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.