403 Access Denied error - timeout issue?

• Install a packet sniffer (e.g. Wireshark) on the client (not on the server), and play with it to make sure that you have the right setting (On or Off) for the Promiscuous flag, so that you get a good capture of all incoming and outgoing packets (but don't get duplicate copies of all outgoing packets)
• Reboot the client so that all the caches are empty (particularly DNS and Kerberos)
• Start up IE but don't visit the VSJ-enabled site yet
• Start the packet sniffer, visit the VSJ-enabled site and successfully do SPNEGO single sign-on, then stop the packet sniffer
• Save that packet trace to a file, then look at it.  Observe that the client makes a Kerberos 5 TGS-REQ to Active Directory for some service principal name and successfully receives a TGS-REP.  [If you hadn't rebooted then this Kerberos ticket might already be cached on the client, so you wouldn't get to see this network traffic].  Make a note of the successful service principal name.
• Wait until you are pretty sure that the failure will occur, then start the packet sniffer again, do whatever it is you do in IE to trigger the failure, then stop the packet sniffer once you have captured the failure.
• Save that packet trace to a different file, then look at it.  You will probably see that the client now makes a Kerberos 5 TGS-REQ for a different service principal name and that AD now sends a Kerberos error response that boils down to "Server not found in Kerberos database".
• Make a note of the unsuccessful service principal name.  Compare it with the successful SPN, and with the SPN mapping(s) that you have set up for VSJ, and with the hostnames that you use in URLs to access the VSJ-enabled site.

However, the approaches that I recommend are one or both of the following:

1. Always use the FQDN, both in the URLs that you use to access in VSJ and in the SPN mapping that you create for VSJ (and hence in the idm.princ value).  Never use the unqualified hostname (aka short name, aka NETBIOS hostname).  Also, don't use DNS aliases;  always use canonical names.
2. Use setspn.exe to add extra SPN mappings for all the SPNs that the client (IE/Windows) somehow ends up using, i.e. make sure that you have SPN mappings both for the FQDN and for the unqualified name.  Also, if you are using DNS aliases, then make sure you have SPN mappings both for the alias and for the canonical name (and, for each of those, you want both the FQDN and the unqualified name).

Approach (1) is a good goal but may not be feasible in some environments because it requires discipline (and people who are accustomed to using short names definitely won't like it), whereas approach (2) should work anywhere.