When you migrate from Windows NT domains to Windows Active Directory domains, there are many aspects of the migration...
that can remain unfinished. These incomplete steps can threaten the overall state of the enterprise and should be eliminated. If you have recently -- or even a long time ago -- migrated from NT to Active Directory, be sure to tidy up the following areas to ensure that you close all of the security gaps that might still exist:
Dual user accounts
If you have created two different domain environments instead of performing an in-place upgrade, you will have two different user accounts for each user. This can cause a situation where one or both of the user accounts is not monitored or configured with the proper account policy settings. You should eliminate the legacy user accounts and domains as soon as possible.
Resource Access Control Lists
Access Control Lists (ACLs) control who can access files, folders, etc. All resources in the legacy domains refer to the old user accounts. All of these resources need to be altered to point to the new user accounts in the new Active Directory domain. This process is called re-ACLing. All servers and their resources need to be migrated to the new Active Directory domain quickly, then re-ACLed so the old user accounts are not needed.
Another byproduct of creating two different domains as you move to Active Directory is that sIDHistory typically is used. This allows the new user account to access resources that the old user account is configured to access. sIDHistory should be deleted and cleaned up from the new user accounts as soon as the migration is complete. All resources then can be configured to the new user account.
With at least two domains in your migration, you want to reduce the final result to only the Active Directory domains. Old Windows NT domains should only be required while dual accounts, old server resources (ACLs) and sIDHistory are used. After these migration features are eliminated, old NT domains can be decommissioned.
Utilize Group Policy
In many migrations, the goal is to just get the enterprise working. However, that omits the key concept of controlling security and standards for computers. You should configure and use Group Policy within Active Directory immediately to control both security and standards for all user and computer objects in the new Active Directory domain.
Delegation within Active Directory
One of the benefits of moving to Active Directory is "Delegation of Active Directory Privileges." These privileges let administrators offload certain tasks to other admins, power users, helpdesk personnel, etc. An example would be to give the helpdesk staff the ability to reset passwords for all users in the Employees organizational unit. Without delegation, some administrators might have too much power within Active Directory.
Cleaning up your environment after a migration is important to ensure that security is upheld at a high level. There are common tasks that need to be completed after a migration, such as cleaning up old user accounts and domains. After these straggling objects and settings are cleaned up, your enterprise will be more secure overall.
10 tips in 10 minutes: Windows IT management
Tip 1: The long-range plan for 64-bit hardware
Tip 2: A Window into interoperability
Tip 3: Third-party software: Do you need it?
Tip 4: Buy 64-bit now; you won't regret it
Tip 5: Maintaining a secure Active Directory network
Tip 6: Firewalls can help or hurt, so plan carefully
Tip 7: Weak passwords can make your company vulnerable
Tip 8: Keys to finalizing your Active Directory migration
Tip 9: Network safety relies on reaction time to Patch Tuesday
Tip 10: Make friends with your security auditors
Derek Melber, MCSE, MVP, and CISM, is the director of compliance solutions for DesktopStandard Corp. He has written the only books on auditing Windows security available at The Institute of Internal Auditors' bookstore. He also wrote the Group Policy Guide for Microsoft Press -- the only book Microsoft has written on Group Policy. You can contact Melber at firstname.lastname@example.org.