Operating with the administrative agent and job manager topology
allows more situations where you might need to add an administrative user
from a different registry into your administrative authorization table (admin-authz.xml).
Each administrative user that needs to be added requires the "accessID"
format of the user from the remote registry. When that user finally is active
in the local cell, the authorization table will already have that accessID
that is required. This task demonstrates how this assignment of users is performed.
Procedure
- You need to determine the accessId for a user on the remote registry.
To do this, you call the following wsadmin task and query based on a user
filter. The following example illustrates a query from the registry realm
"BIRKT60" with a userFilter of "localuser*". This query returns any user from
this realm that begins with "localuser". The resulting accessId is the one
you need to specify in the target administrative authorization table in the
following step. Connect to the sending administrative process:
wsadmin> $AdminTask listRegistryUsers {-securityRealmName BIRKT60 -displayAccessIds true -userFilter localuser*}
{name BIRKT60\localuser@BIRKT60}
{accessId user:BIRKT60/S-1-5-21-3033296400-14683092-2821094880-1007}
- Add "localuser" to the target admin-authz.xml using
the following wsadmin task. Connected to the receiving administrative
process:
wsadmin> $AdminTask mapUsersToAdminRole {-roleName administrator -userids {localuser } -accessids {user:BIRKT60/S-1-5-21-3033296400-14683092-2821094880-1007 }}
- Save the changes.
Results
This task updates the admin-authz.xml in the receiving
administrative process to allow a "cross-realm authorization" to succeed.
The example illustrated here was for a LocalOS registry user. Performing
the same task for an LDAP accessId produces results thatl look more like a
realm and distinguished name (DN).