ibm-information-center/dist/eclipse/plugins/i5OS.ic.ddp_5.4.0.1/rbal1sourcesecurity.htm

206 lines
15 KiB
HTML
Raw Normal View History

2024-04-02 14:02:31 +00:00
<?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="rbal1elementsusetcp.htm" />
<meta name="DC.Relation" scheme="URI" content="../cl/addsvraute.htm" />
<meta name="DC.Relation" scheme="URI" content="../cl/dspsvraute.htm" />
<meta name="DC.Relation" scheme="URI" content="../apis/qsyrtvse.htm" />
<meta name="DC.Relation" scheme="URI" content="../cl/rmvsvraute.htm" />
<meta name="DC.Relation" scheme="URI" content="../cl/chgsvraute.htm" />
<meta name="DC.Relation" scheme="URI" content="rbal1tcpipsetup2.htm" />
<meta name="DC.Relation" scheme="URI" content="../cl/dspf.htm" />
<meta name="DC.Relation" scheme="URI" content="../rzalv/rzalvmst.htm" />
<meta name="DC.Relation" scheme="URI" content="../rzakh/rzakhconfig.htm" />
<meta name="copyright" content="(C) Copyright IBM Corporation 1998, 2006" />
<meta name="DC.Rights.Owner" content="(C) Copyright IBM Corporation 1998, 2006" />
<meta name="DC.Format" content="XHTML" />
<meta name="DC.Identifier" content="rbal1sourcesecurity" />
<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="rbal1sourcesecurity"><a name="rbal1sourcesecurity"><!-- --></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 Universal Database™ 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<sup>®</sup> 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 that if you
are using DDM files which were not created to use the RDB directory, 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="rbal1sourcesecurity__rbal1authentry"><a name="rbal1sourcesecurity__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="rbal1elementsusetcp.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="../rzalv/rzalvmst.htm">Enterprise Identity Mapping</a></div>
</div>
<div class="reltasks"><strong>Related tasks</strong><br />
<div><a href="rbal1tcpipsetup2.htm" title="If you own a Distributed Relational Database Architecture (DRDA) application server (AS) that will be using the TCP/IP protocol, you need to set up the DDM TCP/IP server.">Set up the TCP/IP server for DRDA</a></div>
<div><a href="../rzakh/rzakhconfig.htm">Network authentication service</a></div>
</div>
<div class="relref"><strong>Related reference</strong><br />
<div><a href="../cl/addsvraute.htm">Add Server Authentication Entry (ADDSVRAUTE) command</a></div>
<div><a href="../cl/dspsvraute.htm">Display Server Authentication Entries (DSPSVRAUTE) command</a></div>
<div><a href="../apis/qsyrtvse.htm">Retrieve Server Authentication Entries (QsyRetrieveServerEntries) (QSYRTVSE) API</a></div>
<div><a href="../cl/rmvsvraute.htm">Remove Server Authentication Entry (RMVSVRAUTE) command</a></div>
<div><a href="../cl/chgsvraute.htm">Change Server Authentication Entry (CHGSVRAUTE) command</a></div>
<div><a href="../cl/dspf.htm">Display File (DSPF) command</a></div>
</div>
</div>
</body>
</html>