Managing Local Administrator Accounts with LAPS; And Protecting LAPS from Attack

Webinar Registration

Ah, User RID 500… Otherwise known as Administrator. It’s on every Windows system on your network. It doesn’t lockout and you can’t delete it. You can rename but big deal – that only trips up script kiddies. You can disable Administrator but that has some important limitations and caveats.

All of this has made the local admin account target #1 for attackers. To get companies to stop re-using the same password for Administrator on every computer, Microsoft released LAPS (Local Administrator Password Solution) a few years ago. LAPS takes over management of Administrator’s password assigning a unique randomly generated password for each system. LAPS stores the passwords in Active Directory where access is governed by AD permissions.

In this this real training for free event, I will show you how LAPS works and pivot to how attackers leverage LAPS to gain information and even attempt to attack LAPS itself to gain control of local admin accounts. 

I’ll show you the major components of LAPS such as:

  • LAPS schema extensions to AD
  • Local LAPS agent
  • Client-side GPO extension
  • Interactive LAPS application
  • PowerShell tools

Then as we shift to the security and risks of LAPS we’ll consider:

  • How attackers might use LAPS to gain information about the environment
  • LAPS vulnerabilities and attack methods
  • Important LAPS best practices and security checks you should run if you are using LAPS

At the end of the day, most security researchers agree that LAPS is a decent implementation for what it does but it is very much a point solution. It only addresses the local Administrator account which is one very important but narrow issue when it comes to privileged account management.

We should never be using the local administrator account anyway for any kind of normal day-to-day administration. The local admin account is a necessary evil just like root on Unix; it’s there for when your domain and local systems are so fried the only way to access the system is with a local privileged account. A generic, all powerful account with no accountability between IT staff. 

In addition to everything else you do to secure Administrator, if you are following best practice and avoid ever using Administrator, then you should set a highest level alert in your SIEM for whenever it sees a successful logon by Administrator – or whatever you renamed it to.

So, implementing LAPS – securely – and doing the necessary monitoring of LAPS related attributes in AD and LAPS events on member computers will help you reduce the risks associated with “Administrator”. But we’ll take it further with our sponsor BeyondTrust, who will briefly show you how their technology suite provides comprehensive management of privilege across the entire AD/Windows/Unix environment including passwords, least privilege and auditing.

Please join us for this real training for free solution.

First Name:   
Last Name:   
Work Email:  
Phone:  
Organization:  
Country:    
State:  
How many employees in your organization?:
What is your job function?:
What is your role within your department?:
I'd like to schedule a personalized demo with a BeyondTrust rep for:
 

Your information will be shared with the sponsor.

By clicking "Submit", you're agreeing to our Privacy Policy and consenting to be contacted by us.

 

 

Additional Resources