Configuring the Web Interface

Configuring the Web Interface

The two methods for configuring the Web Interface are as follows :

  • Web Interface Console Available only when the Web Interface is run on a Windows IIS web server (it is not supported on a UNIX web server), the Web Interface Console is a Web-based graphical interface, within which you can quickly perform common administrative tasks . Many of the settings within the Web Interface configuration file can be directly modified using the Web Interface Console. The Web Interface Console is accessible from any client running Internet Explorer 5.5 or later. Non-Microsoft Web browsers are not currently supported.

  • Web Interface configuration file The configuration method available on both Windows and UNIX systems, the specific file, called WebInterface.conf, is a plain-text file that you can edit to modify many of the Web Interface properties. On Windows, this file is located by default in the following folder:

    < WebRoot >\Citrix\MetaFrame\conf

    On UNIX, it is in the following folder:

    < WebRoot >/Citrix/WEB-INF

    In both cases, < WebRoot > represents the path to the appropriate root web folder of the web server. Before any changes made to the configuration file take effect, you must stop and restart the web server service. A full summary of all supported commands is provided in the "Web Interface Administrator's Guide."

Alert

Web Interface configuration focuses on the use of the Web Interface Console and the features it can manage instead of the fields that can be edited in the WebInterface.conf file.


Note

You can also write custom web server scripts or Java servlets to customize the Web Interface site. Citrix provides a special guide called "Customizing the Web Interface" that provides information on how this can be achieved.


As mentioned, the Web Interface Console is available only when you run the Web Interface on Microsoft IIS. The URL to access the Console is

http://< servername >/Citrix/MetaFrame/WIAdmin

where < servername > is the server running the Web Interface.

To be authorized to access the Console, you must belong to the local Administrators group on the server. If the Console cannot automatically authenticate you, you are prompted to provide the necessary credentials.

After you are authenticated, the main Web Interface Console page appears (see Figure 14.3). The page is laid out to represent all the possible components that could make up a Web Interface environment. On this main page, you see the Apply Changes button. Until this button is clicked, any changes made on the individual configuration pages will not take effect until the web server is restarted. Clicking this button immediately applies the changes to the live system.

Figure 14.3. The main Web Interface Console page gives a graphical view of the managed environment.

You manage configuration settings either by clicking an image in the component diagram or by choosing one of the links down the left side of the page. For example, clicking the Authentication link takes you to the same settings as clicking the "Web Interface for MetaFrame" image.

Table 14.3. cross-references the link names with the images in the component diagram.

Table 14.3. Setting Link and Component Diagram Image Cross-Reference

Link Setting

Diagram Component

Authentication

Web Interface for MetaFrame

Workspace Control

End User

Selected Farm

(no equivalent)

Manage Farms

"(Multiple MetaFrame Farms can be added)" text

MetaFrame Servers

"Servers" icon under MetaFrame Farm

DMZ Settings

 

Network Address Translation

Server-side firewall

Secure Gateway Support

Secure Gateway for MetaFrame

Client-side Proxy

Proxy

Client Deployment

Web Browser

Client Customization

ICA Client


General and Client-Side Settings

In this section, we review the configuration settings of the Web Interface.

Authentication

Authentication allows the configuration of the authentication methods available when logging on through the Web Interface. Citrix strongly recommends that you enable only those authentication methods required by your users. Any changes to the authentication for the Web Interface require any active users to close and restart their web browser; otherwise , error messages may appear. The following authentication methods are available:

  • Anonymous A user can access the server without providing a user ID or password. The use of anonymous authentication is not recommended with the Secure Gateway for MetaFrame because it can allow a user to still receive Secure Gateway tickets.

  • SmartCard A user authenticates by inserting a SmartCard into a SmartCard reader attached to the client device. The user is requested to enter a PIN to complete authentication. SmartCard with Single Sign-on eliminates the user's having to enter a PIN again to log on to the farm. SmartCard authentication is not available when running the Web Interface on UNIX. SSL must also be enabled on the IIS server for SmartCard authentication to function properly.

  • Single Sign-on The user credentials used when logging on to the Windows desktop are used to automatically authenticate within the Web Interface. Single Sign-on should be used only over a secured connection.

  • Explicit Login The default setting, this requires the user to provide a user ID and password to log on to the Web Interface. You can choose either Windows domain or Novell NDS authentication. Three general settings apply to either Windows domain or NDS settings. You can allow users to change their passwords. You can also configure two-factor authentication using RSA SecurID or Safeword. The Time To Live value specifies how long a ticket used for explicit authentication is valid before it expires . The default is 200 seconds, but you can adjust this value.

