Secure System Administration Environments

The last thing that we need to look at when considering Terminal Server security is how your servers will be administered. This is often overlooked, but very important. Even the world's most technically secure environments won't actually be secure if too many people have administrative rights.

Another important part of the administration of your Terminal Servers relates to how the servers are actually used, including how administrators or help desk personnel shadow end users and how everyone's actions are logged, recorded, and audited.

As we look at the security of the Terminal Server administrative environment, we'll focus on two areas:

• Remote controlling users.

• Auditing and usage logs.

Session Remote Control

Terminal Server session Remote Control allows administrators to remotely view a selected end user's RDP session. There are several security and privacy concerns raised when deciding how to use shadowing stemming from the fact that a malicious user could shadow another user's session without him knowing it. He would potentially be able to view sensitive or personal information.

To mitigate this security risk, you have the option of choosing not to enable any of the remote control features or choosing to manage the remote control environment so that only authorized users are able to remote control other users. Let's look at how this can be applied in the real world.

Choosing not to Enable Remote Control

If remote control poses a great security risk in your environment, you can disable it at the connection listener port. This is the easiest way to prohibit remote control on a single server. If you have multiple servers, you can also disable remote control via a Group Policy.

Remote Control Rights

You also have the ability to configure which users are able to remote control other users.

You can give a user the ability to remotely control another user as part of his user account properties (AD Users and Computers | Double-click user account | Remote Control tab | Enable Remote Control).

Furthermore, you can configure granular remote control permissions at the connection level (Terminal Services Configuration | Connections | Double-click connection | Permissions tab). Anyone with "Full Control" permissions on that connection listener will be able to remote control other users. If you want users to be able to remote control other users without giving them full control of the connection (helpdesk users, for example), then add their group and click the "Advanced" button to give them the remote control right without giving them other rights.

Remote Controller / Controllee Interaction

Even with permissions to remote control users, there are two additional parameters that can be configured, "Require User's Permission" and "Level of Control."

Checking the "Require User's Permission" box will cause a message box to be displayed in a user's session before the remote control session starts. The user has to grant permission to the remote controller.

The "Level of Control" option lets you configure whether the person doing the remote controlling has the ability to interact with the remote session by using the keyboard and mouse, or whether they are just able to observe the remote session.

You can configure these remote control settings as part as a user account, GPO, or a connection listener property. You'll remember from Chapter 6 that GPOs always take precedence over user account settings. Beyond that, the most restrictive setting will apply if there is a conflict between the user account/GPO setting and the connection listener port setting.

User Auditing

Often Terminal Server administrators want to be able to create log files that they can use to audit specific Terminal Server user events, such as user session logons and logoffs. There are two ways that audit logs can be created:

• Windows user account auditing.

• Third party auditing and logging tools.

Logging Users with Windows Auditing

For simple user logging, it's best to think back to your Windows Administration 101 class.

In Windows 2000/2003 environments, auditing can be configured via a group policy in Active Directory environments (Group Policy Object | Computer Configuration | Windows Settings | Security Settings | Local Policies | Audit Policy), or via the local computer policy when group policies are not used (Administrative Tools | Local Security Settings | Local Policies | Audit Policy). When Active Directory is used, most people configure the audit policies for the Group Policy Object that has the OU that contains their MetaFrame XP servers.

You can configure auditing for any item (file, directory, etc.) via the audit dialog box (Item Properties | Security Tab | Advanced Button | Audit Tab).

You can also enable auditing of Terminal Server-specific activities at the connection level (Terminal Services Configuration | Connections | Double-click connection | Permissions tab | Advanced button | Auditing tab). Just add your user or group there, and configure whether you want to audit the success or failure of any Terminal Server activity on that connection.

All of the Windows audit events will appear in the security event log.

Logging Users with Third Party Tools

If you need heavy duty security auditing and logging in your Terminal Server environment, you'll probably be disappointed with the native components that are available from Microsoft. Fortunately, there are several third-party auditing tools available. Some of the most popular include Techtonik ONEapp (www.oneapp.co.uk) and Lakeside Software's Systrack (www.lakesidesoftware.com). New information about these and other third party tools is constantly available at www.brianmadden.com.