📋 Microsoft Entra Documentation Changes

description: Understand the difference between soft and hard deletions and how to recover or recreate objects in Microsoft Entra ID.

ms.date: 10/06/2025

Managing deletions in Microsoft Entra ID is a critical aspect of maintaining the integrity and availability of your organization's identity infrastructure. This article provides a comprehensive guide to understand the differences between soft and hard deletions, monitor for deletions, and recover or recreate objects in your Microsoft Entra tenant. Whether you're dealing with accidental deletions or preparing recovery strategies, this guide equips you with the knowledge and tools to minimize disruption and ensure continuity. For foundational insights, start with [Recoverability best practices](recoverability-overview.md).

The [Microsoft Entra audit log](~/identity/monitoring-health/concept-audit-logs.md) contains information on all delete operations performed in your tenant. Export these logs to a security information and event management tool, such as [Microsoft Sentinel](/azure/sentinel/overview).

ms.date: 10/06/2025

### Note validations performed by SCIM Validator

 

**Create New User**

- POST /Users – Creates a new user with a complete JSON payload.

- Endpoint returns HTTP 201

- POST response contains created user ID

- GET /Users?filter={joiningProperty} eq "value" – Verifies creation by filtering on the joining property.

- GET returns created user

- Returned values from GET match the passed values from the POST request (varies based on endpoint)

- DELETE /Users - Cleans Up Test User.

- **Federation/Modern Authentication** – Some applications are already federated via [AD FS](/windows-server/identity/ad-fs/ad-fs-overview), or support modern protocols such as SAML or OAuth. These can generally be reconfigured to use Microsoft Entra ID with minimal effort.

- **Other Legacy Methods** – Includes cases where apps use RADIUS against AD or local accounts. Though not the primary focus, these should be documented for completeness. For more information, see: [RADIUS authentication with Microsoft Entra ID](../../architecture/auth-radius.md).

**LDAP-bound applications** or services directly query Active Directory Domain Services (AD DS) via LDAP, most often for authentication using a simple bind with username and password, or for directory reads. Common examples include older enterprise applications, network appliances, or custom-developed apps that rely on LDAP binds to validate credentials. These applications typically require an LDAP server, and can't easily transition to modern authentication protocols. For more information, see: [LDAP authentication with Microsoft Entra ID](../../architecture/auth-ldap.md).

to modern protocols. The managed domain mainly supports read and authentication for LDAP clients. For more information, see: [What is Microsoft Entra Domain Services?](../../identity/domain-services/overview.md).

##### Validations performed by SCIM Validator

 

**Create New Group**

 

- POST /Groups – Creates a new group with a complete JSON payload.

- Endpoint returns HTTP 201

- POST response contains created group ID

- GET /Group?filter={joiningProperty} eq "value" – Verifies creation by filtering on the joining property.

- GET returns created group

- Returned values from GET match the passed values from the POST request (varies based on endpoint)

- DELETE /Groups - Cleans Up Test User.

- Only called if hard delete is supported

 

**Create Duplicate Group**

- POST /Groups – Attempts to create a group using an identical payload (with the same unique/joining attribute) to an existing group.

- Return HTTP 201 on first create request

- Return HTTP 409 on second create request

1. Stop the “*HR to on-premises Active Directory*” provisioning job.

1. For users eligible for SOA conversion, switch the SOA of the users from on-premises Active Directory to Entra ID.

1. Create a new “*HR to Microsoft Entra ID*” provisioning application to provision users from your HR system to Entra ID. Use scoping filters to restrict this app to only handle SOA converted users. For example: In the first phase, if you’re converting SOA only for users in the “Finance” department, then set the scoping filter as department EQUALS “Finance”. Expand the scoping filter in future phases to include more users.

 

1. Start the new “*HR to Microsoft Entra ID*” provisioning job.

 

1. Update the configuration of your “HR to on-premises Active Directory” provisioning app to exclude the SOA converted users from syncing to AD. Ensure that the skip out of scope deletions flag is set on the provisioning job. Continuing with the example above, you can exclude “Finance” department users from syncing to AD by setting the filter department NOT EQUALS “Finance”.

 

