Citrix Integration Methodology Design Guidelines—1.0

(1)

Citrix Integration Methodology

Design Guidelines—1.0

prepared for

Public Information

November 2003

(2)

(3)

Disclaimer _{Novell, Inc. makes no representations or warranties with respect to the contents or}

use of this document, and specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose.

Trademarks _{Novell is a registered trademark of Novell, Inc. in the United States and other}

countries.

* All third-party trademarks are property of their respective owner.

Copyright © 2003 Novell, Inc. All rights reserved. No part of this publication may be reproduced, photocopied, stored on a retrieval system, or transmitted without the express written consent of Novell, Inc.

Novell, Inc.

1800 South Novell Place Provo, UT 84606 USA

Novell UK Limited Novell House 1 Arlington Square Downshire Way Bracknell Berkshire RG12 1WA

Prepared By _{David Shepherd}

Citrix Integration Methodology Design Guidelines November 2003

Statement of Work: SOW Number

(4)

Revision History

Version Date Owner Revisions

0.5 17/11/03 David Shepherd First Draft

(5)

Executive Summary

The aim of the document is to provide an updated source of integration information between the Novell and Citrix environments. Much can be achieved by tight

integration between the environments yet many organisations still regard the choice as an either or decision. The aim of this document is to show what can be achieved using currently released software both from Novell and Citrix. The basis of this work was completed with the assistance of Steve Atkinson from Citrix UK. The following areas will be discussed within the document:

• Zen for Desktops 4 and its limitations with Citrix Metaframe XP FR3.

• Should the Citrix Servers be part of an Active Directory Domain?

• Installation, configuration of Novell client technology on Citrix Metaframe XP FR3 server.

• Integration of the Zen Myapps page and NFUSE.

• Use of Citrix Secure Gateway 2.0 within the environment.

(8)

Software Components

The following packages are discussed as components of this methodology.

• Novell NetWare 6.5

• Novell Secure Login 3.5

• Zen for Desktops 4.01

• Citrix Metaframe XP FR3

• Citrix Web Interface (NFUSE)

(9)

(10)

Current Limitations

Introduction

With the advent of the Zen 6.0 suite of products thin client integration became part of the base product for the first time. This allowed for Microsoft Terminal Servers/ Citrix Servers to launch applications that exist purely as eDirectory/Zen application objects. Another facet of the same product allowed these apps to be displayed and launched via a Web Page.

Limitations of the Approach

Whilst the Zen 6.0 Suite still offers good integration options for pure Microsoft Terminal Server deployments several limitations of the technology become apparent when used with Citrix Metaframe XP FR3.

No Support for Citrix Load Balancing

The method of launching the applications precludes any support for the Citrix Load Balancing service. Although an alternative method of load balancing ships with Zen 6 the Citrix Load Balancing service in personal experience has proved to be more feature rich and reliable.

Limited Support for Citrix Secure Gateway

(11)

Solution Architecture

The aim of the document is to present a properly integrated end-end solution using the components detailed above and with no reliance on Active Directory being deployed. This will allow the creation and provisioning of a user within the Novell Administration utilities but still support the managing of the Citrix Configuration within the Citrix CMC Console.

The configuration detailed within this document aims to support the following functionality.

• Citrix Servers deployed with no NT Domain or Active Directory Forest.

• User Home Directory/ Terminal Server Profile Directory held on NetWare 6.5 Server.

• User administration and configuration managed from ConsoleOne/IMANAGER.

• Policies deployed from Zen for Desktops to control configuration of users.

• Deployment of IPRINT Printers to Citrix/Terminal Servers.

• Applications presented through the Zen for Desktops MYAPPS front end with no difference from a user perspective with regards to launching thin/ thick client application.

(12)

(13)

To AD or not to AD

As has been documented elsewhere Citrix Metaframe XP can be installed on a member server within an Active Directory domain or just on a workgroup Windows 2000 standalone server. This standalone server could then have the Novell Client installed with also the Zen for Desktops 4 Management Agent and the Novell IPRINT Agent. No Citrix specific functionality is impacted by not installing the server as part of an Active Directory Forest.

The decision to implement the server within AD is purely one based on the applications that the Citrix Server is going to serve to the users. It is the

authentication requirements of the Citrix Server Applications that are the critical factor. If an application requires Active Directory for its authentication then it is best to implement the server as part of an Active Directory Forest. In this scenario the Novell Client, eDirectory, Zen and DirXML can still be used to provide full management of the Metaframe Server.

(14)

Novell and Citrix Installation /

Configuration

Introduction

This section of the document will discuss the integration and management of Citrix Metaframe XP via a range of Novell Products. Installation of the Novell Client for Windows NT will provide basic connectivity to NetWare file and Print resources. The addition of the Zen for Desktops 4 management agent will allow Zen to manage just a user’s session to the Citrix Server whilst perhaps applying different policies to the users Thick-Client session. The Zen functionality is also responsible in the AD less environment for creating a temporary local account within NT to give a user access through the box using Citrix. This temporary account creation is controlled and managed from e-directory. Another Zen policy can actually control the definition of various terminal server specific configuration parameters. This will decide the location of the users Terminal Server home directory and the Terminal Server Profile directory.

