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.

0
Answered

Could not complete synchronization on link due to a converging join error

Adrian Corston 3 years ago in UNIFYBroker/Plus updated by Matthew Davis (Technical Product Manager) 3 years ago 3

The follow error is appearing in my UNIFYBroker/Plus log.  Could you tell me more about what it means?

Request to sync changes on link failed.
Request to sync changes on link Employees > AD Users (6410cee2-8159-4cc3-89d6-0a3cc3d46fdb) in direction outgoing failed with message Could not complete synchronization on link '6410cee2-8159-4cc3-89d6-0a3cc3d46fdb' due to a converging join error.
First source entity id: cb04dfa0-66e9-46fd-862d-54512e11f2c3
Second source entity id: fb3ee77f-5370-44e7-b1ce-0b01c39c0f88
Offending target entity id: 4ffd33d1-ec16-464d-90cc-ab0fe7d7b93a [Count:6492]. Duration: 00:00:02.2246402
Error details:
System.Exception: Could not complete synchronization on link '6410cee2-8159-4cc3-89d6-0a3cc3d46fdb' due to a converging join error.
First source entity id: cb04dfa0-66e9-46fd-862d-54512e11f2c3
Second source entity id: fb3ee77f-5370-44e7-b1ce-0b01c39c0f88
Offending target entity id: 4ffd33d1-ec16-464d-90cc-ab0fe7d7b93a
at Unify.Product.Plus.LinkSynchronizer`2.JoinAndMap(IEnumerable`1 filterResult, IDictionary`2 changesDict)
at Unify.Product.Plus.Link.SynchronizeChanges[TSourceEntity,TTargetEntity](IEnumerable`1 changes, IEnumerable`1 syncTasks, Func`1 getTargetContextAccessor, IConnectionsContext connectionContext, ISynchronizationHelper`2 helper, IProvisioner`2 provisioner)
at Unify.Product.Plus.Link.SynchronizeAdapterChanges(IEnumerable`1 changes)
at Unify.Product.Plus.LinkNotifierDecorator.<>c__DisplayClass42_0.<SynchronizeAdapterChanges>b__0()
at Unify.Framework.Notification.NotifierDecoratorBase.Notify[TResult](ITaskNotificationFactory notificationFactory, Func`1 function)
at Unify.Product.Plus.LinkNotifierDecorator.SynchronizeAdapterChanges(IEnumerable`1 changes)
at Unify.Product.Plus.LinkAuditingDecorator.SynchronizeAdapterChanges(IEnumerable`1 changes)
at Unify.Product.Plus.AdapterToLockerSynchronizationJob.RunBase()
at Unify.Product.Plus.SynchronizationJobExecutor.<ThreadAction>d__8.MoveNext()

Answer

I found the duplicate adapter record - this is indeed a data error so this ticket can be closed.

Thank you!

0
Fixed

UNIFYBroker/Plus locker deprovision doesn't remove entities from CSV or PowerShell connectors

I have a UNIFYBroker/Plus link with outgoing deprovision configured to a CSV adapter/connector, and when a joined locker entity is deleted the joined adapter/connector entity isn't deleted when a Changes Sync is run on the link.  It isn't deleted when a Baseline Sync runs on the link, either.

I tried the same process with a PowerShell connector and the same behaviour was apparent (i.e. the adapter/connector entity was not deleted).  I added logging and confirmed that the entity was not passed to the PowerShell connector's Delete script at all.

For reference, after Sync the Remove Joins page for the link did not show the deleted entity for either the locker or the adapter.

I don't know of anyone from Professional Services who has used Outgoing Deprovision in a UNIFYBroker/Plus solution before, so it may be worth checking around to see if this functionality has every been exercised before.

0
Answered

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.

Image 5940

Thank you

Answer

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.

0
Answered

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.

0
Answered

Case insensitive version of $components.CheckFieldUniqueness?

Adrian Corston 3 years ago in UNIFYBroker/Plus updated 3 years ago 3

$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?

0
Fixed

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:

Image 5936

0
Declined

UNIFYBroker/Plus doesn't enforce managed field values during Changes Polling but does during Baseline Sync

Adrian Corston 3 years ago in UNIFYBroker/Plus updated by Matthew Davis (Technical Product Manager) 1 year ago 4

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:

Image 5928

Image 5929

Image 5930

Outgoing to AD Groups:

Image 5931

Image 5932

Image 5933

The mapping priorities in the Locker are as follows (i.e. Azure Cloud Groups is set as a higher priority mapping than AD Groups):

Image 5934

Image 5935

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.

0
Planned

Created/Modified dates are not correct on the Remove Joins screen

Adrian Corston 3 years ago in UNIFYBroker/Plus updated by Matthew Davis (Technical Product Manager) 1 year ago 1

On the Remove Joins screen the Created and Modified dates are both set to "00001-01-01 00:00:00Z" for Adapter entities:

Image 5917

This is not impacting me in any way and I'm just mentioning it for completeness.

0
Fixed

Using Remove Joins (to view existing joins) generates DataTables Error (SocketException: the target machine active refused it)

Adrian Corston 3 years ago in UNIFYBroker/Plus updated by Matthew Davis (Technical Product Manager) 3 years ago 2

The following UI error appears whenever I attempt to view joins via the 'Remove Joins' menu option on a Link in the Netwealth UNIFYConnect DEV instance:

Image 5915

I am using Chrome on the jumpbox VM, logged in with my UNIFY credentials. The error is not written to the UNIFYBroker log.

Answer

Fix deployed. Patch for reference (in Web/bin folder)

Unify.Plus.Web.Extensibility.dll

0

Improved UNIFYBroker/Plus log/UI messages (de/provisioning counts, incompletes, log message grouping)

Adrian Corston 3 years ago in UNIFYBroker/Plus updated by Matthew Davis (Technical Product Manager) 2 years ago 0

UNIFYBroker/Plus would be easier to operate if the following logging and UI messages were added or made more clear:

* A log summary of the count of entities provisioned and deprovisioned by a locker synchronisation (this may already be there, but the terminology is "added" rather than "provisioned" - it would be nice if this was consistent with the UI and clearly delineated as being different to entities "added" to the adapter via reflection)

* An log explanation of the reason(s) why an entity's provision was Incomplete - i.e. which required fields are missing, or whatever else it was that caused it to be Incomplete.

* A way to identify all of the logging messages that are part of the same synchronization operation.  In a busy log file it's hard to see the wood for the trees...

* Not to report un-joined and un-provisioned entities for a linker as Incomplete during Baseline Synchronization.  The configuration clearly doesn't want these entities in the locker - but the yellow (i) box that appears seems to suggests that something may have gone wrong with them.