Hendrik1 Absent Member.
Absent Member.
450 views

IDM 4.7 in mixed environment

Hi Guys

Just wanted to discuss a specific design scenario and whether its feasible or not.

Can IDM 4.7 run in the same eDirectory tree as older versions of IDM i.e. 4.5.3

The plan is to create a separate DriverSet on a separate IDM server running eDirectory 9.1 but within the same eDirectory tree as the IDM 4.5.3 infrastructure.

Thanks
Labels (1)
0 Likes
3 Replies
Knowledge Partner
Knowledge Partner

Re: IDM 4.7 in mixed environment

As long as you only talk about the synchronization engine it should work.
There are a few tokens that only works with the newer version but you obviously do not use those yet.
I gets messy if you use the User Application and all that stuff.
0 Likes
Knowledge Partner
Knowledge Partner

Re: IDM 4.7 in mixed environment

On 1/23/2019 8:34 AM, joakim ganse wrote:
>
> As long as you only talk about the synchronization engine it should
> work.
> There are a few tokens that only works with the newer version but you
> obviously do not use those yet.
> I gets messy if you use the User Application and all that stuff.


Officially, the Identity Apps won't be 'supported' which I understand,
can have odd interactions, but is kind of a dumb approach. There has to
be a time window where versions coexist during an upgrade, so that has
to be expected to not break spectacularly. So it works together or not.

However as Joakim notes, the engine and eDir is basically fine version
mixed up. Better to get to one consistent one longer term since as
noted, new features only exist on newer engines.

The Identity Apps (IA) are another can of worms. There is an odd
dependency between the UA Driver object (Less so the UA Driver itself,
more so the RRSD driver interestingly enough) which is used to store
shared info in a Cluster situation.

IDentity Governance (IDG) made this issue a bit more clear.

First a side note, with IDG and the newer IA, you are basically always
running in a clsuter, even if you only have one node.

For IDG, and IA there is actually two sets of distinct config
information sets. It is less clear in the IA case, but as noted in IDG
it becomes very obvious.

There is stuff stored in ism-configuration.properties, for both IA and
IDG. This is meant to be Node specific stuff. I.e. There may be 3
cluster nodes thus each node might have "Server Specific" info. In IDM
engine side, we use Per-Replica schema flagged attributes for this.

Then there is stuff that is share across the entire cluster. Now you
could maintain this in three places, and a change needs to be made to
all three, or you could store it in a shared location.

IA uses the UA Driver object, the cn=configuration under AppConfig
specifically, in an XML blob in XmlData attribute to store tons of
config info. Like the NMAS SAML method keys to auth to eDir and more.

IDG Uses the shared DB i n the ISM_GLOBAL_CONFIG table.

(IDG handles this in a confusing fashion, by starting it in
global.properties file, and then using a script that calls configutil.sh
to import it into the DB)

So if you wanted two distinct UA's (say two versions) you would need two
distinct drivers at a minimum for the different config info.

0 Likes
Hendrik1 Absent Member.
Absent Member.

Re: IDM 4.7 in mixed environment

Awesome thanks guys.

Thus far none of the Identity Applications have been deployed. Im actually using this as an interim solution to integrate with their new AD Environment and later migrating the other drivers across.

Have a good one!!!
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.