Monitoring Service Accounts with System Center Operations Manager

___________________________________________________________________________________________________________________________

IMPORTANT ANNOUNCEMENT FOR OUR READERS!

AskPFEPlat is in the process of a transformation to the new Core Infrastructure and Security TechCommunity, and will be moving by the end of March 2019 to our new home at https://aka.ms/CISTechComm (hosted at https://techcommunity.microsoft.com). Please bear with us while we are still under construction!

We will continue bringing you the same great content, from the same great contributors, on our new platform. Until then, you can access our new content on either https://aka.ms/askpfeplat as you do today, or at our new site https://aka.ms/CISTechComm. Please feel free to update your bookmarks accordingly!

Why are we doing this? Simple really; we are looking to expand our team internally in order to provide you even more great content, as well as take on a more proactive role in the future with our readers (more to come on that later)! Since our team encompasses many more roles than Premier Field Engineers these days, we felt it was also time we reflected that initial expansion.

If you have never visited the TechCommunity site, it can be found at https://techcommunity.microsoft.com. On the TechCommunity site, you will find numerous technical communities across many topics, which include discussion areas, along with blog content.

NOTE: In addition to the AskPFEPlat-to-Core Infrastructure and Security transformation, Premier Field Engineers from all technology areas will be working together to expand the TechCommunity site even further, joining together in the technology agnostic Premier Field Engineering TechCommunity (along with Core Infrastructure and Security), which can be found at https://aka.ms/PFETechComm!

As always, thank you for continuing to read the Core Infrastructure and Security (AskPFEPlat) blog, and we look forward to providing you more great content well into the future!

__________________________________________________________________________________________________________________________

Brad Watts with another blog on System Center Operations Manager. One of the common scenarios I run into with customers is monitoring service accounts with Operations Manager. Specifically, three common scenarios dealing with service accounts:

· Account Locked Out: typically there are a group of service accounts that you need to know immediately if they get locked out.

· Password Expired: same situation as with the account being locked out but here we will receive an alert if the password has expired.

· Password Age: this can be used in two different scenarios

o Many organizations set their service accounts to never expire but are required to change the password every x number of days. In this scenario this monitoring would alert you when it’s time to change the password.

o This monitoring can also be used as a warning that the password is about to expire. For instance, if the policy is for the passwords to expire after 60 days you could set this to alert when the password is 50 days old.

Each of these scenarios is easy enough for me to set up but if you don’t have experience with Management Pack Authoring then reusability becomes difficult. So my goal is to provide a Visual Studio Solution that will allow a typical Operations Manager Administrator the ability to monitor service accounts. This means that it must be simple to add and remove service accounts from being monitored.

Overview

Disclaimer: This is an example solution and should be handled as such. You should test this in your lab environments before implementing. Once you download the content you are responsible for the solution. This is a community management pack and is in no way a solution from Microsoft.

I decided to break this blog article into four sections:

Section 1: Before You Get Started: This will outline the pre-requisites needed to use this solution.

Section 2: PowerShell Script: This Management Pack uses one simple PowerShell script that we’ll cover in this section.

Section 3: Loading the Solution: Covers loading the Visual Studio Solution that is provided at the end of this blog.

Section 4: Using the Solution: Covers how to add and remove service account using the Visual Studio Solution.

Section 5: Using the Management Pack: Covers importing the management pack and exploring the new monitors.

Before You Get Started

Before you can implement this solution you’ll need to make sure the following items are in place in your environment.

1) Operations Manager 2012 R2

2) Load the Active Directory PowerShell Module on your Management Servers. If you are running Server 2012 R2 this will be available as a Feature that you can add. The workflow in this Management Pack targets the “All Management Server Resource Pool” and loads this module.

3) Visual Studio 2012/2013/2015 (any addition)

