123 lines
7.7 KiB
HTML
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>
|