3 Replies Latest reply on May 23, 2005 8:43 AM by Greg Kullberg

    RBACAdmin role assignable but not distributable

      I can assign users to the RBACAdmin role, but generating/pushing ACLs does not include them in the /usr/lib/rsc/users file. I suspect that the role is managed correctly inside of RBAC because I can manually add a rule in the users file such as:


      1. RBACAdmins ACLs

      RBACAdmins:RBACAdmin rw,map=root

      afmitchell:RBACAdmin rw,map=root


      and various things requiring RBACAdmin role permissions (like pushing acls via blcli) can be performed by the user afmitchell and work fine. Of course, if I push ACLs they only work once. :)


      BladeLogic has admitted this is a bug so I assume it will be fixed eventually, but what are people doing to work around this issue? It's a real pain for us as we would like to be able to script the addition of a server to RBAC. Currently, we can't update ACL's so there's always some bit that we must do manually. I'd love to hear any suggestions. Thanks.

        • 1. Re: RBACAdmin role assignable but not distributable

          We put the entries you describe in the users.local file which does not get updated with an ACL push.


          We even have an entry in our nsh-install-defaults file that does this at agent install time automagically:



          export NSH_USER_FROM


          Obviously concatinate what you want to the end of that value.

          • 2. Re: RBACAdmin role assignable but not distributable

            This is not a bug as much as it is an intermediary step. One of the limitations of the current RBAC model is that it provides no granularity for the RBACAdmins role; if a user is in RBACAdmins, then he/she can manage security on all servers.


            In 6.2.0, engineering added a feature whereby RBACAdmins ACLs (except for the main RBACAdmin account) are not distributed to the users file. It is intended that BL security managers instead put their RBACAdmins in the users.local files. This way, it is possible to give users RBAC rights but granularize the servers over which they have security control.


            For example, in a two-OS environment (Solaris and Windows), there is often a Solaris RBAC administrator and a Windows RBAC administrator. To employ this system, simply put the Windows RBAC administrator in all the Windows users.local files and the UNIX RBAC administrator in all the UNIX users.local files.


            In short, this feature makes managing RBAC accounts slightly less convenient but actually makes it possible to granularize RBAC control to a subset of servers. It's intentional. But it's not the ultimate solution and will ultimately be changed with the next revision or RBAC.

            • 3. Re: RBACAdmin role assignable but not distributable

              In regards to scripting this out, are you utilizing the blcli add server script? I believe the script currently performs a uname to determine the OS of the server being added. You could take this script one step further and then perform an echo to your users.local file for whichever administrators should be managing that OS through RBAC.