Importing permissions, users, and groups

This topic describes how rules available in BMC Atrium Orchestrator Platform 7.6.03 are imported in BMC Atrium Orchestrator Platform 7.8.x environment by using the migration tool.

Rules in BMC Atrium Orchestrator Platform 7.6.03 can only be written against built-in and user-defined roles.

When rules are imported into BMC Atrium Orchestrator 7.8 CDP or repository, the following conditions occur:

  • Rules written against built-in roles are not imported.  
    This may be overridden through the use of role mappings.
  • Only those rules written against user-defined roles are imported.
  • Access Manager mapped roles are treated as "alternate names" for the built-in or user-defined roles to which they're mapped and treated, for rule import, as Mapping File mapped roles.
  • For each group designated by an "alternate name" by a Mapping File (or Access Manager) mapped role, the rules written against the "original" role are imported as rules for the "alternate name".

The following exceptions exist while importing rules:

  • Rules written against the AoAdmin role or group are not imported. The default rule sets used in BMC Atrium Orchestrator 7.8 include non-modifiable rules that permit AoAdmin access to everything.

  • Every group for which rules are imported receives the CDP rules permitting USER role access.
    Users belonging to the USER group do not get access to the repository. USER is a special role in BMC Atrium Orchestrator 7.6 to which every authenticated user implicitly belongs.  
    In BMC Atrium Orchestrator 7.8, there is no substitute role to the USER role so every role must be granted what USER can do. 

    Note

    Achieving true parity with the BMC Atrium Orchestrator 7.6 USER role, you need to create a group in BMC Atrium Single Sign-on to which all of BAO users belong and, associate that "all users" role with USER by using the mapping file.

    For more information, see Using-a-role-mapping-file-to-import-default-roles.

  • After importing the permissions, the ADMIN role from 7.6.03 does not have all permissions as the default admin role in 7.8 is AoAdmin. The AoAdmin group in 7.8 is assigned all permissions. 

Importing permissions into a repository

When importing permissions in the repository, the following elements are imported:

  • Repository operation/artifact access rules
  • Groups or roles for which rules are defined

When importing repository access rules, administrative-level rules are created for every group mapped to the AO 7.6 ADMIN and REPOSITORY_ADMIN roles.  

Importing rules into the repository is governed by whether an existing repository content database is used or not.  If an existing Repository content database is used, rules should be imported into the Repository before it is started for the first time. If a new Repository content database is used, then content must be migrated into the new Repository before rules are imported.

Note

Adding content to a repository causes rules created at the time of the content addition to replace any existing/imported rules for the content.

 Importing rules into the repository sets the permissions associated with the Default group to their initial, permissive values. Following an import, the Repository permissions should be reviewed and adjusted as necessary to conform with the local needs.

Importing permissions into a CDP

When importing into a CDP, the following is imported:

  • CDP operation rules
  • CDP process execution rules
  • groups for which rules are defined

Rules granting rights to the AO 7.6 role USER are imported into every group imported into the CDP.  In AO 7.6, every user authenticated to AO is associated with the role USER so rights granted to USER are available to all logged-in users.  In AO 7.8, the concept of the USER role does not exist – there is no group/role with which all authenticated users are associated.

Importing rules into the CDP is expected to be done before the CDP is started for the first time.  Imported rules will persist in the CDP until the CDP permissions UI is used to alter one or more permissions.  The CDP permissions UI can not be used to display rules for modules not installed in the grid – rules for modules not active on the grid are not displayed.  Once permissions are modified, only rules governing access to installed content are retained – rules imported for modules not yet loaded in the CDP are lost.  So, on starting the CDP following a rules import, all modules governed by the imported rules should be activated on the grid before the CDP permissions UI is used to make changes.

Importing rules into the CDP sets the permissions associated with the Default group to its initial, permissive values.  Following an import, the CDP permissions should be reviewed and adjusted as necessary to conform to local needs.

Importing users and groups into BMC Atrium Single Sign-On

Before running an import using the ‑‑atssoPassword option to import users and groups into BMC Atrium Single Sign-On, it is important to have BMC Atrium Single Sign-On fully configured with any external LDAP/AD systems that were used in Access Manager.

