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.

0
Fixed

DN Fields Missing from LHS of DN Template

Curtis Lusmore 9 years ago updated by anonymous 8 years ago 4

DN fields are missing from the left-hand-side of the DN template configuration. There is also a small bug where the field temporarily shifts up to the end of the previous line while entering a value. See attached screenshots.


i29^cimgpsh_orig.png
i30^cimgpsh_orig.png
LoseDefaultValue.jpg
0
Completed

Allow for multiple query ids on the UI

Tony Sheehy 11 years ago in UNIFYBroker/Aurion updated by anonymous 8 years ago 1

Update the UI to allow for multiple query ids.

0
Fixed

DN Template Generator can spawn element with empty separator

Beau Harrison (Senior Product Software Engineer) 9 years ago updated by anonymous 8 years ago 1

In the DN template generator, clicking 'Add' with the right field empty spawns the separator selection empty, and if committed, causes the separator to be 'null', which breaks everything.

The separator field should always have a default value.

0
Completed

No Warning for multiple adapters with same object class

Curtis Lusmore 9 years ago updated by anonymous 8 years ago 2

There is currently no warning in the management studio if two or more adapters share the same object class, which breaks LDAP compliance by having multiple definitions in the schema for that object class.

0
Fixed

Connector update fails following a rename

Adam van Vliet 9 years ago updated by anonymous 8 years ago 1

If a connector satisfies the following:

  • Implements modify anchor;
  • Implements update;
  • Uses the connector key to look up the repository entity on update;

The update will fail as the new key won't match the repository entity.

See if the matching entities can be modified so that they have the updated key. This was an issue for v4.1, but may not be an issue with v5.0 as the connector doesn't need to look up the entities.

0
Completed

PowerShell connector use original entities on update

Adam van Vliet 9 years ago in PowerShell connector updated by anonymous 8 years ago 8

For the PowerShell connector, the collection of original entities should be available to the script.

0
Fixed

Copy connector function results in polling and getAllEntities timers not to fire

Bob Bradley 9 years ago updated by anonymous 8 years ago 9

This issue is really 2 issues in one:

  • the Copy Connector function causes duplicate Timing id GUIDs to be generated, and
  • the presence of duplicate Timing id GUIDs cause the corresponding timing node not to fire the connector when the cycle comes around.

So Richard Green - I have just discovered the cause of FIM issue 133 (and most likely 134 as well) - namely multiple connectors with the same polling id GUID, causing the timer not to fire. How they got there I believe was via the COPY CONNECTOR menu option, and I have just proven this (see comments following this issue description).

In the attached configuration, the GUID 43b343ba-a287-401f-b92a-347d572b80f0 appears on 2 connectors' polling Timing nodes, and the GUID 15c3fa6b-cf9e-4fb5-8724-5eae2027da49 appears on several getAllEntities Timing nodes.

The impact of the GUIDs being the same appears to be that the timings count down and then roll over and nothing happens (nothing executed - no log of execution). This would explain why a number of the connectors hadn't reported any changes between the time they were installed to TEST last Friday, and the time the bug report was raised (Wednesday).

I am wondering how many other IdB 4.* implementations out there have this sleeper? As a result I have assigned a CRITICAL status (due to the potential impact), even though I now know the cause of the problem and have implemented a solution.

Edit: FIM Event Broker has been confirmed to generate new id's, and as such is not going to have this issue.

0
Answered

Clarification of Identity Broker for chris21 behaviours

Shane Lim 13 years ago in UNIFYBroker/Frontier ichris/chris21 updated by anonymous 8 years ago 2

The customers have to the following questions which I am not enough understanding of Identity Broker for chris21 and chris21 system to simlulate a termination of a user. I will attempt to provide my answer below. Please assist in clarifying or answering these questions if possible.

AHG
I've found that the Connector Delta Import process doesn't seem to pick up termination changes. When I do a Full Import the change comes through.

The steps I have followed are:

1. Terminate user in Chris21
2. Perform 'Synchronise Import' on the connectors
3. Run the Chris21 MA Delta Import process

