Yes this is possible, and no/yes - you should be able to use wildcards. First, make sure you have your windows auditing enabled such that it logs these changes.
The easiest way is to use the out of the box "Auditable Group Events" Alert Group and create a rule that says:
[Auditable Group Events].GroupName = "SG-*_Support"
That will tell you whenever a user is added, removed, or group properties are updated and the Group Name contains that string. Alert Groups basically act like a built in "OR" for multiple different types of events that might occur, so you don't have to build multiple rules.
If you want to send an e-mail, the default "Account Modification" or "Domain Modification" template should work. You definitely want to capture EventInfo (description of change), GroupName (group that was changed), and SourceAccount (account that made the change), along with the timestamp (DetectionTime).
You could also go to the rule library (NATO5 Rules) and clone the rule "Group Events" and tweak it, but I think it'll be just as fast to build yours from scratch since you'll have to tweak both the correlations and the email template anyway.
Edit: I also wanted to add that if you do need to build a list of possible server group names, using a User-Defined Group would be the way to do it. You could build a UDG that had SG-servername1_Support, SG-servername2_Support, etc in it and then plug that into the right side of the equals sign in the correlation. The UDG acts as a built in OR as well ("match one of the items in this list").
Let me know if it'd be helpful to see an example, I can build it and export it for you, or take a screenshot!
Thank you so much for all your help on this. Unfortunately, I am REALLY new to Log and Event Manager. Can you give me the "for dummies" version of your instructions? I went to Build --> Groups and found the Alert Group "Auditable Group Events", but am confused on where to go from there. Do I edit the built in AlertGroup? Or clone it and edit the clone? Or something else entirely? And if I edit it...I cant seem to find the portion to put in "GroupName="SG-*Support"
If you dont mind, it would be really helpful to see an example. I want to build it myself, because that will help me learn it, but I am not sure where to start.
No problem! If you want to use a default group, you don't need to do anything in Build>Groups. That's basically for building blocks that are used in rules, filters, and searches. If you want to get an email, head over to Build>Rules and build a new rule.
Go to Build > Rules
Create a new rule
On the left hand side, select the "Alert Groups" list
Select the "Auditable Group Events" Alert Group
In the list of fields below "Auditable Group Events" click on "GroupName"
Drag "GroupName" into the correlations box (where it says "drag here")
What you'll see will be: [Auditable Group Events].GroupName = *
Click on the * to edit it and make it SG-*Support
At this point you've got a rule that says "if you see any Auditable Group Event where the Group Name matches SG-*Support"... and need to fill out the "then" which is actions.
On the left hand side, select the "Actions" list
Select the "Send Email Message" action
Drag it into the "Actions" box on the right side (orange)
Click the Template dropdown and select the "Account Modification" template
Select the user who should receive the e-mail in the Users dropdown
Fill out the fields in the e-mail by dragging fields from the Auditable Group Events Alert Group into the boxes in the action. For example, for $info, click and drag EventInfo into the box to the right of it. This basically says "whatever is in the EventInfo field when the rule fires, put it in the email".
Do the same thing for the other fields in the email.
Provide a name and click the "Enable" checkbox at the top of the rule to turn it on
At that point, you might make a change and see what you get. You can use the "Change Management Events" filter in Monitor to see that data come in in real-time, in case something comes out not quite as we expected.
It might be helpful to check out the rules quick video which runs through a simpler example first - Creating Rules for Real-time Correlation and Response with Log & Event Manager
Super helpful! Thank you! Just a few things to go over though:
When I try to select a user that should be a recipient of the emails, I actually want it to be a distribution group…how do I do that? Right now the only recipient option that it gives me is the local admin account which doesn’t have an email address. Also, what are the following fields for:
I will definetly watch the video too.
What I'd do to send to a distribution group is go to Build > Users and create a user that's a "Contact" user (doesn't need to be able to log in) that has the address of your DL.
Then, go back to the rule, and select that user as your User to notify. (That list only shows users that are in LEM)
The way email templates work is they glue together plain text in the template with dynamic fields from the events as they occur. So if you're tracking a group change alert, that template has stuff like:
"Something was modified blah blah, this is what it was: $Action. This is when it happened: $Date. This is more info about it: $Info. This is who was modified: $User." $Action, $Date, $Info, and $User are things you tie up to the actual group change event so they get substituted in automatically.
So, you'll want to drag:
[Auditable Group Events].EventInfo into $Action
[Auditable Group Events].DetectionTime into $Date
[Auditable Group Events].SourceAccount into $Info
[Auditable Group Events].GroupName into $User
That way you get the 4 pieces of information you're most interested in (what happened, when, what group was changed, and by whom) into the email.
You can also build your own e-mail templates in Build > Groups. Then you can call the fields whatever you want
Very cool! Can I not use an distribution group in AD for this though instead of a contact that is stored in the virtual appliance? And where are the settings to configure the smtp server that it uses to send with?
Yeah, you should be able to add the AD group to LEM and use the built-in contact address. Here's the KB: SolarWinds Knowledge Base :: How to create LEM console users with domain credentials
To configure the email server: SolarWinds Knowledge Base :: How to Configure the Email Active Response Connector
This alert isnt working... I performed a group membership change after configuring my domain account as the recipient of the alert, and never received the alert. I cant tell if the rule itself isnt firing, or if I'm just not getting the alert because of some sort of mail send error... where do I begin to diagnose this?
Step 1: Did you see the alert in the Console?
Check "Change Management Events" filter or search (Explore > nDepth) for "Auditable Group Events" (make sure the timeframe covers the time you made the change).
If not, we're either looking for the wrong thing, or something's not configured. Make sure the event is appearing in the DC's event log (if not check audit policy), make sure there's an agent on that DC and the right Windows Security Log connector is configured. If that all checks out, try searching for the Event ID instead of the type of event (just put the event ID into the search bar in nDepth).
Step 2: You saw it in the Console, but did the rule fire?
Check "Rule Activity" filter (or SolarWinds Alerts) for InternalRuleFired that says "the <whatever> rule fired" - one of these is triggered corresponding with rules firing so that you can retrace the steps. (If this happened too long ago, you can use upper left Gear > Send to nDepth to search historical data for when it might have fired in the past). Inside that event if you look at the details is a list of the actions that were triggered by that rule firing, so you can make sure the right one is selected.
If you don't see InternalRuleFired, either your appliance clock is more than 5 minutes off from your DC's clock, you forgot to "Activate Rules" after changing the rule, or something's up with the rule. Activate Rules is as simple as going to Build>Rules and pressing "Activate Rules" (this pushes your changes to the appliance so that new alerts are compared against the new criteria). To check the criteria, compare the rule to what you found in the search or filter.
Step 3: You saw InternalRuleFired, but did you get an email?
If you made it this far, chances are something's amiss with the email or user. You can check this with the "SolarWinds Alerts" filter, where you should see Internal alerts that indicate whether the action succeeded or failed - you'll see errors if it failed, or might see empty fields where something's not filled out correctly. You can also use the Event Explorer to see all related events - go back to the "Rule Activity" where you saw your rule fire, click on the InternalRuleFired for your rule, then on the upper right "Explore" and choose "Event". In the center, you'll see your InternalRuleFired, on the left, the alert that caused the rile to fire, and on the right side, you should see the actions that occurred. If you double click on the action, it'll move to the center, and on the right side you'll see the response, whether it succeeded or failed.
Double check the e-mail configuration (does a test e-mail succeed?) and double check the address for the user you've got selected in the rule.
Portions of these troubleshooting steps are also here, but I added some extra steps: SolarWinds Knowledge Base :: Troubleshooting LEM Rules and Email Responses
I do see the event show up in the DC event log and also in the LEM console...the rule is not firing though as far as I can tell. I dont even see a failure event in the SolarWinds alerts filter. I activated the rule, the appliance clock is spot on, but I cant figure out what is wrong with the rule. thoughts?
Does the GroupName field in one of those sample alerts match the criteria? Maybe we need to tweak the rule.
[Auditable Group Events].GroupName = SG-*Support
Maybe the GroupName doesn't contain the group? Does DestinationAccount or some other field? Or maybe GroupName contains it in the DN format and we need some more asterisks?
Let's go back to the beginning on this...
When I use nDepth to look for the events associated with group membership changes, I put in the following filter:
Auditable Group Events.DestinationAccount = SG-*_Support
The results that show up look like this (redacted):
There are two interesting thing to note here;
the first thing to note is that the rule is set up with the same parameters as the nDepth query (see image below), so i should at least be emailed on the events shown above.
the second thing to note is that the group membership add event doesnt show up with this filter. In the end, I primarily want a rule that tells me when membership is added into these groups, but ideally want an alert that shows membership removal as well.
Does this info help at all?
suddenly the alert is sort of working... just not showing the info that am looking for (same alert...why didnt it work before? maybe because "test" was checked? what does that do?)
I recieved the following alerts after adding a user to a group, and them removing that membership a few seconds after adding it.
second alert (weird that it is the same as the first...) :
so now, the questions are
- why didnt the alerts work before?
- Now that they are working, why do the first alerts not show what account was added into the group/what change was made, and who made it?
- Why does the last alert (the one showing the removal) not indicate who made the change?
- On all of the alerts, why is my name listed under "Summary:" ?
1 of 1 people found this helpful
Ohh, yes! The Test check box tells the system that you want it to "Fire" on the conditions, but no Actions are performed.
It's there so you can verify whether you're going to be getting a lot of alerts from this Rule, without actually flooding your e-mail server with those alerts.
In that instance, the event will show up as an "InternalTestRule" instead of "InternalRuleFired".
So to answer your questions:
The first two are literal changes made to the group itself (properties), but not related to Group Membership. If you want to specifically look for Group Membership changes only, instead of using a broadscope search with the Auditable Group Events , use "NewGroupMember" and "DeleteGroupMember", those are additions/deletions to the Group's membership.
( Feel free to replace the field "GroupName" with "DestinationAccount" as Nicole suggested, though from the nDepth capture, I think either field will work to accomplish the same goal. )
According to your Rule and E-mail template setup (guessing without seeing), the "Summary" is the person who made the change, which is why your user appears, and it's where it appears to tell you who made the change. So the last 3 questions are all related to that.
Message was edited by: Chris G. (Added note about GroupName vs. DestinationAccount)
Nicole was kind enough to point out the error in my ways... I hadn't taken into account the send e-mail action needing those details filled in from the events in my process of thinking earlier.
Because we're looking at two different events, there's no way to tell the system to use one or the other inside your Send E-mail Message fields ($Action, $Date, $Info, $User) without using an Alert Group, so the e-mail's information is filled in from whichever event is relevant.
The default Auditable Group Events Alert Group that Nicole suggested contains the following events: NewGroupMember, DeleteGroupMember, NewGroup, DeleteGroup, and ChangeGroupAttribute (the first two screen captures you provided previously were of this type).
So using that Alert Group will cover all possible events that can take place within the AD related to Groups, but since you're only after the membership changes, the best way to get around my earlier suggestion or having to use the entire set of alerts above would be to create your own Alert Group.
I would recommend cloning the default "Auditable Group Events" group under Build->Groups. The option to clone is on the gear menu at the left of the line the group is on. After it's cloned, a few adjustments are needed to make it fit your needs.
On the gear menu of the line that your clone group is on (it should be the selected/highlighted line immediately after cloning) select "Edit", and then change the name to reflect that it is a group of your own creation, maybe something like "MyCompany: Group Membership Events" or something similar. Then under the tree of "Alerts" (Event type), click the arrows for Audit Alert->Auth Audit->GroupAudit. Uncheck the boxes except for the New and DeleteGroupMember, then Save.
Head back over to your rule in Build->Rules, edit it, and open up Alert Groups on the left, and you'll see your newly created group in the list. Highlight it, then go to Fields and select the GroupName field, and drag it over the top of either of the existing correlations left-hand side. (The area that says New or DeleteGroupMember will highlight orange when it's replacing vs. adding.) Whichever of the two correlations you don't replace, just move to the right where the X appears to remove it.
Then in your e-mail message action, select the same fields (EventInfo, DetectionTime, SourceAccount, and GroupName) and just drag and replace those fields appropriately. The end result should be $Action = [My Group].EventInfo, $Date = [My Group].DetectionTime, etc.
Sorry for the confusion, that should set things straight.
I created two separate rules... on that handles the NewGroupMember event, and another that handles the DeleteGroupMember event. this seems to be working out. Thanks for all your help!