Another important benefit within a purely AD less world is the application of Microsoft Group Policies. Zen will allow the application of these policies which can also control application specific settings in the case of MS Office. These group policies can be applied on a per operating system basis, e.g. a users Citrix/Terminal Server policy can be different to the Windows XP policy that applies just when they authenticate to their local machine.

(15)

Initial Configuration of the Citrix Metaframe XP

Server

Once the Windows 2000 installation of the server is completed it is important to add the necessary service packs. As of November 2003 Citrix do not recommend the application of Windows 2000 Service Pack 4 and as such Service Pack 3 should be used in its place.

Before the installation of Citrix Metaframe the Novell Client should be installed. This is a pre-requisite since the Citrix install will detect the presence of the client and actually add a Citrix specific gina and chain this to the existing Novell Client NWGINA and the Microsoft MSGINA. Whilst the Novell Client can be installed after the Citrix installation registry changes to the machine will be required with the use of regedit.

Installation of the Novell Client on to a Terminal Server is fairly straight forward. This document was written using the released Novell 4.9 Client with the following patches applied:

• 49pkb.exe

• 49nwfs4.exe

• 49nmas1.exe

(16)

Installation of the Novell Client

Before the Novell Client is installed the Terminal Server should be placed into install mode by use of the CHANGE USER /INSTALL switch. This command can only be run with administrator privileges present on the local system. Once the

command has been run the Novell Client setup program can then be executed. If installing the client from an installation CD then WINSETUP is executed. Select the Novell Client 4.9 installation option.

After selecting the client installation option and selecting the language the

(17)

Within this dialog box only select the Novell Distributed Print Services option with regards to the optional entries available.

After selecting the Next button in the Novell Client Installation Dialog the following dialog box is displayed.

(18)

The patches required are as follows and they should be installed in the following order. 1. 49pka.exe

2. 49nwfs4.exe 3. 49nmas1.exe

Before installation of the first patch be certain to run the CHANGE USER /INSTALL command. After the installation of each patch do not re-boot the

Terminal Server and only allow the system to re-boot after the installation of the last patch.

Additional Novell Client Configuration

Disable NMAS Authentication

NMAS Authentication is enabled by default on the 4.9 Client. To allow for the correct pass thru of authentication from the Citrix Client to the Citrix Server this functionality is required to be disabled at this time.

The above screen is available through the Novell Client Properties option.

Changes to the Default Location Profile

(19)

As a first option make certain that the ‘Save Profile after Successful Login’ is unchecked.

(20)

After the system is completely installed and tested you may decide to switch off display of the login script. This has the result of tidying up a user’s access to the system with no login script window being displayed.

After all the changes to the default location profile screen have been made then select the OK button and return to the Client Properties screen.

SLP Configuration

Best performance of the client is in a large part dependant on good performance of Name Resolution. This describes the processes by which a service name is resolved by the client to an IP Address. The Novell Client normally achieves this by either multicasting for a Server with SLP configured or by having a static address defined which will allow the client to find a Directory Agent.

With regards to a Citrix /Terminal Server it is best to configure a static Directory agent within the service location tab of the Novell Client properties.

This entry within this document is set as an IP Address but could just as easily be a DNS Name.

DNS Configuration

(21)

Net Identity Agent

The Net Identity Agent from the 4.9 Client must not be installed as part of any automated or manual build procedure.

Microsoft DFS Related Issues

The Microsoft Distributed File System is known to cause some performance issues with the Novell Client. By default all requests originating from a Windows 2000 machine will first check a remote file system to see if it supports Microsoft DFS functionality. Due to the architecture of the underlying OS this check is made over all of the installed Network Providers. Within the Short Client Name environment both the Microsoft and the Novell Network Provider will be installed. When the Network Provider contacts the Novell Server volume this check will fail. The default behavior of the OS can be altered so that it does not try the MS DFS check. This involves the addition of a registry key within the following registry location.

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Mup Registry Value:

DisableDFS REG_DWORD

Value 1

This registry setting will stop the base OS checking for the existence of a Microsoft DFS Volume. Obviously this change pre-supposes no requirement for Microsoft DFS Volumes within the infrastructure.

Network Provider Order

With the installation of the Novell Client on to a Windows XP system two Network Providers will then exist for that system. One provider will allow access to Microsoft Resources and one will allow access to Novell Resources. To provide best

performance of the Client it is important that the Novell Provider is listed first since this will be the primary source of authentication for the workstation and the correct provider order will improve overall network performance from the client perspective.

Contextless Login Configuration

(22)

If NFUSE or the Citrix Client are not being used to pass on authentication

credentials to the eDir back-end then enabling contextless login may be of benefit.

Configuring Client Workstation Only Behaviour

The "Workstation Only" checkbox on the login window can be made (and is, by default beginning with the 4.9 client) "sticky." This allows the setting to be remembered, so that the user need not check the box each time; the previous setting will be remembered. This is controlled by the following registry flag HKLM\Software\Novell\Login\

DWORD Remember WS Only (default 1)

(23)

Optional Additional Configuration

Many different things can affect the performance of the Novell Client under different circumstances and loads. Your mileage from any of the registry settings below will vary according to the environment.

Optimise the Redirectors on the PC

If unused directors are installed on a PC or rarely used directors are configured with a high preference, you will see degraded performance. Common redirectors are the MS Client for Microsoft Networks, Novell Client 32, and various NFS clients.

