cancel
Showing results for 
Search instead for 
Did you mean: 

Provision business role based on AD group

Henrik1
Participant
0 Kudos

Hi,

I'm trying to set up IdM so that it reads from AD, and based on the AD group(s) assigned, it will assign a business role.

I can read the users and groups from AD, and I can provision business roles from IdM, but I can't get the link between having an AD group and being provisioned with a business role.

It seems most AD scenarios are set up to provision from IdM into AD instead.

I have been playing around with the relationships on roles, groups and privileges, but so far I have been unsuccessful.

Has anyone done this? If so, would you be able to give me any pointers?

If this isn't entirely clear, please let me know.

Your help is much appreciated!

On IdM 7.2

regards,

Henrik

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Hi Henrik

There are two options I think.

1) Change the AD import job so that instead of creating groups/privs (or as well as), it creates roles.  Users will be directly assigned to these based on their membership in AD.  Thus the AD groups have a 1:1 correlation with the role.  You can make higher order roles and assign the AD group roles to them if its too granular.

2) You can write a process that assigns the roles on import.  Basically you can have a script which interrogates the roles list for the assigned AD privilege and then automatically assigns that role during the import.  In this way you can assign the AD priv to multiple roles and they should all get assigned.

Both approaches work but you will want to work through all the issues around maintenance and deprovisioning etc as well as where you see it going in the future - if you're never writing to AD then you can use option 1 as probably the easier option.  If you have plans to expand into writing to AD later then you want as few changes to the base functionality as possible.

Peter

Henrik1
Participant
0 Kudos

Hi Peter,

Thanks for that! That sounds like two good solutions.

I will let you know how we get on.

/henrik

Henrik1
Participant
0 Kudos

Hi again - sorry it's taking so long to respond. My comments seems to be stuck in moderation mode.

We followed your first approach, and so far it's looking pretty good. Still some minor issues around removal but a huge help!

thank you!

/henrik

Former Member
0 Kudos

No worries.  Let me know whats going on with removal and I'll see if I can help.

Peter

Answers (3)

Answers (3)

Steffi_Warnecke
Active Contributor
0 Kudos

Hello Henrik,

I don't know if I'm missing something, because there are already so many different ways given to achieve what you want, but would be the easiest way by dynamic groups?

Per SQL-statement in the filter you can set for which AD-groups (after they are imported into IdM of course) it should look and find the users assigned to those. And then you just assign this dynamic group to the role you want the users to get.

Here is a short explanation of dynamic groups (from the help in the Identity Center Console), that probably explains it better than I did above. ^^ I highlighted what I think is what you want to do:

The entry type dynamic group (MX_DYNAMIC_GROUP) provides a possibility to select entries (persons) based on attribute values, for instance all with location "Walldorf" or title "Manager". This can also be a combination of several attributes.

The members of the dynamic group will be the entries that matches the filter defined for the group. Membership in a dynamic group is decided by the values at the time of resolving a group. This can be done using the internal function uIS_ResolveDynamicGroup.
Links are created between the dynamic group and all entries matching the filter for the group.

Note that resolving groups may be time consuming and put a high load on the
system, depending on the complexity of the filter and the number of members.

Dynamic groups can be used in a job to define a selection of entries to be processed at the same time, for instance given a certain value. In this case, you can use the
dynamic group as a source in a job.

A dynamic group can also be specified as a constraint for a role (dynamic roles). In this case any entries matching the filter for the dynamic group will be defined as members of the role. It can also define members which are allowed/not allowed for a role.

Note: When using dynamic groups, consider carefully the performance of any SQL statements used to resolve the group members. Extensive use of dynamic groups is not recommended due to the possible impact on performance.

If you look at the help-file you'll find more information like how to set the dynamic groups up etc.

Regards,

Steffi.

terovirta
Active Contributor
0 Kudos

Steffi Warnecke wrote:

Hello Henrik,

I don't know if I'm missing something, because there are already so many different ways given to achieve what you want, but would be the easiest way by dynamic groups?

Per SQL-statement in the filter you can set for which AD-groups (after they are imported into IdM of course) it should look and find the users assigned to those. And then you just assign this dynamic group to the role you want the users to get.

I think the fundamental question is how to map the Business Role to AD Groups.. Is there 1:1 relationship? How many AD Group driven Business Roles will there be?

If there is 1:1 relationship between the Business Role and AD Group then the suggestion to create the Business Roles in AD initial load/update is best way of creating them.

I would also try to assign the Roles via dynamic groups rather than developing Validate Add/Delete tasks. The bonus via dynamic groups is that the assignment would be product standard.

Only bad thing I've experienced with dynamic groups was on IdM 7.0 and customer required the groups being re-calculated too often. That was a killer for performance, but ancient history (hopefully ) as it's two major versions old information.

Henrik1
Participant
0 Kudos

There will be a 1:1 relationship between the AD groups and the business roles. We are using the approach suggested by Peter, and so far it's looking good. A few minor issues to sort out, but nothing that can't be managed.

Thank you everybody for your input on this.

New to this forum and appreciate the welcome I received 🙂

ivan_petrov
Active Participant
0 Kudos

Hi Henrik,

Well as far I understood, you want to assign to a person different business role based on AD privilege assigned to him. The most simple and straight forward way is to configure the event tasks for a privilege for a privilege. For each privilege you can define what tasks should be executed on PROVISIONING (after the privilege was added successfully to the person), MODIFY and DEPROVISIONING (after the privilege was removed successfully from person) operations.

Just add task that will assign desired business role for ache privilege and that is it.

Right after the AD privilege was successfully attached to the person, adding of desired business role will be triggered automatically

Just be careful that in the business roles, the AD privilege that triggers their addition should not present, otherwise you will end in an endless loop.

Best regards,

Ivan

ivan_petrov
Active Participant
0 Kudos

Hi Henrik,

I've made a small blog about implementation suggested by me.

You can find it here:

Best regard,

Ivan

Former Member
0 Kudos

Hi Henrik,

  I have an idea, but it's a work around.

Important thing to clear first is what are the AD groups for IdM?

Are they privileges or....?

Please describe with more details your scenario, because I don't see the hole picture and I can't give a helpful response.

BR,

Simona

Henrik1
Participant
0 Kudos

Hi Simona,

thanks for the response.

The scenario is as follows:

In AD, the users are set up, and assigned an AD group. They are just standard AD groups.

In IdM we read the AD users and groups. They come in alright, and we can see the AD group assignments.

We then want to map the business role to the AD group, and use that relationship to drive the provisioning of access into SAP.

I understand that you usually do it the other way around, but surely there must be a way of doing it, since we have the data and relationships available.

hope that clarifies it a bit.

thanks,

Henrik