When running an import on AD Groups, the objectSid field is defined as a string on the connector schema. SQL can import this field fine (although shows as jargon on the UI). Postgres fails to import with the following error:

Connector Processing page 1 for connector On-Prem Groups failed with reason 22P05: unsupported Unicode escape sequence. Duration: 00:00:08.3359933.
Error details:
Npgsql.PostgresException (0x80004005): 22P05: unsupported Unicode escape sequence
at Npgsql.NpgsqlConnector.<>c__DisplayClass161_0.<<readmessage>g__ReadMessageLong|0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at Npgsql.NpgsqlConnector.<>c__DisplayClass161_0.<<readmessage>g__ReadMessageLong|0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at Npgsql.NpgsqlDataReader.<nextresult>d__46.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.NpgsqlDataReader.NextResult()
at Npgsql.NpgsqlCommand.<executedbdatareader>d__100.MoveNext()</executedbdatareader></nextresult></readmessage></readmessage>

Changing the field type to 'binary' and attempting an import yields a different error at an earlier stage:

nify.Product.IdentityBroker.EntitySchemaValidationException: Invalid binary - the value was a string, but was not able to be converted as a base64 encoded string from: ??? ? ---> System.FormatException: The input is not a valid Base-64 string as it contains a non-base 64 character, more than two padding characters, or an illegal character among the padding characters.
at System.Convert.FromBase64_Decode(Char* startInputPtr, Int32 inputLength, Byte* startDestPtr, Int32 destLength)
at System.Convert.FromBase64CharPtr(Char* inputPtr, Int32 inputLength)
at System.Convert.FromBase64String(String s)
at Unify.Product.IdentityBroker.EntityBinaryTypeSchemaValidator.CreateValue(Object dataValue)

Hi,

Recently we had an issue come up where the server ran out of disk space while writing the XML config files.

Would we be able to request a feature where the existing file is renamed to a .bak file before writing a new XML file.

If the server runs out of disk space, the file will fail to rename, preventing the mentioned issue.

Thanks

Similar to the checklist developed on the back of the ultimately successful WA Water Lite implementation, this Aurion Pre-installation Checklist contains the necessary steps for a successful implementation UNIFYBroker+ as well as both UNIFYAssure and UNIFYConnect IdAAS flavours.

An updated checklist will now be required for each of the in-flight UNIFYConnect implementations, as well as future Broker+ installations (where the server specs are still required), and apart from the following recommendation needs to be specified by Engineering:

• Correlation IDs are available in all production and non-production Active Directory environments

With the increased focus lately on deployments of the UNIFYAssure/UNIFYConnect/UNIFYBroker+ solution set, recent experience has been that at times it would have been handy to still use UNIFYNow to enhance the operations user experience - even without MIM in the picture, the familiar Operation List concept could apply equally to a Broker+ deployment as it can for MIM sync.

