Forum Discussion

mnagel's avatar
mnagel
Icon for Professor rankProfessor
5 years ago

check sensitive windows groups

In our previous life, we had written a Nagios plugin to check whether a sensitive Windows group had changed (e.g., Domain Admins).  I created a replacement for this within LM, but since we can't really keep track of deltas without a key/value store, we use a property for each group that specifies the expected members, which should be updated when membership changes intentionally.  We also use a property to list the groups for AD so we can store useful ILPs, but since those ILPs are not passed to the collection script (they could be, just are not currently passed for Powershell), the list of groups that can be checked is restricted to what is builtin to the collection script.

For one or more AD controllers then, you would specify (for example):

windows.groupcheck.list: Domain Admins
windows.groupcheck.spec.Domain_Admins: administrator,alice,bob

If the list diverges, the datapoint for that group will alert.  There is also a total count of members that is tracked, and can be used to set an alert if needed (e.g., some groups like Schema Admins should normally be empty, but that can be handled by the spec).

2Y9FM6

  • 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.

    1.  
  • Anonymous's avatar
    Anonymous
    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...

  • Anonymous's avatar
    Anonymous
    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.