Recently, I was engaged on a project for a customer, which included the need to manage local (non-domain) accounts across an entire environment (for both Servers and Workstations).
In this type of scenario, I have seen a lot of anti-best practices being used in many different environments.
For example, there are many organizations out there, that has a local Administrator account (again, non-domain), which has the same password. Yes, that, of course, eases the administration, but it is a huge security liability. Because, if one system is compromised, then all systems are, because they all have the same local Admin account, using the same password.
Another common thing I see is that the default local Administrator account is still being used. This is contrary to best practices because this built-in Administrator account has what’s known as a well known SID. So even if you rename it, an attacker could still identify it through the SID.
So, the best practice would be to disable the default local administrator account and create a new one. This is so that if something were to happen to your system (i.e. it’s lost its trust with the domain, etc.), you are still able to log in locally to correct the issue.
But in a large environment, how do you effectively manage all these local accounts? After all, they’re not maintained inside Active Directory. Allow me to introduce you to the Local Administrator Password Solution (LAPS).
A Brief Intro To LAPS
I’m not going to give you all the information about LAPS, for that you can check out the TechNet article here.
But in short, LAPS uses Active Directory to store the local administrator account for a specific computer object. You can then retrieve the local admin account password (if you have permissions to view it), do what you need to do, and either triggers a reset or allow the Group Policy Object (GPO) to expire the password and randomize/reset it for you.
Now let’s focus on the main reason for this post.
When you implement LAPS, when a password is successfully read from Active Directory a Security Event is logged, like this.
That means, if you are using the Operations Management Suite (OMS) to collect Security data, this event will also be captured. And if we are capturing the events, then we can work with that data.
If you expand the dataset available, you will find useful fields like Account Type, Account/User Name, etc. We can use this data to create a custom OMS solution to visualize what’s occurring in the environment.
The LAPS OMS Solution
Now that we have Security events being collected, and we know what fields and properties we can use, let’s make our custom OMS Solution for LAPS.
Distribution By Account Type
Knowing what LAPS does (facilitates the management of system-local Administrator accounts), I would want to know how many password resets are actually occurring. However, if we just use this search query: SecurityEvent | where EventID == 4662 then we get all events returned.
What we really want to see, is the breakdown of resets by Account Type, because this property can be either “Machine” (i.e. initiated by the GPO and Password Expiry date), or “User” (i.e. initiated by an actual IT user.
So, we append to our search query with some summarization like so: SecurityEvent | where EventID == 4662 | summarize count() by AccountType. That will give us a visual like this:
But we don’t need to see all the data that is returned, that’s 26 different properties! Really, all we want to see is the Account Type (to differentiate between Machine and User), the Account that triggered the reset, and Date/Time it occurred.
To only retrieve these details, we’ll use the Project keyword and select the applicable properties, like so: SecurityEvent | where EventID == 4662 | project AccountType, Account, TimeGenerated. That gives us a nice list to go along with our doughnut graph.
Distribution By User Account
Now that we can easily see the number of resets broken down by Account Type, let’s hone in on Users that are triggering resets.
When the property Account Type shows as “Machine”, this means the system-local Administrator account’s password has been automatically reset via the GPO settings and assigned Password Expiry date.
So rather, we want to focus on when an actual person triggers the reset. This reset can occur either through a PowerShell command, or the LAPS Admin UI.
Let’s take our starting search query (SecurityEvent | where EventID == 4662) and filter where Account Type is “User”. Our new query will look like this: SecurityEvent | where EventID == 4662 | where AccountType == “User”. But we don’t want to list every instance, we want to see the unique set of users that are triggering the resets, so we need to summarize by the appropriate field that lists the User Name.
Note: If you take a look at all the properties that are available from our starting search query, you will notice that there are actually 3 fields that contain some type of username information; namely Account, SubjectAccount, and SubjectUserName.
So how do you know which one to use? Personally, in an enterprise environment, I would want to include the Domain, especially if we’re collecting information across multiple domains (i.e. non-Prod vs Prod). So in this example, I would opt to select either the ‘Account’ or ‘SubjectAccount’ property.
Our new query would then look like this: SecurityEvent | where EventID == 4662
| where AccountType == “User” | summarize count() by Account, and we can use this query to create a visual, like so:
Since the doughnut visual will only show, at most, 3 items, we want to also include a list to make it easier to see all the users. We can use the exact same query from the doughnut visual for our list.
Distribution By Computer
Great! Now let’s duplicate the same thing we did for Distribution by User Name, for Computers; in case we want to see a list of all the Computers that are successfully applying the GPO, and automatically resetting the local-system Administrator account.
We will take our starting search query (SecurityEvent | where EventID == 4662) and filter where Account Type is “Machine”. Our new query will look like this: SecurityEvent | where EventID == 4662 | where AccountType == “Machine”. But again, we don’t want to list every instance, we want to see the unique set of Computers that are triggering the automated resets, so we need to summarize by the appropriate properties that list the Computer Name.
Note: Similarly to the multiple options for User Account properties, we have 5 fields that we can reference for computer information; namely Account, Computer, SubjectAccount, SubjectDomainName, SubjectUserName.
So again, we have to decide which field we want to use. By default, you may initially think about using the ‘Computer’ field, and that will work. But if you’re collecting data in a multi-domain environment, you might want to list domain first before Computer name. For that, you would use a combination of the ‘SubjectDomainName’ property and the ‘SubjectUserName’ property.
In my simple example, I am using the ‘Computer’ property, so my new query looks like this: SecurityEvent | where EventID == 4662 | where AccountType == “Machine” | summarize count() by Computer, and we use this query to create a visual, like so:
Again, the doughnut visual will only show at most 3 items, so we will include a list to make it easier to see all the computers. We can use the exact same query from the doughnut visual for our list.
List Of Queries
Finally, if you are creating an OMS Solution that will be used by others, it is generally a recommended practice to include a list of queries as a quick-reference for others to get started. That way they don’t have to re-create your efforts, and can very easily start from where your solution left off, and tweak/modify it further to meet their needs.
So that’s it. Our custom OMS Solution is now complete.
Although this Solution used simpler query examples, hopefully, it was of interest and help and enables you to get started in your own environments.
And if you’re planning on using the Local Administrator Password Solution (LAPS) in your environment, you can find the .OMSView file available on the TechNet Gallery here.