10 Replies Latest reply on Sep 10, 2009 7:58 AM by RDeMay

    help with locking down permissions on vm group

    Jae Ellers Master

      I have the following group of vm folders. 

      DataCenter

      \|- Test

      \||-Vlan1 /code

      I have a domain group, Admins, that has Administrator privilege to everything.  I have a vm group Test that houses all our test systems.  I have a subgroup Vlan1 that needs to have Admin privilege limited to a few of the admins.  I have a domain group Vlan1_Admins that has only the admins I want to administer that group.

       

      In the Windows world I'd change propagation at the top level, Test, and make a copy of the permissions.  I'd then go  in and add the new Vlan1_Admins with full Administrator permissions.  I'd then go in and remove the original Administrators group on the Vlan1 group and I'd be done.

       

      So I add the Vlan1_Admins at the Vlan1 level, Administrator rights and propagate.  No problem yet.

       

      Then I try to stop propagation of Admins, either at the Test level or the Vlan1 level.  I get this message:

       

      The permission for the user/group, Admins, is inherited from the object, DataCenter.  Modifying it for this object will create a new permission for this object and not change the orginal permission.

       

      OK, fine.  Sounds to me like it's going to keep the top level permissions and stop the propagation at this level.  Click OK.

       

      The requested change could leave the system without full administrative privelege for any user or group.

       

      OK, that sounds bad.  There's only OK to click, so I click.  Nothing gets modified. 

       

      What am I doing wrong and how can I do it without resorting to adding a deny-access group?

        • 1. Re: help with locking down permissions on vm group
          VirtualNoitall Virtuoso

          Hello,

           

          Here is a decent doc on permissions on VI: http://www.vmware.com/pdf/vi3_vc_roles.pdf

           

          I will also say that in a discussion with support around permissions they seemed to favor using deny.  We had so far avoided it ourselves but we have a pretty simple hierarchy.

          • 2. Re: help with locking down permissions on vm group
            Jae Ellers Master

            Seen that before.  I don't need a complex role/privelege setup.  I simply want to allow admin rights to a different group of users. 

             

            I know who I want to have access.  I don't know who I don't want to have access.  Negative permissions are never not uneasy to use.  To keep them working I have to remember to add people to the group when the group I'm negating changes.  This is a maintenance hassle.

             

            My main question is why can't I remove the Admins propagation after I've added the Vlan1 administrators group.  I'm in it.  There are still admins applied to the group.  Why complain?

            • 3. Re: help with locking down permissions on vm group
              VirtualNoitall Virtuoso

              Hey,

               

              I am thinking you can.  You were just being warned the requested change could /bleave the system without full administrative privilege... I think this is just VC not fully understanding what you are doing so it is displaying a pretty stern warning so you think before you do.  

               

              I haven`t tried to do this myself though so I would be trying this out in a sandbox environment first.

              • 4. Re: help with locking down permissions on vm group
                Jae Ellers Master

                Nope.  Just an OK and the permissions still show the propagate box checked when reviewed after clicking OK. 

                 

                Hence my confusion.  Sounds like a warning.  Really it's an error messge, bc it doesn't do what it's warning you about.  If it was a warning there would be a cancel button.

                 

                I've opened SR 189486521.  (I remember when SR numbers were 5 digits long).  Looks like we've done 200 million SRs since those days.  Price of progress.

                • 5. Re: help with locking down permissions on vm group
                  hicksj Master

                  There is an easy explanation to this.

                   

                  It keeps people from cutting their feet off.  This was a huge problem in the past, so VMware has restricted the removal of the base Administrator role assignment.

                   

                  Very similar to Windows permissions, or eDirectory... once Admin is granted it can't be removed below.  Well, you can try, but effective rights remain at superuser level.

                   

                  The key is, only those who should have FULL access within your Virtual Infrastructure should be assigned the Administrator role.  Period.  If you ever think you need to restrict this person below, don't assign them Admin.  Create a new role(s) that provides what they require, and assign only where needed.

                   

                  Bottom line:  You cannot remove the Administrator role assignment.

                  • 6. Re: help with locking down permissions on vm group
                    Jae Ellers Master

                    And that's covered in the docs where?

                    • 7. Re: help with locking down permissions on vm group
                      hicksj Master

                      Ya know, now that I think about this... what I mean is:

                       

                      You must have an Administrator role assigned at every level of the infrastructure... however, I'd have to test if this can be reassigned at various levels.  As long as you assign the new group the Administrator role, then remove the original, I'm not sure why that wouldn't work.  However, I do believe the the Admin from the higher level will be able to reset the permission on this newly restricted folder.  Again, would have to test when I get a chance.  Also, the new Admin group must have a local server account as a member, I think, in the event that VC server becomes isolated from the Domain.

                       

                      sorry, been away from the office & my vm children for 3 weeks.  not yet thinking entirely clearly.  Hope above makes sense. 

                      • 8. Re: help with locking down permissions on vm group
                        Jae Ellers Master

                        Don't think this can be changed.  You basically can change which group is associated with administrators, but only once, afaik.

                        • 9. Re: help with locking down permissions on vm group
                          Sealice Novice

                           

                          What we did to get this to work is create a M$ sec. group and added the admins into it. We then added the "Administrators" role to that group, and added the "Read-Only" role to the (local) Administrators group on VCS. Now all of our nosey domain admins who are local admins on various machines cant connect into our VI environment and break things!

                           

                           

                           

                           

                           

                          Good luck

                          • 10. Re: help with locking down permissions on vm group
                            RDeMay Novice

                             

                            I created a local account on the VC server and added it as Administrator set to not to propagate.  I have done this in the past to test what rights I need to give someone before going live.  This time I go to the datacenter to add the account and I get this message.  I go back to the Host and Clusters and try to change it to propagate, however the message appears.  I can not even remove the account any more.

                             

                             

                            I know this can be removed in SQL, but wanted to see if there was a way to fix this from the VC. 

                             

                             

                            This was not an issue with 3.0 or 3.1.