I have a SCIM gateway configured in UNIFYConnect and the following error appears every time a SCIM request is received:

There is a mapping for the employeeNumber field, as evidenced here:

I tried recycling, and then deleting and recreating the gateway from scratch but it continues to give me the same outcome.

The UNIFYConnect external address for the gateway is "https://unifyconnect-scim-dev.unifysolutions.net/CUSTOMERNAME-dev-B2BAD/"

How can I stop this error from appearing and get my config to work correctly?

I removed a user's application assignment in Azure and it initated a disable (i.e. delete user profile) SCIM operation and reported a successful outcome:

However, the user profile object remained present in UNIFYBroker:

According to the UNIFYBroker logs the request came through as an entity update (I know this from the PowerShell debugging tracewrites shown):

20220428,13:07:42,UNIFYBroker,Logging,Information,Reverse Transform extracted ROLE=[NONE],Normal
20220428,13:07:42,UNIFYBroker,Logging,Information,"[EmployeeGuid, 14de44ec-2322-4c75-b745-cb873341f8e4] [Application, XXXXXXXXX] [Active, False] [UserPrincipalName, admin@unifyXXXXXXXX.onmicrosoft.com] [TicketingID, XXXXXXXXX.14de44ec-2322-4c75-b745-cb873341f8e4] [Role, NONE] [EmployeeName, David Parsonson] [0799C19A00044B368A7D06D9AE23CC07, c36f2c4a-4eb6-46ac-a69c-9565ec327e9e]",Normal
20220428,13:07:42,UNIFYBroker,Connector,Information,"Request to update entity to connector.
Request to update entities [Count:1] to connector Ticketed Application Provisioning.",Normal
20220428,13:07:45,UNIFYBroker,Logging,Information,GIEBP(Application),Normal
20220428,13:07:45,UNIFYBroker,Logging,Information,"PV=(XXXXXXXX) for [EmployeeGuid, 14de44ec-2322-4c75-b745-cb873341f8e4] [Application, XXXXXXX] [Active, False] [UserPrincipalName, admin@unifyXXXXXXXXX.onmicrosoft.com] [TicketingID, Marketo.14de44ec-2322-4c75-b745-cb873341f8e4] [Role, NONE] [EmployeeName, David Parsonson] [0799C19A00044B368A7D06D9AE23CC07, c36f2c4a-4eb6-46ac-a69c-9565ec327e9e]",Normal
20220428,13:07:45,UNIFYBroker,Logging,Information,"Saving [XXXXXXX.14de44ec-2322-4c75-b745-cb873341f8e4] [EmployeeGuid, 14de44ec-2322-4c75-b745-cb873341f8e4] [Application, XXXXXXX] [Active, False] [UserPrincipalName, admin@unifyXXXXXX.onmicrosoft.com] [TicketingID, XXXXXX.14de44ec-2322-4c75-b745-cb873341f8e4] [Role, NONE] [EmployeeName, David Parsonson] [0799C19A00044B368A7D06D9AE23CC07, c36f2c4a-4eb6-46ac-a69c-9565ec327e9e]",Normal
20220428,13:07:45,UNIFYBroker,Logging,Information,update: init Lines=@{Application=XXXXXXX; Active=True; EmployeeId=; EmployeeName=David Parsonson; Role=Admin; UserPrincipalName=admin@unifyXXXXXXXX.onmicrosoft.com; TicketingID=XXXXXXX.14de44ec-2322-4c75-b745-cb873341f8e4; EmployeeGuid=14de44ec-2322-4c75-b745-cb873341f8e4} @ 1,Normal
20220428,13:07:45,UNIFYBroker,Logging,Information,update: after Lines=@{Application=XXXXXXXX; Active=False; EmployeeId=; EmployeeName=David Parsonson; Role=NONE; UserPrincipalName=admin@unifyXXXXXXX.onmicrosoft.com; TicketingID=Marketo.14de44ec-2322-4c75-b745-cb873341f8e4; EmployeeGuid=14de44ec-2322-4c75-b745-cb873341f8e4} @ 1,Normal
20220428,13:07:45,UNIFYBroker,Logging,Information,update done,Normal
20220428,13:07:45,UNIFYBroker,Logging,Information,Updated 1 entities in C:\CSV\XXXXXXXX-Users.csv,Normal
20220428,13:07:45,UNIFYBroker,Connector,Information,"Update entities to connector completed.
Update entities 1 to connector Ticketed Application Provisioning reported 1 entities saved, 0 failed. Duration: 00:00:02.9484342",Normal