If any of these clients are not needed, they should be removed. If they are needed, make sure to only bind the necessary protocols. A client with only IPX bound to the Novell client and IP to the Microsoft and NFS clients may be significantly faster in accessing network resources than one which has IP and IPX bound to the Novell client, plus IP, IPX, and Netbios bound to the MS client due to the unneeded searches performed by the MUP.SYS. Also be sure to make the most used redirectors the primary redirectors.

Verify Duplex Settings

One common performance problem is incorrect duplex settings. Full Duplex is only supported on switches, not hubs. Make sure you are using switches and not hubs before setting your workstations to full-duplex. Also it is important to match the duplex settings between the server, switches, and the client. Make sure all are set to full-duplex or half-duplex. "Auto-Detect" often causes problems due to a failure to properly recognize the correct duplex setting and should be avoided. This is especially important in TCP/IP environments since TCP/IP has a longer

retransmission delay by default than IPX since it is designed to work across the internet as opposed to a local LAN. Therefore, any LAN problems causing retransmissions will cause more difficulty with an IP environment than an IPX environment.

Tweak Netbios Settings

A client can be configured to attempt to locate MS resources via broadcasts, WINS servers, or a combination of both. In addition, the workstation can also be

configured to use hosts file and DNS searches to locate resources. Inefficiencies can occur if a machine is configured to use methods that are configured to work. The registry entries of

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters] "EnableLMHOSTS"=dword:00000000

"EnableDNS"=dword:00000000

(24)

types is a P-NODE, which only uses a WINS server instead of broadcasting for name resolution. The following registry entry will set your machine to a P-NODE. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters] "NodeType"=dword:00000002 (For WinNT Machines)

Here are a few additional registry entries that can be tweaked to improve performance. You may set the values to match your local environment.

BcastNameQueryCount

Key: Netbt\Parameters

Value Type: REG_DWORD - Count Valid Range: 1 to 0xFFFF

Default: 3

Description: This value determines the number of times NetBT broadcasts a query for a given name without receiving a response.

BcastQueryTimeout

Value Type: REG_DWORD - Time in milliseconds Valid Range: 100 to 0xFFFFFFFF

Default: 0x2ee ( 750 decimal)

Description: This value determines the time interval between successive broadcast name queries for the same name.

CacheTimeout

Value Type: REG_DWORD - Time in milliseconds Valid Range: 60000 to 0xFFFFFFFF

Default: 0x927c0 ( 600000 milliseconds = 10 minutes)

Description: This value determines the time interval that names are cached in the remote name table.

(25)

Value Type: REG_DWORD - Count Valid Range: 0 - 0xFFFF

Default: 3

Description: This value determines the number of times NetBT sends a query to a WINS server for a given name without receiving a response.

NameSrvQueryTimeout

Value Type: REG_DWORD - Time in milliseconds Valid Range: 100 - 0xFFFFFFFF

Default: 1500 (1.5 seconds)

Description: This value determines the time interval between successive name queries to WINS for a given name.

Size/Small/Medium/Large

Key: Netbt\Parameters Value Type: REG_DWORD

Valid Range: 1, 2, 3 (Small, Medium, Large) Default: 1 (Small)

Description: This value determines the size of the name tables used to store local and remote names. In general, small is adequate. If the system is acting as a proxy name server, then the value is automatically set to Large to increase the size of the name cache hash table. Hash table buckets are sized as follows: Large: 256

Medium: 128 Small: 16

Windows 2000 OS Registry Tweaks

IoPageLockLimit

This setting determines the number of bytes that can be locked for I/O functions. Increasing the value from the default (512) can have a big boost on the

performance on machines with a large amount of disk I/O. The example below increases the value to 4096bytes.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management]

(26)

LargeSystemCache

This entry will cause NT Workstation to use the same "LargeSystemCache" model used by NT server. This is recommended with systems with extra available RAM to increase the effectiveness of the system cache.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management]

"LargeSystemCache"=dword:00000001

DisablePagingExecutive

This entry will prevent the system kernel from being swapped to disk. NT will slow down significantly if the kernel is swapped to disk.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory

"DisablePagingExecutive"=dword:00000001

NTFSDisableLastAccessUpdate

By disabling this option, NTFS will not record the last time a file was accessed. This can speed up disk operations if applications are written to access many small files very frequently as is found in many pseudo database applications. (Modification timestamps will still be made)

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem] "NtfsDisableLastAccessUpdate"=dword:00000001

Enable DMA Transfers

By default, DMA transfers are disabled for your systems IDE hard drives. This can significantly decrease the performance of your system during periods of high disk usage. Turning on DMA Detection will enableDMA on devices which support DMA. All devices on a channel must support DMA.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\atapi\Parameters\Devic e0]

"DriverParameter"="DmaDetectionLevel = 0x1;"

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\atapi\Parameters\Devic e1]

(27)

Disable Remote Computer Task Scheduler

By default, Windows 2000 will attempt to access the remote scheduler service on remote computers such as Win95, Win98, and Novell Netware. This can cause long delays, over 30 seconds in some cases, while futilely attempting to access the remote service. This was scheduled to be fixed in Windows 2000 SP2, but was not. Use the Registry File excerpt below to delete this key, which will disable this feature.

Windows Registry Editor Version 5.00

[-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Rem oteComputer\NameSpace\{D6277990-4C6A-11CF-8D87-00AA0060F5BF}]

(28)

