ibm-information-center/dist/eclipse/plugins/i5OS.ic.rzalv_5.4.0.1/rzalvambiguousgroupregistry.htm

123 lines
7.7 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="Lookup operation examples: Example 5" />
<meta name="abstract" content="Use this example to learn about lookup operations returning ambiguous results that involve group registry definitions." />
<meta name="description" content="Use this example to learn about lookup operations returning ambiguous results that involve group registry definitions." />
<meta name="DC.Relation" scheme="URI" content="rzalveservereimmaplookup.htm" />
<meta name="copyright" content="(C) Copyright IBM Corporation 2002, 2006" />
<meta name="DC.Rights.Owner" content="(C) Copyright IBM Corporation 2002, 2006" />
<meta name="DC.Format" content="XHTML" />
<meta name="DC.Identifier" content="rzalvambiguousgroupregistry" />
<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>Lookup operation examples: Example 5</title>
</head>
<body id="rzalvambiguousgroupregistry"><a name="rzalvambiguousgroupregistry"><!-- --></a>
<img src="./delta.gif" alt="Start of change" /><!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
<h1 class="topictitle1">Lookup operation examples: Example 5</h1>
<div><p>Use this example to learn about lookup operations returning ambiguous
results that involve group registry definitions.</p>
<p>In some cases a mapping lookup operation returns ambiguous results when
more than one target user identity matches the specified lookup criteria.
Because an ambiguous results situation could cause applications that use EIM
to fail or give unexpected results, you must take action to prevent or resolve
the situation.</p>
<p>In particular, be aware that lookup operations can return ambiguous results
when you specify an individual user registry definition as a member of more
than one group registry definition. If an individual user registry definition
is a member of multiple group registry definitions and you create individual
EIM identifier associations or policy associations that use a group registry
definition as either the source registry or target registry, lookup operations
might return ambiguous results. For example, you might use two different user
identities for two different types of system tasks that you perform: you perform
tasks as a security administrator that require a user identity with QSECOFR
authority, and you perform typical user tasks that require a user identity
with QUSER authority. If both of your user identities reside within the individual
user registry that is a member of two different group registry definitions
and you create target identifier associations to both of the target user identities,
lookup operations finds both of the target user identities and consequently
returns ambiguous results.</p>
<p>The following example describes how this problem can occur when you specify
an individual user registry as a member of two group registry definitions
and you specify one of the group registry definitions as the target registry
in two individual EIM identifier associations.</p>
<br /><img src="rzalv517.gif" alt="" /><br /><p><span class="uicontrol">Example:</span></p>
<p>John Day has the following user identities within a system registry definition
called <samp class="codeph">System B</samp> user registry: </p>
<ul><li>JOHND </li>
<li>DAYJO </li>
</ul>
<p><samp class="codeph">System B</samp> user registry is a member of the following group
registry definitions: </p>
<ul><li><samp class="codeph">Group 1</samp></li>
<li><samp class="codeph">Group 2</samp></li>
</ul>
<p>EIM identifier John Day has two target associations with the following
specifications: </p>
<ul><li>Target association: Target registry is <samp class="codeph">Group 1</samp> which
contains user identity <samp class="codeph">JOHND</samp> in <samp class="codeph">System B</samp> user
registry. </li>
<li>Target association: Target registry is <samp class="codeph">Group 2</samp> which
contains user identity <samp class="codeph">DAYJO</samp> in <samp class="codeph">System B </samp>user
registry. </li>
</ul>
<p>In this situation, the mapping lookup operation returns ambiguous results
because more than one target user identity matches the specified lookup criteria;
both user identities (<samp class="codeph">JOHND</samp> and <samp class="codeph">DAYOJO</samp>)
match the specified lookup criteria.</p>
<p>Similarly, mapping lookup operations might return ambiguous results if
you create two policy associations (rather than individual EIM identifier
associations) that use group registry definitions as target registries.</p>
<p>To prevent lookup operations from returning ambiguous results that involve
group registry definitions, consider the following guidelines: </p>
<ul><li>Specify an individual user registry as a member of no more than one group
registry definition. </li>
<li>Use caution when creating individual EIM identifier associations or policy
associations that use group registry definitions as either the source registry
or target registry. Verify that the group registry definition is a member
of no more than one group registry definition. Be aware that if a member of
the target group registry definition is also a member of another group registry
definition, lookup operations can return ambiguous results. </li>
<li>If you have an ambiguous results situation where you specify an individual
registry definition as a member of multiple group registry definitions, and
you create an individual identifier association or policy association that
uses one of those group registry definitions as either the source registry
or target registry, you can define unique lookup information for each target
user identity in each association to further refine the search. </li>
</ul>
<p>You might define the following lookup information for each target user
identity in the example about John Day: </p>
<ul><li>For <samp class="codeph">JOHND</samp>: Define <samp class="codeph">Administrator</samp> as the
lookup information </li>
<li>For <samp class="codeph">DAYJO</samp>: Define <samp class="codeph">User</samp> as the lookup
information </li>
</ul>
<p>However, base i5/OS™ applications
such as iSeries™ Access
for Windows<sup>®</sup> can
not use lookup information to distinguish among multiple target user identities
returned by a lookup operation. Consequently, you might consider redefining
associations for the domain to ensure that a mapping lookup operation can
return a single target user identity to ensure that base i5/OS applications
can successfully perform lookup operations and map identities. </p>
</div>
<div>
<div class="familylinks">
<div class="parentlink"><strong>Parent topic:</strong> <a href="rzalveservereimmaplookup.htm" title="This information explains the process for Enterprise Identity Mapping (EIM) mapping and view examples.">EIM lookup operations</a></div>
</div>
</div>
<img src="./deltaend.gif" alt="End of change" /></body>
</html>