Access to an instance or a database first requires that
the user be authenticated. The authentication type for
each instance determines how and where a user will be verified.
The authentication type is stored in the configuration file at
the server. It is initially set when the instance is created. There
is one authentication type per instance, which covers access to that
database server and all the databases under its control.
If you intend to access data sources from a federated database,
you must consider data source authentication processing and definitions
for federated authentication types.
Note: You can check the following website for certification information
about the cryptographic routines used by the DB2® database management system to perform encryption
of the user ID and password when using SERVER_ENCRYPT authentication,
and of the user ID, password, and user data when using DATA_ENCRYPT
authentication:
http://www.ibm.com/security/standards/st_evaluations.shtml.
Switching User on an Explicit Trusted Connection
For
CLI/ODBC and XA CLI/ODBC applications, the authentication mechanism
used when processing a switch user request that requires authentication
is the same as the mechanism used to originally establish the trusted
connection itself. Therefore, any other negotiated security attributes
(for example, encryption algorithm, encryption keys, and plug-in names)
used during the establishment of the explicit trusted connection are
assumed to be the same for any authentication required for a switch
user request on that trusted connection. Java™ applications
allow the authentication method to be changed on a switch user request
(by use of a datasource property).
Because a trusted context
object can be defined such that switching user on a trusted connection
does
not require authentication, in order to take full advantage
of the switch user on an explicit trusted connection feature, user-written
security plug-ins must be able to:
- Accept a user ID-only token
- Return a valid DB2 authorization
ID for that user ID
Note: An explicit trusted connection cannot be established
if the CLIENT type of authentication is in effect.
Authentication types provided
The following
authentication types are provided:
- SERVER
- Specifies that authentication occurs on the server through the
security mechanism in effect for that configuration, for example,
through a security plug-in module. The default security mechanism
is that if a user ID and password are specified during the connection
or attachment attempt, they are sent to the server and compared to
the valid user ID and password combinations at the server to determine
if the user is permitted to access the instance.
Note: The server
code detects whether a connection is local or remote. For local connections,
when authentication is SERVER, a user ID and password are not required
for authentication to be successful.
- SERVER_ENCRYPT
- Specifies that the server accepts encrypted SERVER authentication
schemes. If the client authentication is not specified, the client
is authenticated using the method selected at the server. The user
ID and password are encrypted when they are sent over the network
from the client to the server.
When the resulting
authentication method negotiated between the client and server is
SERVER_ENCRYPT, you can choose to encrypt the user ID and password
using an AES (Advanced Encryption Standard) 256-bit algorithm. To
do this, set the
alternate_auth_enc database
manager configuration parameter. This configuration parameter has
three settings:
- NOT_SPECIFIED (default) means that the server
accepts the encryption algorithm that the client proposes, including
an AES 256-bit algorithm.
- AES_CMP means that if the connecting client proposes
DES but supports AES encryption, the server renegotiates for AES encryption.
- AES_ONLY means that the server accepts only AES
encryption. If the client does not support AES encryption, the connection
is rejected.
AES encryption can be used only when
the authentication method negotiated between the client and server
is SERVER_ENCRYPT.
- CLIENT
- Specifies that authentication occurs on the database partition
where the application is invoked using operating system security.
The user ID and password specified during a connection or attachment
attempt are compared with the valid user ID and password combinations
on the client node to determine whether the user ID is permitted access
to the instance. No further authentication will take place on the
database server. This is sometimes called single signon.
If the
user performs a local or client login, the user is known only to that
local client workstation.
If the remote instance has CLIENT
authentication, two other parameters determine the final authentication
type: trust_allclnts and trust_clntauth.
- CLIENT level security for TRUSTED clients only:
Trusted clients are clients that have a reliable, local security
system.
When the authentication type of CLIENT has been selected,
an additional option might be selected to protect against clients
whose operating environment has no inherent security.
To protect
against unsecured clients, the administrator can select Trusted Client
Authentication by setting the trust_allclnts parameter
to NO. This implies that all trusted platforms can
authenticate the user on behalf of the server. Untrusted clients are
authenticated on the Server and must provide a user ID and password.
You use the trust_allclnts configuration parameter
to indicate whether you are trusting clients. The default for this
parameter is YES.
Note: It is possible to trust
all clients (trust_allclnts is YES)
yet have some of those clients as those who do not have a native safe
security system for authentication.
You might also want to
complete authentication at the server even for trusted clients. To
indicate where to validate trusted clients, you use the trust_clntauth configuration
parameter. The default for this parameter is CLIENT.
Note: For
trusted clients only, if no user ID or password is explicitly provided
when attempting to CONNECT or ATTACH, then validation
of the user takes place at the client. The trust_clntauth parameter
is only used to determine where to validate the information provided
on the USER or USING clauses.
To protect against all clients,
including JCC type 4 clients on z/OS® and System i® but excluding native DB2 clients on z/OS, OS/390®,
VM, VSE, and System i,
set the trust_allclnts parameter to DRDAONLY.
Only these clients can be trusted to perform client-side authentication.
All other clients must provide a user ID and password to be authenticated
by the server.
The trust_clntauth parameter
is used to determine where the clients mentioned previously are authenticated:
if trust_clntauth is CLIENT,
authentication takes place at the client. If trust_clntauth is SERVER,
authentication takes place at the client when no user ID and password
are provided and at the server when a user ID and password are provided.
Table 1. Authentication Modes using TRUST_ALLCLNTS
and TRUST_CLNTAUTH Parameter Combinations.| trust_ allclnts |
trust_ clntauth |
Untrusted non- DRDA® Client
Authen- tication (no user ID & password) |
Untrusted non- DRDA Client
Authen- tication (with user ID & password) |
Trusted non- DRDA Client
Authen- tication (no user ID & password) |
Trusted non- DRDA Client
Authen- tication (with user ID & password) |
DRDA Client
Authen- tication (no user ID & password) |
DRDA Client
Authen- tication (with user ID & password) |
|---|
| YES |
CLIENT |
CLIENT |
CLIENT |
CLIENT |
CLIENT |
CLIENT |
CLIENT |
| YES |
SERVER |
CLIENT |
SERVER |
CLIENT |
SERVER |
CLIENT |
SERVER |
| NO |
CLIENT |
SERVER |
SERVER |
CLIENT |
CLIENT |
CLIENT |
CLIENT |
| NO |
SERVER |
SERVER |
SERVER |
CLIENT |
SERVER |
CLIENT |
SERVER |
| DRDAONLY |
CLIENT |
SERVER |
SERVER |
SERVER |
SERVER |
CLIENT |
CLIENT |
| DRDAONLY |
SERVER |
SERVER |
SERVER |
SERVER |
SERVER |
CLIENT |
SERVER |
- DATA_ENCRYPT
- The server accepts encrypted SERVER authentication schemes and
the encryption of user data. The authentication works the same way
as that shown with SERVER_ENCRYPT. The user ID and password are encrypted
when they are sent over the network from the client to the server.
The
following user data are encrypted when using this authentication type:
- SQL and XQuery statements.
- SQL program variable data.
- Output data from the server processing of an SQL or XQuery statement
and including a description of the data.
- Some or all of the answer set data resulting from a query.
- Large object (LOB) data streaming.
- SQLDA descriptors.
- DATA_ENCRYPT_CMP
- The server accepts encrypted SERVER authentication schemes and
the encryption of user data. In addition, this authentication type
allows compatibility with down level products not supporting DATA_ENCRYPT
authentication type. These products are permitted to connect with
the SERVER_ENCRYPT authentication type and without encrypting user
data. Products supporting the new authentication type must use it.
This authentication type is only valid in the server's database manager
configuration file and is not valid when used on the CATALOG
DATABASE command.
- KERBEROS
- Used when both the DB2 client
and server are on operating systems that support the Kerberos security
protocol. The Kerberos security protocol performs authentication
as a third party authentication service by using conventional cryptography
to create a shared secret key. This key becomes a user's credential
and is used to verify the identity of users during all occasions when
local or network services are requested. The key eliminates the need
to pass the user name and password across the network as clear text.
Using the Kerberos security protocol enables the use of a single
sign-on to a remote DB2 database
server. The KERBEROS authentication type is supported on various
operating systems, see the related
information section for more information.
Kerberos authentication
works as follows:
- A user logging on to the client machine using a domain account
authenticates to the Kerberos key distribution center (KDC) at the
domain controller. The key distribution center issues a ticket-granting
ticket (TGT) to the client.
- During the first phase of the connection the server sends the
target principal name, which is the service account name for the DB2 database server service, to
the client. Using the server's target principal name and the target-granting
ticket, the client requests a service ticket from the ticket-granting
service (TGS) which also resides at the domain controller. If both
the client's ticket-granting ticket and the server's target principal
name are valid, the TGS issues a service ticket to the client. The
principal name recorded in the database directory can be specified
as name/instance@REALM. (This is in addition to DOMAIN\userID and
userID@xxx.xxx.xxx.com formats accepted on Windows.)
- The client sends this service ticket to the server using the communication
channel (which can be, as an example, TCP/IP).
- The server validates the client's server ticket. If the client's
service ticket is valid, then the authentication is completed.
It is possible to catalog the databases on the client machine
and explicitly specify the Kerberos authentication type with the server's
target principal name. In this way, the first phase of the connection
can be bypassed.
If a user ID and a password are specified,
the client will request the ticket-granting ticket for that user
account and use it for authentication.
- KRB_SERVER_ENCRYPT
- Specifies that the server accepts KERBEROS authentication or encrypted
SERVER authentication schemes. If the client authentication is KERBEROS,
the client is authenticated using the Kerberos security system. If
the client authentication is SERVER_ENCRYPT, the client is authenticated
using a user ID and encryption password. If the client authentication
is not specified, then the client will use Kerberos if available,
otherwise it will use password encryption. For other client authentication
types, an authentication error is returned. The authentication type
of the client cannot be specified as KRB_SERVER_ENCRYPT
Note: The
Kerberos authentication types are supported on clients and servers
running on specific operating systems,
see the related information section for more information. For Windows operating systems, both
client and server machines must either belong to the same Windows domain or belong to trusted domains.
This authentication type should be used when the server supports Kerberos
and some, but not all, of the client machines support Kerberos authentication.
- GSSPLUGIN
- Specifies that the server uses a GSS-API plug-in to perform authentication.
If the client authentication is not specified, the server returns
a list of server-supported plug-ins, including any Kerberos plug-in
that is listed in the srvcon_gssplugin_list database
manager configuration parameter, to the client. The client selects
the first plug-in found in the client plug-in directory from the list.
If the client does not support any plug-in in the list, the client
is authenticated using the Kerberos authentication scheme (if it
is returned). If the client authentication is the GSSPLUGIN authentication
scheme, the client is authenticated using the first supported plug-in
in the list.
- GSS_SERVER_ENCRYPT
- Specifies that the server accepts plug-in authentication or encrypted
server authentication schemes. If client authentication occurs through
a plug-in, the client is authenticated using the first client-supported
plug-in in the list of server-supported plug-ins.
If the client
authentication is not specified and an implicit connect is being performed
(that is, the client does not supply a user ID and password when
making the connection), the server returns a list of server-supported
plug-ins, the Kerberos authentication scheme (if one of the plug-ins
in the list is Kerberos-based), and the encrypted server authentication
scheme. The client is authenticated using the first supported plug-in
found in the client plug-in directory. If the client does not support
any of the plug-ins that are in the list, the client is authenticated
using the Kerberos authentication scheme. If the client does not
support the Kerberos authentication scheme, the client is authenticated
using the encrypted server authentication scheme, and the connection
will fail because of a missing password. A client supports the Kerberos
authentication scheme if a DB2 supplied
Kerberos plug-in exists for the operating system, or a Kerberos-based
plug-in is specified for the srvcon_gssplugin_list database
manager configuration parameter.
If the client
authentication is not specified and an explicit connection is being
performed (that is, both the user ID and password are supplied),
the authentication type is equivalent to SERVER_ENCRYPT. In this case,
the choice of the encryption algorithm used to encrypt the user ID
and password depends on the setting of the alternate_auth_enc database
manager configuration parameter.
Note: - Do not inadvertently lock yourself out of your instance when you
are changing the authentication information, since access to the configuration
file itself is protected by information in the configuration file.
The following database manager configuration file parameters control
access to the instance:
- authentication *
- sysadm_group *
- trust_allclnts
- trust_clntauth
- sysctrl_group
- sysmaint_group
* Indicates the two most important parameters.
There
are some things that can be done to ensure this does not happen: If
you do accidentally lock yourself out of the DB2 database system, you have a fail-safe option
available on all platforms that will allow you to override the usual DB2 database security checks to
update the database manager configuration file using a highly privileged
local operating system security user. This user
always has
the privilege to update the database manager configuration file and
thereby correct the problem. However, this security bypass is restricted
to a local update of the database manager configuration file. You
cannot use a fail-safe user remotely or for any other DB2 database command. This special user is identified
as follows:
- UNIX platforms: the instance
owner
- Windows platform: someone
belonging to the local "Administrators" group
- Other platforms: there is no local security on the other platforms,
so all users pass local security checks anyway
DB2 10.5 for Linux, UNIX, and Windows