Tweak Novell's Name Resolution Timeout

Under the advanced settings tab of the Novell Client, change the Name Resolution Timeout to 1 from 10. This setting can be pushed via the following registry entry - (HKLM\SOFTWARE\Novell\NetwareWorkstation\Policies\Network

Timeout in Seconds=1)

Disable Unused Protocol Search Methods

By default, the Novell client will attempt to use many different resolution methods for IP that may not be configured for use on your network. Under the "Protocol Preferences" tab of the Novell Client configuration, disable all resolution methods not used.

(29)

Installation of Citrix Metaframe XP FR3

After the Novell Client has been installed and configured the Citrix Metaframe install can begin. This document is just going to examine the Novell specific areas within the overall installation process. It is advisable that Feature Release 3 be installed as part of the installation process since definite performance benefits exist over the earlier code.

The Citrix Metaframe server code install does detect the presence of an installed Novell Client and does make the following registry changes.

Registry Changes made by the Citrix Installation

Registry Key Registry Value Registry

Type

Registry Data

HKLM\Software\Microsoft\WindowsNT\Current\Vers ion\Winlogon

GinaDLL REG_SZ CTXGINA.DLL

HKLM\Software\Microsoft\WindowsNT\Current Version\Winlogon

CTXGINA.DLL REG_SZ NWGINA.DLL

(30)

(31)

The screenshot above is of the Citrix Management Console. This shows how a Citrix Published Application can be assigned to an EDIR User, Group or Container Object. Currently Active Directory cannot assign applications to container objects.

Installation of the Zen for Desktops 4 Agent

With the advent of ZFD 4 Zen functionality that was with earlier versions of Zen installed as part of the Client became the Zen for Desktops 4 Management Agent. This agent has a separate installation routine to the 4.9 client and is required if any Zen functionality is required on the Citrix/Terminal Server. One important pre-requisite for the Management Agent of the Citrix/ Terminal Server is the installation of Internet Explorer 5.5 SP2 or later.

Zen functionality for the Terminal /Citrix Server is divided into the following areas:

• Application of Group Policies from eDirectory.

• Dynamic Local User Policy to manage the installation of the Citrix Servers without any NT Domain or Active Directory implementations.

(32)

Although the use of the MSI file for installation is meant to be Citrix Server aware it is still advisable to execute the CHANGE USER /INSTALL command before the installation starts and the CHANGE USER /EXECUTE after the installation finishes. If the install was started from ADD/REMOVE programs in control panel then the commands mentioned are executed automatically by the system.

After running the MSI file and agreeing to the license agreement the following screen is displayed.

Please note the options that are excluded from the installation. Workstation Inventory for a Citrix/Terminal Server would place an extremely heavy load on to the server with little benefit achieved. By the very nature of what a

(33)

Installation of the IPRINT V2.0 Agent

With the advent of IPRINT V2 (as shipped with NetWare 6.5) IPRINT has the ability to deliver printers on a user basis and not just on a system wide basis. This is vital in a Citrix/Terminal Server environment since one user removing a printer could remove the printer for every user on the system.

The IPRINT Agent needs to be installed on each Citrix/Terminal Server within the farm. The agent is in the form of the file NIPP.exe and again should be run after running the CHANGE USER /INSTALL command at the command prompt on the terminal server. This component should be configured purely for the installation of workstation printers.

With the IPRINT agent installed on to a Citrix/Terminal Server the agent is not capable of being auto-updated which is a feature, for a normal workstation install. After the installation of the Novell IPRINT Client the client software is installed on to the Start Menu under the Programs menu. If selected then the following screen is displayed.

Please note that the iCapture functionality is not currently supported on

(34)

The IPRINT agent is only responsible for printing to network printers however Citrix can also re-direct print jobs to client side printers. For this functionality to correctly operate it is advisable that the Citrix/ Terminal Servers have available to them the same printer drivers as are installed on the local workstation. Citrix MetaFrame does also offer the unidriver which will provide some client printing functionality if a specific printer driver is not available.

For a Citrix/Terminal Server environment then it is suggested that the select ‘Install User Printers Only’ is selected. This will ensure that the printers are deployed and managed as a user printer. This configuration helps with two major issues in deploying Novell Network Printers and drivers to Citrix/Terminal Servers.

• Deployment of a User Printer does not require administrator rights.

(35)

Configuration of Zen Policies

Introduction

The aim of this section is to discuss the configuration of Zen for Desktops 4.01 policies with respects to Citrix/Terminal Server integration. This section will detail the policies required within a Citrix /Novell environment in a situation where Active Directory or an NT Domain has not been deployed.

Scope of the Problem

Within an environment without an NT Domain or an Active Directory Forest the major issue becomes how to manage the local SAM Account database of each Citrix/Terminal Server within the ‘Farm’. Although the initial authentication with the Novell Client installed on the server is an NCP connection a Microsoft

authentication is also required to be made. Without an NT Domain or Active Directory Forest the SAM Databases are unique to each server and not synchronized unless the user names and passwords are manually kept in sync. This is compounded by the requirement for the SAM username/password also requiring to be

synchronised to the eDirectory username/password.

Zen 4.01 Policies

With the advent of Zen 4.01 certain user policies could be applied dependent of the OS type of the users connection. For example if a user authenticates via a Citrix connection a particular package of policies could be applied for that session. However if a user does a normal NTLM authentication via the client system then a different policy package can be applied. One user can have a separate user policy