Note

For security reasons, when two-factor authentication is enabled, the PN Agent cannot be used to access applications via the Web Interface.


Here's one issue to note if you decide to enable the changing of passwords through the Web Interface. If you have multiple server farms defined for the Web Interface and the farms are in separate domains, some farms do not support password changes, or a farm contains a mixture of UNIX and Windows servers, Citrix recommends that you not enable support for the changing of passwords. When you make a password change, the Web Interface contacts each server farm in the order specified until the change request is honored by a farm. At that point, the change password request completes.

Note

When multiple farms reside in different domains and are accessed through the Web Interface, a two-way trust must exist between these domains in order for the application enumeration and access to function properly.


Workspace Control

Workspace Control options are managed within this setting. As we mentioned earlier in this chapter, Workspace Control allows a user to quickly disconnect all running applications, log completely out of all running applications, or reconnect to all of the user's applications, whether disconnected or active at another client device. Workspace Control does require version 8.x or higher of the ICA client.

If users are given the option to override the setting choices you've made on this screen, they see reconnect settings to the Web Interface.

Client-Side Proxy

When a proxy server is employed on the client-side of the Web Interface, you can define settings here that dictate whether the Presentation Server client must communicate through the proxy server when connecting to a MetaFrame server.

Client Deployment

The deployment of Presentation Server clients is managed through the client deployment settings page. The client deployment feature provides a powerful and convenient mechanism for ensuring that your end users have the appropriate client installed. Client installations are advertised in the Web Interface through installation captions in the Message Center portion of the logon page. Figure 14.4 shows what an installation caption looks like in the Message Center.

Figure 14.4. Installation captions prompt the user to install the appropriate client if necessary.

Near the bottom of the client deployment settings page is the Display Client Installation Caption option. It allows you to force captions on or off, or allow them to be auto-detected. When this option is set to Yes, the caption is always displayed, even on Windows machines where the client has been detected. No means the caption is never displayed, and Auto (the default) means the caption is always displayed to non-Windows clients and displayed to Windows clients only if a valid client is not detected .

You can also customize the message displayed by directly modifying the WebInterface.conf file. The specific value to modify is OverrideClientInstallCaption . The same custom message appears regardless of the client choices offered by the Web Interface.

A number of options within the Web Interface Console are configurable for client deployment. Most of the options are specific to the Launch Settings. These settings dictate what client is used to establish a connection with a MetaFrame server when a user clicks an application hyperlink. The information on this page includes

  • Default client Here, you choose the default client that should be used on the client to access published content. The default option is Local Client, which refers to the standard local client corresponding to the client operating system. Other options include the embedded client (ActiveX or Netscape plug-in), the Client for Java, or Embedded Remote Desktop Connection software. If an alternate option is set as the default, note that it is valid only on platforms where the client is supported. For example, the Remote Desktop Connection client is valid only on a Windows 32-bit OS with IE 5.5 or higher.

  • Web Client Settings This box contains settings specific to the ActiveX clients. The default entry corresponds to the Win32 Web client. If you want to deploy the minimal Web client, you can substitute the given cabinet name (wficat.cab) with the name wficac.cab. If you want to deploy the Program Neighborhood or the Program Neighborhood Agent instead of the Web client, you need to manually modify the WebInterface.conf file and edit the Win32Client entry to point to the alternate installation file instead of the default.

    When the Auto-deploy Web Client at Logon option is enabled, the appropriate client is downloaded and installed the first time the user logs on. These settings, along with the Remote Desktop Connection ActiveX settings, are enabled only if the Web client is selected as the default or selected as a possible alternate client. When the Web client has not been chosen as a possible client for installation, these options are grayed out.

  • Client for Java These options allow you to choose the components included with the Java applet. Selecting only the packages required minimizes the size of the data downloaded. One option to note is the Use a Private Root Certificate setting. If you are implementing Secure Gateway for MetaFrame or SSL Relay (both discussed later in this chapter) and have used certificates that require a root certificate not already available on a client, you can use this option to deliver that certificate to the client. The certificate must be placed into the same folder as the Java client packages on the web server.

    The Java client is ideal for environments where client installation files cannot be downloaded and installed.

  • Legacy Support This setting dictates whether Unicode ICA files are generated by the Web Interface. Legacy clients do not understand Unicode ICA files.

