Home > Articles > Operating Systems, Server > Microsoft Servers

  • Print
  • + Share This

Client/MetaFrame Server Communications

The final component to address in securing the NFuse environment is the traffic between the user's ICA client and one or more MetaFrame servers. By default, an ICA client and server will transmit information using Basic Citrix encryption. This information should not be considered secure because anyone with knowledge of the ICA protocol and Basic encryption can sniff user authentication information off the network.

Although the use of session tickets will protect the transmission of the user credentials, it will not protect the ICA session data that is transmitted back and forth while the user is logged on. Citrix does provide strong encryption support for the ICA session, through either FR1 or SecureICA.

The enforcement of strong encryption is configured on the MetaFrame server using the Citrix Connection Configuration utility or Terminal Services Configuration, as shown in Figure 9.

Figure 9

Configuring strong encryption for ICA sessions on a MetaFrame server using Terminal Services Configuration

After it is configured, the MetaFrame server will automatically reject any client connections that do not support the appropriate encryption level.

Before NFuse users will be able to log onto the MetaFrame server, you will need to modify the template.ica file on your site so that the ICA client will use the corresponding encryption level by default. This involves adding the EncryptionLevelSession parameter immediately after the WinStationDriver entry, as shown:

WinStationDriver=ICA 3.0


The four supported encryption levels are:

  • EncRC5-128 - 128-bit encryption

  • EncRC5-0 - 128-bit encryption for logon only

  • EncRC5-56 - 56-bit encryption

  • EncRC5-40 - 40-bit encryption

By default, when utilizing any encryption level stronger than Basic, a MetaFrame server will not allow automatic logins. This is done so that the user credentials are not sent to the server before the establishment of the secure session. Earlier, when I was talking about session tickets, I showed the ICA file parameter called AutoLogonAllowed. The purpose of this parameter is simply to allow the automatic logons to occur even if strong encryption is in place.

Normally, the AutoLogonAllowed option is used in conjunction with session tickets to provide secured user authentication while still allowing automatic logons to occur when strong encryption is being enforced.

Error 1024:Protocol Driver Name Not Found In MODULE.INI

A common error that has been reported when strong encryption is used in combination with seamless widows on an NFuse 1.5-enabled Web site is this “1024” error. The following template.ica file that includes both strong encryption and seamless windows support was generating the error shown in figure 10 for a client of mine who was running the latest version of the 32-bit ICA client (version 6.0) on both Windows 2000 and Windows 98.

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

<[NFuse_setSessionField NFuse_WindowType=seamless]>



WinStationDriver=ICA 3.0


<[NFuse_IFSESSIONFIELD sessionfield="NFUSE_SOUNDTYPE" value="basic"]>







Figure 10

Error 1024 generated when attempting to launch an application using seamless windows and strong encryption.

I found that if I removed the session field tag:

 “<[NFuse_setSessionField NFuse_WindowType=seamless]>
located near the top of the template.ica then users where able
to connect properly using strong encryption, but the application did
not launch seamlessly. Re-adding this line immediately caused
the error to reappear.

Adding to this was the fact that it was only causing problems when launched from within the Web browser. If the generated ICA file was saved on the local client and launched directly then it would connection properly.

Performing the following on the Win98 machine corrected the problem:

  1. I first uninstalled the ICA client from the user’s machine and reboot.

  2. The I searched the disk for any instances of wfica32.exe. An old version was found in the %SystemRoot%.

  3. Then I reconnected to the NFuse Web site but did not install the ICA client.

  4. After logging on to NFuse and selecting an application from the generated application list I received a prompt asking me what I would like to do with the ICA file.

  5. At this point I knew the browser was in no way associated with a “bad” instance of the ICA client and went ahead and reinstalled the 32-bit 6.0 client from within the NFuse Web page.

  6. I then clicked on the application link and it immediately started up, supported both strong encryption and seamless windows.

The Windows 2000 machine, was a little more work. At step 4, when I clicked on the link the mouse turned into an hourglass for a second then back to the pointer without displaying any kind of message. I then opened up REGEDIT and did a search on “application/x-ica” and verified that it was associated with .ICA. I next searched for .ICA and found a reference under the Internet Explorer key to NPICAN.DLL located in the Internet Explorer\PLUGINS directory. Checking the date stamp of the file revealed that it was an only version of the Netscape 32-bit ICA plug-in.

I deleted the references out of the registry and then deleted the NPICAN.DLL file. After this was done, when I returned to IE and clicked on the application link it immediately asked me if I wanted to open or download the template.ica file. I then proceed to reinstall the ICA client and the application link immediately started up with both strong encryption and seamless windows support.

For those of you who are interested, the registry key containing the plug-in information was:

HKLM\Software\Microsoft\Internet Explorer\Plugins\Extension

Under here existed an .ICA subkey.

  • + Share This
  • 🔖 Save To Your Account

Related Resources

There are currently no related titles. Please check back later.