In this lesson, you'll examine your infrastructure from a security perspective.
After this lesson, you will be able to
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.
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.
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.
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:
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.
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.
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:
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.
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 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.
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.
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.
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.
addusers /d users.txt
The information supplied by Addusers is useful if you need to do any of the following:
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.
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).
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.
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.