check sensitive windows groups

We usually bind this check to a DC, so I don't think I have run into that before.  I definitely have for other stuff, like DHCP.  Can't hurt to warn folks in the technical note section!

One note to add to description:  Need to install the Active Directory Powershell module on the LM collector that is monitoring the AD server you are applying the datasource to. 

@mnagelGreat datasource thank you!

Yes, I also pull data from ConfigSources to check into Git repos with post-commit triggers to send email.  That is how we can find out what actually has changed (and we have had to add a decent chunk of post-processing in some cases as the ConfigSources often suck in ephemeral updates, thrashing the changelog).  In this case, I really don't want to pull so much of something that should be handled within LM into external script processing.  My method works fine now, just unfortunately you cannot send ILP tokens into PowerShell collection scripts so the list of groups must be hardcoded.

I monitor certain ConfigSources, using the API. In my use case, I am taking the config data and sending it to documentation, but you could do the same, but send a message.

It could look like this:

1. 1. ConfigSource gets the membership. If a change is detected, generate an alert
2. 2. Using the API, a DataSource script gets alerts for the CS. If an alert is detected, retrieve the latest config data
3. 3. The DataSource could then generate an alert and/or just send a message with the membership, to an e-mail

Of course, you could also just run the alert-check script as a scheduled task, it does not need to be a DataSource.

17 minutes ago, mnagel said:

Changes can not be sent (unless you use an external API script), so you just get the red light alert ("something changed"). 

Yes that is a bummer, hopefully they'll improve that soon.

Just now, mnagel said:

Writing to a file is more or less how we used to do it with Nagios (technically, it was a File::Cache object) but that was with a central Nagios server + gearman and those checks always ran on the central server.  With LM, this would be suboptimal in the face of collector pools (coming, one day) or collector failover. IMO, the right for that is a distributed key/value store.

As for LMConfig -- it is a premium feature that we don't by default push our clients to have to add to their cost structure to achieve things that should be possible without it.  In this case, you could get away with one per domain, so the cost increase is defensible.  Will see what I can do...

Oh yes, now I recall why I did not consider LMConfig. Changes can not be sent (unless you use an external API script), so you just get the red light alert ("something changed").  My current alert message includes the current and expected list.  The alert communication channel in general is fairly small and I hate to constrain it further.

Writing to a file is more or less how we used to do it with Nagios (technically, it was a File::Cache object) but that was with a central Nagios server + gearman and those checks always ran on the central server.  With LM, this would be suboptimal in the face of collector pools (coming, one day) or collector failover. IMO, the right for that is a distributed key/value store.

As for LMConfig -- it is a premium feature that we don't by default push our clients to have to add to their cost structure to achieve things that should be possible without it.  In this case, you could get away with one per domain, so the cost increase is defensible.  Will see what I can do...

43 minutes ago, mhashemi said:

If your script wrote the members to a file, you could detect changes by comparing current membership to the content of that file.

+1 for LM Config

If your script wrote the members to a file, you could detect changes by comparing current membership to the content of that file.