In this morning's MS Identity Advisors session MS provided a clear indication that they are planning to move towards a call-out model for on-demand Access Request integration with external systems.  To get ahead of the curve on this, we could look at offering an extensible REST API endpoint in UNIFYBroker.

Typical usage would be:

Azure sends UNIFYBroker a request for user "bobsmith" asking UNIFYBroker for a certain attribute for that user (e.g. department number) or asking UNIFYBroker to provide an answer to a question (such as "is this user allowed to get access to resource X at the moment?")  UNIFYBroker responds and Azure uses that information to approve or deny an in-flight Access Request.

My suggested solution is that the request for user "bobsmith" (and/or "resource X") would map to a adapter record lookup, and the "answer" UNIFYBroker gives back would be the value of one or more fields for that matching record.

Hi Team,

In IDB 4, the Join Transformation has this configuration (see attached screenshot) 

Whereas, in IDB 5 looks like this (see attached screenshot) 

How come in IDB 4 its a - sign between [posstart] and time offset, whereas in IDB 5 its a + sign? What are the difference? Thank you

Regards,
Marc Laroza

Hello Unify people. A long time ago I posted this:

https://voice.unifysolutions.net/communities/6/topics/2467-aurion-export-failed-employee_no-expected

I have now found out it is not (or no longer) a requirement of the Aurion API method EMP_UPDATE_PERS to have the employee number, and it can work with the WAMIKey, as in the following:

API_FUNCTION=EMP_UPDATE_PERS|WAMI_NO=16798|CONTACT_PHONE=02 9898 9898|WORK_MOBILE=0404 040 404

If the customer asks for an update to the Aurion connector to use the WAMI if Employee_Number is not available, can you do that?

We have recently been having issue whereby the UNIFYBroker service account appdata directory (C:\Users\<IdB Service Account>\AppData\Roaming\Microsoft\Crypto\RSA\<user object SID>) seems to fill up rapidly with RSA files. At its currently rate it appears to be filling up with the addition of thousands of files a day. I have done some testing between UNIFYBroker and Process Monitor and have been able to narrow down a particular operation in UNIFYBroker that seems to be generating all the files in this directory and not clearing them after creating them.

The main operation from what I can tell seems to be the export operation on the google groups connector. I have tested imports on these same connector and this doesn't seem to be generating the files from what I can tell. Please see the images below showing the timings for these jobs lining up at exactly the same time.

Environment Details:

UNIFYBroker: v5.3.1

Google Connector: v5.3.2

Let me know if you need any further information.

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.