1. Planning a Microsoft Windows 2000 Administrative Structure Designing default administrative group membership Designing custom administrative groups local security authority (LSA) functionality Designing secure administrative access Designing secondary access Designing Telnet administration Designing Terminal Services administration

2. Planning Administrative Group Membership Designing default administrative groups Designing custom administrative groups

3. Default Administrative Groups Domain Local Groups Administrators Account Operators Server Operators Print Operators DHCP Administrators DNS Admins WINS Admins Pre–Windows 2000 Compatible Access Replicators

4. Default Administrative Groups (Cont.) Local Groups Power Users Backup Operators

5. Default Administrative Groups (Cont.) Global Groups Domain Admins Group Policy Creators Owners DNSUpdate Proxy

6. Default Administrative Groups (Cont.) Universal Groups Enterprise Admins Schema Admins

7. Assessing Administrative Group Membership Design Poor administrative group design negatively impacts network security. Security is compromised if administrative group membership is not controlled.

8. Auditing Group Membership Microsoft Windows 2000 auditing and periodic manual audits of group membership should be verified against documented membership. The network determines which administrative groups are audited. Audits are achieved by Performing regularly scheduled manual inspections Using third-party products

9. Using Restricted Groups to Maintain Group Memberships Use the Restricted Groups option within Group Policy to predefine memberships within groups. If members are added or deleted, membership is re-established based on the Group Policy. Apply the Restricted Groups option at the site, domain, or OU level. The Restricted Groups option provides two forms of protection for a defined group: Protects membership in the group Limits the groups that the restricted group can be a member of

10. Making the Decision: Assessing Administrative Group Design Determine exactly who must be a member of each administrative group. Do not grant membership to a group that provides excess privileges. Use the Restricted Groups option to ensure that only approved membership is maintained. Ensure that membership is audited for these groups. Scrutinize membership in the forest root domain's Domain Admins group.

11. Applying the Decision: Defining Administrative Groups at Hanson Brothers Administrative roles Stephanie Conroy: Performs backups and Group Policy management Derek Graham: Manages Domain Name System (DNS) and Dynamic Host Configuration Protocol (DHCP) Steve Masters: Manages all user accounts, excluding administrative accounts Kim Hightower: Restores network backups Yvonne Schleger: Manages schema design Eric Miller: Manages backup and restore, share management, and services

12. Designing Custom Administrative Groups

13. Determining When to Create Custom Groups Determine exactly what rights are required by a specific account. Use custom groups to delegate specific rights to an account, rather than provide the account with excess privileges. The Enterprise Admins universal group has a large number of rights in the forest root domain. Membership in the Enterprise Admins group is required to perform specific security tasks in a Windows 2000 forest.

14. Enterprise Admins Group Security Tasks Creating new domains and new domain controllers (DCs) in the forest Authorizing Remote Installation Services (RIS) and DHCP servers in Active Directory Installing Enterprise Certification Authorities Managing sites and subnets

15. Making the Decision: Creating Custom Administrative Groups Determine that an existing administrative security group does not meet security requirements. Determine what rights are required by the custom administrative groups. Determine if the necessary administrative rights can be delegated. Determine what objects are accessed by the permissions. Create a domain local group that will be assigned the desired permissions and rights.

16. Applying the Decision: Creating Custom Administrative Groups at Hanson Brothers

17. Securing Administrative Access to the Network Designing secure administrative access Designing secondary access Designing Telnet administration Designing Terminal Services administration

18. Administrative Access Methods Require smart card logon. Restrict which workstation administrators can log on to. Configure logon hours. Enforce strong passwords. Rename the default administrator account.

19. Requiring Smart Card Logon

20. Restricting Administrative Access

21. Making the Decision: Securing Administrative Access Restrict administrative access to specific workstations. Protect administrative passwords. Protect the administrator account from being compromised.

22. Applying the Decision: Securing Administrative Access at Hanson Brothers Rename the administrator account. Create dedicated administrative accounts. Protect administrative accounts.

23. Designing Secondary Access: Understanding the RunAs Service

24. Making the Decision: Implementing the RunAs Service The RunAS service does not provide facilities for smart card logon. There are several ways to launch the RunAs service. Use a standard prefix for administrative accounts. Create a usage policy for administrative accounts on the network.

25. Applying the Decision: Implementing the RunAs Service at Hanson Brothers Administrative tasks can be performed without logging on to the administrative account. Define a policy that requires all administrative users to use the RunAs service to launch administrative tasks. Ensure that no administrative users require smart card logon, because the RunAs service does not support smart cards.

26. Designing Telnet Administration Windows 2000 includes the Telnet Service to perform remote administration from the command line. Telnet Service can only be run with text-based utilities, such as scripts and batch files. Use the RunAs command or Terminal Services to run utilities requiring GUI interfaces. By default, Telnet uses clear text for transmitting authentication and screen data. NTLM authentication can exclude UNIX clients from accessing the Telnet Service. Use IPSec to encrypt all transmitted data.

27. Making the Decision: Implementing Telnet Service All management commands can be performed from a text-based utility. Consider using NTLM authentication to protect the authentication credentials transmitted to Telnet Services. Use IPSec to encrypt all data transmitted between the client and server.

28. Applying the Decision: Implementing Telnet Service at Hanson Brothers Telnet can be used only for text-based utilities. Telnet must not be configured to use NTLM for authentication because one administrator is using a UNIX SPARC workstation. IPSec must be configured to encrypt all administrative Telnet sessions.

29. Designing Terminal Services Administration

30. Assessing Terminal Services Administration: Application Mode Allows multiple connections by regular user accounts that have been granted Terminal Services access in Active Directory Users And Computers. Additional security can be configured by applying the Notssid.inf security template.

31. Assessing Terminal Services Administration: Remote Administration Mode Configure Terminal Services to run in Remote Administration mode. Limits connections to two concurrent connections. Only members of the Administrators group are allowed to connect to the terminal server.

32. Making the Decision: Using Terminal Services Administration Use Terminal Services to Limit which utilities can be run by a Terminal Services client Restrict access to Terminal Services to administrative personnel only Secure transmission of data between the Terminal Services client and the terminal server Prevent excess rights to domain controllers Determine Terminal Services access based on individual user permission. Allow access to Terminal Services from the widest range of platforms.

33. Applying the Decision: Implementing Terminal Services at Hanson Brothers Restrict Terminal Services to administrators by using Remote Administration mode. Deploy Terminal Services Advanced Client to allow clients running other OSs, but using Microsoft Internet Explorer, to perform administrative tasks in the Windows 2000 domain. Use Terminal Services Advanced Client for the administrator using a UNIX SPARC workstation.

34. Chapter Summary Assessing administrative group membership Designing custom administrative groups Securing administrative access to the network Designing secondary access Designing Telnet administration Designing Terminal Services administration