Chapter 4, Planning a Microsoft Windows 2000 Administrative Structure
Chapter 4, Planning a Microsoft Windows 2000 Administrative Structure
|1|Chapter Overview
Designing default administrative group membership
Designing custom administrative groups
Designing secure administrative access
Designing secondary access
Designing Telnet administration
Designing Terminal Services administration
Chapter 4, Lesson 1
Planning Administrative Group Membership
|2|1.Designing Default Administrative Group Membership
A.Default Microsoft Windows 2000 administrative groups
|3|1.Domain Local groups
a.Administrators
b.Account Operators
c.Server Operators
d.Print Operators
e.Replicators
f.DHCP Administrators
g.DNS Admins
h.WINS Admins
i.Pre–Windows 2000 Compatible Access
|4|2.Local groups
a.Power Users
b.Backup Operators
|5|3.Global groups
a.Domain Admins
b.Group Policy Creator Owners
c.DNSUpdate Proxy
|6|4.Universal groups
a.Enterprise Admins
b.Schema Admins
|7|B.Assessing administrative group membership design
1.Introduction
a.Poor administrative group design negatively impacts network security
b.Security is compromised if administrative group membership is not controlled.
|8|2.Auditing group membership
a.Windows 2000 auditing and periodic manual audits of group membership should be verified against documented membership.
b.The network determines which administrative groups will be audited.
c.Audits are achieved by
(1)Performing regularly scheduled manual inspections
(2)Using third-party products
|9|3.Using Restricted Groups to maintain group memberships
a.Use the Restricted Groups option within Group Policy to predefine membership within the groups.
b.If members are added or deleted, membership is reestablished based on the Group Policy.
c.Apply the Restricted Groups option at the site, domain, or OU level.
d.Provides two forms of protection for a defined group:
(1)Protects membership in the group
(2)Limits groups that the restricted group can be a member of
|10|C.Making the decision: assessing administrative group design
1.Determine exactly who must be a member of each administrative group.
a.Predetermine the group membership and document the proposed membership. This documentation can be used for periodic audits to ensure that membership has not been modified.
2.Do not grant membership to a group that provides excess privileges.
a.Determine exactly what rights a member will require.
b.Restrict access to the Administrators and Domain Admins security groups.
3.Use Restricted Groups to ensure that only approved membership is maintained.
a.The Restricted Group membership definition must be modified if the desired membership changes over time.
4.Ensure that membership is audited for these groups.
a.All administrative group membership should be periodically audited.
b.Audits can be performed manually or with automated reporting utilities, but audits should occur at regularly scheduled intervals.
5.Watch membership in the forest root domain’s Domain Admins group.
a.The Domain Admins group can modify the membership of the Enterprise Admins and Schema Admins groups.
b.Membership in this group must be carefully monitored to ensure that only authorized memberships exist.
|11|D.Applying the decision: defining administrative groups at Hanson Brothers
1.Administrative group memberships
a.Enterprise Admins
(1)Only the default administration account
(2)The account must be restricted to specific locations on the network.
b.DNSAdmins
(1)Derek Gram
c.DHCP Administrators
(1)Derek Gram
d.Account Operators
(1)Steve Masters
e.Schema Admins
(1)Yvonne Schleger
f.Server Operators
(1)Eric Miller
g.Group Policy Creator Owners
(1)Stephanie Conroy
2.Exceptions to, and other requirements for, the administrative group
a.No members are assigned to the Backup Operators group.
(1)Backup and Restore privileges must be divided between Stephanie Conroy and Kim Hightower.
b.Manage membership of Domain Admins, Enterprise Admins, Schema Admins, and Administrative groups by
(1)Defining restricted groups in Group Policy
(2)Auditing success and failure events for account management
(3)Auditing membership in these groups at regular intervals
3.Restricted Groups policy deployed at the Domain Controllers OU
a.Domain Admins
(1)Members include Administrator
(2)Member of Administrators and Enterprise Admins groups
c.Enterprise Admins
(1)Members include Administrator
(2)Member of no other groups
d.Schema Admins
(1)Members include the Administrator and Yvonne Schleger.
(2)Member of no other groups
e.Administrators
(1)Members include Domain Admins, Enterprise Admins, and Administrators groups.
(2)Member of no other groups
|12|2.Designing Custom Administrative Groups
A.Determining when to create custom groups
|13|1.Determine exactly what rights are required by a specific account.
2.Use custom groups to delegate specific rights to an account, rather than providing the account with excess privileges
3.The Enterprise Admins universal group has a large number of rights in the forest root domain.
|14|4.Membership in the Enterprise Admins group is required to perform specific security tasks in a Windows 2000 forest.
a.Create new domains and new DCs in the forest.
b.Authorize Remote Installation Services (RIS) and Dynamic Host Configuration Protocol (DHCP) servers in Active Directory.
c.Install Enterprise Certification Authorities (CAs).
d.Manage sites and subnets.
|15|B.Making the decision: creating custom administrative groups
1.Determine that an existing administrative security group does not meet security requirements
a.If the existing security groups do not offer sufficient rights for the tasks that are required
b.If the existing groups offer excess rights for the tasks required
2.Determine what rights are required by the custom administrative groups.
a.Determine which elevated custom administrative group privileges are required by the custom group by repeatedly testing Active Directory, NT file system (NTFS), and the registry keys.
b.This level of testing ensures that excess privileges are not assigned.
3.Determine if the necessary administrative rights can be delegated.
a.If administrative delegation is supported, develop the OU design to facilitate delegation of administration to all objects, to specific objects only, or for specific attributes only.
4.Determine what objects are accessed by the permissions.
a.This helps set the DACL on these objects to permit the newly created group to access the object with the necessary permissions.
5.Create a domain local group that will be assigned the desired permissions and rights.
a.Test the designed permissions and rights by creating a user account that is a member of the newly created domain local group only.
b.This procedure does not allow other group memberships to affect the testing of rights and permission assignments.
|16|C.Applying the decision: creating custom administrative groups at Hanson Brothers
1.Help desk personnel
a.Create a custom domain local group containing all staff members that work at the help desk.
b.The custom group can reset passwords and clear the account lockout attribute for all user accounts.
c.Delegation is performed at the hansonbrothers.tld domain.
2.Human Resources
a.Create a custom domain local group for members of the Human Resources department.
b.The custom group can modify all HR-related attributes, such as addresses and home phone numbers.
3.BoiseAdmins and CalgaryAdmins
a.Create a custom domain local group for the administrators at each office.
b.The custom group can manage both user and computer objects.
4.BackupsAdmins
a.This group is assigned the user right to Backup Files And Directories.
b.If backup is required only to DCs, then the user right must be applied at the Domain Controllers OU.
c.If backup to all Windows 2000–based computers is required, then this user right must be assigned at both the Domain Controllers OU and at the domain.
5.RestoreAdmins
a.This group is assigned the user right to Restore Files And Directories.
b.If restoring backup data to any Windows 2000–based computer in the network is required, this user right must be assigned at both the domain and the Domain Controllers OU.
Chapter 4, Lesson 2
|17|Securing Administrative Access to the Network
1.Designing Secure Administrative Access
|18|A.Administrative access methods
|19|1.Requiring smart card logon
a.Use smart cards to restrict logon to a specific management location.
b.Only management stations have the necessary smart card reader.
c.Access to the smart card should be guarded.
(1)It can be locked in a safe that requires two people to open the safe.
(2)It can require two people to access the PIN to unlock the private key.
d.Logon can be restricted to require a smart card for authentication.
|20|2.Restricting which workstation administrators can log on to
a.This option requires NetBIOS support on the network, but it can restrict logon to specific management stations using NetBIOS.
b.If logon is attempted from a different location, the logon attempt will fail.
c.Locate these workstations in a restricted part of the office.
3.Configuring logon hours
a.Administration accounts can be restricted to usage only at specific hours.
b.Restrict usage when business policy requires that specific administrative tasks must take place at specific times of day.
4.Enforcing strong passwords
a.Make certain that the administrator accounts use complex passwords that are changed frequently.
b.The administrator accounts should use a more restrictive password policy than typical user accounts.
(1)Enforced through domain account policy, which affects all users of the network.
5.Renaming the default administrator account
a.Renaming prevents an attacker from guessing that the administrator account is named Administrator.
b.The attacker must first determine the administrator’s account name before attempting to guess the password.
|21|B.Making the decision: securing administrative access
1.Restrict administrative access to specific workstations.
a.Implement restrictions so that only specific workstations can be used by administrative accounts.
b.Implement smart card authentication for administrative accounts, and install smart card readers at desired workstations only.
2.Protect administrative passwords.
a.Manually implement complex passwords for the administrator account that exceed the domain account policy.
b.Implement smart card logon that does not expose the actual password of the administrator account.
3.Protect the administrator account from being compromised.
a.Rename the administrator account.
b.Do not use easily guessed account names.
c.Do not leave the administrator account logged on at a workstation.
d.Require smart card logon for the administrator account and store the smart card in a restricted location such as a safe.
e.Do not make day-to-day accounts administrators of the network.
f.Require that each administrator have a day-to-day account for normal network access.
|22|C.Applying the decision: securing administrative access at Hanson Brothers
1.Rename the administrator account.
a.Never use default accounts that ship with the OS because the administrator account has the most rights on the network.
b.Renaming the administrator account reduces the potential of that account being used to attack the network.
2.Create dedicated administrative accounts.
a.Dedicated administrative accounts can be created to perform administrative tasks.
b.Ensure these accounts are recognizable on the network.
3.Protect administrative accounts.
a.Restrict the use of Domain Admins, Administrators, or Enterprise Admins groups to specific workstations, or require a smart card for logon.
|23|2.Designing Secondary Access
A.Understanding the RunAs service
1.Allows users to launch processes under a different security context
2.While users remain logged on using their normal day-to-day account, the process launched using the RunAs service runs under the security context of the provided user account.
3.Use an account with the required administrative privileges on the network.
4.Several methods can be used to launch a process by using the RunAs service.
a.Hold the Shift key while right-clicking a shortcut.
b.Use the RunAs command at a command prompt.
c.Create administrative scripts.
d.Change the properties of a shortcut.
|24|B.Making the decision: implementing the RunAs service
1.The RunAs service does not provide facilities for smart card logon.
a.The account used to authenticate with the RunAs service cannot require smart card logon.
b.All credentials must be manually typed into the RunAs interface because it does not provide support for insertion of a smart card.
2.There are several ways to launch the RunAs service.
a.Launch the RunAs service from the command prompt, a shortcut’s properties, or by right-clicking a shortcut and selecting RunAs.
b.The result is the same, no matter which method is chosen.
3.Use a standard prefix for administrative accounts.
a.Administrative accounts with standard prefixes are easily recognizable when they are in use on the network simply by observing the user’s logon name.
4.Create a usage policy for administrative accounts on the network.
a.Ensure that administrative accounts are not used for day-to-day activities and are restricted to performing administrative tasks.
|25|C.Applying the decision: implementing the RunAs service at Hanson Brothers
1.Administrative tasks can be performed without logging on to the administrative account.
2.Define a policy whereby all administrative users must use the RunAs service to launch administrative tasks.
3.Ensure that no administrative users require smart card logon because the RunAs service does not support smart cards.
|26|3.Designing Telnet Administration
A.Overview
1.Windows 2000 includes the Telnet Service to perform remote administration from the command line.
2.Telnet Service can only be used to run text-based utilities such as scripts and batch files.
3.Use the RunAs command or Terminal Services to run utilities requiring GUI interfaces.
4.By default, Telnet uses clear text for transmitting authentication and screen data.
5.Protect authentication credentials by configuring the Telnet Service to use NT Lan Manager (NTLM) authentication, although this can exclude UNIX clients from accessing the Telnet service.
6.To protect all data in Telnet sessions, configure IPSec to encrypt all data transmitted between the Telnet client and Telnet Server Service.
a.To protect data, create an IPSec filter that will require encryption for all connections to TCP port 23 on the Telnet Server.
b.By using IPSec Encapsulating Security Payload (ESP), all data transmitted between the client and server are encrypted.
c.The use of IPSec does not require a modified Telnet client.
|27|B.Making the decision: implementing Telnet Service
1.All management commands can be performed from a text-based utility.
a.Includes script files, batch files, and management utilities such as netsh.exe and netdiag.exe
2.Consider using NTLM authentication to protect the authentication credentials transmitted to the Telnet Services.
a.NTLM can only be used by clients that can support the NTLM protocol for authentication.
b.Using NTLM authentication excludes UNIX clients from using Telnet.
c.The Telnet server can be configured either to use clear-text authentication, to use NTLM authentication, or to first attempt NTLM authentication and then revert back to clear-text authentication if required.
3.Use IPSec to encrypt all data transmitted between the client and server .
a.NTLM protects only the credentials provided during authentication.
(1)All other information is passed as clear text across the network.
|28|C.Applying the decision: implementing Telnet Service at Hanson Brothers
1.Telnet can be used only for text-based utilities.
2.Telnet must not be configured to use NTLM for authentication because one administrator is using a UNIX SPARC workstation.
3.IPSec must be configured to encrypt all administrative Telnet sessions.
|29|4.Designing Terminal Services Administration
A.Assessing Terminal Services administration
|30|1.Application mode
a.Allows multiple connections by regular user accounts that have been granted Terminal Service access in Active Directory Users And Computers.
b.Additional security can be configured by applying the Notssid.inf security template, which removes the Terminal Services ID (TSInternetUser) from all DACLs.
(1)TSInternetUser is normally used to ensure that all Terminal Service users can access particular resources.
(2)Access is based on the individual user accounts of the Terminal Services users instead of a common SID for all Terminal Service users.
|31|2.Remote Administration mode
a.Configure Terminal Services to run in Remote Administration mode.
b.Limits connections to two concurrent connections
c.Only members of the Administrators group are allowed to connect to the terminal server.
|32|B.Making the decision: using Terminal Services administration
1.Limit which utilities can be run by a Terminal Services client.
a.Create a custom desktop and Start menu profile that will be used by the Terminal Services client.
2.Restrict access to Terminal Services to administrative personnel only.
a.Configure Terminal Services to use Remote Administration mode to restrict access to only the members of the Administrators group.
3.Secure transmission of data between the Terminal Services client and the Terminal Server.
a.Configure the encryption level for the Terminal Services session to be medium or high.
(1)High security uses 128-bit encryption.
(2)Medium encryption uses either 40-bit or 56-bit encryption, depending on the client.
4.Prevent excess rights to DCs.
a.Do not install Terminal Services on a domain controller.
b.This requires that the Terminal Services users have the Logon Locally right, which means that they can log on locally at all domain controllers.
5.Determine Terminal Services access based on individual user permissions.
a.Apply the Notssid.inf security configuration template.
6.Allow access to Terminal Services from the widest range of platforms.
a.Install Terminal Services Advanced Client on a Web server to allow all Microsoft Internet Explorer clients to connect to the terminal server by downloading the ActiveX control that allows access to the terminal server.
|33|C.Applying the decision: implementing Terminal Services at Hanson Brothers
1.Restrict Terminal Services to administrators by using Remote Administration mode.
2.Deploy Terminal Services Advanced Client to allow clients running other OSs, but using Internet Explorer, to perform administrative tasks on the Windows 2000 domain.
3.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 secure administrative access
Designing secondary access
Designing Telnet administration
Designing Terminal Services administration
Outline, Chapter 41
Designing Microsoft Windows 2000 Network Security