Several changes can occur to your environment during an upgrade that will affect the security of your organization. In this lesson, you'll learn about the importance of security in your organization and how to troubleshoot security problems.
After this lesson, you will be able to
Estimated lesson time: 15 minutes
Depending on your Windows NT 4.0 environment, you might have had duplicate accounts in different domains. For example, you might have had two duplicate accounts in different domains with no trust relationship between them. Windows 2000 requires that the LDAP name of any account be unique within the forest, so it won't allow truly duplicate names within your enterprise. Migration tools will have a variety of ways of dealing with name duplication, but you should plan for this eventuality before performing the migration.
Although truly duplicate accounts aren't allowed within Active Directory, it's possible to create two accounts with an identical User Principal Name (UPN). Identical UPNs must be avoided because the UPN provides the means for users to log on anywhere within the enterprise using a single logon. Because Active Directory is a loosely consistent database, tools that query Active Directory to see whether a UPN already exists don't guarantee the uniqueness of UPNs. The best way to ensure that UPNs are truly unique is to have a policy for account creation that ensures this.
Many of the problems that arise from NTFS permissions under Windows 2000 come from a misunderstanding of how they're applied. Windows NT 4.0 implements NTFS version 4.0, whereas Windows 2000 implements NTFS version 5.0, which gives more functionality, such as disk quotas, junction points, and Encrypting File System (EFS), but which is also more complex.
If you're having problems with NTFS permissions, you need to examine the inheritance of permissions. Each file and folder shows the effective permissions that are the result of direct permissions and inheritance. You'll find troubleshooting file and folder access problems easier if you minimize the number of permissions assigned directly to files and limit how much you prevent inheritance flowing from above. The simpler your NTFS security configuration, the easier it will be to troubleshoot, so try to keep your permission structure simple.
If you need to dual-boot Windows NT 4.0 and Windows 2000, you will require at least Windows NT Service Pack 4.0 to be able to access the NTFS 5.0 drive(s).
In general, for security to be effective within your organization, your security processes must be
If you don't consider these points, you're likely to have poor security in your Windows 2000 environment. For example, consider a situation in which you use the latest in firewall technology to block out almost all traffic to and from the Internet, thereby preventing some of the functionality required by the organization. Users in that environment might respond by bringing in their own modems to the organization and accessing the Internet through these. That's a far greater breach of security than you would have suffered if you had configured the firewall more liberally.
When migrating to Windows 2000, you'll find that security is configured in quite a different way. For example, trust relationships are all two way and transitive by default, so trusts can no longer be used for implementing security. OUs give more granular control, but the domain is still the principal security boundary in Windows 2000. Certain security options can be set only at the domain level, such as the minimum password length. This is a major consideration if you're consolidating multiple Windows NT 4.0 domains with different password lengths and other account policy settings into a single Windows 2000 domain. Whichever security regime you opt for will need to be communicated to the users.
Documenting security procedures is critical to maintaining appropriate security in your organization. If you can, document NTFS security on servers, group policy settings, permissions on domains and OUs, and auditing—in fact, document anything to do with security in your organization.
Fortunately, Windows 2000 comes with a comprehensive set of tools allowing you to analyze and configure all aspects of Windows 2000 security, and you've already used a few in earlier chapters. The Security Configuration And Analysis MMC snap-in and the Security Templates MMC snap-in give you a great deal of control and analysis over your environment and should be used to ensure that your security meets your organization's requirements.
User rights were set in User Manager For Domains in Windows NT but are now controlled by group policies in Windows 2000. Group policy can be assigned at the level of the local machine, site, domain, or OU. The hierarchical nature of GPOs combine to give a user logging on to a resource an effective permission on that resource that might not be completely specified at the level of the resource object itself. A useful tool from the Microsoft Windows 2000 Server Resource Kit is Gpresult.exe, which displays the result of the group policies for the currently logged-on user and computer, as shown in Figure 11.14.
Figure 11.14 An excerpt from a Gpresult analysis
If you need to alter user rights, be careful about the level at which you alter the group policy, or you could end up giving particular user rights that you didn't intend to because of the inheritance quality of permissions in Windows 2000 group policy.
Depending on how you've performed the migration, you might need to reshare some directories on file servers. Maybe you're choosing to make a share available in Active Directory. Shares published in Active Directory will be available only to clients that are running Windows 2000, or to those running other versions of Windows that have the Active Directory client extensions installed. Other legacy clients will still be able to access these shares, but only by using the UNC name of the folder.
Group memberships might have also changed in the migration to Windows 2000 and will affect whether clients are able to access shares. Clients might also have drive mappings specified to shares that are no longer correct because the server name has changed.
In this lesson, you learned about the different client security issues you might encounter, how to look for those issues, and how to resolve them.