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.