Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

azuread_synchronization_job_provision_on_demand sometimes deploys prior to the entra group being assigned to the enterprise application #1423

Open
Eternious opened this issue Jun 28, 2024 · 1 comment

Comments

@Eternious
Copy link

Eternious commented Jun 28, 2024

Community Note

  • Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritise this request
  • Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritise the request
  • If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform (and AzureAD Provider) Version

  • Terraform v1.9.0
  • azuread provider v2.52.0

Affected Resource(s)

  • azuread_synchronization_job_provision_on_demand

Terraform Configuration Files

resource "azuread_group" "test" {
  display_name     = "TestGroup"
  security_enabled = true
}

resource "azuread_access_package_resource_catalog_association" "test" {
  catalog_id             = "<Some pre-existing catalog id>"
  resource_origin_id     = azuread_group.test.object_id
  resource_origin_system = "AadGroup"
}

resource "azuread_access_package" "test" {
  catalog_id   = "<Some pre-existing catalog id>"
  display_name = "TestPackage"
  description  = "Test Package"
}

resource "azuread_access_package_resource_package_association" "test" {
  access_package_id               = azuread_access_package.test.id
  catalog_resource_association_id = azuread_access_package_resource_catalog_association.test.id
  access_type                     = "Member"
}

resource "azuread_access_package_assignment_policy" "test" {
  access_package_id = azuread_access_package.test.id
  display_name      = "Initial Policy"
  description       = "Initial Policy"
  duration_in_days  = 1
  requestor_settings {
    scope_type        = "SpecificDirectorySubjects"
    requests_accepted = true
    requestor {
      object_id    = "<Some pre-existing group object id>"
      subject_type = "groupMembers"
    }
  }
}

resource "azuread_app_role_assignment" "test" {
  app_role_id         = "<Some pre-existing enterprise application role id>"
  principal_object_id = azuread_group.test.object_id
  resource_object_id  = "<Some pre-existing enterprise application object id>"
}

resource "azuread_synchronization_job_provision_on_demand" "test" {
  depends_on             = [azuread_app_role_assignment.test]
  service_principal_id   = "<Some pre-existing enterprise application object id>"
  synchronization_job_id = "<Some pre-existing enterprise application synchronization job id>"
  parameter {
    rule_id = "<Some pre-existing enterprise application synchronization job rule id>"
    subject {
      object_id        = azuread_group.test.object_id
      object_type_name = "Group"
    }
  }
}

Expected Behavior

The azuread_synchronization_job_provision_on_demand resource should allow for propagation of the entra group being assigned to the enterprise application.

It should retry if the expected group has not yet propagated after being assigned.

Actual Behavior

Sometimes the azuread_synchronization_job_provision_on_demand resource will deploy prior to the entra group assignment to the enterprise application propagating, causing a failed provision.

Below log from the Audit Logs of the Enterprise App
The Group 'TestGroup' will be skipped due to the following reasons: 1) This object is not assigned to the application. If you did not expect the object to be skipped, assign the object to the application or change your scoping filter to allow all users and groups to be in scope for provisioning.

Steps to Reproduce

  1. terraform apply
@vegardx
Copy link

vegardx commented Jul 1, 2024

I think it would make more sense to fix azuread_app_role_assignment so that it waits for propagation to return success rather than retrying azuread_synchronization_job_provision_on_demand until it succeeds. I'm fairly new to using the AzureAD provider, and Azure in general, and was just bit by this because I expected that an assignment was propagated when it returned success. Took me some time to realize.

But either options works. We should at the very least update the documentation on azuread_app_role_assignment to add a notice about propagation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants