ianhelle
commented
1 day ago Hi @BWC-TomW Frankly this code is a bit of a mess. It was originally written to work only with sub/res/workspace but then I tried to update it to use the details that are (likely) already contained in msticpyconfig.yaml. The majority case is that people have only 1 workspace to worry about.
Anyway, I've tried to fix it so that the parameters (either from full resource ID or sub/resgrp/ws override whatever is in the config. I also implemented the additional alert details in the same PR and did a few other house-cleaning bits and pieces.
Do you want to check that it behaves as you expect
Describe the bug When connecting to SentinelAPI specifying subscription id, workspace name, and resource group the subscription id and resource group are ignored and the first matching workspace name will match resulting in connection to wrong workspace.
I think this is down to https://github.com/microsoft/msticpy/blob/a6747bd438557eaa651771fc8a365b533ca4eb6d/msticpy/context/azure/sentinel_core.py#L132 where workspace config is set on https://github.com/microsoft/msticpy/blob/a6747bd438557eaa651771fc8a365b533ca4eb6d/msticpy/context/azure/sentinel_core.py#L104 and will be the first matching workspace with the given name. this causes the supplied paramaters to be ignored in favor to the match found in WorkspaceConfig.
To Reproduce
connection = MicrosoftSentinel(sub_id=config.mp_settings.get("SubscriptionId"),ws_name=config.mp_settings.get("WorkspaceName"), res_grp=config.mp_settings.get("ResourceGroup"), connect=True)Expected behavior
When subscription details are explicitly defined they should be favored over ones defined in WorkspaceConfig.
Additional context
Easy workaround is to specify the connection string as a res_id when connecting but not sure that this should be the expected behavior when using the alternative connection method defined here https://msticpy.readthedocs.io/en/latest/data_acquisition/Sentinel.html#instantiating-and-connecting-the-microsoft-sentinel-api-connector