This lab prepares you to design administration of a Windows 2000 network by meeting the following objectives:
- Designing the membership of the default administrative groups in Windows 2000
- Planning a method to ensure that administrative group membership isn't modified by adding unauthorized security principals to the groups
- Designing remote administration methods for managing the network
About This Lab
This lab looks at designing administration of a Windows 2000 network. It will look at designing the membership of the default administrative groups, identifying when to create custom administrative groups, and designing remote administration of the network.
Before You Begin
Make sure that you've completed reading the chapter material before starting the lab. Pay close attention to the sections where the design decisions were applied throughout the chapter for information on building your administrative structure.
Scenario: Contoso Ltd.
Contoso Ltd., an international magazine sales company, wants to design the administration of its network. When the proposal was originally distributed to the IT department, all the IT department members asked for their accounts to have administrative capabilities on the network. You've been hired to assist in determining group membership design for Contoso to ensure that members of the IT department aren't granted excess rights on the network.
Contoso's Active Directory design is comprised of four domains: contoso.tld, seattle.contoso.tld, lima.contoso.tld, and london.contoso.tld as shown in Figure 4.9.
Figure 4.9 The Contoso Ltd. domain structure
The following table outlines the administrative tasks that are assigned to the members of the Contoso IT department.
|IT Staff Member ||Tasks |
|Peter Connelly ||Backup and restore for all four domains |
|Scott Gode ||Management of all DNS Servers |
|Kate Dresen ||Management of the schema |
|Elizabeth Boyle ||Creation and management of all user and computer accounts in the Lima domain |
|Suzan Fine ||Creation and management of all user and computer accounts in the Seattle domain |
|Thom McCann ||Creation and management of all user and computer accounts in the London domain |
|Jörg Frey ||Group Policy design for all domains |
|Lisa Garmaise ||Manage membership of forest-wide administration accounts |
Concerns with Group Memberships
Contoso wants to monitor and restrict who can modify the memberships of the following groups in Active Directory:
- Enterprise Admins
- Schema Admins
- Domain Admins
For the development of their administration plan, Contoso has collected the following administration requirements:
- Enterprise Admin accounts must be restricted to logging on at the DCs located in the computer room in London. The names of the two DCs are LONDONDC1 and LONDONDC2.
- Schema administration must be performed at the schema operations master. The schema operations master is named SCHEMADC and is also located in the computer room in London.
- Each member of the administration team must have two accounts: one for administrative duties and one for day-to-day tasks. The account name must help differentiate between the two accounts.
- The administrators responsible for maintaining user and computer accounts for the london.contoso.tld, lima.contoso.tld, and seattle.contoso.tld domains must be able to perform administration of the domains while remaining logged on with their day-to-day user accounts.
- Elizabeth, the administrator at the Lima office, has only a Windows 98 client computer. The administration plan must allow Elizabeth to manage user and computer accounts for the Lima domain.
- An administrator in the Seattle office uses a UNIX workstation as the primary desktop. This administrator must be able to run various administrative scripts without having to move to another computer.
Exercise 1: Designing Preexisting Administration Groups
This exercise will look at designing the membership of the default administration groups in an Active Directory forest. The exercise will also look at methods that you can use to guard the membership of administrative groups. Answers to these questions can be found in the appendix.
Analyzing Administrative Group Membership
A key to managing administrative groups is initially designing proper membership in the administrative groups to prevent excess privileges from being granted to administrators of the network.
- For all of the administrators mentioned for Contoso, what must you do to separate their administrative tasks from day-to day tasks?
- What group memberships does Peter Connelly require?
- What group memberships does Scott Gode require? How can the DNS design affect the group memberships?
- What group memberships does Kate Dresen require?
- Are there any issues with this group membership requirement if Kate's accounts are located in the Seattle domain?
- Complete the following table to define administrative group memberships for Elizabeth Boyle, Suzan Fine, and Thom McCann:
|User ||Group Membership |
|Elizabeth Boyle || |
|Suzan Fine || |
|Thom McCann || |
- Rather than using administrative group memberships, what alternative method could have been used to provide the necessary rights to Elizabeth, Suzan, and Thom?
- What administrative group memberships does Jörg Frey require?
- What is the minimum group membership required for Lisa Garmaise to manage forest-wide administration accounts?
Protecting Administrative Group Membership
Once you've defined administrative group memberships, the next stage is developing a plan to make sure that only desired memberships are maintained for all administrative groups in the forest. Answers to these questions can be found in the appendix.
- Assuming that you will use restricted groups to enforce memberships in administrative groups, where must the Restricted Groups policy be set to have the desired protection of the administrative groups?
- Is it possible to change the membership of a group when a Restricted Groups policy is applied? Provide details.
- What can you do to track who changes membership of a protected administrative group?
- Complete the following table of restricted group configuration for the required administrative groups:
|Group ||Members ||Member of |
|Enterprise Admins || || |
|Schema Admins || || |
|Contoso\Domain Admins || || |
|Lima\Domain Admins || || |
|London\Domain Admins || || |
|Seattle\Domain Admins || || |
|Contoso\Administrators || || |
|Lima\Administrators || || |
|London\Administrators || || |
|Seattle\Administrators || |
- In addition to using restricted groups, what other methods should Contoso consider to protect administrative group membership?
Exercise 2: Designing Administrative Access
In higher security networks administrative design also incorporates the implementation of additional restrictions on the usage of administrative accounts. This exercise will look at the design of restrictions for the use of administrative accounts on the Contoso network. Answers to these questions can be found in the appendix.
- How would you meet the requirement for each administrator to have two accounts?
- Can you restrict the default Administrator account that's a member of the Enterprise Admins group in the forest root domain as defined in the requirements?
- What can you do as an alternative to restricting an Enterprise Admin?
- How would the creation of a new Enterprise Admins account affect your restricted groups design?
- What methods could Suzan and Thom use to manage their respective domains without having to log off their day-to-day accounts?
- What method of administration can Elizabeth use to manage user accounts in the Lima domain?
- What method could the Seattle administrator who uses a UNIX workstation use to run administrative scripts? What additional security considerations must be examined?