Client Customization

Client Customization allows you to define what options a client can override. The three options are window size, window color , and audio quality.

Server Settings

Within the Server Settings, you manage the server farms, associated servers, and DMZ settings.

Manage Farms

The Web Interface supports the creation of an application set based on information gathered from one or more server farms. All the available applications from each farm are retrieved and then displayed within the same interface. If applications in different farms have the same name, the user appears to have duplicate application entries. Applications should have unique names if they will be displayed within the Web Interface to reduce user confusion.

When you define the single MetaFrame server during the Web Interface installation, the default farm named "Farm1" is created, and that MetaFrame server is assigned to that farm. The farm name within the Web Interface is an arbitrary name used only to distinguish the different server lists. These names are not used to validate with the actual server farms. Although you can call these farms whatever you like, you should name them to match your farm names. Farms are easily added, deleted, and arranged. Farms have a priority because the Web Interface contacts each farm to acquire applications. When all information is retrieved from one farm, the Web Interface then moves on to the next . If contact with a farm is slow, it affects the speed with which the applications are displayed.

MetaFrame Servers

Each farm that is created is assigned its own list of servers. All the listed servers must be running the Citrix XML service. Each listed server is eligible to be used by the Web Interface to communicate with the appropriate server farm. When a new server is added, it is added to the bottom of the list. The ordering of the servers is relevant only when employing fault tolerance. By default, the server list is used for load balancing, which distributes connections among all the available servers. If connectivity to a server fails, it is removed from the list for the default of 60 minutes, a setting that can be edited. If the load balancing option is disabled, the Web Interface treats the list as a fault tolerance list. Requests are all processed by the highest priority server unless it fails, at which point it does not attempt to contact that server again for the default of 60 minutes. If all servers fail under either scenario, the Web Interface tries to reconnect every 10 seconds.

All three transport types are available for use. HTTP, the default choice, transmits information to and from the XML Service in plain text. HTTPS is valid only when IIS is also running on the MetaFrame server and the XML Service is configured to share the port with IIS. IIS must also be configured to support HTTPS (SSL or TLS). The final choice is SSL Relay, a listening service that can be configured on each MetaFrame server that you want to communicate securely with the Web Interface server.

Network Address Translation

Network address translation (NAT) allows a local area network to use a set of IP addresses internally, while a separate set of addresses is used for external, usually Internet, traffic. Typically, a hardware- or software-based firewall exists between the two networks and is responsible for managing the translation of addresses from the external to the internal, and vice versa.

When a user accesses the Web Interface from an external address, you need to ensure that you have properly configured network address translation to ensure the Web Interface returns the appropriate external address for a Presentation Server. If NAT is not configured, the Web Interface returns the default or internal address to the external user. The user is unable to connect to the server because that address is invalid on the external network.

The default address translation settings are applied to all users connecting to the Web Interface, unless you have defined a specific address translation setting. When configuring specific address translation settings, you define the subnet address and mask and then configure the appropriate translation behavior. When the Web Interface matches these settings to a client's network, the specific settings are used instead of the default settings.

