Lesson 3: Security Assessment | MCSE Training Kit (Exam 70-222): Migrating from Microsoft Windows NT 4.0 to Microsoft Windows 2000 (MCSE Training Kits)

In this lesson, you'll examine your infrastructure from a security perspective.

After this lesson, you will be able to

Assess your network's security.

Estimated lesson time: 60 minutes

To prevent your system from being compromised in any way, the migration must consider all levels of security to be duplicated or strengthened in the migrated environment and during the migration. Corporate IT security tends to be at its weakest during migration. You might find that to initially migrate some items (for example, RAS services), you'll have to weaken the security before restrengthening it. If so, try wherever possible to isolate the weakened area or ensure the systems being migrated are closed off until that area has been migrated and secured.

Physical Security

In Chapter 4, you'll assess the network for strategically placing servers. Another consideration should be the physical security of the systems. Locating the systems in secure environments will vastly reduce the potential for any security breaches.

Software Security

Windows NT Service Pack 2 and later includes a powerful password filter called PASSFILT.DLL. This filter ensures that users supply strong alphanumeric, case-sensitive passwords. Windows NT Service Pack 3 and later includes 128-bit key encryption of the SAM database via a utility called Syskey. Syskey also has several options that can prevent denial-of-service attacks on user accounts by enforcing a pre-logon password facility. In addition, your corporation might have several third-party software and hardware components such as hardware keys (also called dongles) for strengthening server and workstation security. Your security manager will want to duplicate these in your new environment, so it's essential to test whether you can upgrade these or test whether you can duplicate them via the Windows 2000 security group policies.

Certificate Services

Using certificate services in Windows 2000 provides a powerful method of enabling mutual authentication between, and validation for, both users and computers as trusted sources within your enterprise. For example, it can help prevent rogue computers from being plugged into your intranet and gaining access to servers. Two issues are involved from a migration perspective. The first is that if you already have certificate services, how will you migrate them? The second is that if no certificate services exist, should you incorporate them as part of the migration? If so, you'll also need to test their impact on servers and network traffic.

If you already have certificates as part of your public key infrastructure, you'll need to know the following:

Which servers manage certificate services
Which clients have implemented and require these services
Whether Windows 2000 will support your current certificate software

Biometric Devices and Smart Cards

Modern authentication is based on one or more of three components: something you know, something you are, and something you have. The Windows NT SAM database and the Windows 2000 Kerberos protocol both support username and password combinations; in other words, something you know. Windows 2000 has built-in support for biometric devices such as fingerprint logon (something you are) and smart cards (something you have). However, you might find that migrating biometric devices that you already have requires special drivers to be properly supported in Windows 2000. As with other hardware, it's best to put all security components through the test program prior to migration. The manufacturers of your security devices will also be able to verify whether they have Windows 2000 drivers or when updated drivers will be available.

DACLs, Rights, and Group Control

A particularly difficult endeavor is trying to find out which users and groups have access to network shares, folders, and files across your Windows NT enterprise. This information is something you might want to retain in the migrated Windows 2000 infrastructure. From this perspective, an in-place upgrade is by far the easiest solution, although it might not take advantage of the many benefits of a restructure.

Assessing the access permissions on objects (discretionary access control lists, or DACLs), assessing the privileges (rights) assigned to the various users and groups, and locating which users belong to which groups can be a tedious and thankless task. However, many third-party utilities can help you out here. Utilities supplied by Microsoft include those in the Microsoft Windows NT Server Resource Kit and the security configuration editor that comes as a separate component in Service Pack 4 and later of Windows NT 4.0.

Microsoft Security Configuration Manager

The Microsoft Security Configuration Manager (also known as the Microsoft Security Configuration Editor—MSSCE) allows you to assess the security of your Windows NT systems. It is based around a set of templates that you can use as the basis for validating and reconfiguring a Windows NT system. The Microsoft Security Configuration Manager comes in two parts:

A Graphical User Interface for setting and analyzing a Windows NT system. The GUI comes as an MMC snap-in.
A command-line utility called Secedit for analyzing and deploying a security configuration. Secedit can be used with log-on scripts and Microsoft SMS to deploy a security policy to Windows NT workstations and Windows NT servers.

The GUI component of the Security Configuration Manager comes as a Microsoft Management Console (MMC) snap-in component and is designed to provide a central repository for security-related administrative tasks. It is an essential tool for configuring and analyzing security on one or more Windows NT machines in your network.

