Provisioning

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.

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

We would like to have more audit log information available in elastic about recent changes in the configuration of provisioning source systems. The following actions should be audited in elastic as user actions When a user changes the configuration of a source system Configuration changes will be included from the following areas: Mapping Add or remove fields Import mapping Change of current mapped fields for person/contract Add or remove field Change of mapping configuration when type (fixed, field, complex) or value of a mapped field is changed Change field being required or not Scripting Person import Department import 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 change

We would like a way in which we can convert the current target system state (accounts & permissions) to HelloID entitlement state based on the business rules. This way we have an good overview of all the entitlements which are already assigned in the target system. Another big advantage is that when we do an evaluation after import that we see which accounts are created and which permission are granted instead of everything. This information should improve the go live experience. Also a advantage is that it requires less actions to be executed and reduces the time to go live. Suggestion: Get the following data from the PowerShell V2 target system Account Account Access Permission A new powershell script per account and per permission definition is required to collect the preferred import data from the target system. Convert the data into entitlements (network entitlement state) based on desired entitlements (configured in Business rules) Needs preview to check what the result of script is (preview times the same as in import) Show the difference and match between the network entitlement state and the desired entitlement state (minus enforcement state) based on the correlation configuration Import the (network entitlement state) as the entitlement state Cross check if account which has an account reference to a person does not correlate to another person Show record when only account access should be imported Show record when only memberships should be imported Update accounts on next enforcement after entitlement is imported Add origin imported entitlement to action on evaluation report (Elastic) audit logging: audit log for each managed/imported entitlement and log user action with summary. (add this also in person\system audit logging as managed logging) Add unmanage logging (bulk or manual) to person\system audit logging Import data based on configured grid filters Update all permissions when imported

We would like to see the progress and process logging of importing a target systems which in the end results in a snapshot. Solution: Add new sub menu item snapshots under target Add new sub menu item systems under target (this should refer to all target systems currently targets link) Show all import items in snapshot overview (like snapshot at source but per system import) Per snapshot logging information Show progress from import Add basic logging for AD

On the Contracts tab under Persons, the Primary contract is always shown on top, but the other contracts are seemingly shown in a random order. It would be nice to apply the sorting defined in the Primary contract configuration to this contracts overview. This would make the mechanism more understandable and allow customers to understand why a contract is primary and the other not when actively using more then one criteria. This is already implied because the primary contract configuration is a sorting mechanism, and the primary is the top contract, however not shown on the contracts tab.

We would like to see the username which started the import in the elastic logging when it's started manually.

In some cases as example TOPdesk we would like to use the sAMAccountName as correlation field. Because this is generated by a dependend system (AD) we would like to have support for the person.accounts<<systemname>>.attributes to be set as the person correlation field. This way we support values from dependend systems to be used as correlated value.