Alteration in Terminal Server's Listening Port

As I have described earlier about Application Server Security that is securing your Terminal Servers now will describe how to alter listening port of your Server.

It is a well-known fact that TCP port 3389 is used by Terminal Server and Windows 2000 Terminal Services for client connections. Alteration in this port is not recommended by Microsoft. But you can change this port. You have to perform this task carefully, otherwise you will face serious problems.

• You have to give more concentration while modifying the registry. If you want to change the default port, then you have to follow these steps:


• You start with the task of running Regedt32 and go to this key, HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp.


• Then you have to find the port number subkey and notice the value of 00000D3D, hex is for 3389.


• After this, you have to change the port number in Hex and save the new value

If you want to change the port for a particular connection on the Terminal Server, then follow these steps:

• You have to run Regedt32 and go to this key, HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\connection.


• After this, you have to find the port number subkey and notice the value of 00000D3D, here hex is for 3389.


• Then you have to change the port number in Hex and save this new value.


• After performing this, you have to make alteration in the Port on the Client Side.

Follow these steps to perform this:

• You have to open Client Connection Manager.


• Then on the File menu, click on New Connection and then create the new connection. After executing the wizard, you will view a new connection listed there.


• Then you have to ensure that new connection is highlighted. After this, on the File menu, click Export.


• Then you have to edit the .cns file using Notepad. You have to make modifications in the server port, Server Port=3389 to Server Port= new port number, that you had specified on Terminal Server.


• Now import the file back into Client Connection Manager. Then you will be demanded to overwrite the current one.


• If it has the same name, then overwrite it.

In this way, you will receive a client that has the correct port settings to match your Terminal Server settings. Hope it will help you out, Don’t Forget to subscribe to my blog for more tips and tricks on server and Microsoft Server Support Services

Terminal Server Application Server Security

Since the actual user sessions are executed on the Terminal Servers, they figure greater into a discussion of security. The basic actions to consider when securing your Terminal Servers are:

* Using the NTFS file system.
* Configuring NTFS file permissions.
* Using GPOs to secure the user environment.
* Installing Terminal Services on a domain controller.
* Disabling the "Secondary Logon" Service.
* Remove unnecessary software
* Applying hotfixes and service packs.

Use the NTFS File System

Each user that runs a session on a Terminal Server is essentially running a remote control console session. Without an NTFS file system, you won't be able to set any file-level security permissions. Any user that is logged would be able to access files in use by other users. No mechanism would prevent users from deleting key system files, potentially crashing the server!

There is no reason not to use NTFS on your servers. Every user will be able to access NTFS files via an RDP session, even if his client is running on an operating system that cannot support NTFS, such as Windows 95.

Configure NTFS File Permissions

Using just the NTFS file system might not provide enough security with its default permissions in your environment. Even if you do not intend to fully lock-down your Terminal Servers or plan to run only initial applications, you should secure the basic file system.

When you install Terminal Services on a Windows 2003 server, you're asked whether you want to use "Full Security" or "Relaxed Security." This security setting has nothing to do with your domain configuration or your Active Directory environment. It affects only the level of security that users are given when they access your server via a Terminal Services session. To compare the two settings:

* Full Security. This setting results in Terminal Services users having the same permissions as regular members of the local users group. Regular users are not able to write to inappropriate registry keys or tamper with sensitive system files. Of course, with this level of security comes additional risk. In this case, users will sometimes not be able to run legacy applications. If you choose Full Security, you should thoroughly test your applications before enabling them for any users.
* Relaxed Security This setting results in Terminal Services users having full access to many parts of the registry and many of the system files. This alternate level of security was developed to allow older applications to execute properly.

After selecting the "permissions compatibility" mode during the installation of Terminal Services you can change it at any time via the Terminal Services Configuration MMC snap-in (Administrative Tools | Terminal Services Configuration | Server Settings | Permissions Compatibility). Setting this compatibility affects the following registry key:

Key: HKLM\System\CurrentControlSet\Control\Terminal Server\

Value: TSUserEnabled

Type: REG_DWORD

Data: 1 = Relaxed permissions. 0 = Full Security mode.
Do Not Install Terminal Services on a Domain Controller

Individual domain controllers cannot be managed separately from each other. In order for a user to be able to log on to Terminal Server sessions she must have "log on locally" (called "log on interactively" in Windows 2000) rights. If the Terminal Server is a domain controller, granting the user "log on locally" rights on the server will allow her to log on to any domain controller, even ones that are not Terminal Servers.

Also, domain controllers in Active Directory environments must be located in the "Domain Controllers" OU. You can't use OU-based Group Policy Objects if your Terminal Servers are installed on domain controllers.

Disable the "Secondary Logon" Service

Windows 2000 introduced a secondary logon ability (then called the "Run As" service) which allows users to run programs with different user rights. Within Windows Explorer, a user can shift-right-click on a file and select "Run as..." from the context menu. Alternately, a user can enter the "runas" command into the command line.

Administrators often lock down Terminal Servers for those groups of users that should be using them. The secondary logon ability allows a user who's already connected to a Terminal Server to change his credentials, potentially bypassing any security measures the administrator has configured. (If you read the rest of this chapter, you'll know better than to build servers that exhibit this weakness.)

The secondary logon ability can be disabled at the server by stopping and disabling the "Secondary Logon" service. Disable the service after you stop it, or the system will start it again when it is needed.

Remove all Non-Essential Software

Any extra applications installed on your Terminal Servers represent an increased security risk. Each installed application brings introduces more vulnerabilities. Access to extra tools, (such as those included in the resource kits) makes compromising or abusing the server easier. You shouldn't give your users more than they need to do their job.

Source: http://www.brianmadden.com/blogs/terminal_services_for_microsoft_windows_server_2003_advanced_technical_design_guide/pages/server-security.aspx