Thursday, September 3, 2009

HSLockdown explained

Some times I do see questions about the HSLockdown tool. Yes, there are websites explaining what it does, but what about this fragment? 
(Taken directly from the KB article explaining the usage of this tool)

‘…only the NT AUTHORITY\Authenticated Users security principal is allowed access to the Health Service. But when the Active Directory is hardened, or the agent is misconfigured, the Local System account cannot authenticate through the Authenticated Users security principal. Therefore, the agent cannot process Health Service configuration information…’

Sounds like true Geek mumbo jumbo, doesn’t it? I mean, I work for 12+ years in the IT, have had my share of late night/early morning/weekend disaster recoveries, servers going wild, multiple outbreaks of viruses, management teams with (almost) impossible requirements to be met, users who almost turned me into a Hulk (Hit Any User To Continue…) and yet I survived it all. And learned from it. But that sentence, its like I have been asleep all those years and that I am a total newbie to IT!

I will break it down into a more down-to-earth language. So that we all understand it.

Lets take a look at the word Security Principal, taken from Wikipedia and ‘translated’ by me:

…is an entity that can be authenticated by a computer system or network. It can be assigned permissions and privileges for resources in the network…

In some kind of way it can be seen as some kind of group. Keep this in the back of your mind.

Now a few steps back:

  • The OpsMgr Agent (AKA HealthService) uses the Run As Profile ‘Privileged Monitoring Account’ to run under
  • By default this profile uses the LocalSystem account (= NT AUTHORITY\SYSTEM Security Principal)
  • Under this account the OpsMgr Agent processes the Health Service configuration

So far so good. Still no mumbo jumbo?

Ok, now we are going to walk forward:

  • Suppose that on a DC not the LocalSystem account is chosen for the OpsMgr Agent but a Domain Account, specially made for this purpose
  • During the installation of the OpsMgr Agent the tool HSLockdown is run automatically and denies the HealthService access to the LocalSystem account
  • Now only the NT AUTHORITY\Authenticated Users Security Principal is allowed access to the HealthService

So the bottom line here is that the OpsMgr Agent (HealthService) can’t do anything as LocalSystem/System

Lets pick up some speed:

  • Suppose the Active Directory is hardened (made more secure) or the OpsMgr Agent is not properly configured
  • Due to this the LocalSystem account cannot run responses for the OpsMgr Agent
  • Now this DC will be grayed out in the OpsMgr Console, thus not being monitored:
    image
  • The OpsMgr event log shows errors with EventIDs 7022 and 1120

That’s all! No mumbo jumbo and everything is explained (I hope so…).

Time for some repair jobs:

  • The tool is to be found on every system running the OpsMgr Agent: ~:\Program Files\System Center Operations Manager 2007
  • On the problematic DC open a cmd-prompt and type hslockdown /L in order to get a list what accounts are authorized to monitor the DC: 
    image  
    As you can see the account LocalSystem is denied access

  • Change it like this: hslockdown /A "NT Authority\System"
    image 
    Restart the Health Service and you should be OK now.

  • It’s alive!
    image

3 comments:

Dave Murphy said...

Thanks for the article. Came across this issue on SCOM 2012 RC. The system account was not specifically denied access, however, it was not listed as having access either. Went ahead and added the rights, then restarted the agent. Worked like a charm.

Unknown said...

Still valid for SCOM 2012 R2. Just resolved this issue on a DC this morning.

MouradN said...

Great article. Thanx for this precious info.