Both the default and specific settings share common options:

  • Normal address This is the default behavior. The actual address of the Presentation Server is returned to the client.

  • Alternate address The alternate address defined on the MetaFrame server is returned to the client. You configure alternate addresses on a MetaFrame server using the ALTADDR command-line utility.

  • Translated address The Web Interface consults the server address translation map (at the bottom of the page) to determine the translated address to return to the client. When creating a translation entry, you specify the internal address and port for the server. You then specify the equivalent translated (external) address with the associated translated port number. This translation map is a convenient alternative to defining alternate addresses directly on each server. The use of fully qualified domain names (FQDNs) or IP addresses for the server address is dictated by the AddressResolutionType value in the WebInterface.conf configuration file. If the value is set to DNS-port or DNS, the server address must be a FQDN. If the value is IPv4-port or IPv4, it must be an IP address. The default resolution type is IPv4-port.

  • Secure Gateway Server When the Secure Gateway Server is employed, this option must be selected along with the corresponding translation type. Choosing a translation type for the Secure Gateway determines how Presentation Server addresses are translated when the Secure Gateway attempts to communicate with a server. A translation option is required only if NAT is employed on a firewall between the Secure Gateway and the MetaFrame server farm. If the translated address option was chosen, you do not populate the address translation map on this page. Instead, you need to populate similar settings on the Secure Gateway Support page. Secure Gateway configuration for the Web Interface is reviewed in the next section of this chapter.

Alert

Remember that specific address translation settings are used as exceptions to the default settings. When both external and internal users are using the Web Interface, it is best to define the default configuration for external users and then define exceptions for users on the internal network.


Secure Gateway Support

If you have deployed Secure Gateway in your environment, you need to configure the Web Interface to work with the Secure Gateway. Configuring the Secure Gateway is discussed in the "Securing Server Access with the Secure Gateway" section of this chapter.

With the Secure Gateway, clients no longer connect directly to the appropriate MetaFrame server in the farm. Instead, the client is directed to the Secure Gateway, through which the connection is created and managed. All traffic to and from the Presentation Server is directed through the Secure Gateway.

On the Secure Gateway Support page, you configure the following options:

  • Secure Gateway Server You provide the fully qualified domain name for the Secure Gateway Server. This address is passed to the client so that it can connect to the Secure Gateway. This name must match the certificate installed on the Secure Gateway. The default port number is 443, but this can be changed if necessary.

    You also provide the full URL to one or more servers running the Secure Ticket Authority (STA). The STA is responsible for generating tickets, which are passed to the client, then to the Secure Gateway, and eventually back to the STA in exchange for the information necessary to launch the application requested by the client. Tickets generated by the STA are different from those generated by the Web Interface without the Secure Gateway. Web Interface tickets replace the use of user credentials in the generated ICA file. STA tickets replace not only the user credentials, but also the specific MetaFrame server and published application information. Multiple STAs can be provided, and by default, they load balance exactly the same way that the Web Interface load- balances access to the Citrix XML Service. If an STA server is unavailable, it is removed from the list for the same period of time defined on the MetaFrame Servers property page (60 minutes by default).

    Note

    Citrix does not recommend the use of third-party load balancers for managing access to multiple STA servers.


  • Internal firewall address translation map If you have configured the NAT property page to use the Secure Gateway with translated addresses, then it is here that you actually define the list of server and translated addresses. You are required to configure translated or alternate addresses with the Secure Gateway only if a firewall exists between the Secure Gateway and the Presentation Servers, and that firewall is employing NAT to access the Presentation Servers. NAT is not required when the only firewall that exists is the one between the Secure Gateway and the client device.

Disabling Error Messages

On the Windows platform, you have the option to disable the custom Web Interface error messages and display more informative messages. You do this by editing the web.config file. The file is located in

< WebRoot >/Citrix/MetaFrame/WIAdmin

Change the default setting of

 <customErrors mode="On" defaultRedirect="html/serverError.html" /> 

to

 <customErrors mode="Off" defaultRedirect="html/serverError.html" /> 

The custom message simply says "An internal error occurred" if a server error is encountered .



Citrix CCA MetaFrame Presentation Server 3. 0 and 4. 0 Exam CramT (Exams 223 and 256)
Citrix CCA MetaFrame Presentation Server 3. 0 and 4. 0 Exam CramT (Exams 223 and 256)
ISBN: N/A
EAN: N/A
Year: 2003
Pages: 199

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net