package configured for the following OS variations.

• Windows 98

• Windows NT

• Windows 2000

• Windows 2000 Terminal Server

• Windows XP

(36)

The user policy package is comprises a number of separate polices and the

following section of the document will discuss each of the policies in turn and how they relate to the Citrix/Terminal server configuration.

Notice the Policy tab in the top right hand corner of the screen shot. The policy detailed here will only apply if the user attempts a Citrix/Terminal Server connection to a Windows 2000 server.

Dynamic Local User Policy

As has been discussed in an earlier section of the document one of the largest areas of management in a world without Active Directory or an NT4 Domain is the

(37)

The Microsoft SAM account can also be set to be volatile. This would mean that when the user logged out of eDirectory the local SAM account would be removed from the Citrix Server.

Also important as part of the configuration is that this dynamically created local NT account can be assigned to an NT Group membership. This can again be really useful in granting special file-system privileges on the NT Server machine.

(38)

Novell IPRINT Policy

The Novell IPRINT policy controls the configuration and deployment of printer drivers for the IPRINT agent.

This policy should allow the deployment of particular printer drivers based purely on the user who has made the connection. If the Citrix/Terminal Server does not have the printer driver concerned then the IPRINT functionality will deploy the driver in such a way as to permit the installation of user printers.

(39)

If the policy cannot be used then it is best to deploy printers via the command line.

This command line could then be executed as part of the login script for that user and is also responsible for configuration and installation of any driver files.

Novell Remote Control Policy

The remote control policy has no benefit on a Citrix/Terminal Server and no benefit should be made to try and deploy it within this environment.

Windows Group Policy

(40)

After selecting the edit button ConsoleOne launches the Microsoft Group Policy editor.

(41)

Some of the policy options that can be set include

• Removal of the Reset box from the logoff dialog.

• Removal of the Security Menu from the Start Bar.

• Restrict Access to the Command Prompt.

• Only allow the running of specific applications.

If required a users access to the desktop can be severely restricted with Group Policies. Again all of this functionality does not require Active Directory. Group Policies are extendable with Policy Templates available for many

(42)

Windows Terminal Server Policy

This policy provides essential functionality to the overall integrated solution.

The Connection page allows the enforcement of specific Citrix/Terminal Server related settings. These include allowing the user to logon to the Citrix/Terminal Server and whether shadowing for that user is enabled or disabled.

(43)

The client devices section of the screen shot can also be quite important. This allows the configuration of how the Citrix Client handles connections both to local device drives and printers. This behaviour can be enabled or disabled within this policy.

Conclusion

(44)

(45)

Zen for Desktops 4.01 and Citrix Web

Interface Integration

Introduction

In a Citrix environment the Citrix Web Interface component allows for the presentation of Citrix Published applications via a Web interface. Due to the wide range of Citrix Client software and browser support this can allow many different flavours of operating system to both authenticate and run a Citrix Published

application. A large proportion of the security capability of Citrix Secure Gateway is also tied in with Web Interface functionality. Web Interface also provides Citrix with a Web based alternative to the Java Citrix Management Console.

Zen for Desktops 4.01 does have some capability to manage and present Citrix applications; however it cannot provide support for Citrix Load Balancing, Secure Ticketing Agent, Citrix Secure Gateway and client support for non-windows platforms.

The aim of this section of the document is to detail a method by which a Zen application object can launch a Citrix published application hosted via Citrix Web Interface Server. This would allow a user to use one interface to launch both Thin and Thick Client applications whilst preserving support for the following Citrix capabilities.

• The Secure Ticketing Agent

• Citrix Load Balancing

• Citrix Secure Gateway

The method discussed here does not alter any Citrix installed code, nor impact any existing Citrix functionality.

The aim is to allow both NAL and the web based MYAPPS page to present an application object. This object will talk to the Citrix Web Interface Server and via two custom asp pages added to the server will allow Web Interface to launch the required Citrix Published application. The user should see this as a seamless process with no extra request for authentication.

(46)

Existing Novell and Web Interface Integration

Within the Citrix Web Interface product integration with Novell eDirectory exists within the base product. If the Web Interface Server is installed on a Windows 2000 Server system with the Novell Client also configured then context-less

authentication is supported via the web interface server.

The search context list within the dialog box provides a list of context start points that will allow Web Interface to establish the full context of the user without the full context being entered at authentication time.

(47)

Notice with he above screen shot how the authentication screen does understand both context and tree.

(48)

Architecture of the Solution

The components of the solution comprise the following components:

CITRIX Metaframe XP FR3

Windows 2000 Server SP3 Novell IPRINT Agent ZEN 4.01 MA

S D S D ESC DLT PROLIANT 8000 SD

P rofessional Wo rkstatio n 6000

PRO S D S D ESC DLT PROLIANT 8000 S D S D E SC DLT PROLIANT 8000

NETWARE 6.5 SERVER

Runs the directory and provides authentication Holds the users home directory and profile. Runs the Network Printers via IPRINT Runs the server portion of Secure Login 3.5

CITRIX Web Interface Server

Windows 2000 Server SP3 Novell Client 4.9 Zen Middle Tier Server Citrix Secure Gateway V2.0 Citrix Secure Ticketing Agent

Client System

