DB2 Version 9.7 for Linux, UNIX, and Windows

Trusted context problem determination

An explicit trusted connection is a connection that is successfully established by a specific, explicit request for a trusted connection. When you request an explicit trusted connection and you do not qualify for one, you get a regular connection and a warning (+20360).

To determine why a user could not establish a trusted connection, the security administrator needs to look at the trusted context definition in the system catalogs and at the connection attributes. In particular, the IP address from which the connection is established, the encryption level of the data stream or network, and the system authorization ID making the connection. The -application option of the db2pd utility returns this information, as well as the following additional information:

Connection Trust Type: Indicates whether the connection is trusted or not. When the connection is trusted, this also indicates whether this is an explicit trusted connection or an implicit trusted connection.
Trusted Context name: The name of the trusted context associated with the trusted connection.
Role Inherited: The role inherited through the trusted connection.

The following are the most common causes of failing to obtain an explicit trusted connection:

The client application is not using TCP/IP to communicate with the DB2® server. TCP/IP is the only supported protocol for a client application to communicate with the DB2 server that can be used to establish a trusted connection (explicit or implicit).
The database server authentication type is set to CLIENT.
The database server does not have an enabled trusted context object. The definition of the trusted context object must explicitly state ENABLE in order for that trusted context to be considered for matching the attributes of an incoming connection.
The trusted context objects on the database server do not match the trust attributes that are presented. For example, one of the following situations may apply:
- The system authorization ID of the connection does not match any trusted context object system authorization ID.
- The IP address from which the connection originated does not match any IP address in the trusted context object considered for the connection.
- The data stream encryption used by the connection does not match the value of the ENCRYPTION attribute in the trusted context object considered for the connection.
You can use the db2pd tool to find out the IP address from which the connection is established, the encryption level of the data stream or network used by the connection, and the system authorization ID making the connection. You can consult the SYSCAT.CONTEXTS and SYSCAT.CONTEXTATTRIBUTES catalog views to find out the definition of a particular trusted context object, such as its system authorization ID, its set of allowed IP addresses and the value of its ENCRYPTION attribute.

The following are the most common causes of a switch user failure:

The user ID to switch to does not have CONNECT privileges on the database. In this case, SQL1060N is returned.
The user ID to switch to, or PUBLIC, is not defined in the WITH USE FOR clause of the trusted context object associated with the explicit trusted connection.
Switching the user is allowed with authentication, but the user presents no credentials or the wrong credentials.
A switch-user request is not made on a transaction boundary.
The trusted context that is associated with a trusted connection has been disabled, dropped, or altered. In this case, only switching to the user ID that established the trusted connection is allowed.