The UNIFYBroker entity for the user should have been deleted rather than updated.  It looks like UNIFYBroker has missed the "Action: disable" part of the SCIM request from Azure, which is the only indication I can see that the request was to disable/delete the user, rather than update it.

Can you please check that UNIFYBroker work with SCIM disable requests from Azure correctly?

This is high priority for me as I have been asked to deliver SCIM app provisioning functionality (including disable) for the customer to UAT by early next week.

Thanks

I am seeing the above error *sometimes* when attempting to update a user via SCIM.

In every case of the error that I've seen SCIM has been trying to update a single field (Role) which is mapped from Azure's large "appRoleAssignments" XML field value, but I don't actually know if that's relevant or coincidental.

The full stack trace is:

20220428,11:53:00,UNIFYBroker,Logging,Information,Healthcheck,Normal
20220428,11:54:00,UNIFYBroker,Logging,Information,Healthcheck,Normal
20220428,11:54:05,UNIFYBroker,SCIMGateway,Error,"Error during SCIM operation: System.InvalidOperationException: Sequence contains more than one element
at System.Linq.Enumerable.Single[TSource](IEnumerable`1 source)
at Unify.Product.IdentityBroker.SCIMProvider.Patch(IAdapterEntity adapterEntity, PatchRequest2 patch, ISCIMGatewayMapping mappings, IValueAdapter`2 valueAdapter, IEntitySchema schema)
at Unify.Product.IdentityBroker.SCIMProvider.d__20.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.SystemForCrossDomainIdentityManagement.ProviderBase.d__45.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.SystemForCrossDomainIdentityManagement.ProviderAdapterTemplate`1.d__15.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.SystemForCrossDomainIdentityManagement.ControllerTemplate`1.d__5.MoveNext()",Normal
20220428,11:55:00,UNIFYBroker,Logging,Information,Healthcheck,Normal

Here's the Azure provision on demand output that corresponds to the error:

I can't work out why this happens for some user updates, but others go through just fine.  Since I can't packet trace the SCIM protocol in UNIFYConnect environment my ability to debug this is limited, and unfortunately right now I don't really have time to set up a non-UNIFYConnect test environment to debug what's going on.

The backing connector for the SCIM gateway is a PowerShell one, but the error appears to be occurring before it's even called.

I saw https://voice.unifysolutions.net/en/communities/6/topics/3913-sequence-contains-more-than-one-element for the same error, but I am running the latest of everything so the advice on that ticket (upgrade) didn't help.

Do you have any hints what might be going on to result in that error message?

I put through an update from Azure via SCIM which had two attributes changing at the same time, and the following error appeared in the UNIFYBroker log:

20220422,05:36:27,UNIFYBroker,SCIMGateway,Error,"Error during SCIM operation: System.InvalidOperationException: Sequence contains more than one element
at System.Linq.Enumerable.Single[TSource](IEnumerable`1 source)
at Unify.Product.IdentityBroker.SCIMProvider.Patch(IAdapterEntity adapterEntity, PatchRequest2 patch, ISCIMGatewayMapping mappings, IValueAdapter`2 valueAdapter, IEntitySchema schema)
at Unify.Product.IdentityBroker.SCIMProvider.d__20.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.SystemForCrossDomainIdentityManagement.ProviderBase.d__45.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.SystemForCrossDomainIdentityManagement.ProviderAdapterTemplate`1.d__15.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.SystemForCrossDomainIdentityManagement.ControllerTemplate`1.d__5.MoveNext()",Normal