Windows NT(XP/2000) Secure Login 3.5 Client

Novell Client 4.9

For the purposes of this discussion the Citrix Web Interface server is also acting as the Zen Mid Tier Server. This is not a recommended deployment config and it

would be suggested that both servers are on separate boxes. The same could also

apply to the Citrix Secure Gateway and the Citrix Ticketing Agent. These two components have been installed on the Web Interface Server just by using their default installs. Citrix Secure Gateway has been setup to utilise a server certificate provided by IIS and the Novell Certificate Server.

The client system could equally be on the Local Lan or accessing the system over the internet in a secure manner.

(49)

The screen shot above shows the MYAPPS web interface where the user can see two applications. Word 2000 is in fact a Citrix App that is published via a Citrix Web Interface server. The Zen App displayed is in fact a pointer to the Web Interface Server that will via a URL authenticate the user and launch the application.

(50)

How MYAPPS and Citrix Web Interface can

Integrate

The configuration of both the Novell and the Citrix environments will be discussed in depth in this section with regards to managing and launching Citrix Applications via the Zen MYAPPS / NAL front end.

Configuration of the Citrix Published Application

The Citrix Published application is configured in the normal manner with no extra or different configuration required. The name of the published app should be noted since the value should be recorded since it is required by the Zen App object that will launch the application URL from the Zen perspective.

Configuration of the Zen Application Object

The Zen Application object is effectively responsible for launching the Citrix Published Application via a URL to the Citrix Web Interface Server. This URL refers to two custom ASP pages that are the only configuration changes required to the Citrix back-end.

(51)

The web URL launches one of the two custom ASP pages. These pages are

responsible for authenticating the user to the Web Interface backend and launching the Citrix Published application. These pages will be discussed in a later section in greater depth.

The %app% refers to a custom macro. This value is changed in accordance with the name of the Citrix Published Application at the backend. With regards to the Word 2000 application the following value was set as a custom Macro within the Zen Application object.

This application object can then be assigned to a user, group or container in the normal way. The application will allow the user to launch the application either from the Web Front end or the Novell Application Launcher.

Setup of the Custom ASP Pages and Authentication to Citrix Web Interface

When a user selects the Zen Application object it will launch the following URL:

http://nfuse-srv.nwcon.com/Citrix/examples/login_test.asp?app=%app%

(52)

The Secure Login client is able to execute in both connected and disconnected modes and will allow the automatic insertion of the Client machines desktop authenticated credentials. Since the authentication page does not require the users context this will allow the process to execute correctly both when the client machine has an authenticated connection or not.

The Secure Login Script to allow this functionality is detailed below. I am only a novice with SSO so any suggestions on how to improve this script will be gratefully accepted.

type ?SYSUSER #1

type ?SYSPASSWORD #2

click #1

This script will allow the login form to be automatically filled with the username and password that have been used to login the workstation. Since the context is not required the authentication will still work correctly regardless if the user is

connected or disconnected from eDirectory.

Below is the first of the two ASP scripts that are required. LOGIN_TEST.ASP is responsible for presenting the authentication form that Secure Login then fills with no user intervention. It makes the window only 100 x 100 so that the processing of the form is invisible to the user. It also starts a timer off that ensures the

(53)

<HTML>

<HEAD>

<TITLE>Web Interface Login</TITLE>

</HEAD>

<BODY LANGUAGE=Javascript onload="return time_out()">

<SCRIPT LANGUAGE=Javascript> window.resizeTo(100,100); function time_out() { setTimeout("return window_exit()",1000) } function window_exit() {

parentwin = window.self; // Make handle for current window named "parentwin"

parentwin.opener = window.self; // Tell current window that it opened itself

parentwin.close();

}

</SCRIPT>

<form method="POST" target="_self"

action="launch_1.asp?NFuse_Application=Farm1x003a<%=Request.QueryString(" app")%>" onsubmit="return time_out()" name="NFuseForm">

Username: <input type="text" name="user" size="20">

Password: <input type="password" name="password" size="20">

<input type=submit>

</form>

</BODY>

(54)

Again the purpose of this script is to demonstrate a principal since the script itself could be made more elegant.

Once Secure Login has filled the form and automatically selected the submit button the second script is launched with the following parameters passed to it;

• Username

• Password

• Published Application Name

The second script is called LAUNCH_1.ASP and is shown below;

<%

Response.Buffer=true

' Replace REPLACE_USER, REPLACE_DOMAIN and REPLACE_PASSWORD with

' some valid credential strings

Dim user, domain, password, user1, context ,tree, gPropKey, gNdsObj

user = Request.Form("user")

response.write "UserName :" & Request.QueryString("NFuse_User") & "<BR>"

Session("NFuse_Domain") = Request.Form("domain")

Session("NFuse_Password") = Request.Form("password")

' Get the login information

domain = Session("NFuse_Domain")

password = Session("NFuse_Password")

tree="NAKOMA-TREE"

dim bcontext

bcontext = 1

Set credentials = Server.CreateObject("com.citrix.nfuse.ClearTextCredentials")

credentials.initialize user, domain, password

(55)

context=gPropKey.getProperty("SearchContextList")

dim retVal, successOrFailure

retVal=gNdsObj.getToken(context,user,tree,bcontext)

successOrFailure=split(retVal,Chr(10))

user=successOrFailure(1)

Session.Contents.Remove("NFuse_User")

