I have a ASP.NET application running on Windows 2003 that needs to communicate with a DB2
database that resides on the mainframe. We installed DB2 Client driver v9.5 on our server so the application can perform the connection and work with the database. The connection string to connect to the database contains the username and password, it is not a trusted connection.
To be clear, we are using the DB2 .NET provider and not OLE DB, ODBC, etc.
What we're noticing is that when the ASP.NET application is attempting to make that first connection to DB2, it takes a very long time, roughly 20 seconds. After talking to one of our resident DBAs, they said it may be because the DB2 driver is trying to authenticate the user account that is being used to connect to the database, against Active Directory.
Their solution to this was to create a local user account on the Win2003 server, with the same name as the user account that is being used to make the connection. The local user account does not have to be a member of any acl groups and it can be disabled.
I tried this solution, and to my amazement, it actually worked. The connection was made within milliseconds. What I am concerned with is that this "feature" seems like a flaw in the DB2 driver, and any new versions of this driver could actually prevent this from working again.
Does anyone know if there is an actual setting in the DB2 driver that we could set, so it does not try to authenticate with Active Directory? I would feel more comfortable using that setting, than relying on, what looks to me, a flaw in their authentication algorithm.
Thanks
Best Answer
In the db2 client configuration setup there are sever options for authentication. The descriptions on the options are confusing. The default is "use authentication define in servers dbm config". On the client the "servers dbm config" really means the local machine. If your local machine is microsoft windows then the connection will try to authenticate the ID using the default authentication method. If the default is active directory then things can get very slow. Once it gets a return from windows (good or bad) it will try to connect to db2 using the id/passwd anyway. Thats why your DBA said to catalog the connection with "use server authentication". There is a bug in mix too. If your using odbc it may try and go to the domain controllers anyway and to fix that a local id would be required.