I have seen a couple of issues lately launching CLNTRUST. Besides the issue with Symantec Antivirus as described below. One issue is that CLNTRUST doesn't want to be launched from a batch file. Novell tells me that it really is designed to launch from the login script though I have to admit I don't see why there would be a distinction on how it launches.
Another issue is that on some PC's (usually Win2k or XP), the login script hangs when you hit the CLNTRUST launch. In particular, I have seen this happen with very recent versions of CLNTRUST, such as in BM37FP4D.EXE. For these systems, using the @ symbol instead of the # symbol to launch CLNTRUST seems to work fine. Using an @ symbol to launch an external program causes the login script process to continue and not wait for the program to finish launching. (Best to do some research on this if you are not aware of the difference between using # and @ in login scripts).
In general, you may have issues using certain versions of CLNTRUST with certain versions of Windows. You may find that older versions of CLNTRUST work better on Win98, while the latest one (using @ to launch it) works better on WinXP and Win2k. You can use an IF statement in the login script to test for OS version, and branch to a section of the login script that launches a specific version of CLNTRUST.
Microsoft's Windows XP service pack 2 enables the XP personal firewall by default. This will cause CLNTRUST to fail, until you disable the personal firewall again. See the note
below dated Feb. 3., 2003. If you need to run the XP firewall, configure it to allow UDP port 3024 (CLNTRUST port). Also, if you have BorderManager 3.8, be aware that 3.8 ships with the Novell Client
Firewall (NCF), which is a pretty good personal firewall. You can find NCF in the sys:public\brdrmgr\ncf directory.
CLNTRUST works by responding to proxy requests, not by making a request to a proxy. That means that the PC must accept inbound connections from the proxy server. Any personal firewall (XP's, ZoneAlarm, Black Ice, etc.) can cause the same issue. For Windows XP, type Firewall into the built-in Help engine, and it should take you to instructions on enabling or disabling the Internet Connection Firewall, which is done as an advanced property of the network connection in use.
If you see your PC's hanging on CLNTRUST, during or after loading in the login script, be aware there is some issue when using CLNTRUST at the same time as Symantec Antivirus 9.0 if the
antivirus software was installed with the POP3/SMTP option. As far as I know, the only solution is to remove the POP3/SMTP option (from the add/remove programs menu). You may be fine until opening a
browser, when proxy traffic invokes a CLNTRUST authentication request, at which point the PC locks up. Here is some information from the Novell Public Forums:
Tom Hafemann says "First, all were running SAVCE 8.1 and were upgraded to 9.0. They have SymantecAntivirusUser and SymantecAntivirusAdmin groups. The users are a part of the SAVuser group.
Most of them are running NW 6 or NW 6.5 SBS with BM 3.7 sp2 and all the patches. The also have groupwise 6 or 6.5 and Zen 3.2 or 4.0.1. The login script has the normal SAV stuff in it to do the
automatic update. CLNTRUST is near the end of the login scrip. The SAV SSC has everything but file system auto-protect turned off. During the upgrade, all that stuff, including internet Email
Auto-protect, Lotus Notes Auto-protect and Mircosoft Echnage Auto-protect are installed but not turned on.
There are a few services regarding "symantec" that are set to Manual. The most problem one seems to be the Symantec Name ???? that acts as a service proxy. Once this is gone, the problem goes away.
This is the service that Internet e-mail autoprotect uses."
Matt Hudson says "The only fix for this I have found is to remove the "POP3/SMTP Snap-In" via add/remove programs."
If you are seeing some PC's fail to work with some PC's and have no problems with others, check the revision date of CLNTRUST.EXE being used. I have seen issues with the versions dated 2003 that went away when using an older version. In BM37SP2.EXE, there is a version dated April 16, 2002. In field test patch BM37FP3E (and some earlier ones), there is a version dated Sept, 2003. I have been finding that PC's having problems with the 2003 version work fine with an earlier version. Try backrevving. Mar. 2, 2004: If you can't find an older version that works, try the April, 2002 version here.
An issue I saw on a client system today was related to licensing. For some reason, CLNTRUST was reporting a continuously updating success count in the CLNTRUST stats. The network had a single NW 6.0 server running BorderManager 3.7, and the rest of the servers were running NW 5.1. There were no NW 6.0 user licenses in the tree, and two grace logins were in use on the BorderManager server. Freeing a license on that server got CLNTRUST working for my client. I know that CLNTRUST is not supposed to need a license, but in this case, it appeared to be failing due to a licensing issue.
Another issue I saw today, on a different client, was an intermittent failure of CLNTRUST to work. At times it was fine, but other times, the SSL Login screen popped up instead. This one was due to filtering, with CLNTRUST trying to talk to the server's public IP address instead of the private one. I had already included the private address in NCP parameters, but it was not helping on this NW 6.5 server. I finally allowed port 524 from private interface to the public IP address with a stateful filter exception. (I have had an example of this in my BorderManager filtering book for years, and I call it CLNTRUST-ST there).
This is just an FYI. There are various versions of CLNTRUST available, depending on BorderManager version and service pack/patch level. There is a version of CLNTRUST that gets
installed with BorderManager itself. If that version works fine for you, you can leave it in place. There is also a newer version (April 16, 2002) in the BM37SP2 patch, and a newer version than that
(Sept. 5,l 2003) in the BM37FP3D patch. (The version in BM37FP3D has the new /noicon command line feature, where you can hide the icon from the users). If you are having problems with CLNTRUST
working, you might as well try different versions.
Updated Nov. 6, 2002: I have pulled the interim field test version of CLNTRUST off my web site as the version number was incorrect, and was causing confusion with Novell support.
If you want the newer version, get it from the latest BorderManager patch. Note - some people in the Novell public forums have said that the new version did not work with XP, but back-revving to the
older version worked for them. You should use the version that works best for you, and if necessary, CLNTRUST can be launched from a C: drive.
Also, CLNTRUST 1.4, will not work if the BorderManager server does not have a replica on it. (And BorderManager servers SHOULD have a replica that at least holds the server object and its
licenses).
UPDATE, May 31, 2002: Novell's officially updated version of the CLNTRUST program is included in the PXY031.EXE and BM36C02.EXE (and later) patches. The problem discussed below is addressed
with the new version of CLNTRUST.
When Windows XP came out, there were frequent reports of problems getting any version of CLNTRUST to work properly. Symptoms would be 403 Forbidden errors, or SSL Login screens popping up even though
CLNTRUST was running. Sometimes repeated attempts to load a web page would result in success. Sometimes increasing the SSO Timeout value (to 30 seconds or more) in NWADMN32 would help. Occasionally,
these problems were also seen on Windows 2000.
Novell found a problem in how requests to CLNTRUST were handled between CLNTRUST and certain versions of Client32 on Windows XP Professional. As of April 10, 2002, an updated version of CLNTRUST has
been available, and users testing it have reported nearly 100% success with it. The new file will be available soon as an official patch, and should show as version 1.4.
You can run CLNTRUST from a server, or a workstation. If you want to replace the version on a server (in the SYS:\PUBLIC directory), you may experience problems trying to copy it with the old version
being held open while it is in use. You may need to clear all user connections (can do this with a dismount/remount SYS if you are desperate), or remapping the CLNTRUST load in the login script
temporarily to a different server.
*** The remainder of this tip discusses an old patch issue, and is not relevant to current patches ***
Running CLNTRUST.EXE is the easy way to get Proxy Authentication working. CLNTRUST.EXE made its appearance with BorderManager 3.0, and was updated once in the BM3SP2.EXE patch. For some
reason, that update, which was minor, never made it into a BorderManager 3.5 patch, though you could easily pull it out of the BorderManager 3.0 patch and run it on a BorderManager 3.5 server.
That is, until now. There is a new CLNTRUST.EXE, dated 6/22/00, which has been released for BorderManager 3.0 and 3.5 in the BM3SS01.EXE patch. You can find it on the Novell Minimum Patch List. It is
supposed to provide a faster way to authenticate over IP connections when tree-walking is required.
Have a look at the readme.txt file included in the patch. There is this:
"INSTALLATION INSTRUCTIONS:
BEFORE YOU USE THIS NEW FILE
- Your server must be a NetWare 5.x server.
- Your client must be v.3.21 (for Windows95/98) or v.4.71 (for WindowsNT).
- Your client must be capable of mapping a drive to the BorderManager server
over IP (not IPX)."
And later, there is this:
"So, users who are not running the right version of Client32, or don't have it
installed correctly will see no difference by using this version of
CLNTRUST.EXE. Also, users of BorderManager running on NetWare 4.11 will see no
difference by using this version of CLNTRUST.EXE as NetWare 4.11 does not
accept NCP connections over IP."
Several reports have come into the Novell public forums that say the new version of CLNTRUST.EXE does NOT work correctly in an IPX environment. It appears that the new CLNTRUST never falls back on the 'old apis' when used with Client32 v3.21. Here are some comments from a user that sums things up.
"I'm running into a problem with 403 error. You are not logged into this
server.
I'm running CLNTRUST on a different server than the BM 3.5 server. They
are both in the same tree though. The BM 3.5 server is a 4.11 patches
with sp8a, and BM is patched with all the latest patches. I tried to
move CLNTRUST over to the w/s hd and increased time out in NWadmin, but
still all my users are getting the 403 error. I removed athentication
and you can browse just fine."
"Small update. Watching CLNTRUST on the client when you try to go to any web
page you can see Request Failed: climb by a obscene amount on each web page
request."
Turns out he was running the new version of CLNTRUST. I told him to try the original version because of reports of problems with the new version. He tried that and replied:
"I reinstalled the older CLNTRUST.EXE from the CD and that fixed the
problem. Odd very odd though. The old NW client 32 ver 3.2 works fine
with the newer clntrust from BM3SSO1. But the new client 32 ver 3.21
doesn't. It works with the older CLNTRUST."
So if you have installed the BM3SSO1 version and now have problems with Client32 v3.21, try going back to the older version.