A cloud-based identity and access management service for securing user authentication and resource access
The account expiration attribute from on-premises Active Directory does not synchronize to Microsoft Entra ID, so an expired AD account remains active in Entra ID when using password hash synchronization. Because of this, Entra ID cannot natively block sign-in based directly on the on-premises accountExpires value without additional logic.
The supported approach is to implement automation that reacts to account expiration in AD and then enforces access restrictions in Entra ID. Key options from the documented guidance:
- Use a scheduled PowerShell process on-premises
- Monitor the
accountExpiresattribute in AD. - When the account passes its expiration date, run a scheduled script that updates the user account to enforce the desired behavior.
- The documentation recommends using a scheduled PowerShell script with
Set-ADUserto disable AD accounts after they expire. Although the example focuses on disabling the AD account, the same pattern (scheduled script reacting to expiration) is what enables you to coordinate changes with Entra ID.
- Monitor the
- Disable or update accounts via Microsoft Entra automation (Lifecycle Workflows / provisioning)
- Implement Microsoft Entra Lifecycle Workflows to handle leaver scenarios.
- Configure a leaver workflow that, after the scheduled leave/expiry date, performs actions such as:
-
Disable user accountin on-premises AD (via the on-premises update capability in Lifecycle Workflows). - Optionally, a later workflow to
Delete userfrom AD after a retention period.
-
- These workflows can be scheduled to run on or after the user’s leave/expiry date and can update both AD and Entra ID, ensuring that expired users lose access consistently.
- Revoke access to cloud apps as part of deprovisioning
- Use Microsoft Entra app provisioning and Lifecycle Workflows to deprovision users from SaaS and on-premises applications when they leave or when their account is considered expired.
- This ensures that applications revoke their own sessions and stop accepting Entra access tokens, even if the Entra account itself is not hard-disabled.
- Combine with Conditional Access and sign-in/session controls (if needed)
- After the automation marks users as leavers (for example, by setting a specific attribute, group membership, or disabling the account), Conditional Access policies can be used to block access for those users or groups.
- This is a secondary control; the primary enforcement still comes from disabling or deprovisioning accounts based on expiration.
Important points from the documentation:
-
accountExpiresis not synchronized to Entra ID, so Entra ID cannot directly evaluate that attribute for sign-in decisions. - Recommended practice is to use a scheduled PowerShell script to disable AD accounts after they expire, and to re-enable them if the expiration is removed.
- For broader lifecycle management, use Lifecycle Workflows and Entra app provisioning to automate deprovisioning and revocation of access across AD, Entra ID, and applications.
In summary, to block authentication in Entra ID when the on-premises expiry date is in the past, implement a scheduled or workflow-based process that:
- Detects that
accountExpiresis in the past in AD. - Updates the user state (for example, disables the account or marks them as a leaver) in AD and/or Entra ID.
- Uses Entra provisioning and Lifecycle Workflows to revoke access to applications and, if desired, to Entra sign-in itself.
References:
- Best practices to migrate applications and authentication to Microsoft Entra ID
- Implement password hash synchronization with Microsoft Entra Connect Sync
- Revoke user access in Microsoft Entra ID
- Increase the resilience of authentication for federated applications deployed at sites with colocated users
- Protect Microsoft 365 from on-premises attacks