Lesson 2: Securing Administrative Access to the Network | MCSE Training Kit (Exam 70-220): Designing Microsoft Windows 2000 Network Security: Designing Microsoft(r) Windows(r) 2000 Network Security (IT-Training Kits)

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

Plan methods for administrators to access the network and securely perform administrative tasks

Estimated lesson time: 30 minutes

Designing Secure Administrative Access

You can use several methods to secure how administrators can access the network. These include

Requiring smart card logon. You can use smart cards to restrict logon to a specific management location. Only management stations will have the necessary smart card reader. You can lock the smart card in a safe that requires two people to open it to access the smart card or to access the PIN for the smart card for unlocking the private key on the card. You can also restrict logon to require a smart card for authentication in the user account's properties.
Restricting which workstation administrators can log on to. This option requires that NetBIOS is supported on the network, but it can restrict logon to specific management stations using NetBIOS. If logon is attempted from a different location, the logon attempt will fail. These workstations can be located in a restricted part of the office.
Configuring logon hours. You can restrict an administration account to usage only at specific hours. You can do this when policy requires that specific administrative tasks must take place at specific times. For example, the addition of new domains in the forest must take place after business hours so it won't affect bandwidth due to initial replication to the new domain.
Renaming the default administrator account. While not the utmost in security, this prevents an attacker from guessing that the administrator account is named Administrator. This ensures that if an attacker is attempting to compromise the administrator account, they must determine the account name before attempting to guess the password.
Enforcing strong passwords. Make sure that the administrator accounts use complex passwords. You could enforce this through domain account policy, but that would affect all users of the network. In general, administrator accounts should use a more restrictive password policy than typical user accounts. One organization uses a password for the admin account that's more than 30 characters long, uses a mix of uppercase, lowercase, and symbols, and is changed every 30 days.

Making the Decision

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.

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.

Applying the Decision

Hanson Brothers can take several actions to secure administrative access to their network. These include

Renaming the Administrator account. A common attack that's performed against networks is to use default accounts that ship with the operating system. For example, the Administrator account has the most rights in a Windows 2000 network. By renaming the Administrator account, you can reduce the chance that the Administrator account will be used to attack the network.
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.
Creating dedicated administrative accounts.Rather than assigning the day-to-day user accounts for the six administrators into the administrative groups on the network, you can create dedicated administrative accounts that are used to perform administrative tasks. To ensure that these accounts are recognizable on the network, you could create the accounts using a common prefix, such as "a_". For example, you could create two accounts for Steve Master: smaster for day-to-day activities and a_smaster for administrative tasks.
Protecting administrative accounts.If additional administrative accounts are added to the Domain Admins, Administrators, or Enterprise Admins groups, further restriction can be made to limit use of these accounts to specific workstations. Restrictions can include restricting the account to specific administrative workstations or requiring a smart card for logon, as shown in Figure 4.6.

Figure 4.6 Restricting administrators to a specific computer by workstation restrictions or by requiring smart card logon

NOTE
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.

Designing Secondary Access

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.

Understanding the RunAs Service

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

Holding the Shift key while right-clicking a shortcut. This enables the RunAs option on the pop-up menu. The user can then provide alternative credentials for running the application, as shown in Figure 4.7.

Figure 4.7 Providing alternative credentials when running an application
Using the RUNAS command at a command prompt. The RUNAS command allows you to provide both the alternative credentials and the application that you wish to run using the alternative credentials. The syntax of the command is as follows:
```
 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:administrator@nwtraders.tld "mmc c:\winnt\system32\dsa.msc" 
```
The RunAs service would then prompt you for the administrator@nwtraders.tld account password before launching the Active Directory Users And Computers console.
Creating administrative scripts. You can create administrative scripts that launch administrative processes at a higher security context. To further secure these scripts, you can protect access to them by configuring the DACLs on the scripts to allow only approved users to access the scripts.
Changing a shortcut's properties. Within the property pages of a shortcut, you can configure the shortcut to Run As A Different User, as shown in Figure 4.8. This action brings up the Run As Another User dialog box and allows you to provide alternative credentials.

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.

NOTE
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.

Making the Decision

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:

The RunAs service doesn't provide facilities for smart card logon. The account used to authenticate with the RunAs service can't require smart card logon because the RunAs interface doesn't provide support for the insert of a smart card. All credentials must be manually typed into the interface.
There is more than one way to launch the RunAs service. The RunAs service can be launched either from the command prompt, a shortcut's properties, or by right-clicking a shortcut and selecting RunAs from the pop-up menu. You and all other administrators must determine the method that works best. Remember that whatever method you choose, the final result is the same.
Use a standard prefix for administrative accounts. If you use a standard prefix for administrative accounts, the administrative accounts can be recognized when they're used on the network simply by inspecting the user's logon name.
Create a policy for the usage of administrative accounts on the network. Ensure that administrative accounts aren't used for day-to-day activities and are restricted to performing administrative tasks.

Applying the Decision

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.

Designing Telnet Administration

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.

Making the Decision

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:

All management commands can be performed from a text-based utility. This includes script files, batch files, and management utilities such as Netsh.exe and Netdiag.exe.
You can use NTLM authentication to protect the authentication credentials when transmitted to the Telnet Services. NTLM can only be used by clients that support the NTLM protocol for authentication. This can exclude UNIX clients from using Telnet.
NOTE
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.
Use IPSec to encrypt all data transmitted between the client and server to prevent inspection of the data as it's transmitted. Remember that the use of NTLM only protects the credentials provided during authentication. All other information entered into the Telnet session is passed in clear text across the network.

Applying the Decision

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.

Designing Terminal Services Administration

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.

NOTE
You can download the Terminal Services Advanced Client by going to http://www.microsoft.com and searching for "Terminal Services Advanced Client."

Assessing Terminal Services Administration

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.

Making the Decision

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.

Applying the Decision

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.

NOTE
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.

Lesson Summary

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.