Once you've designed the groups that will be allowed to perform administrative tasks on your network, the next phase of your security plan is to design how these administrative accounts may be used on the network. This includes planning restrictions on the use of administrative accounts and planning methods that can be used to allow administrative access.
After this lesson, you will be able to
Estimated lesson time: 30 minutes
You can use several methods to secure how administrators can access the network. These include
In a high-security network, you can use the decision matrix shown in Table 4.5 to restrict administrative access to the network.
Table 4.5 Restricting Administrative Access
|To||Do the Following|
|Restrict administrative access to specific workstations|
Implement workstation restrictions so that only specific workstations can be used by administrative accounts.
Implement smart card authentication for administrative accounts and install smart card readers only at desired workstations.
|Protect administrative passwords|
Manually implement complex passwords for the administrator account that exceed the domain account policy.
Implement smart card logon that doesn't expose the password of the administrator account.
|Protect the administrator account from being compromised|
Rename the administrator account. Don't use easily guessed accounts.
Don't leave the administrator account logged on at a workstation.
Require smart card logon for the administrator account and store the smart card in a restricted location, such as a safe.
Don't make day-to-day accounts administrators of the network. Require that each administrator have a day-to-day account for normal network access.
Hanson Brothers can take several actions to secure administrative access to their network. These include
Maintaining an Alternative Administrator Account
In some networks, after the Administrator account is renamed, a network administrator will create a new account named Administrator. But instead of having administrative rights on the network, this account is only a member of the Domain Guest group. By mixing the creation of a nonadministrative Administrator account with a strategy of auditing account logon failures and successes, you can determine if someone is attempting to use the Administrator account.
Figure 4.6 Restricting administrators to a specific computer by workstation restrictions or by requiring smart card logon
The default Administrator account can't be restricted to specific workstations or required to use a smart card for logon. To protect this account, a complex password must be implemented along with additional security processes, such as storage of the password in a location like a central safe in the IT department.
Windows 2000 allows administrative tasks to be launched at a higher security level than the current user's account. This is done by providing alternate credentials to the RunAs service when launching the administrative tasks.
The RunAs service allows you to launch processes under a different security context. While the user remains logged on using her normal day-to-day account, the process that she launches using the RunAs service runs under the security context of the provided user account. Typically, this account is one with the required administrative privileges on the network.
You can use several methods to launch a process by using the RunAs service. These include
Figure 4.7 Providing alternative credentials when running an application
RUNAS /user:UserName program
For example, if you wished to launch Active Directory Users And Computers under the security context of administrator of the domain nwtraders.tld, you would use the following command:
RUNAS /user:email@example.com "mmc c:\winnt\system32\dsa.msc"
The RunAs service would then prompt you for the firstname.lastname@example.org account password before launching the Active Directory Users And Computers console.
Figure 4.8 Configuring a shortcut to use alternative credentials
To distinguish administrator accounts from everyday accounts, you can require all administrator accounts to use a prefix such as a_. For example, if my day-to-day account is johndoe, then my matching administrative account would be a_johndoe. This allows for auditing to determine which administrator performed the task.
If tasks are launched using the RunAs service, you can determine which security context an application is running in by using the Microsoft Windows 2000 Resource Kit utility Pulist.exe. This displays a list of current running processes and the user account used to launch each process. Alternatively, if Terminal Service is loaded, you can configure the Task Manager to display the username column to show the security context of each running process.
If you plan to implement the RunAs service to allow processes to be run under alternative security credentials, you must include the following considerations in your security design:
Hanson Brothers could define a policy requiring all users with administrative accounts on the network to use the RunAs service to launch administrative tasks rather than logging on directly to the network. Because the process then runs in the security context of the administrative task, the task can be performed without having to log off the network and then log on using the administrative account.
The only scenario where this wouldn't work would be any administrative accounts that are defined to require smart card logon. If an account is defined to require smart card logon, it can't be used for the RunAs service. This is because the interface for the RunAs service doesn't support the use of smart cards.
Some tasks can be performed from a command prompt. To allow remote administration using these command line tools, you can use the Telnet Service that ships with Windows 2000. You can use the Telnet Service only to run text-based utilities such as scripts and batch files. If the utility requires a graphical interface, you must deploy alternative methods, such as RunAs or Terminal Services.
Your security plan must take into account that Telnet uses clear text for the transmission of authentication and screen data by default. In Windows 2000 you can protect authentication credentials by configuring the Telnet Service to use NTLM authentication. This protects the password used to access the Telnet service but restricts access to the Telnet Service and prevents UNIX clients from accessing the service.
To protect all data in the Telnet sessions, you must configure IPSec to encrypt all data transmitted between the client workstation running the Telnet client and the Telnet Service. You do this by creating an IPSec filter that requires encryption for all connections to TCP port 23 on the Telnet Server. By using IPSec Encapsulating Security Payloads (ESP), you can encrypt all data transmitted between the client and the server. This doesn't require a modified Telnet client.
You can't use Telnet administration in all circumstances. Remember that Telnet assumes that text-based administration is taking place. When you design administrative access by using Telnet, use the following considerations when you make your security plan:
You can configure Telnet authentication methods by using Telnet Server Administration from Administrative Tools. Within the tool you can configure the Telnet server to use either clear-text authentication, NTLM authentication, or to first attempt NTLM authentication but fall back to clear text if required.
Hanson Brothers can use Telnet for network administration only in specific cases. As discussed, Telnet can be used only for text-based utilities. The Microsoft Windows 2000 Server Resource Kit does provide several utilities that you can use to manage Windows 2000 services from the command line. These include Netsh and Dnscmd.
For Hanson Brothers, the Telnet service must not be configured to use NTLM for authentication. This is because there's an administrator who uses a UNIX SPARC workstation, which won't support NTLM authentication. If additional security were required for administration from this station, IPSec would be required to encrypt all Telnet transmissions to and from the Telnet server where the administration takes place.
You can install Terminal Services on a Windows 2000 Server to allow administration of a computer from a remote location. The Terminal Services session provides a virtual desktop that's running within the memory space of the server hosting the Terminal Services session.
The advantage of Terminal Services over other methods of remote administration is that the client computer doesn't have to be running the Windows 2000 operating system. Windows 95, Windows 98, and Windows NT clients can all be used to run the Terminal Services Client. In addition, Microsoft released the Terminal Services Advanced Client around the same time as the Windows 2000 Service Pack 1. This ActiveX control allows clients running Microsoft Internet Explorer to connect to a terminal server without loading any client software locally.
You can download the Terminal Services Advanced Client by going to http://www.microsoft.com and searching for "Terminal Services Advanced Client."
You can install Terminal Services in one of two modes. Application mode allows multiple connections by regular user accounts (as long as they've been granted Terminal Service access in Active Directory Users And Computers). For remote administration, it's preferable to configure Terminal Services to run in Remote Administration mode.
Remote Administration mode has two key benefits when you're designing secure administration of the network. First, it's limited to only two concurrent connections. Second, only members of the Administrators group are allowed to connect to the terminal server. This ensures that only administrators of the network can utilize the terminal server.
If the terminal server must run in Application mode, you can configure additional security by applying the Notssid.inf security template, which removes the Terminal Services ID (TSInternetUser) from all DACLs. This user is normally used to ensure that all Terminal Services users can access particular resources. Rather than having a common SID that allows all Terminal Services users access to resources, access is instead based on the individual user accounts of the Terminal Services users. This ensures that security is based only on the individual user accounts and not on the state of the user.
When designing network administration by using Terminal Services, you can use Table 4.6 to finalize your security design for Terminal Service access.
Table 4.6 Securing Terminal Server Access
|To||Do the following|
|Limit what utilities can be run by a Terminal Services client|
Create a custom desktop and Start menu profile that will be used by the Terminal Service client.
|Restrict access to Terminal Services to only administrative personnel|
Configure Terminal Services to use Remote Administration mode. This restricts access to only the members of the Administrators group.
|Secure transmission of data between the Terminal Services client and the terminal server|
Configure the encryption level for the Terminal Services session to be medium or high security. Both medium and high security ensure that data is encrypted in both directions between the client and the server. High security utilizes 128-bit encryption, while medium encryption uses either 40-bit or 56-bit encryption, depending on the client.
|Determine Terminal Service access based on individual user permissions|
Apply the Notssid.inf security configuration template to the terminal server.
|Prevent excess rights to DCs|
Don't install Terminal Services on a DC. This requires the Terminal Service users to have the Logon Locally right, which means that they can log on locally at all DCs.
|Allow access to Terminal Services from the widest range of platforms|
Install the Terminal Services Advanced Client on a Web server to allow all Internet Explorer clients to connect to the terminal server by downloading the ActiveX control that allows access to the terminal server.
For Hanson Brothers, Terminal Services could be restricted to administrators of the network by configuring Terminal Service to use Remote Administration mode. This restricts Terminal Services to only members of the Administrators domain local group.
The other advantage of Terminal Services is that the new Terminal Services Advanced Client could be deployed. This would allow clients running other operating systems (but using Internet Explorer) to perform administrative tasks on the Windows 2000 domain from the alternative client operating system computer. This would be another alternative to providing administrative capabilities to the administrator using a UNIX SPARC workstation.
The only accounts that couldn't be used in the Terminal Services client would be administrative accounts that are required to use smart cards for authentication. Smart card authentication isn't supported for Terminal Services.
The task of designing network administration involves not only deciding who will be an administrator of the network, but also restricting where administration can take place on the network.
Depending on the methods that you allow for network administration, you can restrict administration tasks to specific utilities, such as Terminal Services or Telnet Services.