User's Guide
As DB2 Connect administrator, you can determine where user names and
passwords are validated. With DCE directories, you do this by setting the
following:
- The security type of the communication protocol in the database locator
object representing the DB2 Connect workstation. Use security type NONE.
- The authentication type of the database object.
- The security type of the communication protocol in the database object
- The authenticate at gateway parameter in the routing
information object
Table 12 and Table 13 show the possible combinations of these values and where validation is
performed for each combination. Only the combinations shown in these tables
are supported by DB2 Connect with DCE Directory Services.
REFID='T3'.
Table 12. Valid Security Scenarios with DCE using APPC connections
|
| Database object of the Server
| Routing object
| Validation
|
| Case
| Authentication
| Security
| Authentication at DB2 Connect Gateway (1=true, 0=false)
|
|---|
| 1
| CLIENT
| SAME
| 0
| Remote client (or DB2 Connect workstation)
|
| 2
| CLIENT
| SAME
| 1
| DB2 Connect workstation
|
| 3
| SERVER
| PROGRAM
| 0
| DRDA server
|
| 4
| SERVER
| PROGRAM
| 1
| DB2 Connect workstation and DRDA server
|
| 5
| DCE
| NONE
| Not applicable
| At the DCE security server
|
| Note: | If a remote client is connected to the DB2 Connect Enterprise Edition gateway
workstation via an APPC connection, specify a security type of NONE
in the DCE locator object of the gateway.
|
Table 13. Valid Security Scenarios with DCE using TCP/IP connections
| Case
| Database object of the Server
| Routing object
| Validation
|
|
| Authentication
| Authentication at DB2 Connect Enterprise Edition Gateway (1=true,
0=false)
|
|---|
| 1
| CLIENT
| 0
| Remote client (or DB2 Connect workstation)
|
| 2
| CLIENT
| 1
| DB2 Connect workstation
|
| 3
| SERVER
| 0
| DRDA server
|
| 4
| Not applicable
| Not applicable
| None
|
| 5
| DCE
| not applicable
| At the DCE security server
|
Each combination is described in more detail below:
- In the first case, the user name and password are validated only at the
remote client. (For a local client, the user name and password are validated
only at the DB2 Connect workstation.)
The user is expected to be authenticated at the location he or she first
signs on to. The user ID is sent across the network, but not the password. Use
this type of security only if all client workstations have adequate security
facilities.
- In the second case, the user name and password are validated at the DB2
Connect workstation only. The password is sent across the network from the
remote client to the DB2 Connect workstation but not to the DRDA server.
- In the third case, the user name and password are validated at the DRDA
server only. The password is sent across the network from the remote client to
the DB2 Connect workstation and from the DB2 Connect workstation to the DRDA
server.
- In the fourth case, the user name and password are validated at both the
DB2 Connect workstation and the DRDA server. The password is sent across the
network from the remote client to the DB2 Connect workstation and from the DB2
Connect workstation to the DRDA server.
Because validation is performed in two places, the same set of user names
and passwords must be maintained at both the DB2 Connect workstation and the
DRDA server.
- In the fifth case, a DCE ticket is obtained from the DCE security
server.
Notes:
- For AIX systems, all users using security type SAME must belong
to the AIX system group.
- For AIX systems with remote clients, the instance of the DB2 Connect
product running on the DB2 Connect workstation must belong to the AIX
system group.
- Access to a DRDA server is controlled by its own security mechanisms or
subsystems; for example, the Virtual Telecommunications Access Method (VTAM)
and
Resource Access Control Facility (RACF). Access to protected database
objects is controlled by the SQL GRANT and REVOKE
statements.
[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]
[ DB2 List of Books |
Search the DB2 Books ]