EmployeeOn 3/31/2022 at 11:50 PM, Antony Hawkins said:What:
A DataSource that uses the /setting/roles API endpoint to examine global and User Role settings for Multi-Factor Authentication (MFA) and Remote Session status, and User count per Role, to monitor how many (if any) Users can access your portal without MFA, and how many have any access to the Remote Session functionality.
Note that this does not examine for SSO status; if you are using or mandating SSO then any MFA requirements would typically be enforced by your SSO solution.
The per-Role Remote Session monitoring will indicate access if the Role has any Remote Session abilities, whether that's to one specific Resource Group or all Resources. I'm not seeing an easy way to further differentiate within the DataSource structure, having examined the API response. As such the Remote Status metrics won't change if, for example, a Role already has Remote Session enabled for one Resource Group and is edited to permit Remote Session for other Resource Groups. For that you could take bits of this script and rework it into a ConfigSource, which I think would be the most efficient way to alert on subtle changes like this.
As per documentation, if MFA is enforced, or Remote Session disabled, globally, these settings override the respective Role settings. While these are individually reported by this DataSource, the counts of Users for each setting takes account of both the Role and global settings - i.e. if a Role has Remote Session enabled but this is globally disabled, the count of Users in that Role with Remote Session access will always be recorded as zero (and similarly for the MFA counts).
Why:
Bluntly, because a prospective customer asked if there was any way to be alerted if there were any changes to the 2FA and Remote Session settings, and it didn't seem particularly difficult.
Their intention is that no-one (save possibly full admins) should have Remote Session access, and all users should have 2FA enforced. Your intentions may vary, of course, but you may still want to keep track of such things in an alertable manner.
You will need:
A LogicMonitor Portal Resource such as you may already have created and applied all our core LogicMonitor_Portal_* LogicModules to (as per https://www.logicmonitor.com/support/logicmonitor-portal-monitoring), and LogicMonitor API credentials set as Resource Properties on this, for an API user with the rights to view Settings data. These modules will accept the same properties that those core modules use, i.e. lmaccess.id or logicmonitor.access.id for the API token ID; and lmaccess.key or logicmonitor.access.key for the token key (in those orders of preference).
The script will take the account name directly from collector settings.
The AppliesTo also aligns with those core modules, for obvious reasons.
Then what?
Sit back while it applies and monitors...
Various graphs are defined to show overall and per-Role statuses and counts.
Clearly, different customers will have different opinions on what counts as acceptable or otherwise, both globally and per-Role, so no alerting thresholds are set.
DataSource Name: LogicMonitor_Portal_RoleSecurity
v1.0 Published with lmLocator: 2HRMAM
is this publicly available, as facing issue while addin it .