Session("NFuse_User") = user

response.write "Full Name :" & successOrFailure(1) & "<BR>"

user=Session("NFuse_User")

' Create a TemplateParser object which allows you to set the session fields

' and generate an ICA file for the client based on the template ICA file.

Dim parser

Set parser = Server.CreateObject("com.citrix.nfuse.TemplateParser")

' Similar to other examples, the user, domain and password are hard-coded in

' the scripts. In normal operation, pass the credential information using

' some other method such as HTTP POST, cookie storage, database storage,

' etc. It is necessary to set the session fields, NFuse_User, NFuse_Domain

' and NFuse_Password for launching a published application.

Dim cookieStr

cookieStr = "NFuse_User=" & user &_

"&NFuse_Domain=" & domain &_

"&NFuse_Password=" & password

parser.setCookieSessionFields cookieStr

' Set the session field, NFuse_Application by calling setUrlSessionFields

' The information is retrieved from the query string generated in

(56)

Dim URLSessionFields

URLSessionFields = Request.ServerVariables("QUERY_STRING")

parser.setUrlSessionFields(URLSessionFields)

' Set the session field, NFuse_TemplatesDir by calling

' setSingleSessionField.

' Here we assume the template ICA file is in the same directory as this file

' (launch_1.asp)

Dim currentTransPath

currentTransPath = Request.ServerVariables("PATH_TRANSLATED")

parser.setSingleSessionField "NFuse_TemplatesDir", _

Left(currentTransPath,InStrRev(currentTransPath,"\"))

parser.setSingleSessionField "NFuse_DomainType","NDS"

parser.setSingleSessionField "NFuse_WindowType", "Seamless"

parser.setSingleSessionField "NFuse_WindowColors","4"

parser.setClientIPv4Address Request.ServerVariables("REMOTE_ADDR")

' Set the NFuse_Template session field to the name of the template ICA file.

Dim templateFile

templateFile = "template_1.ica"

parser.setSingleSessionField "NFuse_Template", templateFile

' Call Parse() to generate the ICA file and substitute any tags set in this

' file to the template ICA file.

If parser.Parse() Then

' Set the MIME type for the Citrix ICA Client

Response.ContentType = "application/x-ica"

' Large negative value for expires to ensure timeout in the past even if

(57)

Response.Expires = -10000

' Pass the current data block to the client, until the parser returns

' EOF (a blank line)

Dim Continue

Continue = True

While (Continue)

Dim HtmlString

HtmlString = parser.getNextDataBlock()

If HtmlString = "" Then

Continue = False

Else

Response.Write(HtmlString)

End If

Wend

Else

Response.Write "ERROR! " & parser.getLastError()

End If

Set parser = Nothing

Server.ScriptTimeout = 100

%>

This script is responsible for performing a context-less lookup against eDirectory based on the username and password supplied by Secure Login. The context is then added to the username and later used for the authentication to the Citrix Server. This script is again based on a sample script mentioned within the Citrix Web Interface documentation. This script makes reference to a Template_1.ica file. This file both static and dynamic entries within it. The dynamic entries are built on the fly from Web Interface configuration parameters before the application is

(58)

This ICA file is also configured to support the Citrix Secure Gateway functionality. This allows for a user on the Internet to make a secure and authenticated

connection to the Web Interface Server over port 443. This connection is then proxied by the Web Interface server to port 1494 for transfer to the Citrix Metaframe Server within the exterior company firewall. No port on the Citrix Metaframe Server is directly exposed to the Internet and access to this server can only be achieved after a valid authentication.

TEMPLATE_1.ICA

<[NFuse_IFSESSIONFIELD sessionfield="NFUSE_LANGUAGECODE" value="ja"]>

[Encoding]

InputEncoding=SJIS

<[/NFuse_IFSESSIONFIELD]>

<[NFuse_IFSESSIONFIELD sessionfield="NFUSE_LANGUAGECODE" value="de"]>

[Encoding]

InputEncoding=ISO8859_1

<[NFuse_IFSESSIONFIELD sessionfield="NFUSE_LANGUAGECODE" value="en"]>

[Encoding]

<[NFuse_IFSESSIONFIELD sessionfield="NFUSE_LANGUAGECODE" value="fr"]>

[Encoding]

(59)

[Encoding]

<[NFuse_setSessionField NFuse_ContentType=application/x-ica]>

[WFClient]

Version=2

ClientName=[NFuse_ClientName]

[NFuse_TransportReconnect]

RemoveICAFile=yes

[NFuse_SOCKSSettings]

[ApplicationServers]

[NFuse_AppName]=

[[NFuse_AppName]]

Address=[NFuse_AppServerAddress]

InitialProgram=#[NFuse_AppName]

LongCommandLine=[NFuse_AppCommandLine]

DesiredColor=[NFuse_WindowColors]

TransportDriver=TCP/IP

WinStationDriver=ICA 3.0

[NFuse_ClientLogon]

[NFuse_SOCKSSettings]

(60)

[NFuse_Ticket]

[NFuse_IcaAudio]

[NFuse_IcaWindow]

SSLEnable=On

SSLProxyHost=nfuse-srv.nwcon.com:443

SSLCiphers=all

SecureChannelProtocol=Detect

SessionsharingKey=[NFuse_SessionSharingKey]

[EncRC5-0]

DriverNameWin16=pdc0w.dll

DriverNameWin32=pdc0n.dll

[EncRC5-40]

DriverNameWin16=pdc40w.dll

[EncRC5-56]

DriverNameWin16=pdc56w.dll

[EncRC5-128]

(61)

[Compress]

DriverNameWin16=pdcompw.dll

DriverNameWin32=pdcompn.dll

Configuration settings within this file within both angled and square brackets are dynamic entries that are filled in by the LAUNCH_1.asp file. The finished ICA file is presented to the web browser. This ICA file is then used by the locally installed Citrix Client to initiate the launch of the application.

The end result of this process is that the session is launched to the Citrix Server and the user is then authenticated via the Novell Client to the session and the thin client application starts.

The configuration as detailed here provides support for Citrix Secure Gateway, Citrix Load Balancing and the Secure Ticketing Agent.

Issues with the Solution

(62)

Citrix Integration in a Dual Tree

Environment

Introduction

With a Corporate eDirectory implementation with respect to a medium to large size company the directory design will be partitioned and replicated to allow for separate geographical locations. Corporate implementations may in all probability be running multiple versions of the server operating system and the directory service. Upgrade schedules both with respect to Server OS and Hardware tend to have limited scheduling windows when they have a direct impact on the line of business corporate environment. A number of separate factors may combine to make implementing Citrix Integration to the Corporate Tree unworkable. In general Citrix Metaframe implementations tend to be based at one geographic location with a Citrix Farm being split over multiple sites only happening with the largest installations. This can be at odds with a geographically dispersed heavily hierarchical corporate Novell directory environment.

One possible solution is the concept of the Citrix Tree, synchronised to the corporate environment via DirXML. This can present a best of both worlds solution which allows for the Citrix Tree to exist at limited geographic locations whilst having to carry out minimal change to the corporate environment to support the DirXML synchronisation of account information. This scenario would allow for the synchronisation of user and group information between the trees (including passwords) and allow the administrators to provision a user account with Citrix Applications just from within the corporate tree. DirXML would then synchronise the changed information to the Citrix Tree.

This solution gives us one of two possibilities

1) Implement straight Citrix Integration to the Citrix Tree. Create the Citrix Published apps and policies in the Citrix Tree and provision those apps by the synchronisation (via DirXML) of users and groups from the corporate environment. The user uses the normal Citrix Web Interface to present the applications.

2) Implement Zen for Desktops in the corporate tree and the Citrix Tree. Using the Web Interface Integration discussed earlier this would allow the Zen Thin Client Apps to be configured in the corporate tree as per normal. Since these applications just refer to a URL and users and passwords are synchronised between the

