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.