Use the following information to help you troubleshoot issues with your JDBC identity source.
Issue: I have copied all of my users into the indirect.usr table, and the user count on my appliance Admin page has increased, but my users cannot log in. The user count never reconciles to the same number.
I also see one of the following messages in the catalina.out file: mssqljdbc count: 20, or oraclejdbc count: 20.
Answer: The connector for JDBC uses triggered publications, meaning the connector caches the users in the indirect.usr table only if some event (insert, update, delete) has occurred on the indirect.usr table entry, so the built-in triggers add the rows to the indirect.indirect_process table for the connector to consume and process.
To trigger a synchronization of the existing users in the indirect.usr table, you must perform a trigger action. For example, run an SQL query that would touch the records and trigger an update.
UPDATE indirect.usr SET disabled = disabled WHERE idu IS NOT NULL
Issue: I have groups defined in my indirect.grp table, but the users are not being imported to my appliance.
Answer: The connector for JDBC uses triggered publications, meaning the connector will cache the users and groups in the indirect.usr or indirect.grp table only if some event (insert, update, delete) has occurred on the table entry, so the built-in triggers add the rows to the indirect.indirect_process table for the connector to consume and process.
To trigger a synchronization of the existing users in the indirect.usr table, you must perform a trigger action. For example, run an SQL query that would touch the records and trigger an update. For example:
UPDATE indirect.usr SET disabled = disabled WHERE idu IS NOT NULL
For groups, a query similar to the one below will trigger group events:
UPDATE indirect.grp SET group_name = group_name
Issue: I have changed the indirec.proc_authuser stored procedure to use my desired tables for authentication, but I am still getting a login failure.
Answer: There are two separate ways that the stored procedure verifies the user name and password parameters passed to the proc_authuser stored procedure.
Oracle: The password parameter is hashed and then compared to the existing password with the default settings.
MSSQL: The stored procedure uses the PWDCOMPARE built-in function with the default settings.
In some cases, when customizing the stored procedure, the password might not be encrypted. In cases like this, the password= clause in the stored procedure might also need to be altered.