(63)

Challenges of the Solution

Access to Corporate Tree Resources

Even though a user is authenticating to Citrix via the ‘Citrix Tree’ there may still be a requirement to access corporate tree resources such as mapped drives and printers.

Access to Corporate Tree Mapped Drives

The users login script in the ‘Citrix Tree’ can be made to refer to the corporate tree by the use of the TREE command. This command can take an eDir user attribute as a parameter. This attribute would be created via DirXML and held against the user object. The contents of this attribute would be created when the user is first created in the Citrix Tree. The attribute would hold the context of the user within the Corporate Tree. This information when used as a parameter to the

Tree command would allow the transparent authentication of the user to the Corporate Tree from within the Citrix Session.

The Tree command is always supplied in pairs. The first tree command would switch the context of the login script to the Corporate Tree. Any use of

environment variables such as %HOME DIRECTORY would refer to the users home directory within the Corporate environment. The use of the Tree command (even though the user has authenticated via the Citrix Tree) allows the users environment to appear the same from within the thin-client session as from normal workstation access.

This access to Corporate Tree resources could also be managed by group so that no mappings take place if the user was not a member.

Access to Corporate Tree Printers

Many printers within a corporate environment are connected via a dedicated print server box of some description. This would allow IPRINT from the ‘Citrix Tree’ to refer to already installed printers within the Corporate Tree via LPR/LDP type functionality. This also gives the option of limiting the scope of network printers available from the thin client session.

Provisioning Users and Applications

Using DirXML functionality this will allow users and their attributes to be synchronised from one tree to another in accordance with pre-defined business rules. This synchronisation includes all password related information. This would allow the management of users purely within the Corporate Tree.

(64)

Applications objects would be the most difficult to manage in this scenario. This would involve the creation of a Citrix Published application within the Citrix Tree. Within the Corporate tree a ZEN application would also have to be created from an application template object and the APP pointed via a URL to the Citrix Web Interface server located in the other tree.

Benefits of the Solution

This solution would allow the deployment of a Novell Integrated Citrix environment in parallel to a companies existing Corporate Tree. If the Corporate environment requires extensive updates with respect to Directory Service and OS version the implementation of a DirXML synchronised solution would involve much less work within the Corporate environment. Many companies Corporate Trees are

responsible for the provision of critical line of business applications and unless issues exist customers are justifiably wary of extensive changes.

(65)

Conclusion

(66)

Contact List

Give the customer any names, addresses, phone numbers, etc. that they might find useful.

(67)

Appendix A:

Sources of Information

http://www.ithowto.com/novell/clientspeed.htm Citrix Consulting White Paper on Novell Integration Citrix Web Interface Product Documentation

(68)

Citrix Integration Methodology Design Guidelines—1.0