While we may consider pursuing this idea, a better outcome would be to incorporate UNIFYNow features in the UNIFYBroker+ product configuration itself (i.e. not only adding the Locker menu, but also an Operations menu ... sharing the existing Agents/Groups/Logs menus I imagine, and using the Groups concept to simplify the UX.

In scenario where pre/post processing is required (e.g. mailbox provisioning, notifications, workflow-like activities, etc.) such a configuration would undoubtedly be more maintainable and operationally easier to handle than it is without the UNIFYNow model we enjoy today for MIM solutions with similar out-of-band integration.

I deleted a Connector Group in UNIYFBroker (using the Web UI) and now the API returns an invalid ID in the ConnectorGroups array in the response to Connector/GetConnector for a Connector which used to be a member of that group.

Using the latest UNIFYBroker release.

At the UNIFYBroker site I am presently working on there are now 7 Broker-driven management agents for MIM, most of which interact with multiple adapters.  I have found that it starts to get unwieldy when it a single schema change in a single connector requires a schema/interface refresh of all 7 management agents.  Furthermore, when deploying MIM sync configuration and using the schema matching dialog, there is a need to deselect all of the adapters (LDAP partitions) which are not relevant to each particular MA, complicating the deployment process.

It would be great if there was a way to limit visibility of the UNIFYBroker adapter set on a per-management agent basis - and the most obvious way I could think of achieving this would be by using multiple LDAP user accounts, and extending the Settings page to support mutli-selection of adapters per LDAP user.  In this way, adapters visible to any given MIM MA would be determined by the use of an appropriate user account - rather than the current practice of using the same LDAP user for every MA.

This would address both of my above scenarios as follows:

1. A single connector schema change would potentially limit the need for schema refreshes to a single MA; and
2. Partitions not visible to the LDAP account would no longer appear on the partition matching dialog, and in most cases this would reduce the number of partitions requiring deselection (and in many cases eliminate the partition matching dialog being displayed altogether) when importing MIM sync server config XML.

Hi guys,

I have multiple Chris21 connectors failing in a customer system with the following error when running a full import:

My initial thoughts were that this was a problem with Chris21. But I have had the customer run the GTR query directly against Chris21 and it has received no such status failed messages.

The customer had recently upgraded to Chris21 version 8.19.10. Identity Broker version is 4.1.1 and Chris21 Connector version 4.1.1.0. Version upgrades were undertaken on the 12/05 and completed on the 14/05, however the issue was only recently raised so we weren't able to grab logs before these date's to see if it was an active issue.

The customer has pointed out that one field has been renamed on one of the forms but this field is not used in the schema in Idb.

Before this the agent and connector was displaying this error which we fixed by setting the interface in Chris21 to "Default":

Not sure if it is related but I thought it would be helpful as to understanding the full scope of the problem.

Would anyone be able to shed any light as to why this could be happening?

Thanks, Liam

Hi All,

I am currently assisting a client with an issue in UNIFYBroker, whereby a Google Group connector, is reporting a duplicate account error for some users when trying to added them to google groups. We can inspect the groups manually in google and these groups definitely do not contain these users. Being unable to find a root cause for the issue in Broker/MIM, the client raised a ticket with Google and received the following response:

Thank you for contacting Google Cloud Support. I understand that you are not being able to add an address to one of your Groups as you are getting a message that the address has already been to the Group.

I reviewed the information you provided on the chat and did the checks we do in this cases. The reason you are not able to add the external address is because the address you are trying to add is either an alias, a contact or a recovery address for a Google account. The system has the Google account already associated to the Group and since the system already knows the main account is already added it does not let you add it again. In this case you will need to contact the external user and ask for an alternate address they may have and check if that address is already on the Group. The other address is already receiving the messages sent to the Group.

Not being able to find a solutions around this within Broker and MIM I was hoping you may be able to take a look and see if you can spot anything we may be missing here.

This issue has quite a big of attention within the client environment as key people are missing out on important Covid-19 information. The current work around is listed in Google's response, however this often takes weeks to remediate.

Let me know if you need any further information.

Thanks

Currently have a client getting errors on all exports to a Broker (5.3.1) adapter (ma-extension-error).

Happening on adds,updates,deletes

Not much in the way of messaging provided except for the following after each attempt at export:

The extensible extension returned an unsupported error.

The stack trace is:

"System.Collections.Generic.KeyNotFoundException: The given key was not present in the dictionary.

at System.ThrowHelper.ThrowKeyNotFoundException()

at System.Collections.Generic.Dictionary`2.get_Item(TKey key)

at Unify.Product.IdentityBroker.ExportProxy.EntryToModifyDNRequest(CSEntryChange entry)

at System.Linq.Enumerable.WhereSelectListIterator`2.MoveNext()

at Unify.Product.IdentityBroker.ExtensionMethods.Take[TSource](IEnumerator`1 source, Int32 count, IList`1& items)

at Unify.Product.IdentityBroker.ExtensionMethods.d__3`1.MoveNext()

at System.Linq.Enumerable.d__5`2.MoveNext()

at System.Collections.Generic.List`1..ctor(IEnumerable`1 collection)

at System.Linq.Enumerable.ToList[TSource](IEnumerable`1 source)

at Unify.Product.IdentityBroker.BulkUpdateRequest.Send(Func`2 send, Func`2 recv)

at Unify.Product.IdentityBroker.LdapConnection.SendRequest(ILdapRequest request)

at Unify.Product.IdentityBroker.ExportProxy.GetBulkRequestResult(BulkUpdateRequest request)

at Unify.Product.IdentityBroker.ExportProxy.BulkExportEntries(IList`1 csentries)

at Unify.Product.IdentityBroker.ExportProxy.Export(IList`1 csentries)

at Unify.Product.IdentityBroker.UnifyLdapConnector.PutExportEntries(IList`1 csentries)

Forefront Identity Manager 4.5.412.0"

I have an adapter with the following transform:

This transform works as expected in both directions, but when an update comes from the LDAP gateway to delete the DN value that LDAP request is successful, but the old values for the DN (SubsectionDN) and the source attribute (Subsection) are retained.