1. Restart the “*HR to on-premises Active Directory*” provisioning job.

 

1. Update the configuration of your Entra Connect Sync / Cloud Sync app to exclude the SOA converted users from syncing to Entra ID using a similar scoping filter.

### Public Preview - Convert Source of Authority of synced Active Directory users to the cloud

 

**Type:** New feature

**Service category:** Group Management

**Product capability:** Microsoft Entra Connect and Microsoft Entra Cloud Sync

 

The Source of Authority (SOA) at the object level allows administrators to convert specific users synced from Active Directory (AD) to Microsoft Entra ID into cloud-editable objects, which are no longer synced from AD and act as if originally created in the cloud. This feature supports a gradual migration process, decreasing dependencies on AD while aiming to minimize user and operational impact. Both Microsoft Entra Connect Sync and Cloud Sync recognize the SOA switch for these objects. The option to switch the SOA of synced users from AD to Microsoft Entra ID is currently available in Public Preview. For more information, see: [Embrace cloud-first posture: Transfer user Source of Authority (SOA) to the cloud (Preview)](../identity/hybrid/user-source-of-authority-overview.md).

 

---

 

ms.date: 10/06/2025

# Collect custom user attributes during B2B collaboration sign-up

> This article applies to B2B collaboration user flows in workforce tenants. For information about external tenants, see [Collect custom user attributes during external tenant sign-up](customers/how-to-define-custom-attributes.md).

1. Search the Microsoft Entra admin center for the user. Verify that all user fields are greyed out, and that source is Windows Server AD DS.

## Restore deleted locations

 

If a Conditional Access policy or location is deleted, it can be restored within the 30 day soft-delete period. For more information about restoring Conditional Access policies and named locations, see the article [Recover from deletions](../../architecture/recover-from-deletions.md#conditional-access-policies).

 

##### Restore deleted policies

 

If a Conditional Access or location is deleted, it can be restored within the 30 day soft-delete period. For more information about restoring Conditional Access policies and named locations, see the article [Recover from deletions](../../architecture/recover-from-deletions.md#conditional-access-policies).

 

# Collect custom user attributes during external tenant sign-up

> This article applies to user flows in external tenants. For information about workforce tenants, see [Collect custom user attributes during B2B collaboration sign-up](../user-flow-add-custom-attributes.md).

>[!NOTE]

>When using Microsoft Entra certificate-based authentication on Android devices in kiosk mode (common in Shared Device Mode), customers should allow list com.android.systemui as a required package to ensure they are presented with the appropriate UI to complete their authentication.

 

**Scenario**: You’ve transferred the SOA for users and now want to allow them to access both on-premises, and cloud, resources. Instead of completely removing users from on-premises, introduce Cloud Kerberos Trust password-less authentication to allow them to maintain a hybrid presence allowing them to continue to access their on-premises resources, while also allowing them to access cloud resources. Password-less authentication methods, such as [Windows Hello for Business](/windows/security/identity-protection/hello-for-business/configure) or [FIDO2 security keys](../../identity/authentication/how-to-enable-passkey-fido2.md), can be used to allow these users to access both their on-premises resources, and cloud resources such as [Azure Files](/azure/storage/files/storage-files-introduction) through [Microsoft Entra Private Access](../../global-secure-access/concept-private-access.md). Using Password-less authentication also enables Multifactor Authentication on the SOA transferred users increasing security. Password-less authentication also allows you to enable Conditional Access policies on the on-premises resources, allowing greater control and security over these resources. **The user account must remain in Active Directory for this scenario to work**.

This article describes how Group SOA can help IT administrators transition group management from AD DS to the cloud. You can also enable advanced scenarios like access governance with Microsoft Entra ID Governance. For a guide on using group SOA for IT architects, see: [Cloud-First identity management: Guidance for IT architects](guidance-it-architects-source-of-authority.md)