Hybrid Provisioning in AD and Azure AD

Identity Security Cloud (ISC) ISC Discussion and Questions
,
1

I have a scenario that’s exactly the same as scenario 3 in this document

In our environment, all accounts are first created on the on-premise Active Directory, and later synced to Azure AD. There’s a birthright role that ensures the account is created. That role has 2 access profiles; one that grants the requisite groups on the on-prem AD, and the other that grants other Azure AD access, like licenses, etc

Everything work fine, but I’ve noticed in the events search, that at the time the on-prem account is getting created, IdentityNow is also attempting to create the corresponding account in Azure AD by reason of the role assignment criteria match. The WriteUser permission isn’t granted to the AzureAD- IdentityNow integration, so this expectedly fails.
Is there a way to stop IdentityNow from trying to create the account in Azure AD? It’s not a show stopper, but it would be nice to not see those “FAILED” events in the logs for when IdentityNow tries to create the account in Azure AD.
I’ve tried deleting the Provisioning Policies on the Azure AD source but that didn’t help.
Any idea?

2

What are you seeing is expected behavior. You can try altering the plan by removing the CREATE ACCOUNT in before prov rule for Azure AD, assuming that the other AD Group is used to trigger the assignment of Azure License.

3

Thanks Sunny, but the beforeProvisioningRule on the Azure AD source has the value of “null”. There’s no rule associated with that source as far as I can tell.

4

Add a new criteria on the role that corresponds to an Azure AD account existing - something like:
Type: Account Attribute
Source: Azure Active Directory
Attribute: userPrincipalName
Operation: Contains
Value: @

This will ensure the user matches the role criteria only after the Azure account is correlated to the user - which means you may need a new role created - one to add AD access, and a second to add Azure access.

5

We have the similar setup. What you can do is add the follwing crtieria in the Role Assignment so that the Role is added only if the user has an Azure AD Enabled Account.

image
image1242×160 11.1 KB

Please let us know once you have done the setting and it works for you.

Thanks

6

Thanks Kevin. I had thought of this approach earlier but wanted to avoid it, since doing it this way would mean having twice as much roles for each team/department. It doesn’t seem like there’s much of a choice around this.

7

Thanks Rakesh, let me try this out.

8

Thanks for your suggestion. I tried it out and it’s working as expected. There’s one other finding though. Here’s the flow:

  • The on-prem account is created by another onboarding birthright role that grants generic access.
  • The on-prem account is synced to AAD.
  • AAD source is aggregated and the account in AAD is correlated with the on-prem account but the access profiles in the role is not processed for both the on-prem AD and AAD accounts. (The role contains 2 access profiles; one for on-prem AD and the other for AAD). Neither of the on-prem & AAD accounts gets the access profiles several hours after.
    I was able to get it to process the role by clicking “Apply Changes” on the role page. Is there a way to avoid this and get IDN to process things automatically upon matching the role assignment criteria?
9

Hi Ola,
This is expected behaviour. I would recommend have 2 separate roles. One for On-Premise AD having On-Demand-Premise. The other role containing AAD access profile.

10

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.