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.
My AD service account has permission to update users in AD. How can I get more information about why this is happening?
New install, Broker/Plus 22.214.171.124
Matt & Adam investigated - the issue was that the OU to which Broker was attempting to move a user object was not present in AD. I have noticed that "5012" errors like this one have been associated with AD OU issues before.
The screen shot above includes the text "MoveEntryAsync" in the middle of the stack trace, which alerted Adam to the fact that the issue was related to a DN move operation.
I'm getting this in the log files
Request to sync adapter to locker completed.
Sychronization job completed syncing 524 changes on the 'Active Directory to Person' link from the adapter to the locker. Delayed: 0 Incomplete :524 Denied: 0 Job ID <guid> Duration <time>
What does the incomplete status mean?
Looks like that link is not configured to provision. Is your locker empty? If the link doesn't provision and there is nothing to join onto, then that will also count as incomplete.
"Active Directory User to Person" Link is processing a Locker and creating an Outgoing Change even though there is no corresponding linked (or able to be linked) Adapter object and Outgoing Provisioning is disabled
I am using Broker/Plus to only join to objects from Aurion to AD, and not to provision (i.e. Outgoing Provisioning is disabled). For a user in Aurion (with corresponding Locker record) where there is no corresponding AD record (i.e. the join criteria are not met for any existing AD adapter objects) the Link still reports an Outgoing Change for that object.
I have 7 Lockers:
I have four users in AD:
When I run a Baseline Synchronization on the AD Link, I see this:
Note that there are 7 Outgoing Changes, even though there are only 4 objects in the AD Adapter, and Provisioning is disabled so it should not be provisioning new ones.
Log file attached:
This is the intended behaviour. As the information message states
... Ensure that either the field/s used in the join rules are correctly mapped or, if this link is not responsible for provisioning, the joining entities already exist. ...
Meaning that of the 7 entities being synchronized, 4 were OK since the mapped adapter entities existed. The remaining 3 have no mapped adapter entities, and cannot provision them since that is disabled, so are considered incomplete and not processed.
As long as the intended behaviour is for those three entities to not be synchronized, then you can ignore that information message.
In Broker/Plus, outgoing provisioning tasks are run even when the outgoing provisioning flag is disabled.
That task can be used for out of band provisioning operations. Since the configuration flag only turns off object provisioning via the target adapter (and not any out-of-band provisioning activities that the task performs) the flag isn't as useful as it could be and the flag operates in a manner that may be contrary to user expectations.
Broker/AD fails to create new user objects with error "UnwillingToPerform ... Message: 0000052D: SvcErr: DSID-031A1254, problem 5003 (WILL_NOT_PERFORM)"
I will attach the Extensibility files. This used to work, but some configuration change has caused it to stop working now. Reverting is not an option as there have been many changes and this project is under time constraints to deliver ASAP.
In my Broker/Plus environment (based on UNIFYAssure for Aurion) I am trying to synchronise the manager attribute to AD but seeing the following error:
My configuration has an Aurion connector/adapter -> Link -> Locker -> Link -> AD connector/adapter in a standard setup.
The Manager attribute in the Aurion adapter is calculated via a DN join:
Here's an example, looks correct.
I synchronise the Manager attribute from the Aurion Adapter to the Locker:
It looks correct in the Locker:
Then from the Locker to the AD Adapter:
Here's the AD Adapter configuration:
When I attempt a Baseline Synchronisation on the AD Link this is what I see, and the error above appears in the log file:
Can you please tell me what I need to do to get the synchronisation of the manager attribute to work correctly from the Locker to the AD Adapter?
When a provisioning task fails in a Broker Plus Link due to a PowerShell error, the information written doesn't indicate which provisioning task failed, which line the error occurred on, or which entity was being processed.
It would be extremely helpful for debugging to know which provisioning task is the source of the error and which line is executing when the error occurs.
It would also be helpful to know which entity is being processed, but given that the PowerShell script loops over objects internally this information is not automatically available to the calling engine. In order to help with this I suggest adding a function which allows the PowerShell script to (optionally) indicate when it starts and finishes processing an entity, in order to allow Broker to include that information in the log entry.
foreach ($joinedEntity in $joinedEntities)
# Tell Broker which entity we're working on $personNumber = $SourceEntity["PersonNumber"].Value
$username = $SourceEntity["sAMUsername"].Value
$logger.setIdentifier("Person $personNumber ($username)")
# Process the entity $isTerminated = $joinedEntity.SourceEntity["Terminated"].Value
$joinedEntity.TargetEntity["isTerminated"] = $isTerminated -eq "True"
# Tell Broker we're finished processing the entity
How do I set sAMAccountName from Broker/Plus when provisioning, but then flow it back in from AD thereafter?
I need to set a user's account name when provisioning via Broker/Plus, but then flow that value back in from AD subsequently (so the value is picked up when joining to an existing AD account, and so that if the username can be changed in AD it will be automatically updated in Broker).
Can you please confirm whether or not the approach below will work, and advise if there is a better way to do it?
1. Set the Link mapping on the AD->Locker to Bidirectional for the AD username field
2. Set a value for the attribute in the Outgoing Pre-Provisioning Task
Your approach is correct, however you won't need to set username field as bidirectional on the AD->Locker link. Values set by pre-provisioning task aren't affected by the mapping rules, so Adapter to Locker is fine.
On CheckFieldUniqueness, yes that function is available in outgoing pre-provisioning tasks.
I am a new Broker/Plus user and want to see where a Locker is getting its field values from, so I clicked on the Entity Id and then on Origin Info. This is the screen I see:
This doesn't tell me which Adapter contributed the current value for the sAMUsername field. I tried searching the Extensibility files for the Entity Id and Partition Id, but neither told me which Adapter the field value came from.
Could you please add the name of the Adapter that contributed the field value somewhere on this popup?
Also, it's not clear what the Type information here means. What does it mean that my 'sAMUsername' field is of type 'PlugIn'?
As part of an upgrade activity on an MA, we were required to deliver a difference report on the data as it would appear pre vs post synchronisation of the upgrade MA. This was done to better understand and review what attributes would be updated when a full sync of the upgraded MA would occur in PROD.
We were able to achieve this deliverable by exporting two csv's of the data pre & post synchronisation, and doing a data comparison in a third party app. This could be simplified if Identity Broker Plus could generate a difference report for full syncs to ensure that the MA update is producing clean data.
This report could vary in detail, but as a first pass being able to see a count of the new and updated identities and attributes would be preferable.
Customer support service by UserEcho