LAPS Audit Reporting via WEF PoSH and PowerBI

So I have a few of these dashboard type solutions now for MS products that we’ve put together to help with the management of something where we don’t have a reporting GUI that ships with the product.  The previous blog article covered creation of one of these for the EMET product, this article is basically the same thing however this dashboard is geared at configuring auditing for the Microsoft LAPS solution , forwarding the audit events from your DC’s to a centralized WEF server, parsing those out to .csv with powershell and then visualizing that data via a PowerBI dashboard file (either locally or on the PowerBI service).

With that said lets break it out into the following portions:

• Ensuring you are auditing LAPS Password Retrievals
• Forwarding those audit events to a central system
• Parsing out those events and visualizing them via PowerBI

I’ve put all the scripts etc for this on GitHub at https://github.com/kurtfalde/LAPS-Reporting, you will also need the EventLogWatcher.psm1 module from https://pseventlogwatcher.codeplex.com/ as well.

Configuring auditing for LAPS

• The first step is to ensure that you place the right SACL / audit entry on the OU’s / Computer objects that you wish to audit access to.  The step to do this is found in the LAPS_OperationsGuide.docx and basically calls out using the PowerShell cmdlet that comes with the product:

• Set-AdmPwdAuditing –OrgUnit: <name of OU on which you want to setup the auditing> -AuditedPrincipals: :<identification of users/groups whose access to password shall be audited>

•  

• The next step is to ensure that your Domain Controllers have the right audit policy applied to them.  In this case the specific audit policy setting we are looking for is under Advanced Audit Policies > DS Access > Audit Directory Service Access as seen below.

Forwarding the Audit Events for LAPS

• I’m going to kind of skip over verifying you are getting audit events I’m hoping you test with the LAPSUI and with Active Directory Users and Computers and verify you are actually seeing the audit events in your DC logs.  While testing make sure you are testing reading against a specific DC and checking that DC’s logs to make your life easier.
• Since we are forwarding events from the Security Event log we need to ensure the Network Service account has ‘read’ rights to this log (by default it does not).  The quickest way to do this is to add the Network Service group to the Event Log Readers group in the domain you are gathering events from.  You could also modify the SDDL on the security log channel via GPO but that’s a bigger change and I’m not a fan of doing it that way.
• Create a GPO for your DC’s or modify an existing one that touches your DC’s to have them point to your WEF (Windows Event Forwarding) server.  You need to modify the setting Computer>Policies>Admin Templates>Windows Components>Event Forwarding>Subscription Manager

• At this point we need to go to the WEF server and copy all of the content from the GitHub link above to a folder c:\laps on this server.
• We also need to download the EventLogWatcher.psm1 module from codeplex at https://pseventlogwatcher.codeplex.com/ and place in the c:\laps directory
• Make sure to ‘unblock’ the two ps1 files in the folder as they were downloaded from the Internet and PS will throw an error regarding them on initial runs.
• Edit the LAPSServerSetup.ps1 script in the PowerShell ISE

• Modify the $DCTOQUERY value to point to the DC you have created test laps audit events on

• Run the LAPSServerSetup.ps1 script… IF this works properly you should get the following:

• A task scheduler item called LAPS Parsing Task that runs the parsing script automatically on reboot of the system
• An Event Forwarding Subscription called “LAPS Audit Events” which has the proper XPath filter for laps audit events and is set to get data from DC’s in your domain.
• The script also does a number of other things such as ensuring WinRM and Windows Event Collection service are setup and running properly as well

• Since DC’s refresh policy every 5 min by default we should start seeing ‘Source Computers’ for the subscription in rather quick order.  Also if they have any LAPS audit events those should start showing up quickly in the Forwarded Events log as the subscription is configured to grab any pre-existing events from the client logs.

Parsing the events and visualization via PowerBi

• At this point if there are events in the Forwarded Events log then go to Task Scheduler and start the LAPS Parsing Task that was created.  This should in turn start parsing those events and outputting the results to a c:\laps\laps.csv file on the system.
• Install the PowerBI Desktop client on your WEF server, this can be obtained from https://powerbi.microsoft.com/en-us/desktop for FREE!!
• Use the PowerBI Desktop client to open the ‘LAPS Audit Dashboard.pbix’ file.  The data in the file by default is stale data from my lab so utilize the “Refresh’ button from the top ribbon to have the laps.csv file from your environment parsed into the data model in PowerBI. 
• At this point you should see some graphics showing Users that have queried for LAPS passwords along with which computers have been queried for on the first page and a second page with the raw data in pivot slicers.  Sorry not the best dashboard as I didn’t spend much time on this piece yet but may again soon and if so I will update the GitHub with a newer .pbix file.

• That is pretty much the end of this story if you are going to use this locally.  If however you subscribe to the PowerBI service either via an individual subscription 12$ /month or have PowerBI via your O365 subscription then I would highly recommend installing the Personal Gateway on your WEF server and the .pbix file up in the PowerBI service and configuring the gateway to sync your data up to the cloud instead.  This gives you a nice(r) web portal and also the ability to use IOS/Android/Windows apps to view the dashboard.

Hopefully this works for you and if not please provide comments and I’ll do my best to fix.  Thanks for reading.

Comments

• Anonymous
  December 28, 2015
  Hi, Jessica Payne from Microsoft Enterprise Cybersecurity Group's Global Incident Response and Recovery