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.
Log directory
Getting myself confused by the logging in IdB5. With no log writer configured, my logs end up under c:\program files\Unify solutions\identity broker\services\logs and I cannot see anywhere to set a different directory. If I configure the standard csv logger I can specify a directory, but all this gives me is the same files being created in two places. is there a way to point the default log directory to somewhere other than under program files?
Hi Eddie,
There is currently no way to configure the logging directory of the UNIFY Core Log Writer. I've made an item on the Team Services backlog to look at having this configurable. As a workaround, you could possibly replace the Logs directory with a symbolic link to your desired directory.
IdB and High Availability
Since IdB is now presenting data to FIM via LDAP, is there any technical reason why two IdB server could not be load balanced behind an F5 or similar? Customer currently has FIM and IdB4 on a server and a second (warm standby) with the same. If idB5 were on separate servers (one active and the other warm standby) and if the FIM MA were pointing to a name that resolved to a VIP, then I assume that as long as the VIP could work out which IdB server had the service running that would work. Do we know if anyone has done/tried this, or do we generally recommend keeping FIM and IdB co-located on the same server?
Ah - we have a semantic issue - my definition of a cold standby is when the spare server is not running. My definition of a warm standby is where the server is running but the FIM and IdB services are stopped. Full on both running, which as you say would require separate databases and could cause all sorts of pain I would call hot standby.
At one of our customers they wrapped the service in small program that checked the other server and has some smarts built in to stop the service running on both. For my current engagement I think I will recommend their current design with FIM and IdB co-located and the services disabled on the standby server. Thanks
Aurion credentials vs security user
Following the online doco https://unifysolutions.jira.com/wiki/display/IDBAUR50/Aurion+Agent for Aurion and it is a little light when it comes to the Aurion Agent and user credentials.
We have required fields Security User and password, where security user is described as The name of the Security User account used to connect to the Aurion system.
Then we have credentials:
The type of credentials used to connect to the target system.
any idea what that means? If I select custom I get the option for Account name and password - the other options are none, default, defaultcredentials and defaultnetworkcredentials, but nothing in the doc that I can see that tells me what any of those mean.
Is there a doc somewhere that tells us more about Aurion?
Hi Eddie,
These settings are for the SOAP endpoint credentials and can most likely be ignored (left as None). I've made a note to improve the documentation.
IDB5 service will not start
On a test server that was riunning IdB4, I uninstalled IdB 4 and have run through the install of IdB5. Selected a new database (unify.identitybroker5) and the install reported that it had completed successfully.
Tried to start service, started then stopped. Checked event viewer - error that the service had no rights to read its extensibility config files. I have added the idb service account as full control of that directory, but the error persists.
If I look at the effective rights at the individual file level, the svc account has no rights because of file permissions. Has anyone seen that before? I tried removing (renaming) the extensibility directory and re-ran the installer and selected repair - but it ends prematurely and rolls back, without displaying anything useful on the screen. Do I have to go and explicitly grant my svc account rights to each file?
It looks like the previous version was installed under a differennt account (not a service account). I copied all the files, deleted the originals and renamed the -copy versions back to the original names and it all worked fine
IsOperative not updated on date change
IDB 5.0, Aurion Connector 5.0.
I have an Adapter that links to the primary "Aurion Person" connector, and joins to data from an "Aurion Employee" connector, and a CSV connector bringing in custom Org Unit names.
I have used a number of IsOperative transformations to set "Passed" and "NotPassed" flag values relating to various dates: DateCommenced, ContractExpiryDate, DateTerminated.
For a test user - on initially importing their details the DateCommencedStatus was correctly "NotPassed". However 5 days after the date it was still "NotPassed" - it had not toggled to "Passed". When I ran a Generate Changes manually in the Adapter it then went to Passed.
The Aurion Connectors are only running Full Imports and run multiple times a day. I assume the IsOperative transformation did not get re-evaluated because the source data did not change - the only thing that has changed is @NOW.
I need a workaround for this - is there a way I can force Generate Changes to run on a schedule or through the IdB web services?
How do I delete an entity in a Powershell connector?
The issue is on a Delta import - we can detect that an object has been deleted from the connector system (LDAP) but I can't delete the entity in IdB. (I think a Full Import will but I wanted this to work on the Delta).
The example on this page https://unifysolutions.jira.com/wiki/display/IDB50/PowerShell+Connector under "Delete Entities" is either missing something, or it's about exports.
Hi Carol,
Let me start by clarifying a few more points about the PowerShell connector. The Import All, Import Changes (for the "Entity" Import Changes Method), Request Changes and Get Entities (for the "Entity Id" Import Changes Method) are all import scripts. Import scripts are run when the Identity Broker connector's Import All or Import Changes operations are triggered.
The Add Entities, Updates Entities, Delete Entities, Delete All Entities and Change Password scripts are all export scripts. Export scripts are run when an IDM (e.g. FIM) sends adds/deletes/updates (e.g. during a FIM Export run step) to the relevant Identity Broker adapter via the LDAP endpoint. To avoid confusion with FIM's Full Import and Delta Import operations, please refer to IDB operations as Import All and Import Changes, as they are not part of the same process.
I'll give an example of deleting entities during a PowerShell connector Import Changes operation. The connector schema has two fields, ID (the key) and Name, and assume there are 5 entities in the connector context with IDs 1 through 5.
This is the Request Changes script:
function Get-UpdatedKeys
{
return 1, 2, 3, 4, 5, 6;
}
foreach ($key in Get-UpdatedKeys)
{
$changedKey = $keys.Create();
$changedKey['ID'] = $key;
$changedKey.Commit();
}
This indicates that all 5 entities have been changed, and a previously unknown entity (with ID 6) has also been changed.
This is the Get Entities script:
function Get-EntityByKey
{
param ($key)
if ($key -eq 3) { return $null; } # let's say entity with ID 3 is deleted
return @{Key = $key; Value = "Value$key"};
}
foreach ($key in $components.InputKeys)
{
$changedEntity = Get-EntityByKey $key['ID'];
if ($changedEntity -eq $null)
{
# don't commit, deleted
continue;
}
$entity = $entities.Create();
$entity['ID'] = $changedEntity['Key'];
$entity['Name'] = $changedEntity['Value'];
$entity.Commit();
}
This iterates over the changed keys returned by the Request Changes script and retrieves the corresponding entities. If the entity is not flagged as deleted (Get-EntityByKey returns $null), then the entity is commited, otherwise it's ignored and the entity will be deleted from the connector space automatically by IDB. In this case, the entity with ID 3 would be deleted, the entity with ID 6 would be added, and the other entities would be updated.
Placeholder Connector Migration container
When a placeholder connector is created, an import is done to import the container object into FIM such that it can subsequently provision objects back out to the placeholder connector.
When doing an Identity Broker migration between environments by way of config migration, there was a bug where FIM would report that - when trying to run the import to get the container object; there was in fact no objects to import.
Did a bit of digging, ended up changing the Container Name in the placeholder connector in IDB to something different, saving connector, and then changing it back - and then running the import into FIM. Upon doing this, the container successfully imported.
It seems like it stores something in the database as an entity for the container (logically) and when you migrate, this does not get copied across (logically). However a rename triggers this entity to be created and thus picked up by FIM when the import is run.
Thanks for raising this Matthew. Luckily it's known and a fix has already been prepared and is just waiting for the v5.1 release.
Thanks.
Allow timezone configuration for watermark in the WD Connector for IDB
Workday have confirmed that they cannot change their timezone in Workday to match the UTC timezone we use in our Import Changes requests. Given our client is located across 12 different timezones, this means that we miss a lot of the (utc-x) requests. Would it be possible to add a timezone offset to the Connector so that we can change this to match the Workday set timezones? This will allow for a consistent set of changes to be detected
Aurion export failed "EMPLOYEE_NO expected"
I am trying to export Fax_Number to an Aurion Person connector.
There are two connectors for Person and Employee. The Person connector is the primary one that links through to the Adapter; the Employee connector is joined via the Adapter.
The schema of the Person connector (as I've implemented it) is as follows:
- PersonNumber (Person_Number)
- ContactPhoneNo (Contact_Phone_Number)
- FaxNo (Fax_Number)
- GivenNames (Given_Names)
- PreferredName (Preferred_Name)
- Surname (Surname)
I did not include EmployeeNumber as I didn't think it was relevant to Person so that's probably my mistake - I can see it's listed in the Default Schema Provider. So firstly - do I ask the customer to add that to the Aurion query?
And next - do I map it to "EMPLOYEE_NO"?
As a doco suggestion it would help if the schema was listed in the doco along with which fields are required.
Sorted out by adding Employee_Number to the Person connector's Aurion query. Initially I was not getting the data because I used the name Employee_No (as specified by that error message) but actually the query uses Employee_Number. Thanks to Ryan for suggesting I run the report directly in Aurion and inspect the resulting XML file.
Now that Employee_Number is populated in the Person connector my test export to Fax_Number has succeeded.
Cannot change Queue On Blocked through UI
I could not find a way to change the Queue on Blocked setting of the Aurion v5 connectors through the UI and had to do it in the XML.
Thanks Carol, this has already been fixed and is just awaiting release.
Customer support service by UserEcho
