Posted: 24 Aug 2005

This article addresses a specific need that some network administrators experience. Many organizations run Windows Terminal Services to extend applications outside the local area network (LAN), or even to provide certain applications within the LAN on a controlled OS platform. In many cases, the Windows Terminal Servers that are running the applications need to operate within the existing Novell file and print services environment. And in some implementations, that means installing and configuring the Novell client on the Windows Terminal Server(s).

As an example of this, let's say that an organization has a program that runs as a client-server application with a database or shared files stored on a NetWare server, and the client portion runs on individual workstations. The users need Novell (eDirectory) authentication to access the database files, as well as whatever authentication is provided within the database application. This can apply whether there is a database engine running on the NetWare platform ("true" client-server), or if only network file access is required ("dumb" database).

The application was designed to run on the LAN, but now, with increasing demand to "work from anywhere", we wish to now extend the application's availability to workers outside the LAN. Enter Windows Terminal Services. We build our Terminal Server environment, and install the application on the Terminal Servers, and to provide Novell authentication and access to the NetWare server-stored databases or files, we install and configure the Novell client on the Terminal Servers.

Access Decisions

Early on in the design and planning of this type of solution, decisions have to be made regarding the degree of access we intend to give the end users within the Terminal Services environment, as well as within the NetWare environment to which they will secondarily connect. Many articles have been written on the subject of locking down Terminal Services, but here I would like to focus on the specifics of configuring the Novell client for the type of Terminal Server access as per our example.

One level of access that many organizations provide for Terminal Services might be classified as "robust". The Terminal Services provide a fully-functional Windows desktop environment for the user, and the Novell client provides the exact level of NetWare server access – mapped drives, network applications, etc. – that the user would have if they were logging in at the office with their own PC.

