System Center Configuration Manager Feedback

Suggestion box powered by UserVoice

How can we improve Configuration Manager?

Integrate Microsoft LAPS Functionality

The Microsoft Local Admin Password Solution (LAPS) is great because of the security it provides, but is not in widespread use because it isn't enabled by default and requires desktop/server teams to work together to implement.

Integrate the functionality of Microsoft LAPS into the ConfigMgr infrastructure.

This could include simple steps to control replace the group policy need with a new compliance item node, or could include completely supplanting of the functionality (similar to how MBAM makes it so you don't need AD for managing BitLocker recovery keys).

Anything that ConfigMgr can do to bring down the bar for securing local admin passwords would do a great service to organizations.

246 votes
Sign in
Sign in with: Facebook Google
Signed in as (Sign out)
You have left! (?) (thinking…)
Nash Pherson (MVP) shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


Sign in
Sign in with: Facebook Google
Signed in as (Sign out)
  • Starmantle commented  ·   ·  Flag as inappropriate

    gMSA is actually the perfect solution.. Install a gMSA on the main sccm server.. use group policy to include that account into the local administrator group of every machine. ... And restrict the gMSA to 1 way authentication.. so it can only be used from the main server.. That "should" actually work right now. You might have to set the account in sccm using powershell rather than the gui... I will be trying this soon.

  • bdam commented  ·   ·  Flag as inappropriate

    The trick would be to secure the account used to access the LAPs password from AD. If in implementing this solution they made those account vulnerable in any way, shape, or form then the attacker now has access to every admin password stored plain-text in a well documented AD attribute.

  • Bram Vlasblom commented  ·   ·  Flag as inappropriate

    The integration of the LAPS extension is awesome, but we would like integration of the passwords in a the SCCM database so that is should be possible to register multiple passwords per computer just like MBAM does with recovery keys.

  • Anonymous commented  ·   ·  Flag as inappropriate

    Man, I am out of votes, but want to give this +++. I agree that this would be a great enhancement to reduce security risk of lateral propagation if the client push account is compromised.

  • Adam Stasiniewicz commented  ·   ·  Flag as inappropriate

    @Joe: Yes, I was commenting on the current state. Forgot to mention, that I like your solution.

    I do wish LAPS be built into the OS though; but that's feedback for a different team. :)

  • Joe Safe commented  ·   ·  Flag as inappropriate

    @Adam - this applies to how client push is currently configured, yes.

    If Client Push was amended to utilise LAPS, the attack scenario you're describing would be irrelevant as if someone obtained the password via this method it would be unique to one PC and expire within X amount of hours.

    Unfortunately this is a feature which is heavily used by many and since current branch brings more updates, utilising client push will probably be the preferred method so I can't see how Microsoft can advise against this (especially as introducing LAPS integration would bring a huge security improvement to this).

  • Adam Stasiniewicz commented  ·   ·  Flag as inappropriate

    Using a Client Push is well understood to be the least secure option for deploying ConfigMgr. As this results in a theft-able credential being left behind. If this credential is highly privileged, it offers an attacker a very easy avenue to compromise the environment.

    A simply attack scenario could be as easy as this: Attacker gains control of a single system (maybe a phished user's workstation, a poorly protected DMZ server, etc). They uninstall the ConfigMgr client, wait for the admin to re-push the agent, then capture the Client Push credential. From there, they now have a credential that has administrative rights to every system in the environment.

    For more information, I highly recommend reading the Pass-The-Hash whitepapers: At minimum, guidance around Client Push should be updated to discourage its use.

  • Joe Safe commented  ·   ·  Flag as inappropriate

    Integrate an alternative for the client push account within SCCM. Rather than having an account which requires administrator access across all workstations and servers, allow alternatives such as LAPS (Local Administrator Password Solution).

    You could specify the account named used by LAPS (i.e. localadmin) and have SCCM obtain and then authenticate using the LAPS password for each individual machine.

Feedback and Knowledge Base