Identity Broker Forum
Welcome to the community forum for Identity Broker.
Browse the knowledge base, ask questions directly to the product group, or leverage the community to get answers. Leave ideas for new features and vote for the features or bug fixes you want most.
Access to source entity fields for target entities returned by CheckFieldUniqueness
When using the CheckFieldUniqueness component to ensure target entity field uniqueness I would like to use source entity field values in order to calculate candidate values for the unique field. I'm only aware of a way to access target entity field values.
Is there a way to access the source entities for a target entity in this scenario?
Otherwise, please change this ticket to an Idea to have the ability to do so.
I see. You could just mapping the required values to to fields on the target entities, but assuming you don't want to do that you should process the $joinedEntities collection into a HashTable keyed on the target entities. For example:
$entityMap = @{};
foreach ($joinedEntity in $joinedEntities)
{
$entityMap[$joinedEntity.TargetEntity] = $joinedEntity.SourceEntity;
}
You'll then be able to use the target entities returned by CheckFieldUniqueness to lookup the corresponding source entity efficiently.
Time Offset Flag description in UNIFYBroker doesn't match the implementation or the voice documentation
On the Edit Timeoffset Flag page in the UNIFYBroker UI, the description says:
In particular, "The target value is populated based on whether the current time is less than, equal to or greater than the offset value".
The Voice documentation (https://voice.unifysolutions.net/en/knowledge-bases/7/articles/2888-time-offset-flag-transformation) says:
An actual configuration appears like this in the UI:
When this transform was evaluated on 15/12/2020 for a value of StartDate="03/Feb/2020" the value to which PreStart was set was "Yes".
This matches the UI configuration, and the Voice documentation (i.e. source time compared to NOW - with the source time offset implied). However, it does not match the description in the "Edit Timeoffset Flag" UI (i.e. NOW compared to the offset value - with "offset value" presumably meaning "source time plus offset"). The "Edit Timeoffset Flag" UI description is reversed compared to those others and therefore misleading.
This has been implemented and is available in the release of UNIFYConnect V6, which will be made available shortly.
AD Agent default destination port should be 636 if SSL is selected
In the ActiveDirectory agent the default destination port is 389. This can be overridden by appending a colon and an explicit port to the Server configuration.
In AD, port 389 is conventionally used for non-SSL traffic and port 636 is used for SSL traffic. The default port should reflect the SSL setting, in order to avoid confusion and reduce the risk of inadvertent configuration error.
Managing AD user account distinguished name/organisational unit from UNIFYBroker (The connector does not support anchor modification)
Using UNIFYBroker and the Active Directory agent/connector I can set a new user account's organisational unit via their distinguishedName during account creation, but when I subsequently try to modify it this error is logged:
UnifyLog20201207.csv:14572:System.AggregateException: One or more errors occurred. ---> System.AggregateException: One or more errors occurred. ---> System.NotSupportedException: The connector AD Users does not support anchor modification.
My customer's solution requires that an employee's OU be managed. Do you have any suggestions how I could achieve this?
Hi Adrian
The "anchor" in the error message is in reference to the connector schema field/s which are marked as Key. Use a different, unique field which doesn't change as the connector key instead. Moving a user between OUs with the AD connector works, and has been done a lot in the past, so there should be plenty of PS resources you can reference.
Allow $logger component to specify module and submodule fields
There is no documented way to set the third and fourth fields (which I will call 'module' and 'submodule') of each UNIFYBroker log entry when calling the $logger component. It would be nice to be able to set them to more informative values, rather than always having them as 'UNIFYBroker' and 'PowerShellTask' respectively.
Hi Adrian,
The $logger component is designed to be a simple wrapper around the logging mechanism. For more complex log messages, use the $messageService variable.
There's some extension methods provided for the next level of logging. You can find more information on those here:
Class NotificationEnumerableExtensions (unifysolutions.net)
Otherwise, you can use the underlying NotificationMessageService to notify listeners of a particular message. In this case, the product loggers will be listening on ILogEntryNotification: Class LogEntryNotification (unifysolutions.net)
The tricky thing with crafting one of these will be building the branding object, (for a BrandedLogEntry). Technically this would allow you to change both the 'module' and 'submodule' components.
For ease of use, i'd recommend just using the NotificationEnumerableExtensions to log - which still use the underlying product for the third field but allow you to define the fourth field.
As a side note, for some reason the $messageService variable isn't actually hooked up for the Plus components, but is hooked up for the Powershell connector and transformations.
Request to sync changes on link in direction outgoing failed with message Duplicate key calculating target to source id lookup
Can you tell me what circumstances might cause this error to happen? I'm not sure where to start investigating. I can't find any problems with what the solution is doing, just this error that occurs whenever I run a Baseline Sync on one of the links.
Thank you
Hi Adrian
It looks like a number of of your locker entities have had multiple connections generated for them. Connections are the record Broker keeps that maps adapter entities to locker entities. Normally there is only one per entity pair per link, but it's not impossible for duplicates to be generated if a link is reconfigured.
The quickest way to fix this would be to clear the locker and re-baseline all related links, which deletes any connections associated with the locker entities. The same also applies to adapter entities.
Generating unique field values in Link pre-provisioning tasks
In a Link pre-provisioning task I would like to generate a unique value for an adapter field. I tried using $components.CheckFieldUniqueness to check $targetEntities, but that variable only contains adapter entities that are being provisioned, and not all the others that already exist in the adapter.
I also looked at $joinedEntities, but it similarly only includes the entities being provisioned.
Can you suggest some way that I can perform a unique value check for a field across all adapter entities?
In the MH solution I used a call-out to AD directly (via the ActiveDirectory PowerShell module) rather than using $components.CheckFieldUniqueness() so I didn't see this behaviour.
Unfortunately in this solution the field value clashes will be very common because the customer wants the first UPN that gets tried to be derived solely from the person's first name.
Case insensitive version of $components.CheckFieldUniqueness?
$components.CheckFieldUniqueness appears to be case sensitive, but UserPrincipalName in AD is case insensitive.
In my solution I am doing a check to ensure my UserPrincipalName field value is unique and $components.CheckFieldUniqueness tells me it is, but my update to AD fails because there that value is already present with different case.
i.e. "tom@contoso.com" vs "Tom@contoso.com"
How can I perform a case insensitive unique value check?
Unify.Framework.EvaluatorVisitorException: An error occurred while evaluating a task on a worker thread. See the inner exception details for information. ---> Npgsql.PostgresException: 22P05: unsupported Unicode escape sequence
UNIFYConnect instance created some new users in an AD connector, but then the next time it ran the following error appeared:
UNIFYBroker/Plus doesn't enforce managed field values during Changes Polling but does during Baseline Sync
When a lower priority incoming adapter source field value change is processed by a Changes Polling operation, higher priority field values from the target locker are not written back to the adapter entity. When a Baseline Sync operation runs they are. The practical outcome of this is that UNIFYBroker only enforces managed field values in downstream systems when a Baseline Sync is run.
Here's an example from a UNIFYConnect instance: MemberDNs is a multi-valued string field for managing group membership.
Incoming from Azure Cloud Groups:
Outgoing to AD Groups:
The mapping priorities in the Locker are as follows (i.e. Azure Cloud Groups is set as a higher priority mapping than AD Groups):
When the MemberDNs field of the Azure Cloud Groups entity changes (i.e. add or remove a value) that change goes through to the AD group and the AD group's membership is updated with the current values from the Azure Cloud Group and locker entity, as expected.
However, if the group membership's membership is then changed directly in AD that change then comes back as far as the adapter entity, but doesn't flow into the locker entity (and neither should it, because there are already a higher priority values mapped into the locker from the Azure Cloud Group adapter). However, the correct values from the locker are not being written back to the adapter, which is the functionality we would like to have, so that when a change is made to a managed attribute in a downstream system UNIFYBroker/Plus will quickly revert that change and enforce the correct upstream value.
When a subsequent Baseline Sync is run on the AD Groups link the correct value from the locker is written to the adapter and the downstream system is updated to enforce the value. This is a functional workaround, but scheduling frequent Baseline Sync operations has an operational overhead.
Perfect - thanks for confirming. I'll close this one and we'll track progress on the related ticket:
Customer support service by UserEcho
