13 Replies Latest reply on Aug 2, 2016 4:21 PM by Bill Robinson

    Impacts of restricting server access for BLAdmins role

    Yanick Girouard

      By convention, I believe it is customary that the BLAdmins role has access to all servers and objects in the BSA console by default. This means that indirectly, it has full admin access to any server present in the console, and could therefore potentially run administrative commands on any server even if it doesn't manage it at the OS level.

       

      Typically, based on what I've seen, the BLAdmins role will have all accesses, but functional roles will only have access to a subset of servers. For example, WindowsAdmins would have access to Windows servers only, and UnixAdmins to Linux and Unix servers.

       

      Let say that the Unix team does not want the BLAdmins role to have access to their servers (BLAdmins role not present in any Unix server's ACL), and does not want my user account to be a member of the UnixAdmins role either. What would be the impact for me as a BSA administrator ?

       

      On top of my head, I can think of the following:

       

      - I would no longer be able to push ACL to any Unix server using a nightly job or ad-hoc

      - I wouldn't be able to add or decommission Unix targets
      - I would no longer be able to run any job against any Unix server, including admin tasks such as Update Server Property or Update Configuration Objects, etc...

      - I wouldn't be able to troubleshoot any issues with any Unix jobs against Unix targets

      - I wouldn't be able to run the database cleanup jobs as deleting a job or component BLAdmins doesn't have access to will produce errors

      - I wouldn't be able to see Unix jobs running in the "Tasks in progress" window (not sure about that one, can BLAdmins always see all regardless?)
      - I wouldn't be able to even see any Unix targets in the console, so no checking of properties, no license counting (unless I use a database query)

      - I might encounter issues during a BSA upgrade if BLAdmins doesn't have sufficient permissions to certain objects (seen this before)

       

      ... and more...

       

      Has anyone ever done this kind of hardening in BSA to restrict BLAdmins' access, and if so, what has to be done exactly and what was the impact and implications of such a change ?

        • 1. Re: Impacts of restricting server access for BLAdmins role
          Bill Robinson

          Kyle Sorg - we were just talking about this...

           

          imo BLAdmins w/ * on all the things is a bad convention.  BLAdmins is explicitly granted * for everything and on everything and does not need it.  BLAdmins should really only be used to manage the bsa environment and the bsa infrastructure.  everything else should be does by specific functional roles that map to your organization - eg patch admins, patching users, compliance admins, os admins, whatever.

           

          from your list:

          - I would no longer be able to push ACL to any Unix server using a nightly job or ad-hoc

          [BR] this would have to be done as a role w/ acl push perms on the targets

          - I wouldn't be able to add or decommission Unix targets

          [BR] yep
          - I would no longer be able to run any job against any Unix server, including admin tasks such as Update Server Property or Update Configuration Objects, etc...

          [BR] right

          - I wouldn't be able to troubleshoot any issues with any Unix jobs against Unix targets

          [BR] right

          - I wouldn't be able to run the database cleanup jobs as deleting a job or component BLAdmins doesn't have access to will produce errors

          [BR] if you have BL_Administration.* and the ability to run the cleanup jobs that should still work.

          - I wouldn't be able to see Unix jobs running in the "Tasks in progress" window (not sure about that one, can BLAdmins always see all regardless?)

          [BR] BLAdmins has an implicit read on all objects so you should still see everything.
          - I wouldn't be able to even see any Unix targets in the console, so no checking of properties, no license counting (unless I use a database query)

          [BR] implicit read

          - I might encounter issues during a BSA upgrade if BLAdmins doesn't have sufficient permissions to certain objects (seen this before)

          [BR] the UMO job would have to be run as a role w/ perms on the particular object.  any post-install stuff like compliance content updates, the maintenance job creation may have issues.

           

          remember that it's all rbac - so bladmins can still have * given to the role but only on certain objects.

           

          another option would be to create a role that has * on everything (jobs, etc) but have a process on putting users in that role for troubleshooting purposes and maintain the BLAdmins role to manage the bsa infra.  or if you need to troubleshoot some job you get your account added to that role for some period of time.

          • 2. Re: Impacts of restricting server access for BLAdmins role
            Jeremy Bragg

            We wanted to limit some of this type of access.  We still use BLAdmins to push ACLs and update server properties but we created a special user for server imports and decommissions.  We also have ACL policies attached to the templates of every role so when our engineers create content, the policy will allow access to the content to the intended roles that does not necessarily include BLAdmins.

             

            There are ways you can limit access but you will want to be cautious as correcting ACLs down the road becomes more challenging.

            • 3. Re: Impacts of restricting server access for BLAdmins role
              Yanick Girouard

              Yeah, the ACL pushing was one of my main concern as well. Isn't the ACLPush auth also requiring Server.FileCreate permissions to be effective or is it implicit ?

              • 4. Re: Impacts of restricting server access for BLAdmins role
                Jeremy Bragg

                Since it updates the users file on the target server, I am sure Write is required.

                1 of 1 people found this helpful
                • 5. Re: Impacts of restricting server access for BLAdmins role
                  Yanick Girouard

                  Which in turns gives rw (read-write) permissions in the users file of the agent...

                  • 7. Re: Impacts of restricting server access for BLAdmins role
                    Yanick Girouard

                    D'oh ! Sorry I meant Server.FileCreate

                    • 8. Re: Impacts of restricting server access for BLAdmins role
                      Bill Robinson

                      I don’t think it needs that either – should just need server.aclpush.

                      • 9. Re: Impacts of restricting server access for BLAdmins role
                        Yanick Girouard

                        In this case I could probably manage a special "RSCDAgentManager" role that I could use to schedule daily tasks. Can you think of any other type of BSA admin task (the actions in the Admin Tasks context menu) that would need Server.FileCreate though? What about the agent cleanup blcli command ? Wouldn't it need Server.FileDelete ?

                        • 10. Re: Impacts of restricting server access for BLAdmins role
                          Jeremy Bragg

                          I just tested this out of curiosity.  With Server.Read and Server.PushACL, I could push ACLs successfully.  The caveat is that the role must already have access to be able to push ACLs.  So you will need to update your users.local or push ACLs with a role that already has access first to update users.

                          • 11. Re: Impacts of restricting server access for BLAdmins role
                            Bill Robinson

                            well, it’s always the case that you can’t push acls w/o being mapped to a user that can write to the users file.  If BLAdmins is doing the push, then most people put an entry for BLAdmins in the users.local so no matter what acls get pushed to the target, they can always be mapped to a local user that can write to the users file.

                            • 12. Re: Impacts of restricting server access for BLAdmins role
                              Jeremy Bragg

                              That's exactly what we do Bill.  Its baked in to the installer/upgrader.  I do like the idea of creating a separate role for ACL push to reduce the access risk and only have that in the users.local. But I fear that will come back to haunt us later.  We push an updated exports file in the install to reduce risk of a rogue environment so I am not sure how much benefit we will get.

                              • 13. Re: Impacts of restricting server access for BLAdmins role
                                Bill Robinson

                                BLAdmins has an implict read on all objects, and RBACAdmins has an implicit read and modifyacl.  that's it.  all other permissions are explicitly granted.  which means generally there is no difference between BLAdmins and any other role w/ the same permission set. there are a few things hard-coded for BLAdmins - i think just the dashboard access and a couple unreleased blcli commands.  so as long as users.local has the override for whatever role and that role has acl push it should be all good.  in 6.x we used to have RBACAdmins do the acl pushes and iirc that was basically hard-coded - i don't think acl pushes could work as other roles.  that got opened up in 7.0.