Unanswered: Active Directory authentication latency / most efficient DB2-AD connection settings
Sorry...this is a bit general, but I suspect someone here has specific information on things I can try. I have run into this issue in the past, and I am now trying to answer the question for a couple of other DBAs that have the same issue using the same DB2-based application: a number of application that all use the same DB2 database seem to take an extraordinarily long time during the Active Directory authentication phase when opening the application. Now, I know this depends on what the application is specifically doing; however, the third-party developers have assured us that the place where we see the latency is, indeed, during Active Directory authentication.
The environment is previous DB2 9.7 FP 7 now being migrated to DB2 10.5 (not sure which FP, though). So my question here is how one might specifically trace latency, which possible registry settings or DB2 configuration settings are related, whether there are Hyper-V host/guest machine settings that could affect this, and--most of all--if there are specific DB2 settings related to AD authentication that can make authentication to the same AD organization more efficient than others. In all cases, there is no big forest involved, just a single AD DC.
It has been suggested to duplicate the AD username, password, and group as local objects on the DB2 server; however, that solves the problem only for the DBA doing the testing, not for the end users that, once all of our upgrade testing is done, will be stuck with any poor choices we make in testing as we attempt to figure this all out. I saw a suggestion on one geek site to run this: db2set -g DB2_GRP_LOOKUP=local. However, that looks suspiciously like a workaround that could backfire when the bulk of domain users later need to connect and do not have local accounts.
And yes, I am already aware of some detail on this via the IBM site, such as here: http://www.ibm.com/support/knowledge.../c0055077.html. But even as a fairly geeky geek, I cannot really tell what that all means regarding efficiency and potential latency for the real world where all users exist in AD only and not on the local (DB2 server) machine.
In the end, this turned out to be an application-specific issue in which the application vendor made a network call to one of their servers, and the DBA in question was working with a server that did not have internet access, and there was a rather high timeout set. Go figure; it was not even a DB2 issue! The user got a registry hack from the provider to disable this call. Not sure why the vendor needs our servers contacting their systems...sounds kind of like Microsoft's data-collection stuff that arrived in Windows 7 along with the Windows 10 upgrade prompts.