Client trust fails 1st time, after two refreshes succeeds

Question

For some reason this year after installing NW6.5 SP7, my BM 3.9 server seems to be failing to authenticate via the Client Trust the first time someone tries to open a web browser.
If the end-users click refresh in the browser two or three times, the trust authentication then succeeds and all is well from that point forward.
The NW6.5 BM machine in question was also virtualized last summer but I don't see what that would have to do with anything. The servers were upgraded and the original BM server converted to virtual disk files.
This machine has an I2O SCSI RAID controller and Novell decided to stop I2O support back in SP6, while Microsoft continues to support I2O without complaint. So to deal with the I2O support problems the machine runs Windows 2003 SP2, the free VMWare Server 1.06, and NW65SP7.
The machine has dual 1.4 ghz Xeons, and windows task manager load never exceeds 20% on CPU 1, with zero load on CPU 2. Two gig of RAM and 1 gig allocated to the BM VM, so the machine is not busy and it is not thrashing its memory.
A third issue the might be related but I cannot tell, is that the DSRepair Time synchronization check always shows a +1 for this server (from other servers) or a -1 for other servers (from this server). The time sources appear to be configured correctly, with a different NW65SP7 server being the master for all local servers including this one.
Yes, I am aware of SP8. I don't do service packs during the school year. I am going to have to wait until at least June before that can be done.

Answer 1

The little issues you noted seem entirely unrelated to me (timesync,
hardware, etc.)
What we need is a little more specific data for troubleshooting.
CLNTRUST works as follows:
1. Browser requests file from proxy, and proxy sees need to
authenticate user.
2. PROXY issues a UDP 3024 request TO the client. Note that this is
not a request initiated by the client where the proxy responds to it.
It is a request initiated by the server to the client, so the client
firewall has to allow that traffic.
3. Proxy waits for specified amount of time for a response from the
client. This is 3 seconds by default, which is normally plenty of
time. However, feel free to increase that value a bit, say to 5
seconds. (In the Authentication Context menu for Proxy). If you go
higher than 5 seconds, and it helps, I have to question what's wrong
with your network! Anyway, it can be useful to capture packets to see
what is going on. PKTSCAN.NLM can be used on the server to do that.
Wireshark can be used on the client.
4. Client PC receives a CLNTRUST request, and CLNTRUST responds.
Client32 also (I think) passes data to the server with user name and
password hash. However it works at this point, the important thing
about debugging here is that you should see a successful request in the
CLNTRUST stats. Problems include seeing no requests at all (0 usually
means firewall blocked the inbound traffic, though a nat hop between
server and client can also do that. Thousands of failed requests
usually means client isn't logged in or is not in the same tree).
5. Client PC's responses are returned to server, which looks up
username and confirms password hash. Proxy associates browser's IP
address with user name and compares name against access rules. User
name shows up in log files.
So, look for presence of UDP 3024 packets at the client to start with.
If there are network issues, where packets get dropped, you might see
the symptoms described.
Craig Johnson
Novell Support Connection SysOp
*** For a current patch list, tips, handy files and books on
BorderManager, go to http://www.craigjconsulting.com ***