Best Practices

The following is a list of rules and best practices for joining the ad.msu.edu Active Directory structure at Michigan State University.   

All Windows 2000 systems within the child domain must follow the prescribed DNS naming scheme.  The system's machine name matches DNS hostname and domain name matches DNS zone name.  (i.e., a system currently registered as example.ais.msu.edu will have the machine name of "example" in a W2K domain called "ais.msu.edu" and having a full DNS entry of example.ais.ad.msu.edu). 

Departments are strongly encouraged to use passwords that are 8 or more characters in length.  AIS will require 8 character minimum passwords for those domains users who access resources in the AIS domain.  In addition, passwords should be minimally set to expire at least every 42 days.  These policies should be setup immediately upon domain creation. 

The built-in Windows 2000 Administrator account should be renamed.  In addition, sensitive domain accounts with elevated privileges should be put in separate organizational units that have more restrictive permissions so that they cannot be viewed by all users forest-wide. 

Departments are strongly encouraged to physically secure their servers.  Server and domain security can be compromised by unauthorized physical access to the system. 

Child domains must meet Microsoft’s minimum computer hardware requirements. 

Departments are encouraged to provide at least 2 domain controllers to provide fault tolerance for their domain. 

The child domain controllers must be in a backup program and have full recoverability tested. 

All service packs and relevant hot fixes should be installed in a timely manner.  Administrators are strongly advised to subscribe to Microsoft’s Security Notification Service to receive the latest email updates on hot fixes and service packs.

Administrators should protect their workstations and servers with a proven antivirus solution.  It is recommended that the antivirus software be configured to automatically update its definition files on a daily basis, at minimum. 

Administrators should thoroughly test any software or hardware firewall implementations before deployment into a production environment.  Improperly configured firewalls can interfere with client/server communications and Active Directory replication.  Special care should be taken to maintain Outlook client access when locating Exchange servers behind firewalls. 

Administrators should use the RestrictAnonymous registry value on Windows 2000-based computers to restrict access over anonymous connections.  See Microsoft Knowledge Base article Q246261 for more information. 

Optionally, Domain Admins can hide objects from other domains and users in Active Directory.   These objects include organizational units, containers, printers, etc.  Depending on the security on the object, it can be hidden from domain searches from other domains.  For example, Domain Admins can make their printers viewable only to their domain users.  This can be accomplished by adjusting the printer permissions so that only internal department groups have "view" and print access.  On the printer's sharing tab, uncheck the box to "list in the directory."  Those printers that need to be listed in Active Directory should use a standard naming convention in which the printer name begins with the department name or abbreviation. 

Departments should avoid the use of the “Everyone” and “Authenticated Users” groups when granting access to shared network resources.  Domain-specific security groups should be used in their place.  It is recommended that child domains use the Microsoft’s groups scheme A-GG-U-DL-P.  Accounts (users) go into Global groups, Global groups into Universal groups, Universal groups into Domain Local groups and permissions are assigned to the Domain Local groups. 

Site-level group policies will not be implemented in the ad.msu.edu forest because they span multiple domains. 

All domain user logons should use a display name format of last, first as the standard display method.  This is essential for inclusion in the Exchange 2000 Global Address List. 

Domains that will include Microsoft Exchange users should be switched to Native Mode.  Native mode allows for the use of Universal Groups.  Universal Groups will be used for Exchange distribution lists (DLs).  Global groups and global distribution lists only replicate their membership to servers within the local domain.  If the client connects to a global catalog that is outside of the local domain, the global catalog will not have the membership list of the distribution list, and will not, therefore, be able to send that information to the client.

Universal Groups will be used for DLs and only nest Universal Groups for DLs - no Global or Local Groups as DLs in a multi-Domain environment.  More information on this issue can be found in Microsoft Article Q262200.

In addition, Microsoft recommends that departments with Exchange 2000 put a global catalog server 'near' the Exchange 2000 server.  It is important to note, however, that the infrastructure master role cannot be the same domain controller that hosts the global catalog. 

The child domain will use Organizational Units to subdivide their administrative structure rather than hosting sub domains. 

Departments should follow Microsoft recommendations for the use and placement of the operations masters.  The Active Directory defines five FSMO roles: schema master, domain master, RID master, PDC emulator and infrastructure. The schema master and domain naming master are per-forest roles and thus reside on the AD domain root servers housed in the AIS department. The remaining three, RID master, PDC emulator and infrastructure master are per-domain roles.

General Recommendations for FSMO Placement

1. Place the RID and PDC emulator roles on the same DC. Good communication from the PDC to the RID master is desirable as down-level clients and applications target the PDC, making it a large consumer of RIDs. It is also easier to keep track of FSMO roles if you cluster them on fewer machines.

2. If the load on the primary FSMO load justifies a move, place the RID and PDC emulator roles on separate domain controllers in the same domain and active directory site that are direct replication partners of each other.

3. The infrastructure master should be located on a non-global catalog server that has a direct connection object to some global catalog in the forest, preferably in the same Active Directory site. Since the Global Catalog server holds a partial replica of every object in the forest, the infrastructure master, if run on a Global Catalog server, will never update anything because it does not contain any references to objects that it does not hold.

4. Most importantly, confirm that all FSMO roles are available using one of the management consoles (such as Dsa.msc or Ntdsutil.exe).

Some domain controllers may also function as Global Catalog servers.  Exchange 2000 relies heavily on the Global Catalog servers to fully function.  Exchange 2000 refers Outlook clients to Global Catalog servers for directory access.  It is extremely important that Global Catalog servers are available to the Outlook clients.  Special care should be taken when promoting a Domain Controller to a Global Catalog server or when demoting a Global Catalog server to a Domain Controller.

1.  When promoting a server to a Global Catalog server, be sure to reboot the server immediately afterwards.  See Q304403 for details.
2. When demoting a Global Catalog server to a Domain Controller, be sure to follow the steps in Microsoft Knowledge Base article Q305065.  These steps require Windows 2000 Service Pack 3.

For additional information, please refer to Microsoft Knowledge Base articles Q304403, Q305065, Q295419, Q241795, Q256976 and Q251468. 

All Windows 2000 systems within the child domain will use the root AD-Integrated DNS server settings.  The child domain controllers will use static IP entries and will not run DHCP servers. 

Schema and root-level security changes will occur after acceptance by all Enterprise and Domain Administrators. 

A contract will exist between the Enterprise Administrators, System Owners and Administrators of Child Domains regarding fair use and the University’s Acceptable Use Policy. 

Administrators are strongly encouraged to review the following publications on Windows 2000 Security:

Windows NT Security Step by Step - The SANS Institute

Securing Windows 2000 Server Guide – Microsoft

National Security Agency’s Windows 2000 Security Recommendations Guides 

This document will be revised and updated as technologies and security practices evolve.  This document will also be re-distributed to Domain Administrators as changes occur.