This morning a PHRIS event occurred which resulted in the unwanted disabling of some 2K+ AD user accounts - see CSODBB-312.

The culprit turned out to be the nightly PHRIS practice of truncating the PERSON table at 3 AM, which had a knock-on effect of causing Identity Broker adapter DELETIONS of some 3.5K JOB records - by virtue of a SQL join on EMPLOYEE in the JOB view which is used within the PHRIS JOB web service method implementation.

This is not something we can prevent from happening in the future - but we need to mitigate the impact this could have - and it has been agreed with the Red Rock consultant (Andy Ross) that the best strategy is to institute a "black out" on all PHRIS web service calls from midnight to 5 AM (this includes a buffer of about a couple of hours either side of the activity).

Looking at the IdB 3.0.7 timing documentation I can see that this idea is supported in this version of the product, but I would appreciate confirmation of the correct use of this setting in my current connector configuration.

The JOB connector timing is presently configured as follows:

        <getAllEntities>
          <timing name="RecurringTimespanStandardTime">
            <timespan value="01:00:00" />
          </timing>
        </getAllEntities>
        <polling>
          <timing name="RecurringTimespanStandardTime">
            <timespan value="00:01:00" />
          </timing>
        </polling>

Am I correct in understanding that I should change the above to the following to achieve the desired "black out"?

        <getAllEntities>
			<timing name="DailyExclusion" start="00:00:01" end="05:00:00" UseLocal="True">
				<timing name="RecurringTimespanStandardTime">
					<timespan value="01:00:00" />
				</timing>
			</timing>
        </getAllEntities>
        <polling>
			<timing name="DailyExclusion" start="00:00:01" end="05:00:00" UseLocal="True">
				<timing name="RecurringTimespanStandardTime">
					<timespan value="00:01:00" />
				</timing>
			</timing>
        </polling>

Appreciate your help with a simple yes/no (plus fix) answer - I am about to start testing the above idea in the lab but thought it would be best to seek confirmation that this will work as I expect.

Add support for SCIM 2.0 to support outbound provisioning from AAD, PingFederate

Request

https://unifysolutions.jira.com/wiki/display/IDB50/LDAP+Configuration

In Identity Broker 5.X, if services on other servers need to contact Identity Broker you have to supply the servers IP address. I have the following questions:

a) The UI does not allow me to enter in another servers IP address, if I do this I get a message stating the IP is not valid in the current context. This is good. What happens however if the servers IP address was to be changed. Will Identity Broker pick this up and compensate when it's next restarted, will it fail to start or will something else happen?

b) Is there any reason this field can't take in the fully qualified domain name of the server? The FIM Administrators aren't likely to be network administrators, so ideally they could configure services with a higher level of granularity than an IP address (which they don't manage). 127.0.0.1 is ok for localhost as it's universal, anything else might cause issues based on the behaviour in question A.

c) As an extension of part b, could the field be removed outright? If traffic is to be restricted to localhost firewall rules could be used on the assigned port.

Task

• Update documentation to let users know that IdB can be bound to any IP.
• Make the any IP easier to configure on the UI
• Consider offering ability to select the IP (or preferably the network adapter) (keep in mind this should come from the server and not studio)

It seems if a form has its EAI disabled, simply enable EAI will not allow connector to detect changes from it.
Steps I took to make connector to be able to detect changes:
1. Restart Chris21 service. (as a result, connector is not able to detect changes)
2. Restart IdB service. (as a result, connector is not able to detect changes)
3. Do a "Import all" and then modify some data in CHRIS21. (as a result, connector is able to detect changes)

From PRODUCT-7:

In order to aid diagnosis of failing processes, I think it would be a good idea for there to be a configurable option to provide detailed diagnosis information at every interface boundary within Identity Broker.

By that, I mean every Identity Broker process that has interfaces should be able to have a decorator inserted to provide details information about the methods and data provided at each step of a process. This would prevent the kinds of Product Support issues where: "I can't really tell what's going on so I suspect something is wrong with Identity Broker".

This could be achieved by implementing the interfaces of major boundaries, and logging debug information. IDB-84 (filter on log verbosity) will have to be looked at to avoid flooding the logs.

From DEEWR-55, there were difficulties using multiple fields as relationships. These difficulties will be documented in IDB-352.

It could be of benefit to be able to generate a hash of any number of fields and have this included in the schema for the connector. Could be of benefit to allow this to be used as the key of the connector, and to be used for relationships.

Obviously the UI will have to be updated to accomodate, as would the config files and adapter/factory pairs. The schema provider may have to be updated to allow for these hashes to be suggested, depending on how the configuration is done.

The hash must always calculate the same for the same input, differently should the same values be swapped between two of the fields, and be resilient to clashes.

From PRODUCT-14, the current clear database script is out of date and there isn't currently a script for v4.0.

Please change TruncatePartitionsCommandText to a .sql file and rename and move to the database directory.

Please add to the installer such that it is included like the other script.

Thanks.

For investigation, please try and reproduce the error from IDB-116 and IDB-400.

As discussed, try to get the delete individual partition and the delete script to be called. Run a SQL trace to ensure that the correct calls are being made.

Mitchell Dowd (Coffey) has mentioned the desire to limit memory usage. The high memory occurs during FIM import and is likely a result of way transformations can greatly increase the factor of data requested from the database.

Please determine what our options are.

When there is a mismatch between the number of fields in the schema, and the number of fields with a matching info type configuration, the following exception is thrown:

Mismatch in field count between entity schema and info type definitions in connector {0}

This should also specify the complete list of fields on both sides of the comparison.