188 lines
14 KiB
HTML
188 lines
14 KiB
HTML
|
<?xml version="1.0" encoding="UTF-8"?>
|
||
|
|
<!DOCTYPE html
|
||
|
|
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
||
|
|
<html lang="en-us" xml:lang="en-us">
|
||
|
|
<head>
|
||
|
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
||
|
|
<meta name="security" content="public" />
|
||
|
|
<meta name="Robots" content="index,follow" />
|
||
|
|
<meta http-equiv="PICS-Label" content='(PICS-1.1 "http://www.icra.org/ratingsv02.html" l gen true r (cz 1 lz 1 nz 1 oz 1 vz 1) "http://www.rsac.org/ratingsv01.html" l gen true r (n 0 s 0 v 0 l 0) "http://www.classify.org/safesurf/" l gen true r (SS~~000 1))' />
|
||
|
|
<meta name="DC.Type" content="concept" />
|
||
|
|
<meta name="DC.Title" content="Application requester security in a TCP/IP network" />
|
||
|
|
<meta name="abstract" content="Different connectivity scenarios call for using different levels of authentication. Therefore, an administrator can set the lowest security authentication method required by the application requester (AR) when connecting to an application server (AS) by setting the preferred authentication method field in each RDB directory entry." />
|
||
|
|
<meta name="description" content="Different connectivity scenarios call for using different levels of authentication. Therefore, an administrator can set the lowest security authentication method required by the application requester (AR) when connecting to an application server (AS) by setting the preferred authentication method field in each RDB directory entry." />
|
||
|
|
<meta name="DC.subject" content="Kerberos, authentication" />
|
||
|
|
<meta name="keywords" content="Kerberos, authentication" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rbae5elementtcpip.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="../rbam6/rbam6clmain.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="../ddp/rbal1kickoff.htm" />
|
||
|
|
<meta name="copyright" content="(C) Copyright IBM Corporation 1999, 2006" />
|
||
|
|
<meta name="DC.Rights.Owner" content="(C) Copyright IBM Corporation 1999, 2006" />
|
||
|
|
<meta name="DC.Format" content="XHTML" />
|
||
|
|
<meta name="DC.Identifier" content="rbae5sourcesecurity" />
|
||
|
|
<meta name="DC.Language" content="en-us" />
|
||
|
|
<!-- All rights reserved. Licensed Materials Property of IBM -->
|
||
|
|
<!-- US Government Users Restricted Rights -->
|
||
|
|
<!-- Use, duplication or disclosure restricted by -->
|
||
|
|
<!-- GSA ADP Schedule Contract with IBM Corp. -->
|
||
|
|
<link rel="stylesheet" type="text/css" href="./ibmdita.css" />
|
||
|
|
<link rel="stylesheet" type="text/css" href="./ic.css" />
|
||
|
|
<title>Application requester security in a TCP/IP network</title>
|
||
|
|
</head>
|
||
|
|
<body id="rbae5sourcesecurity"><a name="rbae5sourcesecurity"><!-- --></a>
|
||
|
|
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
|
||
|
|
<h1 class="topictitle1">Application requester security in a TCP/IP network</h1>
|
||
|
|
<div><p>Different connectivity scenarios call for using different levels
|
||
|
|
of authentication. Therefore, an administrator can set the lowest security
|
||
|
|
authentication method required by the application requester (AR) when connecting
|
||
|
|
to an application server (AS) by setting the preferred authentication method
|
||
|
|
field in each RDB directory entry.</p>
|
||
|
|
<p>The administrator might also allow the decision about authentication method
|
||
|
|
to be negotiated with the server, by choosing to allow a lower security authentication
|
||
|
|
method. In this case, the preferred authentication method is still attempted,
|
||
|
|
but if the AS cannot accept the preferred method, a lower method can be used,
|
||
|
|
depending on the server security setting and other factors such as the availability
|
||
|
|
of cryptographic support. For example, if two systems are in a physically
|
||
|
|
unprotected environment, the administrator might choose to require Kerberos
|
||
|
|
authentication without allowing lower security authentication methods.</p>
|
||
|
|
<p>On the application requester (client) side, you can use one of the two
|
||
|
|
methods to send a password along with the user ID on DRDA<sup>®</sup> TCP/IP connect requests. If you do
|
||
|
|
not use either of these methods, the CONNECT command can send only a user
|
||
|
|
ID.</p>
|
||
|
|
<p>The first way to send a password is to use the USER/USING form of the SQL
|
||
|
|
CONNECT statement, as in the following example from the interactive SQL environment: </p>
|
||
|
|
<pre>CONNECT TO rdbname USER userid USING 'password'</pre>
|
||
|
|
<p>In a program using embedded SQL, the values of the user ID and of the password
|
||
|
|
can be contained in host variables in the USER/USING database. </p>
|
||
|
|
<p>In a program using CLI, the following example shows how the user ID and
|
||
|
|
password are presented in host variables to the DRDA application requester (AR):</p>
|
||
|
|
<pre>SQLConnect(hdbc,sysname,SQL_NTS, /*do the connect to the application server */
|
||
|
|
uid,SQL_NTS,pwd,SQL_NTS);</pre>
|
||
|
|
<p>The second way to provide a password is to send a connect request over
|
||
|
|
TCP/IP using a server authorization entry. A server authorization list is
|
||
|
|
associated with every user profile on the system. By default, the list is
|
||
|
|
empty; however, you can add entries by using the <span class="cmdname">Add Server Authentication
|
||
|
|
Entry (ADDSVRAUTE)</span> command. When you attempt a DRDA connection
|
||
|
|
over TCP/IP, the <span class="keyword">DB2<sup>®</sup> UDB for iSeries™</span> client
|
||
|
|
(AR) checks the server authorization list for the user profile under which
|
||
|
|
the client job is running. If it finds a match between the RDB name on the
|
||
|
|
CONNECT statement and the SERVER name in an authorization entry (which must
|
||
|
|
be in uppercase), the associated USRID parameter in the entry is used for
|
||
|
|
the connection user ID. If a PASSWORD parameter is stored in the entry, that
|
||
|
|
password is also sent on the connect request.</p>
|
||
|
|
<p>A server authorization entry can also be used to send a password over TCP/IP
|
||
|
|
for a DDM file I/O operation. When you attempt a DDM connection over TCP/IP, <span class="keyword">DB2 UDB for iSeries</span> checks the server authorization
|
||
|
|
list for the user profile under which the client job is running. If it finds
|
||
|
|
a match between either the RDB name (if RDB directory entries are used) or
|
||
|
|
'QDDMSERVER' and the SERVER name in an authorization entry, the associated
|
||
|
|
USRID parameter in the entry is used for the connection user ID. If a PASSWORD
|
||
|
|
parameter is stored in the entry, that password is also sent on the connect
|
||
|
|
request.</p>
|
||
|
|
<p>To store a password using the <span class="cmdname">Add Server Authentication Entry
|
||
|
|
(ADDSVRAUTE)</span> command, you must set the QRETSVRSEC system value to
|
||
|
|
'1'. By default, the value is '0'. Type the following command to change this
|
||
|
|
value:</p>
|
||
|
|
<p><samp class="codeph">CHGSYSVAL QRETSVRSEC VALUE('1')</samp></p>
|
||
|
|
<p>The following example shows the syntax of the <span class="cmdname">Add Server Authentication
|
||
|
|
Entry (ADDSVRAUTE)</span> command when using an RDB directory entry:</p>
|
||
|
|
<p><samp class="codeph">ADDSVRAUTE USRPRF(user-profile) SERVER(rdbname) USRID(userid) PASSWORD(password)</samp></p>
|
||
|
|
<p>The USRPRF parameter specifies the user profile under which the application
|
||
|
|
requester job runs. What you put into the SERVER parameter is normally the
|
||
|
|
name of the RDB to which you want to connect. The exception is if you are
|
||
|
|
using DDM files which were not created to use the RDB directory. In that case,
|
||
|
|
you should specify QDDMSERVER in the SERVER parameter. When you specify an
|
||
|
|
RDB name, it must be in uppercase. The USRID parameter specifies the user
|
||
|
|
profile under which the server job will run. The PASSWORD parameter specifies
|
||
|
|
the password for the user profile.</p>
|
||
|
|
<p>If you omit the USRPRF parameter, it will default to the user profile under
|
||
|
|
which the <span class="cmdname">Add Server Authentication Entry (ADDSVRAUTE)</span> command
|
||
|
|
runs. If you omit the USRID parameter, it will default to the value of the
|
||
|
|
USRPRF parameter. If you omit the PASSWORD parameter, or if you have the QRETSVRSEC
|
||
|
|
value set to 0, no password will be stored in the entry and when a connect
|
||
|
|
attempt is made using the entry, the security mechanism attempted will be
|
||
|
|
user ID only.</p>
|
||
|
|
<p id="rbae5sourcesecurity__rbal1authentry"><a name="rbae5sourcesecurity__rbal1authentry"><!-- --></a>You can use the <span class="cmdname">Display Server Authentication
|
||
|
|
Entries (DSPSVRAUTE)</span> command to determine what authentication entries
|
||
|
|
have been added to the server authentication list. The <span class="cmdname">Retrieve Server
|
||
|
|
Authentication Entries (QsyRetrieveServerEntries) (QSYRTVSE)</span> API
|
||
|
|
in a user-written program can also be used.</p>
|
||
|
|
<p>You can remove a server authorization entry by using the <span class="cmdname">Remove
|
||
|
|
Server Authentication Entry (RMVSVRAUTE)</span> command. You can change
|
||
|
|
a server authorization entry by using the <span class="cmdname">Change Server Authentication
|
||
|
|
Entry (CHGSVRAUTE)</span> command </p>
|
||
|
|
<p>If a server authorization entry exists for a relational database (RDB),
|
||
|
|
and the USER/USING form of the CONNECT statement is also used, the latter
|
||
|
|
takes precedence. </p>
|
||
|
|
<div class="section"><h4 class="sectiontitle">Kerberos source configuration</h4><p>Distributed
|
||
|
|
Relational Database Architecture™ (DRDA) and distributed data management (DDM)
|
||
|
|
can take advantage of Kerberos authentication if both systems are configured
|
||
|
|
for Kerberos.</p>
|
||
|
|
<p>If a job's user profile has a valid ticket-granting
|
||
|
|
ticket (TGT), the DRDA application requester (AR) uses this TGT to generate
|
||
|
|
a service ticket and authenticate the user to the remote server. Having a
|
||
|
|
valid TGT makes the need for a server authentication entry unnecessary, because
|
||
|
|
no password is directly needed in that case. However, if the job's user profile
|
||
|
|
does not have a valid TGT, the user ID and password can be retrieved from
|
||
|
|
the server authentication entry to generate the necessary TGT and service
|
||
|
|
ticket.</p>
|
||
|
|
<p>When using Kerberos, the remote location (RMTLOCNAME) in the
|
||
|
|
RDB directory entry must be entered as the remote host name. IP addresses
|
||
|
|
will not work for Kerberos authentication.</p>
|
||
|
|
<p>In cases where the Kerberos
|
||
|
|
realm name differs from the DNS suffix name, it must be mapped to the correct
|
||
|
|
realm. To do that, there must be an entry in the Kerberos configuration file
|
||
|
|
(krb5.conf) to map each remote host name to its correct realm name. This host
|
||
|
|
name entered must exactly match the remote location name (RMTLOCNAME). The
|
||
|
|
remote location parameter displayed by the DSPRDBDIRE or DSPDDMF command must
|
||
|
|
match the domain name in the krb5.conf file. The following figure shows an
|
||
|
|
example of the DSPRDBDIRE display: </p>
|
||
|
|
<div class="p"> <pre class="screen"> Display Relational Database Detail
|
||
|
|
|
||
|
|
Relational database . . . . . . . : RCHASXXX
|
||
|
|
|
||
|
|
Remote location:
|
||
|
|
Remote location . . . . . . . . . : <strong>rchasxxx.rchland.ibm.com</strong>
|
||
|
|
Type . . . . . . . . . . . . . . : *IP
|
||
|
|
Port number or service name . . . : *DRDA
|
||
|
|
Remote authentication method . . :
|
||
|
|
Preferred method . . . . . . . . : *KERBEROS
|
||
|
|
Allow lower authentication . . . : *NOALWLOWER
|
||
|
|
Text . . . . . . . . . . . . . . :
|
||
|
|
|
||
|
|
Relational database type . . . . : *REMOTE
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
Press Enter to continue.
|
||
|
|
F3=Exit F12=Cancel
|
||
|
|
</pre>
|
||
|
|
</div>
|
||
|
|
<p>Here is a portion of the corresponding krb5.conf file contents
|
||
|
|
showing the domain name matching the remote location name (Note: The <span class="cmdname">Display
|
||
|
|
File (DSPF)</span> command is used to display the configuration file contents):</p>
|
||
|
|
<div class="p"> <pre>DSPF STMF('/QIBM/UserData/OS400/NetworkAuthentication/krb5.conf')
|
||
|
|
|
||
|
|
[domain_realm]
|
||
|
|
; Convert host names to realm names. Individual host names may be
|
||
|
|
; specified. Domain suffixes may be specified with a leading period
|
||
|
|
; and will apply to all host names ending in that suffix.
|
||
|
|
<strong>rchasxxx.rchland.ibm.com</strong> = REALM.RCHLAND.IBM.COM</pre>
|
||
|
|
</div>
|
||
|
|
<p>Jobs
|
||
|
|
using Kerberos must be restarted when configuration changes occur to the krb5.conf
|
||
|
|
file.</p>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div>
|
||
|
|
<div class="familylinks">
|
||
|
|
<div class="parentlink"><strong>Parent topic:</strong> <a href="rbae5elementtcpip.htm" title="DDM and DRDA over native TCP/IP does not use i5/OS communications security services and concepts such as communications devices, modes, secure location attributes, and conversation security levels which are associated with Advanced Program-to-Program Communication (APPC). Therefore, security setup for TCP/IP is quite different.">Elements of security in a TCP/IP network</a></div>
|
||
|
|
</div>
|
||
|
|
<div class="relconcepts"><strong>Related concepts</strong><br />
|
||
|
|
<div><a href="../rbam6/rbam6clmain.htm">Control language</a></div>
|
||
|
|
<div><a href="../ddp/rbal1kickoff.htm">Distributed database programming</a></div>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
</body>
|
||
|
|
</html>
|