The robust access strategy is undoubtedly the easiest to setup, once the Terminal Services environment and licensing is correctly installed. In terms of the Novell client, there is not much difference in the way it is installed on a regular PC, and the way it would be installed on the Terminal Server. Most of the focus on restricting access will be on the Terminal Server environment (obviously, you wouldn't want end users having the ability to reboot the server, or make system configuration changes).

However, for many organizations, this "robust" access model for Terminal Services is not an acceptable solution, from a security standpoint. Having LAN access to network resources generally requires that two hurdles be crossed: first, locality, and second, password security. That is, you first have to access a PC that is directly connected to the LAN (or the private WAN, for multi-site networks), and then you have to provide a correct username and password combination to access the network resources.

Windows Terminal Services can extend your LAN to the world at large, when the Terminal Server becomes the "PC" connected to LAN. Users can now open a Windows terminal session, and thus login from potentially anywhere on the Internet. While this capability opens new opportunities for "work from anywhere" productivity, it also nullifies the first traditional security hurdle: locality. This can leave many network administrators and security personnel feeling exposed, now relying entirely on password security to protect the network from any malicious intrusion.

As an alternative to providing "robust" Terminal Services access to end users, many network administrators opt to provide very specific application access to limit the Terminal Services experience – and thus limit a user's exposure to the local network as well.

Limiting Terminal Services access to specific applications can be done with the proper configuration within Terminal Services itself, and is enhanced with additional products such as Citrix Presentation Server. But when the Novell client is used on the Terminal Server, some judicious settings in the Novell client configuration can also help to limit user access to only those applications and resources that are required.

Configuring the Novell Client

Very often a particular application is used by a particular group within an organization, rather than by all users in general. And very often those users are members of a specific department or workgroup, which is reflected by a context container in eDirectory, such as "Marketing", or "ITStaff". If that is so, then it makes sense to configure the Novell client on the Terminal Servers hosting that application to login specifically – and only – that that container. This is easily accomplished using the Location Profiles settings in the Novell client.

Under Novell Client Properties | Location Profiles | Login Service | Default | Properties:

De-select "Save profile after successful login" to prevent our standardized settings from being overwritten. On the "Credentials" tab, the Username should be blank, unless there is a need to pre-supply a generic username (usually considered a security risk). On the "NDS" tab, check Active Authenticator and the appropriate Tree and Context should be supplied. Sometimes, however, specifying the default server name is also considered a security risk.

On the "Script" tab, depending on the network environment needed for the application, you can select whether to Run scripts, Display results, etc. The "Windows" tab allows you to specify Windows login information according to your Windows environment. However, by default the Windows username is passed on from the supplied NDS username.

The Variables button on the "Script" tab allows you to pass variables to the login script execution, which can be handy. For example, you might want to differentiate between regular LAN users and Terminal Server users during the processing of a container login script. The regular users (on the LAN) might get a full complement of mapped network drives to multiple servers, while the Terminal Server users may need only to have specific drives mapped for a specific application.

This can be accomplished by setting a variable in the location profile, and then referencing that variable in the container login script. For example, we could set the "%2" variable to be "TERMINAL", and then in the container login script add a conditional loop that specifies something like:

IF "%2"="TERMINAL" THEN
  WRITE "GOOD %GREETING_TIME, %FULL_NAME."
  WRITE "You are logging into ACME using Terminal Server."
  MAP DISPLAY ON
  MAP ROOT F:=SERVER1APP:APP23
  MAP ROOT G:=SERVER1DATA:APP23DB
  GOTO ENDSCRIPT
END

The LAN users, not having that variable set, will skip this section and go on to map the normal drives specified in the container login script. The same users, logging into the Terminal server, however, will have the variable set, and will map these specific drives, and skip over processing the rest of the container login script.

Configuring Advanced Login Settings

The kind of Location Profile settings outlined above are not at all unusual, even for regular desktop PC configurations. But the point is that the more specifically we control the login process, the more we can limit the Terminal Server users to specific access to resources for specific applications. The Advanced Login settings give us even more opportunities to "lock down" the Novell client.

Under Novell Client Properties | Advanced Login:

The "Advanced Button" should be set to Off, to prevent the user from selecting any other tree, context or server than what we specified in the Location Profiles. Alternatively, there are some "child" settings under Advanced Login that affect the same things: the "Context Box", "Context Browse Button", "Tree Box" and the "Tree Browse Button" settings can be set to Off to prevent users from selecting a different tree or context. But these are irrelevant if the Advanced Button is already set to Off.

To prevent the user from bypassing Novell security, all of the "Workstation Only" settings should be set to Off, including the "Remember Workstation Only setting" setting.

Configuring Service Location Settings

In an IP-only network, the Novell client needs a way to resolve the eDirectory tree, context and server names to an actual IP address of a NetWare (eDirectory) server that can provide authentication. On a simple LAN, the client can send an IP broadcast to discover this information, but on a multisite WAN, the SLP scope and Directory Agents must be listed.

Under Novell Client Properties | Service Location:

Add the scope name and Directory Agent IP addresses (or DNS names)

Configuring Advanced Settings

Under Novell Client Properties | Advanced Settings:

Change the default setting (On) of "Set Station Time" to Off, since the Terminal Server user will not have the ability to set the system time on the Terminal Server.

Configuring Advanced Menu Settings

The Advanced Menu Settings page for the Novell client properties has the greatest number of settings that determine what the user can or cannot do, or view, using the Novell client.

Under Novell Client Properties | Advanced Menu Settings:

You may wish to set the "Show Novell System Tray Icon" setting to Off, effectively disabling a host of NetWare user administration options available from the system tray applet. Like the "Advanced Button" setting mentioned above, this acts as a "parent" to many "child" settings (such as "Enable Login Dialog") that many administrators would prefer not to have available within a Terminal session. Here is a full list of "child" settings that would be become unavailable:

Enable Login Dialog

Enable NetWare connections Dialog

Enable Map Dialog

Enable Disconnect Dialog

Enable Capture Dialog

Enable End Capture Dialog

Enable NetWare Utilities

Enable NetWare Copy Dialog

Enable Send Message Dialog

Enable Trustee Rights Dialog

Enable Inherited Rights Dialog

Enable Object Properties Dialog

Enable Salvage Dialog

Enable Purge Dialog

Show User Administration Menu

Enable NDS Personal Information

Enable NDS Work Information

Enable NDS Mailing Information

Show Edit Login Script Item

Enable Login Administration

Enable Password Administration

Enable Group Membership Dialog

Enable Browse To Dialog

Enable Systray Config Dialog

Enable Update Novell Client

Enable Novell Client Help

Enable Novell Client Properties

Note that disabling the Novell System Tray does not truly disable all of the above settings – it merely makes them unavailable to the user through the System Tray ("Red N") icon. To completely disable the various context menu options provided by the NetWare client (such as NetWare Copy, Novell Map Network Drive), you must specifically disable each feature setting.

Other settings that affect context-specific menu dialogs provided by the NetWare client are also in the Advanced Menu Settings:

Enable NetWare Copy Dialog

Enable Map Dialog

Enable Salvage Dialog

Enable Purge Dialog

Enable Trustee Rights Dialog

Enable Inherited Rights Dialog

The above settings (default: On) affect the options available in the context menu when a user right-clicks on any NetWare volume or mapped drive, as well as availability within the menu of the Novell System Tray icon (as above).

Enable Who Am I Dialog

Enable Logout of Server

Enable Logout of Tree

Enable Authenticate to Server

Enable Authenticate to Tree

These settings (default: On) similarly affect whether the above context menu items are available when a user right-clicks on a NetWare server or NDS tree in My Network Places (Network Neighborhood).

Enable Change Context Dialog

Enable NDS Login to Tree

Enable Set Current Tree

Enable Show Parent Context

Enable Set Default Context

The above settings (default: On) similarly affect whether those context menu items are available when a user right-clicks on an NDS tree or context in My Network Places (Network Neighborhood).

All of the above Advanced Menu Settings are set to On by default. Disabling all of these settings effectively disables all of the enhanced "Red N" features that the Novell client introduces into the Windows user interface.

Other Advanced Menu settings in the Novell client affect not what the users can do, but what information they can view from the Novell client:

Display Volume Information Page

Display Volume Statistics Page

Display NetWare Information Page

Display NetWare Rights Page

These settings (default: On) determine whether the user sees the four additional properties pages when they view Properties on any NetWare volume or mapped drive in a Windows Explorer window.

Display Bindery Services Page

Display Container Page

Display Directory Services Page

Display Server Page

Display Tree Page

The above settings (default: On) similarly affect whether the users see the properties pages they right-click and select Properties on an NDS tree, container or server in My Network Places (Network Neighborhood). When disabled, the user merely receives the message "The properties for this item are not available."

The typical modus operandi that network administrators use when trying to lock down access to any resource is to start locking down everything we think the users won't need to access. Then we start testing user access, and then incrementally we open up the access settings again, when we discover that it is locked down a little too tight.

For an exhaustive description of the Novell client settings and operation, see http://www.novell.com/coolsolutions/appnote/620.html.

Windows Group Policy Settings

Within Terminal Server, you can (and should) also use Group Policies to lock down the Terminal Server. It is highly recommended that you create a new organizational unit instead of modifying the policies on an existing one, since with the following settings, even the administrator account will have restricted access. These recommended settings are excerpted from Microsoft's support page under Q278295 (http://support.microsoft.com/default.aspx?scid=kb;en-us;278295).

Use Active Directory Users and Computers to create a new organizational unit (OU). Right-click the OU, click Properties, and then on the Group Policy tab, click New Policy.

Edit this policy by enabling all of the following settings:

[Computer ConfigurationAdmin TemplatesSystemGroup Policy]

User Group Policy loopback processing mode

[Computer ConfigurationWindows SettingsSecurity SettingsLocal PoliciesSecurity Options]

Do not display last user name in logon screen

Restrict CD-ROM access to locally logged-on user only

Restrict floppy access to locally logged-on user only

[Computer ConfigurationAdministrative TemplatesWindows ComponentsWindows Installer]

Disable Windows Installer

[User ConfigurationAdministrative TemplatesWindows ComponentsWindows Explorer]

Remove Map Network Drive and Disconnect Network Drive

Remove Search button from Windows Explorer

Disable Windows Explorer's default context menu

Hides the Manage item on the Windows Explorer context menu

Hide these specified drives in My Computer (Enable this setting for A through D.)

Prevent access to drives from My Computer (Enable this setting for A through D.)

Hide Hardware Tab

[User ConfigurationAdministrative TemplatesWindows ComponentsTask Scheduler]

Prevent Task Run or End

Disable New Task Creation

[User ConfigurationAdministrative TemplatesStart Menu & Taskbar]

Disable and remove links to Windows Update

Remove common program groups from Start Menu

Disable programs on Settings Menu

Remove Network & Dial-up Connections from Start Menu

Remove Search menu from Start Menu

Remove Help menu from Start Menu

Remove Run menu from Start Menu

Add Logoff to Start Menu

Disable and remove the Shut Down command

Disable changes to Taskbar and Start Menu Settings

Turn off personalized menus

[User ConfigurationAdministrative TemplatesDesktop]

Hide Internet Explorer icon on desktop

Hide My Network Places icon on desktop

Prohibit user from changing My Documents path

Remove My Computer icon on the desktop

[User ConfigurationAdministrative TemplatesControl Panel]

Disable Control Panel

Important: When you enable this setting, you prevent administrators from installing any MSI package on to the Terminal Server, even if the explicit Deny is set for the Administrator account.

[User ConfigurationAdministrative TemplatesSystem]

Disable the command prompt (Set Disable scripts to No)

Disable registry editing tools

[User ConfigurationAdministrative TemplatesSystemLogon/Logoff]

Disable Task Manager

Disable Lock Computer

In addition to these recommended settings, I would also add

[[Computer ConfigurationAdministrative TemplatesSystemRemote Assistance]

Offer Remote Assistance      Disabled

Solicit Remote Assistance    Disabled

[User ConfigurationAdministrative TemplatesWindows ComponentsWindows Update]

Remove access to use all Windows Update features   Enabled

In addition to these Group Policy settings, I would also modify some of the default menu items:

C:Documents and SettingsAll UsersStart Menu – delete Windows Update link
C:Documents and SettingsDefault UserStart MenuPrograms – delete Remote Assistance link

What Works for You

There might be several other settings I might add – or subtract – both in my Novell client settings, or in the Windows settings, depending on the network environment and the requirements that users have for the Terminal Services. To quote the Microsoft guideline, "The use of these policies does not guarantee a secure computer, and you should use them only as a guideline". Obviously, you have to do what works for you, in your own network environment.

By using a combination of "locking down" the NetWare client on the Terminal Server – to limit access to the NetWare environment – and locking down the Windows operating system with group policies, we can better provide the "work from anywhere" capabilities of Windows Terminal Services, without over-exposing our network to the potential hazards of external threats.