Do I understand your architecture correctly: You've got an IDM instance with an AD driver, and you publish account and permission information there via the driver.   You have a collector in IG pulling from IDV and that AD driver.   You manage those accounts and the permission/group assignments in IDV, NOT in AD.  Is that correct?

I HIGHLY recommend always linking the permission assignment to the account object to which it is granted, and in turn linking the account object back to the identity.  Also, collect perms and accounts from the system you want to do fulfillment to.  That is, if you are managing perms on the IDV side, you DO want to collect accounts there, along with their permission assignments.   I'd suggest update your driver to sync the relavant attributes back to IDV so you can get them in IG.  With this model you filfill against IDV.

Alternatively, what are you getting with IDV management of those perms?  You could point IG directly at AD. Pull in perms linked to accounts, then link the accounts back to your identities.  That requires you to have a matching value on the AD account and on the identity source.   With this setup, you would perform fulfillment against AD accounts/groups.

Note that part of a fulfillment includes the which permission and which account is changing so that the fulfiller can go change a group membership.  Its for this reason that you want the perm and the account that will be assigned/removed to be sourced from the same system.  

--Jim

Thanks for the detailed answer!

Yes, in most cases we are managing everything in the IDV.

"I'd suggest update your driver to sync the relavant attributes back to IDV so you can get them in IG.  With this model you filfill against IDV." - with this, the attributes would be attached to the identity and not the account - correct?

I think I understand now, when to use which collector. Because we normally have the IDM AE Permission collector and an AD connector. So we collected the accounts via IDM and via AD. And with the AD collector you can collect more attributes, without the need to import them into the IDM.

"I HIGHLY recommend always linking the permission assignment to the account object to which it is granted, and in turn linking the account object back to the identity." - I need to check if this is the case - I have a permission to identity and account to identity mapping. I will need to check if the accounts also have permissions assigned or if they are all mapped to the identity.

Thanks for your input, I think I need to revisit the whole collector topic to get a better understanding of the possibilities.

BR

Tobias

Note that in the permission collector where it maps the assignment back to a user/identity or account the drop down there has two portions, one with all the identity attributes, and one with account attributes. You have to scroll down past the default identity attrs to see the account stuff to link the perm to the account.
By experience, I'd probably choose to collect attributes like last login, last password set to the account object in IG, as part of the application data collector.

So he's where things get funky, if you are coming from an IDM background: the identity row/object you create in IG from an authoritative source of all your users/identities (probably from IDV) is a logical set of users you will link ALL your application perms and accounts to. Its like a master list of who is who. Separately, I'd suggest you pull in accounts and perms from every app you want to perform reviews for. This means you might use IDV BOTH as a identity collector, and ALSO as a application collector. In this case it should be really simple to map accounts map to identities (they should share a DN or other unique identifier).

Identities in IG are for selecting individuals or groups for reviews, or for figuring out who the supervisor is. You select identities to be the reviewers and owners of permissions. Accounts and Perms are reviewable items. You review that access has been granted to an account owned by an identity. Fulfillment needs the perm and the account to add/remove an access. So, the best practice is collect account and permission from the system you are reviewing, and also link the account to the identity who is getting the access.

Yes, that is what we are doing. We try to collect directly from the application if it is necessary (mostly AD).

That was the initial reason why I didn't want to import accounts from the IDM AE collector, because I already collect them via the AD collector directly and mapped those accounts to the identites and since we are provisioning the AD-accounts via IDM we always have an matching attribute. (Of course, there are user that are only in the AD, but with the IG we can also identity those easier)

I think I will need to play more with the collectors, identity/account-mapping and reviews. Also I will need to check when to use permissions or accounts in a review - I understand the difference between those two entities but still need to do a little bit testing to get a feeling which review would be better for use to use.

Thank you Jim for sharing your experience and your feedback! :)

PS: The main reason actually I wanted to disable the account collecting with the IDM AE permission collector was, that if you use the IDM AE collector and an AD collector, you can find the following account mapping at the identity:

 
Those accounts are the same, both describe the AD account. One (AD Driver) is collected via IDM AE collector, the other one (AD Cloud.local (direct) directly from the AD. I don't see a reason to have both accounts mapped to the identity or why I need both accounts in the first place. 

It is more of a "visual" reason and I can still do a review only for the AD-Account, but it might be confusing to have two accounts. But I think this is also a quite complex 

(Yes, I should have shown this screenshot from the start to clarify what my 'problem' is - sorry about that)

I agree with you - you'd only want one of those in IG ----probably.   It comes back to fulfillment in my mind - which mechanism will you use to fulfill changes.   If the driver supports what you need, you can go that route.  Or, just go straight AD.   It may be best to live in a hybrid environment for a while, just knowing you've got two records for the same account in IG.

--Jim