Assigning users from a foreign realm to the admin-authz.xml

Operating with the administrative agent and job manager topology allows more situations where we might need to add an admin user from a different registry into the admin authorization table (admin-authz.xml). Each admin 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.


  1. we 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 specify in the target admin authorization table in the following step. Connect to the sending admin 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}

  2. 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 }}

  3. Save the changes.



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).


Related tasks

Authorizing access to admin roles