BSA Role Framework: Sharing Users & Roles across multiple environments

Version 2
    Share:|

    This document aims to explain a method of brokering user & role access across multiple BSA environments where server objects are dual enrolled but "managed" by one of the environments. The obvious goal would be to merge the environments, but in the unlucky case where politics or migration difficulty get in the way, this should prove be an interim solution.

     

    Notes:

    • The users and roles described here are modeled as read-only for documentation purposes but can be expanded per your requirements.
    • The objective ultimately is to satisfy a requirement of sharing server objects through a common role
    • Make sure you run through this document twice -- once on each environment
    • At the very least this a good instructional document on how to create roles, authorization templates, acl templates. (it's probably better at this than the original goal)

     

    Requirements:

    • Two BSA environments
    • A need to have server objects enrolled in multiple environments
    • Specific server objects are managed by their respective infrastructures via ACL pushes
      • Servers1-100 are enrolled into both BSA1 and BSA2
        • Servers1-50 are controlled by BSA1, Servers51-100 are controlled by BSA2
        • BSA1 controls the ACL pushes for Servers1-50, Servers51-100 are excluded
        • BSA2 controls the ACL pushes for Servers51-100, Servers1-50 are excluded
    • User set 1 and User set 2 will access the server objects from their associative infrastructures (BSA1,BSA2). The idea being that they will not have to switch infrastructures to access different servers. Once again, I know you're saying "just merge the environments", unfortunately politics can get in the way here as well as the cost of a merge in dollars, people, and downtime is sometimes unreasonable.
    • The roles & users described in this document must be identical in both BSA1 and BSA2

     

    Method for creating Read Only roles in BSA1 and BSA2 infrastructures

    Author: Richard McLeod

    Email: richard.mcleod@gmail.com

    Date Created: 2013-03-07

    Date Modified: 2013-09-09

    Version: 1.3

    Objective: Create a method of brokering matched access across multiple BladeLogic infrastructures where agents are dual enrolled.

     

    Creating the RO_ROLE Authorization Profile

    1. Create an authorization Profile (think of this a template for base style roles)
      1. Login to the BladeLogic infrastructure with a user that has the RBACAdmin role
      2. Open the RBAC Object in BladeLogic
      3. Right Click Authorization Profiles
        • Choose New -> Authorization Profile
      4. A dialog box will open, enter the follow values for the input fields
        • Name: RO_ROLE
        • Description: Read Only Authorization Profile for ROLE
        • Selected Authorization
          1. Here we will want to choose all authorizations that end in .Read or .Browse. Below I have provided a table of the necessary selected authorizations. Please select these authorizations in the table to the left and move them to the table on right with the right arrow ‘>’ between the tables.
      5. Once all necessary authorizations are shown under the ‘Selected Authorizations’ table, please choose Finish

    Name

    Type

    Description

    1. ACLPushJob.Read

    Authorization

    Read ACL Push Job

    1. ACLTemplate.Read

    Authorization

    Read ACL template information

    1. AIXSoftware.Read

    Authorization

    Open depot software

    1. AuditJob.Read

    Authorization

    Read Audit Job

    1. AuthProfile.Read

    Authorization

    Read authorization profile information

    1. BatchJob.Read

    Authorization

    Read Batch Job

    1. BLPackage.Read

    Authorization

    Open BLPackage

    1. Component.Browse

    Authorization

    Browse component assets

    1. Component.Read

    Authorization

    Read server properties and other metadata

    1. ComponentGroup.Read

    Authorization

    Read contents of a component group

    1. ComponentTemplate.Read

    Authorization

    Read component template

    1. ComponentTemplateFolder.Read

    Authorization

    Read contents of a component template folder

    1. ComponentTemplateGroup.Read

    Authorization

    Read contents of a component template group

    1. ConfigFile.Read

    Authorization

    Read/open configuration file

    1. CustomCommand.Execute

    Authorization

    Execute custom command

    1. CustomCommand.Read

    Authorization

    Open custom command

    1. CustomSoftware.Read

    Authorization

    Open depot software

    1. DeployJob.Read

    Authorization

    Read Deploy Job

    1. DepotFile.Read

    Authorization

    Open depot file

    1. DepotFolder.Read

    Authorization

    Open depot folder

    1. DepotGroup.Read

    Authorization

    Open depot group

    1. Device.Read

    Authorization

    Read devices

    1. DiscoveryJob.Read

    Authorization

    Read Discovery Job

    1. ExtendedObject.Read

    Authorization

    Read extended object definition

    1. HPUXSoftware.Read

    Authorization

    Open depot software

    1. JobFolder.Read

    Authorization

    Open job folder

    1. JobGroup.Read

    Authorization

    Open job group

    1. LinuxSoftware.Read

    Authorization

    Open depot software

    1. NSHScript.Read

    Authorization

    Read NSH Script

    1. NSHScriptJob.Read

    Authorization

    Read NSH Script Job

    1. PropertyInstance.Read

    Authorization

    Read property instance

    1. ProvisionJob.Read

    Authorization

    Read Provisioning Job

    1. Role.Read

    Authorization

    Read role information

    1. Server.Browse

    Authorization

    Browse server assets

    1. Server.Read

    Authorization

    Read server properties and other metadata

    1. ServerGroup.Read

    Authorization

    Open server group

    1. SnapshotJob.Read

    Authorization

    Read Snapshot Job

    1. SolarisSoftware.Read

    Authorization

    Open depot software

    1. SystemPackage.Read

    Authorization

    Open system package

    1. SystemPackageFolder.Read

    Authorization

    Open system package folder

    1. SystemPackageType.Read

    Authorization

    Open system package type

    1. UpdatePropertiesJob.Read

    Authorization

    Read Update Server Properties Job

    1. User.Read

    Authorization

    Read user information

    1. WindowsSoftware.Read

    Authorization

    Open depot software

     

     

     

    Create the Read-Only Roles

    1. Next we’ll create the Roles, please repeat the below steps to create the following role names that are required.
      1. Role Names:
        • ROLENAME1_RO
        • ROLENAME2_RO
        • etc
      2. Right click the roles object and choose New -> Role
        • Once the dialog box appears enter the following values for the inputs
          1. Name: <Choose from above list of Role Names>
          2. Description: Read Only role for <Choose from above list of Role Names>
          3. Selected Authorizations, Choose the RO_ROLE authorization and press the ‘>’ to move the authorization profile to the selected authorizations table
          4. Then click next
        • The next dialog that will be displayed allows us to configure target mappings, please configure them as specified
          1. Choose the Read Only radio button in the upper left portion of the dialog box
          2. Check the Map to username box
          3. If the Read Only group name from above has (Unix) next to it please enter ‘nobody’ into the Map to: input box
          4. If the Read Only group name from above has (Windows) next to it please switch to the Windows tab and enter ‘<YOUR DEFINED WINDOWS USER>’ into the Map to: input box.
          5. Click next
        • We’ll skip the user entry for now, click Finish
        • Repeat the above steps for each Read only group name listed above, when complete there should be a role for each group name.

     

     

    Create the ACL Policies

    1. Next we need to create the associated ACL Policies to house the authorizations, please repeat the below steps to create the following ACL Policy names that are required.
      1. ACL Policy Names:
        • RO_ROLENAME1
        • RO_ROLENAME2
        • etc
      2. Right click the ACL Policy object and choose New -> ACL Policy
      3. Once the dialog appears enter the associative values into the input box
        • Name: <Choose ACL Policy name from above list>
        • Description: Read Only ACL Policy for <ACL Policy name>
        • Click Next
      4. Click the green ‘+’ sign in the upper right portion of the dialog box to add a Policy Access Control List (this spawns a new dialog box)
        • From here choose the associative Role from the drop down at the top-center
        • Then from the Available Authorizations table switch to the profile tab
        • Click the RO_ROLE profile and then press the ‘>’ to move the authorization profile to the Selected Authorization table, then click OK
        • You will now be back at the original dialog box, and you should notice that the ACL Policy now contains all of the Read Only authorizations from the profile, click Next
        • Click Finish (Please repeat these steps until an ACL Policy has been created for each ACL Policy name listed above)

     

    Create the ACL Templates

    1. Now we’ll create the ACL Templates, please repeat the below steps to create the following ACL Templates that are required
      1. ACL Template names:
        • RO_ROLENAME1
        • RO_ROLENAME2
        • etc
      2. Right click the ACL Templates object and choose New -> ACL Template
      3. Once the dialog appears enter the associative values into the input box
        • Name: <Choose ACL Template name from above list>
        • Description: Read Only ACL Template for <ACL Template name>
        • Click Next
      4. First click the green ‘+’ sign in the upper right portion of the dialog box (this spawns a new dialog box)
        • From the top-center drop down choose the associative role name
        • Then switch to the Profiles tab under the Available Authorizations table
        • Choose the RO_ROLE authorization profile and click the ‘>’ sign to move the authorizations to the Selected Authorizations table, then click OK
        • You will now be back at the original dialog box, in the bottom table ACL Policies choose the green ‘+’ sign that is on top of a paper icon. (this will spawn a new dialog box)
        • Choose the associated ACL Policy for the template and click OK
      5. Click Finish

     

     

    Setting up Server Groups

    1. Next We’ll setup a static group and some smart groups to identify servers that need to receive the ACL policies/templates (Switch to the BLAdmin role) --this assumes that the roles you created were to separate Windows and Unix access amongst roles, modify as necessary.

      1. Create Windows and Unix smart groups
        • Right click the Servers Object and choose New -> Server Group
          1. Name: Cross Infra Object Access
          2. Click Finish
        • Right click the ‘Cross Infra Object Access’ Group and choose New -> Server Smart Group
          1. Name: Windows Servers
          2. Description: Cross Infrastructure Windows Server Access
          3. The following should be used to create the logic of the group
            1. Any Server where OS equals Windows
            2. Click Next
            3. Click the add button on the ACL Policies table and choose the RO_WINDOWSROLENAME policy, click OK
            4. Click Finish
        • Right click the ‘Cross Infra Object Access’ Group and choose New -> Server Smart Group
          1. Name: Unix Servers
          2. Description: Cross Infrastructure Unix Server Access
          3. The following should be used to create the logic of the group
            1. Any Server where OS is one of “Linux”, “Solaris”, “AIX
              • Note these values need to be entered manually by using the ellipsis button and the green + on the Edit List Values dialog box.
            2. Click Next
            3. Click the add button on the ACL Policies table and choose the RO_UNIXROLENAME policy, click OK
            4. Click Finish

     

    Object Permissions

    1. Now we’ll permission the objects with the ACL policies
      • Expand the Static Group ‘Cross Infra Object Access’
      • Right Click the ‘Windows Servers’ Server Smart Group and choose Update Permissions
        1. In the ACL Policies table choose the green + symbol and choose RO_WINDOWSROLENAME, Click OK
        2. Ensure that the Append Permissions radio button is checked, Click OK
        3. The ACL Policy will now be applied to the objects in the ‘Windows Servers’ Group
        • Right Click the ‘Unix Servers’ Server Smart Group and choose Update Permissions
          1. In the ACL Policies table choose the green + symbol and choose RO_UNIXROLENAME, Click OK
          2. Ensure that the Append Permissions radio button is checked, Click OK
          3. The ACL Policy will now be applied to the objects in the ‘Unix Servers’ Group
        • After this is completed, the ACL Policies that were applied to the objects should trickle down to the server level through organic ACL push jobs that occur with-in the ARM environment.

     

     

    Test Case

    Test the cross infrastructure functionality

    Users: (Add users to the RO_WINDOWSROLENAME role)

    user1@domain.com

    user2@domain.com

    Servers:

    server1.domain.com (managed by BSA1, enrolled into BSA1,BSA2)

    server2.domain.com (managed by BSA1, enrolled into BSA1,BSA2)

    Cases:

    Live Browse

    -Retrieve File System sizing

    -Retrieve members of Local Administrators group

    -Check the status of the Themes service

    Custom Command Execution

    -Run NSH Here

     


    1. Users 1&2 should log into BSA1 and ensure their read only access works as expected in the server(s) home environment. Once the users confirm the access is working as expected, they should login to BSA2 and perform the same set of tests against server1 and server2, the access should be the same.

     

     

    Further Configuration

    The following configurations will need to occur to allow the cross-infrastructure access to succeed.

    1. Permission Server Objects per Role for the Read Only group to have Server.Read and Server.Browse via the Access Control List in BSA2
    2. Permission the Server Object groups where BSA1 servers are located in the BSA2 environment to allow the role groups to see the objects using the Access Control List
    3. repeat these steps for the opposite case as well


    Based on the attached diagram (I know, I'm awful at visio) User 1/2 can access servers1-100 from either infrastructure because the roles and authorizations are identical. The diagram only displays the flow for one role group, cast your mind to envision more.