Accountselector for requesting entitlements using manage user access

8.4p2

Share all details about your problem, including any error messages you may have received.

I have two accounts on AD. One is my regular account and the other one is my “adm_” account. When I request an entitlement, I get a pop-up to pick one.

Is there a way to pre-select the one not having “adm_” ?

For roles, we have accountselector rule and we are fine.

Thanks.
pasha

Could you please clarify, are you trying to implement an account selector without using roles? Because using roles is generally a better approach for account selection.

Yes we allow users request entitlements (AD Groups) directly. Again, we have no issues when using roles to assign AD groups. But want to do the same for entitlement requests.

Hi @pasha - yes, you can setup an account selector rule on the IT role under Provisioning Target Account Selector Rules. Add an appropriate rule that returns the link of the account you want to provision. This will avoid the prompt. Example:

for (Link link : links) { String accountName = (String) link.getAttribute(“sAMAccountName”); //If the account name contains “adm”, select it for this role if (accountName != null && accountName.toLowerCase().contains(“adm”)) { return link; } }

But we want to request an entitlement directly. Not using any roles.

Ah, sorry mis read your original post. In that case you would have to modify the LCM Provisioning Workflow to intercept that and have logic to assign the correct account.

This selection pop-up seems to come up before the workflow kicks in.

The workflow is active at that time. You would need to add your step after the Initialize step in LCM but before Create ticket and return the correct native Identity to the plan.

For entitlements, we cannot do it that way. Instead, you can create a role of type “Entitlement” and assign the entitlement there. Then, you can easily request it from Manage User Access, with the account selector rule applied to that role.

@pasha We also ran into similar usecase.. Even used to have adm and couple of more additional types. We decided to split the application: one regular AD and other one is AD Privileged. In this way, it was working fine for us. Keeping both accounts type in one app was causing below issues:

  • Role Filters was not working it was always picking the first link account, not considering the others for filters evaluation.
  • Additional role account selector was needed
  • Popups in OOTB Manage user access (one which you highlighted)
  • For custom code, you need to be aware of the native identity, else it used to open a work item to select the native identity
  • Impacted our termination flow, where some role assignments were not having the application native id populated and it blocked the request.

Thank you @neel193 that’s a great suggestion. I think I have to go with this approach.

@pasha Sure.. give it a try and let us know for any further help. Thanks.