Authentication considerations for remote clients
When you catalog a database for remote access, you can specify the authentication type in the database directory entry.
Recovery can result in more flows to reconcile the difference, or in an error if the Db2 database cannot recover. In the case of a mismatch, the value at the server is assumed to be correct.
The authentication type DATA_ENCRYPT_CMP is designed to allow clients from a previous release that does not support data encryption to connect to a server using SERVER_ENCRYPT authentication instead of DATA_ENCRYPT. This authentication does not work when the following statements are true:
- The client level is Version 7.2.
- The gateway level is Version 8 FixPak 7 or later.
- The server is Version 8 FixPak 7 or later.
When these are all true, the client cannot connect to the server. To allow the connection, you must either upgrade your client to Version 8 or later, or have your gateway level at Version 8 FixPak 6 or earlier.
The determination of the authentication type used when connecting is made by specifying the
appropriate authentication type as a database catalog entry at the gateway. This is true for both
Db2 Connect scenarios
and for clients and servers in a partitioned database environment where the client has set the
DB2NODE registry variable. You will catalog the authentication type at the
catalog partition with the intent to hop
to the appropriate partition. In this scenario, the
authentication type cataloged at the gateway is not used because the negotiation is solely between
the client and the server.
You may have a need to catalog multiple database aliases at the gateway using different authentication types if they need to have clients that use differing authentication types. When deciding which authentication type to catalog at a gateway, you can keep the authentication type the same as that used at the client and server; or, you can use the NOTSPEC authentication type with the understanding that NOTSPEC defaults to SERVER.