The Synch stats show that there are no changes that have been picked up.
If I perform a Full Import using the Chris21 MA I still have no changes.

Shane Lim - I understanding is the "Synchronise Import" on the Termination Connector to bring in the delta change into the Termination connector table. This delta change would then be processed/transformed into the Adapter table. When the user perform the "Delta Import" in FIM chris21 MA the delta change in the Adapter table would flow in FIM chris21 MA.
Having said this I have not done this scenario before since I have no knowledge how to terminate a user in chris21.

AHG
If I complete a full import on all the connectors, then a delta import using the Chris21 MA I have the update I expect. Is this the correct behaviour? I had expected that performing a Synch Import would pick up such a change, or am I mistaken?

Shane Lim I expect the "Synchronise Import" in Unify Management Studion followed by the "Delta Import" in FIM chris21 MA to pick up the delta change.

AHG
The other question is, out of curiosity, when I terminate someone, should I be able to just import from the Termination connector seeing as the only change that was made to Chris21 is the addition of a termination record? Currently this doesn't work, I get the same GTR error we were getting last week. I have to first import from Person, then the Termination connector.

Shane Lim I expect that each Identity Connector be able to perform the "Synchronise Import" independently.
PS: Cabrini Health fundamentally using the same Identity Broker for chris21 Connector and Adapter configuration files and they have not report experiencing the same behaviour here.

AHG
Something else I have noticed is that for the Metaverse to be updated by the change made to AD to disable the account for the terminated employee, I have to perform a Full Import using the ADDS MA and then a Delta Sync. Again, I had expected that a delta import should do the job, but, I may be mistaken?

Could you please clarify this for me as perhaps i'm misunderstanding when we need to perform a Full Import versus a Delta Import. I thought we really only needed to perform a Full Import when we are populating the Metaverse and the Connected Spaces for the first time. After that I thought Delta's should give us any changes made but that doesn't seem to be the case. I am running through multiple cycles as you recommended so I can ensure the data change flows through all the different steps properly.

Shane Lim
My understanding and expectation is that a "Full Import" in the Unify Management Studio and in the "Full Import" in the FIM chris21 MA is not necessary after the initial "Full Import" is completed. But then we do have the schedule in the Identity Broker for chris21 Connector configuration for performing getAllEntities.
Thus now I am no certain what the expected behaviour.

Please assist.

0
Fixed

entryUUID Missing from Delta Imports

Richard Courtenay 9 years ago updated by anonymous 8 years ago 11

This issue is a follow on to the now resolved https://unifysolutions.jira.com/browse/IDB-1216

What I'm finding is that if I provision an entry to UNIFY Identity Broker, and then perform a delta import, the entryUUID is not in the list of values returned. This then results in FIM throwing an exported-change-not-reimported error. If however a full import is performed, the entryUUID is present.

Generally this likely won't matter if the entryUUID isn't explicitly being used, but it is an issue if the adapter DN is UID=@idBID and you thus need to set the UUID (as the previously linked to issues final post implies)

I've captured some screen shots of the error and behaviour of delta and full imports

Performing a full sync preview which triggers provisioning that sets some defaults, as well as applies some flows

Export to occur, including the entryUUID (set so that I could also control the DN, pictured)

Errors resulting from a delta import performed after the export (there was a 1 minute gap between the export and running this import)

Missing attribute

What the delta Import brought in

Finally running a full import, which has the entryUUID present

I'd expect that deltas should bring in the entryUUID following a provision. To reproduce it I don't think you necessarily need to be using the entryUUID as part of the DN for the adapter, just select on the MA that as an attribute to be read into FIM and then provision a new record and follow it up with a delta import.


ACTH-197 uuid fix.zip
ss1.png
ss2.png
ss3.png
ss4.png
ss5.png
ss6.png
ss7.png
0
Completed

Add local flag to time offset flag

Adam van Vliet 9 years ago updated by anonymous 8 years ago 2

The time offset flag transformation deals with times, but does not have a local setting. To allow for local calculations without having to use the offset, add the local setting.