AppNote: Novell Client Settings with Windows Terminal Server
Novell Cool Solutions: AppNote
By Gary Childers
Digg This -
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.
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:=SERVER1\APP:\APP23 MAP ROOT G:=SERVER1\DATA:\APP23\DB 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 Configuration\Admin Templates\System\Group Policy]
- User Group Policy loopback processing mode
- [Computer Configuration\Windows Settings\Security Settings\Local Policies\Security 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 Configuration\Administrative Templates\Windows Components\Windows Installer]
- Disable Windows Installer
- [User Configuration\Administrative Templates\Windows Components\Windows 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 Configuration\Administrative Templates\Windows Components\Task Scheduler]
- Prevent Task Run or End
- Disable New Task Creation
- [User Configuration\Administrative Templates\Start 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 Configuration\Administrative Templates\Desktop]
- 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 Configuration\Administrative Templates\Control 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 Configuration\Administrative Templates\System]
- Disable the command prompt (Set Disable scripts to No)
- Disable registry editing tools
- [User Configuration\Administrative Templates\System\Logon/Logoff]
- Disable Task Manager
- Disable Lock Computer
In addition to these recommended settings, I would also add
- [[Computer Configuration\Administrative Templates\System\Remote Assistance]
- Offer Remote Assistance Disabled
- Solicit Remote Assistance Disabled
- [User Configuration\Administrative Templates\Windows Components\Windows 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 Settings\All Users\Start Menu – delete Windows Update link
C:\Documents and Settings\Default User\Start Menu\Programs – 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.
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com