Provisioning

Enable manual linking of an unmanaged account (not currently matched via correlation or as account entitlement in system) to a person when processing an entitlement import report. This facilitates future automatic matching through updated correlation values. Manual Selection of Unmanaged Accounts Allow users to manually select an unmanaged account from the entitlement import report when: A person should have an account entitlement, but no matching account is found based on the correlation value. Also when we found mulitple macthing accounts. There exists a potential unmanaged account not currently linked or managed to another person. Search on account username & displayname as returned in import account data script. Allow to edit/clear the manual selected account up until the entitlement import is executed Add extra filtering state “manually matched” Link and Import Action Upon selection: The unmanaged account is imported and granted to the selected person. The system should perform an update acount on the imported account, setting the account correlation value (e.g., username, employee ID) to match the person’s correlation property value. When account is selected update the view with account access and permissions that will be imported When a manual selection for an account has been made then add warning uppon recreate report for the import of entitlements: Export import entitlement report Add manually selected state and other states to report Effect on Future Imports This linkage ensures that: On the next entitlement import run, the previously unmanaged account is now recognized and automatically matched to the correct person. Remove correlation reports from AD & Azure AD builtin target systems Use Case Example Person John Doe should have an account entitlement, but no matching account is found. An unmanaged account jdoe123 exists in the source system but the correlation value of the account doesn’t matched the person correlation value. Admin manually selects jdoe123 to link to John Doe. The account is imported, the correlation value (e.g., username) is updated to jdoe123, and the account is linked to John Doe. When all account entitlements are unmanaged on the next entitlement report, the system automatically matches jdoe123 to John Doe.

Currently, we support processing up to 3 million records from snapshots for reconciliation. However, this limit is insufficient for larger tenants or those with numerous target systems. To address this, we plan to increase the supported limit. This effort will be best-effort and timeboxed—we will allocate one sprint (approximately one month) to focus on scaling this capability. The goal is to achieve meaningful improvement within that timeframe, without guaranteeing support for all possible volumes.

We would like to have more audit log information available in elastic about recent changes in the configuration of provisioning target systems. The following actions should be audited in elastic as user actions When a user changes the configuration of a target system Configuration changes will be included from the following areas: Mapping Add or remove fields Import mapping Change of current mapped fields Rename field Change type (text, array) Change of description Change of applicable entitlement action configuration(s) Change of mapping configuration when type or value of a mapped field is changed - Options Enable/disable use in notifications Enable/disable store in account data Scripting User lifecycle for PowerShell V2 Permission configuration changes for PowerShell V2 Retrieve permissions script Grant, revoke, update, or all in one script changes scripting Resource configuration Add or remove resource configuration sets Resource creation script Post actions scripting for Active Directory Uniqueness validation Scripting changed Changes in the applicable action selection Correlation configuration Thresholds Enable or disable a threshold Configured threshold value change System configuration Configuration of fields (Custom connector configuration) Configured field values (from configuration TAB) Execute on-premises or cloud changed For target system changes the functionality will be limited to only include the following systems: Active Directory (builtin) PowerShell V2

In certain scenarios, it's necessary to establish precedence among permissions in the event of conflicts or to optimize licensing costs by consolidating entitlements. To address this, we utilize toxic combinations, which dictate how conflicting permissions are resolved when multiple entitlements are granted. Configure a Toxic combination: Name: Provide a descriptive label for the rule. Description: Briefly explain the purpose and context of the toxic combination. Input entitlements: Define the conflicting combination of permissions from one or more systems. Output entitlements: Specify the subset of permissions to be retained when the toxic combination occurs. Benefits: Permission Conflict Resolution: Effortlessly configure conflicting combinations of permissions and specify the preferred resolution. Overview of Configured Toxic combinations: Easily access and manage all established toxic combination. Evaluation Visibility: Clearly indicate actions triggered or caused by toxic combinations during evaluation processes. Filtering Capabilities: Streamline analysis by filtering actions based on their association with toxic combinations.

We would like to force update of accounts and permissions via enforcement instead of running separately with an fire and forget mechanisme . This has the advantages that dependencies from systems are taken into account and the inconditions flag will be up to date on contracts because the updates are running in an enforcement. The only drawback is that the force update will not trigger immediately but an enforcement is needed to execute the update actions.

Fieldmapping types with the type none cannot be seperated from actual mapped fields with a $null value. This is very confusing and makes it a bit of a strage mapping type to use. The purpose of a field with mappingtype none would be to return the data from a target using the script, and not set it. It would be way more logical to not provide the fields in the actionContext, because they should not be set. But keep them in the outputContext because they do need to be returned.

Currently, when running an enforcement, you must wait for all actions to execute successfully or fail. This can lead to longer implementation times, as mistakes made during configuration may only become apparent when processing a large set of actions. To assist implementers, we would like to introduce a way to cancel running actions within an enforcement. Requirements: Add a button to cancel an enforcement while actions are still running or waiting. Only cancel actions that have not yet started or have not been sent to the agent.

We would like to see when accounts or permissions are not imported from a target system because the data isn't valid. As example a permission is missing an account reference when returned from powershell in the import target system data script. Show overview of invalid data (tab in snapshot overview) Show info that data is deleted when a new snapshot is created (only latest is stored) Show origin of data Reason of invalid (like source -> field and error) validate all data and show (possibly) multiple validation errors Filter on origin/reason/search on displayname

Within this feature we review the HelloID entitlement state agains the current state of a Powershell V2 target system. Match the state from a Powershell V2 system (network state) against entitlement state (based on account entitlement reference) Match only on granted entitlements (not on open actions) Based on mismatching show the following data in a report Filter on systems & scenario & mapped account properties. This should contain all the same specifications as the current reconciliation for Active Directory. The biggest differences are that we support subpermissions in the report but it's not possible to take actions (against the target system) on the subpermissions besides exclude or resolve. Limits: We support the processing of up to 3 million records for reconciliation. This limit includes records from all configured systems.

We would like to remove reconciliation exclusions in bulk so it's easier to manage the exclusions. Too remove the exclusions in bulk we add support for filtering the following information: account permission name (sub permission in case sub permission issue type)