4) Visual Studio Authoring Extension (https://www.microsoft.com/en-us/download/details.aspx?id=30169)

I know for some people Visual Studio is something they try to stay away from. Stick with me in this case because in this solution we use what are called Management Pack Snippets in order to make your life easier.

PowerShell Script

At the core of this solution is a very simple PowerShell script that pulls the information we need for the service accounts.

param($account,$debug)

#Constants used for event logging

$SCRIPT_NAME = ‘MonitorADAccount.ps1’

$EVENT_LEVEL_ERROR = 1

$VENT_LEVEL_WARNING = 2

$EVENT_LEVEL_INFO = 4

$SCRIPT_STARTED = 841

$PROPERTYBAG_CREATED = 842

$SCRIPT_ENDED = 845

#==================================================================================

# Sub: LogDebugEvent

# Purpose: Logs an informational event to the Operations Manager event log

# only if Debug argument is true

#==================================================================================

function Log-DebugEvent

{

param($eventNo,$message)

$message = “`n” + $message

if ($debug -eq $true) {

$api.LogScriptEvent($SCRIPT_NAME,$eventNo,$EVENT_LEVEL_INFO,$message)

}

}

#Start by setting up API object.

$api = New-Object -comObject ‘MOM.ScriptAPI’

$message = ‘Account: ‘ + $account

Log-DebugEvent $SCRIPT_STARTED $message

import-module ActiveDirectory

$bag = $api.CreatePropertyBag()

$user = get-aduser $account -Properties *

$bag.AddValue(‘LockedOut’,$user.lockedout)

$pwd = [DateTime] $user.PasswordLastSet

$now = get-date

$passwordlastset = ($now – $pwd).days

$bag.AddValue(‘LastSet’,$passwordlastset)

$bag.AddValue(‘Expired’,$user.PasswordExpired)

$bag

$message = ‘Account: ‘ + $account + ‘ – Accounts Retured: ‘ + $user.count + ‘ – Account Locked Out: ‘ + $user.lockedout + ‘ Password Age: ‘ + $passwordlastset + ‘ Password Expired: ‘ + $user.PasswordExpired

Log-DebugEvent $PROPERTYBAG_CREATED $message

There is one item that I won’t cover in the script. This monitor has an overridable parameter [CR1] called Debug. If this is set to true you will log a couple of events in the Operations Manager event log each time the script is run. You’ll get event number 841 when the script is kicked off and this will show you the account it is attempting to get information on. You’ll also get event number 842 when the script is finished that should show you the details on the account that you targeted.

Now let take a look at the important lines of the script.

import-module ActiveDirectory

This will add the Active Directory PowerShell commands that we need and connect to the domain that the Management Server is a member of.

$bag = $api.CreatePropertyBag()

Operations Manager uses Property Bags to pass information out of scripts. Here we are just initializing the Property Bag.

$user = get-aduser $account -Properties *

$bag.AddValue(‘LockedOut’,$user.lockedout)

$pwd = [DateTime] $user.PasswordLastSet

$now = get-date

$passwordlastset = ($now – $pwd).days

$bag.AddValue(‘LastSet’,$passwordlastset)

$bag.AddValue(‘Expired’,$user.PasswordExpired)

$bag

First we get the user using “get-aduser” along with the account name that is passed in. Once we have the user account we can start to add values to our Property Bag. We have three values that are passed out in the Property Bag, LockedOut, LastSet, and Expired. Each one of these will be used for a different monitor. Note that we get the age of the password by subtracting the current date to the PasswordLasSet property of the use account. Once we’ve filled out the Property Bag we return the values with the line containing just $bag.

Loading the Solution

Once you’ve downloaded the zip file provided below you can extract the content to a folder of your choosing. The only caveat here is that wherever your running Visual Studio from will need to have access to the extracted folder.

Now that you’ve got the extracted solution you can launch Visual Studio with the VSAE already installed. When Visual Studio loads it should bring you to a splash screen. On this splash screen choose to “Open Project”

Navigate to the location where you extracted the content. In the base folder you should find a sln file named “Example.ADAccount.Monitoring.”

Opening this file should load the solution. Once loaded your “Solution Explorer” should look like the following.

Using the Solution

Now that you’ve loaded the solution the next step is using the solution. The nice part about this setup is typically they only folder you need to be concerned about in the “Solution Explorer” is the one labeled “Action.”

You can see under the “Action” folder are three different “Snippet Data” items. There is one that you need to fill out for each scenario on monitoring a service account. The easiest way to demonstrate using this solution is to walk through a scenario. Let say we have two service accounts we want to monitor.

· Svc-lockout

o Account Locked

o Password Age: older than 45 days

o Password Expired

· Svc-sql

o Account Locked

o Password Age: older than 45 days

Start by double clicking on “Account Locked.mpsd” in your “Solution Explorer.” This should bring up a screen that looks like this.

Click on the “Click here to add a new item” and we’ll add the two service accounts. Note that I have the “ID” as a column due to the fact that many account have “-“ in them that aren’t accepted in the ID field. Typically I just use the service account name minus the “-“. Here is what the filled out data should look like:

Walk through the same procedure for “Password Age.mpsd.” Once you finished here the data should look like:

Walk through the same procedure for “Password Expired.mpsd.” Note here that we are only monitoring the svc-lockout account here. Once you finished here the data should look like:

Once you’ve filled out the information you can build your solution by selecting “Build | Build Solution”

This will place the Management Pack under the following path:

<Path you extracted content>\Example.ADAccount.Monitoring\Example.ADAccount.Monitoring\bin\Debug

Recommendations

Note on Cook Down.

· This Management Pack does not cook down between Accounts. What I mean by that is if you are monitoring 20 accounts then it will run the script at least 20 times. The script is not resource intensive but it is something you should keep in mind.

· Cook down does occur between the scenarios as long as the same interval is passed in to each. So when monitoring svc-sql for instance I would want to make sure I use the same interval. You’re initial thoughts may be that I need to check lockout every 10 minutes but password age just once a day. In actuality you get no benefit from setting them differently. If I set both to run every 10 minutes, I’ll run the script one less time each day than if I set one to 10 minutes and the other to every 24 hours. (With cook down you run the script once every 10 minutes and without cook down you run it once every 10 minutes plus the once a day for the password age)

Removing a Service Account

It should be pretty straight forward on how to add more service accounts to be monitored but what about removing a service account. If you go back to where you added in the accounts highlight one of the rows my first thought is to right click and choose a delete option. Well when you right click nothing at all happens. The solution is extremely simple, after clicking on one of the rows you can simply press your ”delete” key to remove that row.

Adding Service Accounts Through CSV Files

Instead of adding each account individually you can use a csv file to add in the accounts. The only caveat here is that you shouldn’t have any headers in the file. For example for the Password Age template you’re csv file should look similar to the following:

svclockout,300,svc-lockout,45

svcsql,300,svc-sql,45

Using the Management Pack

Now that we’ve gone through and created the management pack using the Visual Studio Solution we need to see what this looks like in Operations Manager. Take the Management Pack that was created in the Debug directory mentioned above and import it into Operations Manager. Once imported you can create a state view in the console. Below I went into My Workspace | Right Clicked | New | State View. When creating the State View I selected the “All Management Server Resource Pool.”

In the new view you can open up the Health Explorer for the Resource Pool. Under “Configuration” you should have a new aggregate monitor named “Account Status.” If you open this up you will see all of the accounts that you are monitoring.

In the above you can see that the svc-lockout has expired and it was set longer than 45 days ago but the account isn’t locked out. Also the svc-sql account’s password age is older than 45 days but it isn’t locked out. Also notice that we aren’t monitoring for the “Password Expired” on the svc-sql account.

You can also check your “Active Alerts”

Summary

Being able to monitor service accounts is a common request that I see for Operations Manager. In the above solution hopefully can be used by two different camps. First, would be people that have no Authoring Experience but would like to be able to monitor for these three scenarios. With this solution they should be able to use this just to add in this monitoring. This can also be useful for people with authoring experience. In that case this would be a starting point that they can add in additional scenarios or extend what the PowerShell script is currently doing. For example, the current script is assuming a single domain environment and would need to be modified for multiple domains. Here is a link to the solution:

http://tinyurl.com/zgmlb23[CR2]

---

[CR1]Suggest changing this to ‘parameter than can be overridden’.

[CR2]Suggest using sxp to make an aka.ms vanity alias for this: https://sxp.cloudapp.net