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.

How to filter sub-OUs in AD connector
An AD connector will search objects in an OU in sub-tree mode. This means it looks through all sub-OUs.
What to do if only objects in few selected sub-OUs need to be imported? i.e.
Based Container: OU=User, DC=company, DC=com
only objects in 2 sub-OU needed to be import:
OU=Staff,OU=User, DC=company, DC=com
OU=Disabled_Staff,OU=User, DC=company, DC=com

Allow for IdB 5.2.1 Plus to be deployed without a Database Connection to support Container based deployments
Most Container based orchestration solutions, including Kubernetes and Docker Compose with Swarm, provide almost no ability to modify the contents of the files in Volumes mounted within Server nodes they deploy.
To simplify deployments, without needing to resort to tools like Puppet, Chef or Ansible to carry out post provisioning tasks such as modifying Connection Strings in XML files, it would be useful to allow IdB to have the Connection String configurable via it's Management API.

Supported with containerization attached volumes.

Feature request: credential passthrough for authentication to Broker's LDAP interface from within powershell connector
It would be helpful if a valid username/password (or other authentication credential object) was made available to the powershell connector, for the purpose of submitting LDAP queries back into Broker for complex data manipulation operations.
The solution outlined here currently has to store and pass the broker LDAP query credentials manually.

Hi Adrian,
This is not possible, as the passwords are encrypted in a format that cannot be reversed.

Feature request: Identity Broker 5.2 object filtering facility
I needed to filter a subset of objects from one connector or adapter (i.e. All Organisation Unit objects) to create separate connectors or adapters for just those objects (i.e. All Business Units).
There does not seem to be any way to filter using Broker's built-in functionality, so the solution I chose was to write a powershell script to perform an LDAP query against Broker and populate a new connector based on the selected subset of objects.
Please consider adding this functionality (or something equivalent) to the base Identity Broker product.

Identity Broker 5.2 LDAP interface timeout when another connector is running
In my solution, when one of my connectors is running I see timeouts when performing LDAP queries against Identity Broker containers.

My solution is a simple powershell script invoked from a Broker powershell connector, so it won't retry and the Import will fail (and presumably log an error in Broker).
You could consider adding retry logic to the PowerShell script. See this blog post as an example.
However when MIM connects to Identity Broker, it uses the same LDAP interface, so that would causes the MIM import to fail as well and report a connection error.
That seems like a significant issue to me - having Identity Broker unavailable for any queries while a connector is running is a poor situation. Can I confirm that you're effectively saying that practically speaking, Identity Broker is single-threaded?! What is the situation if the connector takes a long time to complete - is it unavailable for requests for the majority of that time?
The connector operations are performed in pages, and the lock should only be held for a single page, giving other operations a chance to run between pages. LDAP queries are similarly performed in pages, meaning the sequence of pages might end up being interleaved. Other factors such as the health of the database and hardware specifications of the server can also impact the duration that database locks are held. Please see Identity Broker Database Recommendations.
I agree that failed imports are not ideal, but solutions need to be resilient to failing operations for a number of other reasons as well. That said, we have work in the pipeline to improve database performance and context isolation to improve this situation.

Health Check Uptime for IDaaS only shows past 24 hours
This is probably fine for the customer facing thing - but I think we need to have something for our own purposes that gives a little more information than this.

Graphs for IDaaS will be reviewed and redesigned with the pending migration to the new UNIFYMonitor.

Provisions in Last Month graph should be bar chart instead of line chart
This graph is confusing - if it's the "last month" - where's the last month? I also think it would be better as a bar graph.

Graphs for IDaaS will be reviewed and redesigned with the pending migration to the new UNIFYMonitor.

Link Connector Errors is poorly designed
This graph is misleading - this is total connector messages. We need to rethink what this section of the graph is trying to say.

Graphs for IDaaS will be reviewed and redesigned with the pending migration to the new UNIFYMonitor.

Schedule "Generate Changes" for an Adapter in Identity Broker
Hi,
I'm looking for scheduling "Generate Changes" for an Adapter that is using PowerShell transformation.
I had a look at using Scheduled Jobs PowerShell activity, the documentation online don't really show examples or if it is possible.
Please can you direct me with some examples?

Hi Alan,
As you suggested, this should be possible with a Scheduled Job similar to the following
$adapterId = [Guid]'00000000-0000-0000-0000-000000000000'
$components.AdapterEngine.SimulateChanges($adapterId)
I'm curious what your specific use case is, because I think ultimately there's a better solution to this problem. Do you know at the time that the transformation runs when future changes will be required for each entity?

Configuring Identity Broker Plus v5.2.1 via API's only
Looking for guidance on how to configure IdB Plus via API's only. Thanks in advance.

Hi Adam,
See APIs. If you visit the Swagger endpoint you can see documentation on the API operations available to you. For the default API endpoint, this should be http://localhost:59991/IdentityBroker/swagger
Customer support service by UserEcho