Highlighted
Noel_G Absent Member.
Absent Member.
331 views

Possibilityt to override User and Group Container per driver

My tree looks like this:

[ROOT]
--CompanyA
----US
-------Divison
----ASIA
-------Divison
--Company B
-----US

My current IDM Driver set is currently setup:
GCV Common Settings - User and Group Containers US.CompanyA

I need to extend the the driver set to the entire tree. Since [ROOT] doesn't work I'm figuring that I can use CompanyA, and CompanyB as User and Group Containers. I want these drivers to behave exactly the same for both containers and I don't want to spin up another server to add another driver set if I don't need to. So a thought came to my mind about overriding the GCV Common Settings on a per driver basis. In my test environment I've created another driver, and RL set and I manually added idv.dit.data.user and idv.dit.data.groups to the GCV Common Settings of the driver. I then set the those values to CompanyB.Of course this didn't work, it began to sync US.CompanyA.

I'm pretty novice with IDM, so I'm hoping that somebody can point me in the right direction. I'm using IDM 4.0.2 SE and the AD driver 4.0.1.

Thanks!
Labels (1)
0 Likes
2 Replies
Knowledge Partner
Knowledge Partner

Re: Possibilityt to override User and Group Container per dr

Noel_G;2462601 wrote:
My tree looks like this:

[ROOT]
--CompanyA
----US
-------Divison
----ASIA
-------Divison
--Company B
-----US

My current IDM Driver set is currently setup:
GCV Common Settings - User and Group Containers US.CompanyA

I need to extend the the driver set to the entire tree. Since [ROOT] doesn't work I'm figuring that I can use CompanyA, and CompanyB as User and Group Containers. I want these drivers to behave exactly the same for both containers and I don't want to spin up another server to add another driver set if I don't need to. So a thought came to my mind about overriding the GCV Common Settings on a per driver basis. In my test environment I've created another driver, and RL set and I manually added idv.dit.data.user and idv.dit.data.groups to the GCV Common Settings of the driver. I then set the those values to CompanyB.Of course this didn't work, it began to sync US.CompanyA.

I'm pretty novice with IDM, so I'm hoping that somebody can point me in the right direction. I'm using IDM 4.0.2 SE and the AD driver 4.0.1.

Thanks!


Post a level 3 trace of this driver starting. GCV resolution should have picked up the "closer" value, if I recall correctly.
0 Likes
Knowledge Partner
Knowledge Partner

Re: Possibilityt to override User and Group Container per driver

On 7/25/2017 2:44 PM, Noel G wrote:
>
> My tree looks like this:
>
> [ROOT]
> --CompanyA
> ----US
> -------Divison
> ----ASIA
> -------Divison
> --Company B
> -----US
>
> My current IDM Driver set is currently setup:
> GCV Common Settings - User and Group Containers US.CompanyA
>
> I need to extend the the driver set to the entire tree. Since [ROOT]
> doesn't work I'm figuring that I can use CompanyA, and CompanyB as User
> and Group Containers. I want these drivers to behave exactly the same
> for both containers and I don't want to spin up another server to add
> another driver set if I don't need to. So a thought came to my mind
> about overriding the GCV Common Settings on a per driver basis. In my
> test environment I've created another driver, and RL set and I manually
> added idv.dit.data.user and idv.dit.data.groups to the GCV Common
> Settings of the driver. I then set the those values to CompanyB.Of
> course this didn't work, it began to sync US.CompanyA.
>
> I'm pretty novice with IDM, so I'm hoping that somebody can point me in
> the right direction. I'm using IDM 4.0.2 SE and the AD driver 4.0.1.


Welcome! Lots of good advice here.

So think about how you decide where to put a user? Which policy set
would that be? Well it is convieniently named, Placement for that reason.

So in the Sub and Pub channel, you need to decide if the default
packaged versions of the drivers do what you need. Demonstrably not,
from your email above.

So go look at the Placement policies and see if you can easily modify them.

One thing to consider... You can just let the driver do as it does, and
then in a policy AFTER do your check to decide where to place, and use
Set Operation Destination DN, since the last one used wins.

Now you might also be talking about the scoping on the Sub channel that
says, only take users from idv.dit.data.users/groups containers.

Where would you first implement this? Well you could do it Event
transform, but really you only want this to apply to unassociated
users/groups who need to be created, so probably the Match policy set is
the right place, since the matching object may exist, so before you even
try to match you should do this.

You will see that the NetIQ packages will set an operation property,
"attempt-to-match" =true or false.

So you can leave existing policy alone, make a object that follows it
and has a rule that does your test for the second container, and if
true, re-sets the op prop to true. Again, last one wins.

Then you need to look at where in the target system you are matching.
Still the same? Or do you need toe xpand the scope there?

If so, again you can do this additive, since Find Matching object can be
called as many times as you need. First one to find a user stops the
others from even looking. So no harm is doing 5 Find Matching.

And so on...

This applies in both channels, since your question is unclear, but
hopefully gets you pointed in the correct direction.



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.