com.dstc.security.kerberos.KerberosError: Client not found in Kerberos database (39416)

Currently I am using VSJ3.1 and it is working fine. Now I tried to use the latest version VSJ3.2 and getting the following error. Same SPN and keytab files works fine with VSJ3.1

In both VSJ 3.1 and 3.2, the instructions for configuring the VSJ service account in AD specify that ktpass.exe should be used to set a -princ mapping that is consistent with the idm.princ and idm.realm values for VSJ, i.e.
ktpass -princ HTTP/uaxprap3.DATACENTER.RADIANGROUPINC.NET@DATACENTER.RADIANGROUPINC.NET -mapuser your_vsj_service_account
in this scenario.
 
When VSJ starts up, it runs some sanity checks that in effect check whether this mapping is correct (and consistent with idm.princ and idm.realm).   The "Client not found in Kerberos database" error from Active Directory means _either_ that you have zero mappings like this (i.e. you didn't use the command above to configure AD for VSJ) _or_ that you have two or mappings like this for different objects in AD (i.e. duplicate mappings).   Be aware that "Client not found in Kerberos database" errors pertain to the LDAP 'userPrincipalName' attribute (which is what ktpass.exe sets), NOT to the 'servicePrincipalName' attribute.
 
VSJ 3.1 runs these sanity checks if you use VSJ with a password (com.wedgetail.idm.sso.password) but, if you use a keytab (idm.keytab) as you did, VSJ 3.1 blithely assumes that you got everything right and doesn't run the sanity checks.
 
By contrast, VSJ 3.2 always runs the sanity checks regardless of whether you use a password or a keytab.

So this AD configuration issue has been there all along, but VSJ 3.1 didn't tell you about it, and presumably your application hasn't used VSJ in a way that caused this to become a problem at runtime.
 
One quick-and-dirty approach is to set the VSJ 3.2 parameter "idm.disableTicketSanityCheck" to "true", which turns off the sanity-checking code in VSJ 3.2, i.e. makes it behave the same as the way that you have been using VSJ 3.1.