Here is the corresponding update from the Azure side:

As a possible complication for this ticket, the user involved previously didn't have a value for their employeeNumber field (which is a required/key field of the underlying connector) and that caused this error:

20220422,05:34:08,UNIFYBroker,An exception has occured in the AdapterEntityChangeDetectorCollator. Please see the exception for details,Error,"Npgsql:
System.InvalidOperationException: Parameter 'key1value0' must have its value set
at Npgsql.NpgsqlParameter.ResolveHandler(ConnectorTypeMapper typeMapper)
at Npgsql.NpgsqlParameter.Bind(ConnectorTypeMapper typeMapper)
at Npgsql.NpgsqlCommand.ValidateParameters()
at Npgsql.NpgsqlCommand.d__100.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Npgsql.NpgsqlCommand.d__92.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Npgsql.NpgsqlCommand.ExecuteNonQuery()
at Unify.Product.IdentityBroker.MultiKeyValueQueryExecutor`2.PopulateTempTable(NpgsqlConnection connection, NpgsqlTransaction transaction, IDictionary`2 tempKeyLookup, ValueToObjectAdapter adapter, IEnumerable`1 multiKeyValues, String tempTableName)
at Unify.Product.IdentityBroker.MultiKeyValueQueryExecutor`2.Execute(NpgsqlConnection connection, ValueToObjectAdapter adapter, Guid partitionId, IEnumerable`1 multiKeyValues, String tempTableName, String entityValueFieldName, String entityTableName, String partitionIdName, Func`2 readData)
at Unify.Product.IdentityBroker.KnownEntityPartitionPostgreSqlUpdatableContextBase`3.GetEntities(Guid partitionId, IEnumerable`1 keys)
at Unify.Product.IdentityBroker.EntityRepositoryExtensions.<>c__DisplayClass1_0.b__0(MultiKeyValue`1[] multiKeyValues)
at Unify.Product.IdentityBroker.EntityRepositoryExtensions.ConvertConnectorEntities(IEnumerable`1 connectorEntities, IMultiKey`1 schemaKey, Func`2 retrieveEntities, Guid connectorId, IEnumerable`1 wellKnownEntities)
at Unify.Product.IdentityBroker.EntityRepositoryExtensions.ConvertConnectorEntities(IEnumerable`1 connectorEntities, IMultiKey`1 schemaKey, IKnownEntityContextBase`3 context, Guid connectorId, IEnumerable`1 wellKnownEntities)
at Unify.Product.IdentityBroker.EntityChangeDetector.ProcessConnectorChangedEntities(Guid connectorId, IEnumerable`1 connectorEntities, IEnumerable`1 wellKnownItems)
at Unify.Product.IdentityBroker.AdapterEntityChangeDetectorCollator.DetectChanges(KeyValuePair`2 connectorEntities)
at Unify.Framework.Visitor.<>c__DisplayClass0_0`1.b__0(T item, Int32 index)
at Unify.Framework.Visitor.Visit[T](IEnumerable`1 visitCollection, Action`2 visitor)
at Unify.Product.IdentityBroker.AdapterEntityChangeDetectorCollator.Run()
at Unify.Framework.AsynchronousJobExecutor.PerformJobCallback(Object state)",Normal

Could you please investigate and fix the update error, and also consider improving the behaviour when a connector's required field is missing in a SCIM update?

For the purposes of my demo next week I can make sure this 'bad data' doesn't occur, and so the only dependency for this is SIT/UAT meaning that it's a medium priority.

I have a SCIM gateway configured in UNIFYConnect and Azure is able to use it to Add users just fine, but when it attempts an update this error is shown:

There's nothing written into the UNIFYBroker log when this happens.

Could you please investigate and advise how to make updates work?

The strangest thing ever... For this adapter:

When I generate changes to update the DNs (used to be DN=@IdBID), I see DNs assigned with different segment orders like this:

The two digit CN is DepartmentID.  The date CN is StartDate.  The four digit CN is PositionID.  The three letter CN is LocationID.  The six digit CN is EmployeeID.

I tried clearing precalculated entities and re-running Generate Changes, but the same thing happens with the newly generated entities - the segments are always in the same (wrong) order for each entity.

This is happening in a non-Production environment, and the DN segment order for each entity appears to be persistent, so this is a very minor (but very strange) issue.

I have a customer where connector entity create fails (due to external issue on the customer side) for a number of entities during link sync, and for each one I end up with a Join showing on the Locker but no corresponding adapter entity.

For example, for a baseline sync I see:  Update entities 1690 to connector AD User reported 1690 entities saved, 3 failed

After this I look at locker joins:  Showing 1 to 10 of 1,693 entries

But adapter joins says: Showing 1 to 10 of 1,690 entries

This causes problems on the next baseline sync, because even though the locker is already joined (to a non-existant adapter entity) another attempt to create the adapter/connect is still made but then this error appears:

Unify.Product.Plus.JoinExecutorTargetEntityAlreadyJoinedException: Source entity '2ac4395a-2cb7-4f6e-9d80-e6a6a38994b7' value matched to target entity 'f70abdcf-4097-4d41-84a6-b0703308f16f', however this target entity is already connected to another source entity. 'fb9d3fea-9b4a-4708-a0e1-e730551ef030'. Cannot proceed with join.

I thought we worked through this and already had a patch for this issue, but I cannot work out which ticket it was in.

Could you please investigate and see what the situation around this is?

My customer's adapter has two entities for every every connector entity.  I am not aware of what might have caused this, other than the service outage that was resolved yesterday (unresponsive UI and no data was flowing through the system).

Could you please advise what caused there to be two adapter entities for each connector entity?

Hi, 

Monash Health  reported an issue with AD user creation. 

Following is the product installed, there have been no recent changes to the configuration.

UNIFYBroker v5.3.2 Revision #0

Plug-in Version Details
Plugin Key Version
Microsoft Active Directory 5.3.0.0
Chris21 Connector 5.3.0.0
Sync Changes 5.3.0.2
Plus Change Tracking 5.3.0.2
Connections 5.3.0.2
Links 5.3.0.2
Link Statistics 5.3.0.2
Lockers 5.3.0.2
Locker Statistics 5.3.0.2
Provisioning 5.3.0.2
Plus 5.3.0.2

Azure's SCIM implementation when creating a user who has a manager follows this approach:

1. Create the new SCIM user (without the manager reference)
2. Make sure the new user has been created
3. Update the new user's manager field

It seems the reason for this approach is because Azure wants to create all the users first, before it tries to add references to them via the manager field (which makes sense from a referential integrity perspective).

However, when using the UNIFYBroker SCIM gateway, step 2 is failing and Azure can't find the newly created user.  Azure first tries to get the new user object by ID, and then by username lookup, but neither works.  See the attached packet trace "SCIM User with manager creation.pcapng" for details.  The connector/adapter entity created has the same entity ID that was returned to Azure (9a9978e0-6179-42b5-8218-2173d7b6c0e5 in the packet trace) and the username field set correctly (adrian.corston@unifysolutions.net).

A later attempt by Azure to look up that entity by username (package trace "SCIM User lookup.pcapng") is successful (that lookup was followed by a PATCH which failed, but that is due to a different issue so please ignore that part of the trace).

SCIM User with manager creation.pcapng
SCIM User lookup.pcapng

This github ticket has information about the Azure SCIM pattern for setting manager: https://github.com/MicrosoftDocs/azure-docs/issues/11784 (comment from asmalser-msft)