Important

Configuration must include settings under "User Stores" as well as "Realm Authentication". Once configuration is complete, use the Atrium SSO administration UI to verify that users and groups that should be defined in an external LDAP/AD system are visible to Atrium SSO and that the members of groups defined in the external LDAP/AD system are also visible. If Atrium SSO configuration is not complete, using the migration tool to import users and groups into Atrium SSO might result in duplicate definitions that must be cleaned up manually.

When importing into either a Repository or a CDP and an --atssoPassword option value is provided, the following is imported into Atrium SSO:

  • Users exported from Access Manager
  • User-defined roles (as groups) exported from Access Manager
  • Groups specified, in a role mapping file, as alternate group names for built-in and user-defined roles exported from Access Manager
  • Group membership reflecting the membership as exported from Access Manager

Note

The built-in roles and Access Manager mapped roles are not imported into BMC Atrium Single Sign-On.  When BMC Atrium Single Sign-On is properly configured with the external LDAP/AD systems configured in Access Manager, Access Manager mapped roles (and their membership) will be available to AO.

Definitions for users already defined in BMC Atrium Single Sign-On or known to BMC Atrium Single Sign-On through an external definition are not altered.  User passwords can not be exported from Access Manager so a generated password is used during import. The password for an user imported into BMC Atrium Single Sign-On is set to the userid padded, as necessary, with "12345678" to create a password of the minimum length required (default: 8 characters).For example, the user named 'sam' will be assigned a password of 'sam12345'.  The minimum password length is defined by BMC Atrium Single Sign-On

In BMC Atrium Single Sign-On, a group may be defined within BMC Atrium Single Sign-On or known to BMC Atrium Single Sign-On through an external definition.  When importing a role/group definition, a group definition is not added to BMC Atrium Single Sign-On if BMC Atrium Single Sign-On knows of an external definition.  Group membership is updated only for groups defined within BMC Atrium Single Sign-On (or added during import) and only with users defined within BMC Atrium Single Sign-On (or added during import).

It is safe to provide the --atssoPassword option for both Repository and CDP import operations as neither users nor groups will be imported more than once and group membership is updated only if necessary.

It is possible for a principal (user or group) to be both defined within and defined externally to BMC Atrium Single Sign-On though though duplicate definition is usually something undesired in a security environment. The distinction between defined within and defined externally turns out to be an important one for import processing.

When performing an identity (user/group) import, there are four different possibilities for each of user and role/group

  • Not defined
  • Defined within BMC Atrium Single Sign-On
  • Defined externally but known in BMC Atrium Single Sign-On
  • Both defined internally and defined externally 

When importing a user, the following cases are possible:

  1. Not defined – the user is added to BMC Atrium Single Sign-On
  2. Defined only internally – the user is not added to BMC Atrium Single Sign-On
  3. Defined only externally – the user is not added to BMC Atrium Single Sign-On
  4. Defined both internally and externally – the user is not added to BMC Atrium Single Sign-On

When importing a role/group, similar cases are possible:

  1. Not defined – the group is added to BMC Atrium Single Sign-On and internally-defined members are set
  2. Defined only internally – the group membership is updated, if necessary, to add additional internally-defined members
  3. Defined only externally – the group is not added to or updated in BMC Atrium Single Sign-On
  4. Defined both internally and externally – the group membership (in BMC Atrium Single Sign-On) is updated, if necessary, to add additional internally-defined members

Notes

  • A BMC Atrium Single Sign-On group can only have members that are defined within BMC Atrium Single Sign-On. Externally defined users cannot be a member of an BMC Atrium Single Sign-On group. Therefore, when adding a group or updating the membership set of a group in BMC Atrium Single Sign-On, each member is verified to ensure that it is defined within BMC Atrium Single Sign-On and retain only those internally-defined users are retained in the group membership.
  • A consequence of the internal versus external definition view of BMC Atrium Single Sign-On for best import results, customers should establish connections to any external LDAP/AD systems in BMC Atrium Single Sign-On before performing an import.

 

 

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*