API-driven provisioning to on-premises AD: repeated accountDisabled update on identical payload, and direct accountDisabled mapping does not trigger disable

We are testing Microsoft Entra API-driven provisioning to on-premises Active Directory and are trying to understand whether this behavior is expected or if we are using the status mapping incorrectly.

Scenario

We are provisioning users from a custom API into on-premises Active Directory by using API-driven provisioning. We tested two different mappings for the AD target attribute accountDisabled.

Test 1: Expression mapping

We configured: accountDisabled = Not([active])

Mapping settings:

• Mapping type: Expression
• Target attribute: accountDisabled
• Apply this mapping: Always

We then sent a payload where the user should be disabled:

  [
    {
      "schemas": [
        "urn:ietf:params:scim:schemas:core:2.0:User",
        "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User",
        "urn:ietf:params:scim:schemas:extension:custom:2.0:User"
      ],
      "id": "10001234",
      "userName": "test.user",
      "externalId": "10001234",
      "accountDisabled": true,
      "active": false,
      "name": {
        "givenName": "Test",
        "familyName": "User"
      },
      "displayName": "Test User",
      "emails": [
        {
          "value": "test.user@example.com",
          "type": "work",
          "primary": true
        }
      ],
      "phoneNumbers": [
        {
          "value": "+4000000000",
          "type": "mobile"
        }
      ],
      "addresses": [
        {
          "streetAddress": "",
          "locality": "TestCity",
          "region": "",
          "postalCode": "",
          "country": "",
          "type": "work"
        }
      ],
      "title": "Engineer",
      "department": "IT",
      "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User": {
        "employeeNumber": "10001234",
        "department": "IT",
        "manager": {
          "value": "20005678",
          "displayName": "Manager User"
        },
        "division": "Example Company"
      },
      "urn:ietf:params:scim:schemas:extension:custom:2.0:User": {
        "employmentStatus": "M",
        "mobile": "+4000000000",
        "orgChartName": "Example Company;IT",
        "positionStartDate": "2021-03-01T00:00:00",
        "employmentsEndDate": null,
        "employmentsStartDate": "2021-03-01T00:00:00",
        "managerEmail": "manager.user@example.com",
        "startDateStatus": null
      }
    }
  ]

We verified in our application logs that the outbound request sent to Microsoft Graph contains:

• active: false
• accountDisabled: true

Result of Test 1

First request:

• provisioning runs an Update
• the AD user is disabled correctly
• Modified Properties shows accountDisabled = True

Second request, later, with the exact same payload:

• provisioning runs another Update
• Modified Properties again shows accountDisabled = True

Expected result on the second identical payload:

• no modified properties
• skipped / RedundantExport

Test 2: Direct mapping

We also tested direct mapping:

• Mapping type: Direct
• Source attribute: accountDisabled
• Target attribute: accountDisabled
• Apply this mapping: Always

In that case, when we sent a payload with:

• accountDisabled: true
• active: false

the disable did not trigger as expected. Provisioning did not perform the AD disable in the same way as with Not([active]).

Questions

1. For API-driven provisioning to on-premises AD, is Not([active]) -> accountDisabled the correct supported mapping?
2. Is it expected that a second identical payload still triggers another Update for accountDisabled even when the AD account is already disabled?
3. Is direct mapping accountDisabled -> accountDisabled supported for this scenario, or is active the only reliable source attribute for account state?
4. Is there any known issue or limitation where Entra provisioning cannot compare the target AD disabled state correctly for accountDisabled?
5. Is there any recommended configuration that makes the second identical payload result in RedundantExport instead of another update?

Documentation we reviewed

We reviewed these Microsoft references while testing:

• API-driven provisioning FAQ
• bulkUpload examples that use active: false
• attribute mapping / expression documentation
• examples where Active is shown as the source for AD accountDisabled

Because of that, we want to confirm the correct supported pattern for on-premises AD account disablement.