5 Replies Latest reply: Sep 17, 2013 2:01 PM by Jim Campbell RSS

    Patching DCs and the System account

    Jim Campbell

      Our security team is worried about the prospect of using a domain admin account to patch domain controllers with an automation principal.  We have disabled User Mapping as a result of the numerous issues it has caused on Domain Controllers and while everything works properly using the automation principal in a test environment security is hesitant to release the reigns of a domain admin account to our team.


      With Marimba and SCCM it was apparently not as big a problem as these tools use the System account rather than a domain admin account to perform tasks such as patching.  Is there any way to force the blade agent to use the System account on DCs and preferably while continuing to disable User Mapping?  Has this ever been discussed as an option?  I am told there is a subantially greater risk of compromise from giving us access to a domain admin account as opposed to the System account on the domain controllers.

        • 1. Re: Patching DCs and the System account
          Bill Robinson

          It’s a complete change to the way the RSCD agent works, and this has been brought up before.  I suggest you bring this up w/ BMC Product Management and/or your account rep.

          • 2. Re: Patching DCs and the System account
            Jim Campbell

            Thank you, I will check with our account rep.

            • 3. Re: Patching DCs and the System account
              Jim Campbell

              I contacted our account representative to check into this but I had an additional question.  How do other people handle this issue?  We're trying to figure out why we have issues with this (related to PCI compliance I believe) but apparently other organizations are able to use Bladelogic with domain controllers with (presumably) the same types of permission restrictions.  Do most people organize it such that the small number of allowed domain admins are also users of Bladelogic?  Or do people create a special role for only a small number of their Bladelogic users to allow access to domain controllers such that the additional access granted is limited?

              • 4. Re: Patching DCs and the System account
                Steffen Kreis

                Hi Jim,


                we have exactly the same challenge in front of us now.

                Would be great if you could share some information on how you have resolved the security-issue at your end ?


                Many thanks in advance


                • 5. Re: Patching DCs and the System account
                  Jim Campbell

                  BMC support found a Microsoft link indicating that using the System account as with other automation tools was not really more secure (  http://msdn.microsoft.com/en-us/library/windows/desktop/ms677973(v=vs.85).aspx ).  We worked around the problems with User Mapping by using a feature of newer agents that allows renaming the account created by the agent from 'bladelogicrscd' to something else - this prevents member servers from accidentally attempting to log on with the domain account (since the member servers attempt to log in as domain\bladelogicrscd which does not exist and so they do not lock the (renamed) account the domain controllers use.  Automation Principals and disabled User Mapping would have worked as well but this would have been cumbersome to maintain automation principal passwords for every domain.


                  We just had to give the existing domain administrators access to the DCs via Bladelogic using a specific Role for the purpose.