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
that look more like a realm and distinguished name (DN).
Note: If
you change your realm you must repeat this process with the new realm
name.