The Security Configuration Manager is useful if you're performing an analysis on a server-by-server basis. However, it's best used in GUI mode because its text reports are unable to quantify mismatches.

User and Group Account Security

A number of tools exist to aid the migration of Windows NT users and groups to Windows 2000. However, depending on the migration methodology, you might need to examine potential issues that could affect users and groups. For example, if you're migrating multiple Windows NT account domains to a single Windows 2000 domain, you'll need to know whether any duplicate usernames and groups exist and determine a policy for handling duplicates.

You might also want to find out which users have been strategically placed in the built-in groups to help with the administration of Windows NT. This information can then be used to determine whether they should have less responsibility in the new Windows 2000 infrastructure via delegated management.

For example, you might have users who are in the Windows NT Accounts Operators group purely to help with password administration for their own departments. In Windows NT, this means they also have the ability to affect users in other departments. You can use a feature of Windows 2000 to design a group policy for these users to have password administration only of the people in their department. You can do this without giving them authority over other users or over other attributes of the users in their department, such as the users' full names.

Other important user information that will help your migration include

The profile and logon scripts being used.
A full listing of the groups to which the user belongs.
Information about the workstations and the times the user is allowed to log on.
When the user account was last used. If it hasn't been used for a considerable period, you might want to check with your human resources department about removing the user from the SAM database and thus avoiding further problems migrating this user.

The NET command and such utilities as Usrstat and Addusers from the Microsoft Windows NT Server Resource Kit will help you assess much of this information. In the next practice, you will use these tools to assess user accounts on your system.

Practice: Checking Windows NT User Accounts

Exercise 1: Using the NET Command to Analyze a Server's Security

In this practice, the NET command is used as an alternative for creating a report regarding your users and shares. This exercise requires that you are working on a domain controller. Use PC1 for this practice.

Log on to MIGKIT1 as Administrator with the password secret.
Open the command prompt and enter the following lines, pressing Enter at the end of each line:
```
net user > usrshare.txt net user administrator >> usrshare.txt net user guest >> usrshare.txt net share >> usrshare.txt net share netlogon >> usrshare.txt notepad usrshare.txt
```
The first command takes the output of the Net user command and places it in a new file named Usrshare.txt. Subsequent commands append additional categories of information to the same file.
Review the contents of the file by opening it in Notepad.
What information does the file contain?

Answers

Exercise 2: Assessing User Accounts

In this practice, you use the Addusers utility from the Microsoft Windows NT Server Resource Kit to gain information about the Windows NT user accounts.

Be sure you are logged on to MIGKIT1 as Administrator.
Open the command prompt and change to the C:\Tools folder.
Type the following command:
```
addusers /d users.txt
```
Examine the contents of Users.txt by opening it in Notepad.
What information about users does users.txt contain?

Answers

The information supplied by Addusers is useful if you need to do any of the following:

Migrate user accounts from one Windows NT domain to another prior to the migration. You can use the Addusers utility to take this file or an amended version and recreate these users (but not their passwords) in another domain.
Compare user accounts from one domain with others to ensure that no duplication of accounts occurs during an upgrade or restructure.
Recreate at an individual level single user accounts or a subset of the accounts collected.

Exercise 3: Detecting Unused Accounts or Falsely Used Accounts

In this practice, you use the Usrstat utility from the Microsoft Windows NT Server Resource Kit to determine whether some accounts should be considered for deletion prior to the migration. The syntax of Usrstat is Usrstat domain > filename, where domain is the name of the domain, and filename is the file to which the results will be written.

Open the command prompt on MIGKIT1 and change to the Tools folder.
Type usrstat MIGKIT > usedacct.txt.
This command will create a file that contains information about the last time user accounts were used and for how long. This method is good for finding out whether an account has been used and for investigating suspected abuses (for example, whether the Administrator account was used when corporate policy strictly forbids its use).
Review the contents of the usedacct.txt file by opening it in Notepad.
Which accounts have never been used?

Answers

The Microsoft Windows NT Server Resource Kit has many tools that are useful for assessing security; however, many of these aren't able to produce comprehensive reports. You might need to consider using other tools such as DumpSec, from www.somarsoft.com, which can give you a security analysis from a group and DACL perspective.

Lesson Summary

In this lesson, you learned how to gather information about your current security services. You also learned about tools that you can use to assess your user and group accounts, registry settings and DACLs, file and folder DACLs, and policy settings. Finally you learned that security is likely to be at its weakest during the height of migration and how to take steps to mitigate this.