tags:

views:

21

answers:

1

I am from a MSSQL Server background and tried to search to see if there was a way to perform a trusted connection in DB2 similar to how you do that in MSSQL? I basically do not want to have a user name and password in the connection string and have the "runas" user have that information.

Thank you for any help!

UPDATED .NET with the IBM.Data.DB2 provider

+1  A: 

You didn't specify your platform/language, so here are a few ideas.

If you're using Java and Direct connect, the IBM documentation on this can be found here. If it can be done, this is the place to look.

OR for any language that can use ODBC (including .NET. VB6, VBSCRIPT, etc) you can set it up via ODBC, and have the username/password there.

http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp?topic=/com.ibm.db2.udb.apdv.cli.doc/doc/r0021682.htm

And finally, in case these don't work because they don't apply to you, and you're using .NET, if the problem is that you don't want the username and password to be readable in the config file, you can always store part or all of the connection string in the registry to make it more difficult, as described here: http://support.microsoft.com/kb/891028

Hopefully one of these options will work for you.

David Stratton
Sorry about that its .NET with the DB2 provider. I would rather not use the registry because of the frequency the password's change. I was really looking to see if their was a solution that would use the "RunAs" user information instead.
Nic
I understand. If you do come up with a solution, could you post it here as well? We never did, and we do a lot of development for the iSeries. We ended up compromising and setting up a limited range of users with passwords that either do not change (for non-sensitive data) or that we manually coordinate. Most of our web apps look to the same place (the registry on one of our servers) to get the DB2 connection string, and we have the registry keys secured using Active Directory. It's the closest we could get to what you're looking for, which is what we were looking for, too.
David Stratton