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.
Thank you, I will check with our account rep.
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?
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
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.