Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.


share|improve this question
up vote 1 down vote accepted

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.

share|improve this answer

Our DBA just found the proper solution, and it works without adding that local user.

Basically it's something to do with when you catalog the connection on the DB2 Application server, you must specify something like 'Authentication Server'. This prevents the DB2 driver from authentication against the Active Directory.

I know the answer is vague, but that's the most I could get out of him.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.