MODIFIED docs/identity/conditional-access/agent-id.md

Modified by shlipsey3 on Jun 3, 2026 6:48 PM
📖 View on learn.microsoft.com

+16 / -62 lines changed

Commit: ca-agents-trim-link-060326

Changes:

Before

After

 
Conditional Access is an intelligent policy engine that helps organizations control how users and agents access corporate resources. It brings together real-time signals such as user's and agent's context, device, location, and session risk information to determine when to allow, block, or limit access, or require more verification steps.
 
Learn about Conditional Access for agents:
 
- High-level overview of Conditional Access: [What is Conditional Access?](overview.md)
- Guide to managing agent identities across your organization: [Manage agent identities in your organization](../../agent-id/manage-agent-identities-admin.md).
- Securing agent flows using Conditional Access:
    - [Configure policies for autonomous agent access](policy-autonomous-agents.md)
    - [Configure policies for on-behalf-of agent access](policy-on-behalf-of-agents.md)
 
## How Conditional Access evaluates agent access requests
 
 
### On-behalf-of flow
 
The most common access is the on-behalf-of signed-in user (OBO) flow. In this flow, the agent accesses resources with the user's identity and permissions to retrieve data or perform actions that the user can also can do. For example, when an agent reads your emails, the agent is accessing your mailbox *on your behalf*.
 
> [!NOTE]
> The on-behalf-of flow is also known as delegated access. Agents using this type of access are sometimes called interactive agents or assistive agents, as they involve a user interface for human interaction.

 
Conditional Access is an intelligent policy engine that helps organizations control how users and agents access corporate resources. It brings together real-time signals such as user's and agent's context, device, location, and session risk information to determine when to allow, block, or limit access, or require more verification steps.
 
Conditional Access for agents requires Microsoft Entra ID P1 or P2 and a Microsoft Agent 365 license for each user. Enforcement of Agent 365 licensing is coming soon. Network controls for agents require Microsoft Entra Internet Access. For more information, see [What is Microsoft Entra Agent ID](../../agent-id/what-is-microsoft-entra-agent-id.md#how-to-get-started).
 
Learn about Conditional Access for agents:
 
- High-level overview of Conditional Access: [What is Conditional Access?](overview.md)
- Guide to managing agent identities across your organization: [Manage agent identities in your organization](../../agent-id/manage-agent-identities-admin.md).
- [Configure policies for autonomous agent access](policy-autonomous-agents.md)
 
## How Conditional Access evaluates agent access requests
 
### On-behalf-of flow
 
The most common access pattern is the on-behalf-of (OBO) flow. In this flow, a user signs in to an agent application, and the agent accesses downstream resources using the user's identity and delegated permissions. For example, when an agent reads your emails, it accesses your mailbox *on your behalf*.
 
> [!NOTE]
> The on-behalf-of flow is also known as delegated access. Agents using this type of access are sometimes called interactive agents or assistive agents, as they involve a user interface for human interaction.

MODIFIED docs/fundamentals/whats-new.md

Modified by Ortagus Winfrey on Jun 3, 2026 11:28 AM
📖 View on learn.microsoft.com

+49 / -0 lines changed

Commit: Whats New missed items

Changes:

Before

After

---

### Public Preview - Workload identity-based authentication for SAP SuccessFactors provisioning integrations 

**Type:** New feature

---

### General Availability - NetBiosName resolution test now informational

**Type:** Changed feature  
**Service category:** Entra Connect  
**Product capability:** Entra Connect    

The “NetBIOS Name Sysvol Connectivity resolution” test in the AD DS health monitoring agent has been _reclassified_ from an alerting test to an informational test. Going forward, if this test fails, it will no longer generate an alert or require remediation action on your part. Instead, the test runs in the background and logs results for your information only.  

**What Changed**

**The NetBIOS Name Sysvol Connectivity test is now _informational-only_**. Previously, when this test failed (e.g. if a domain controller couldn’t resolve the **NetBIOS name** to access its **SYSVOL share**), an **alert was triggered** in Connect Health, prompting you for action. Now, **failures in this test will not raise an alert** in Microsoft Entra Connect Health.

**Why We Made This Change**

**NetBIOS is a legacy networking protocol that is not critical in modern Active Directory environments.** Many organizations no longer rely on NetBIOS name resolution in day-to-day operations. **Reclassifying this test as informational reduces noise in your alert feed and allows you to focus on issues that are genuinely critical to your identity infrastructure.** In short, we want to ensure that Connect Health alerts highlight _meaningful issues_ and help you prioritize real problems, rather than flagging non-essential conditions.

MODIFIED docs/identity/conditional-access/policy-autonomous-agents.md

Modified by shlipsey3 on Jun 3, 2026 7:10 PM
📖 View on learn.microsoft.com

+28 / -2 lines changed

Commit: revisions

Changes:

Before

After

- Target all agent users or select specific agent users
- Apply policies using custom security attributes
- Apply agent risk conditions to block risky agents
- Scope policies by agent execution environment (cloud, cloud-hosted VMs, end-user devices, on-premises)
- Enforce device compliance for agents running on managed endpoints
- Enforce compliant network locations for agents with a Global Secure Access client
 
To create a Conditional Access policy for agents operating with their own identity, use the following settings:
 
[!INCLUDE [conditional-access-report-only-mode](../../includes/conditional-access-report-only-mode.md)]
 
## Related content
 
- [Manage agent identities in your organization](/entra/agent-id/manage-agent-identities-organization) - Overview of agent management across the full lifecycle.

- Target all agent users or select specific agent users
- Apply policies using custom security attributes
- Apply agent risk conditions to block risky agents
- Use the agent execution environments condition to scope policies to agents running on endpoints
- Enforce device compliance for agents running on managed endpoints (Windows 365 Cloud PCs)
- Enforce compliant network locations for agents with a Global Secure Access client
 
To create a Conditional Access policy for agents operating with their own identity, use the following settings:
 
[!INCLUDE [conditional-access-report-only-mode](../../includes/conditional-access-report-only-mode.md)]
 
### Require a compliant network for agents' user accounts
 
Similar to device compliance, you can require agents running on endpoints to connect through a compliant network using [Global Secure Access](/entra/global-secure-access/overview-what-is-global-secure-access). The Global Secure Access client installed on the endpoint provides the network location signal that Conditional Access evaluates.
 
Use the **Agent execution environments (Preview)** condition to scope this policy to endpoint-based sessions only. Without this condition, cloud-native agents without a Global Secure Access client are blocked with no path to compliance.
 
1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com) as at least a [Conditional Access Administrator](../role-based-access-control/permissions-reference.md#conditional-access-administrator).
1. Browse to **Entra ID** > **Conditional Access** > **Policies**.
1. Select **New policy**.

MODIFIED docs/identity/authentication/howto-password-smart-lockout.md

Modified by Ken Withee on Jun 3, 2026 5:49 PM
📖 View on learn.microsoft.com

+3 / -2 lines changed

Commit: Add SSPR recovery guidance to smart lockout article (WI 583955)

Changes:

Before

After

title: Prevent attacks using smart lockout
description: Learn how Microsoft Entra smart lockout helps protect your organization from brute-force attacks that try to guess user passwords.
ms.topic: how-to
ms.date: 04/29/2025
ms.reviewer: rogoya
ms.custom: sfi-image-nochange
---
# Protect user accounts from attacks with Microsoft Entra smart lockout
 
 
  To refrain the system from locking out a user signing in from an unfamiliar location, they must use the correct password to avoid being locked out and have a low number of previous lockout attempts from unfamiliar locations. If the user is locked out from an unfamiliar location, the user should consider SSPR to reset the lockout counter.
 
* After an account lockout, the user can initiate self-service password reset (SSPR) to sign in again. If the user chooses **I forgot my password** during SSPR, the duration of the lockout is reset to 0 seconds. If the user chooses **I know my password** during SSPR, the lockout timer continues, and the duration of the lockout isn't reset. To reset the duration and sign in again, the user needs to change their password.
 
Smart lockout can be integrated with hybrid deployments that use password hash sync or pass-through authentication to protect on-premises Active Directory Domain Services (AD DS) accounts from being locked out by attackers. By setting smart lockout policies in Microsoft Entra ID appropriately, attacks can be filtered out before they reach on-premises AD DS.
 
 

title: Prevent attacks using smart lockout
description: Learn how Microsoft Entra smart lockout helps protect your organization from brute-force attacks that try to guess user passwords.
ms.topic: how-to
ms.date: 06/03/2026
ms.reviewer: rogoya
ms.custom: sfi-image-nochange
ai-usage: ai-assisted
---
# Protect user accounts from attacks with Microsoft Entra smart lockout
 
 
  To refrain the system from locking out a user signing in from an unfamiliar location, they must use the correct password to avoid being locked out and have a low number of previous lockout attempts from unfamiliar locations. If the user is locked out from an unfamiliar location, the user should consider SSPR to reset the lockout counter.
 
* After an account lockout, the user can initiate self-service password reset (SSPR) to sign in again. SSPR lets users reset or change their own passwords without help desk or administrator assistance. If the user chooses **I forgot my password** during SSPR, the duration of the lockout is reset to 0 seconds, so the user doesn't need to wait for the lockout duration to expire. If the user chooses **I know my password** during SSPR, the lockout timer continues and the duration of the lockout isn't reset. In that case, to regain access the user should either change their password or wait until the configured lockout duration expires.
 
Smart lockout can be integrated with hybrid deployments that use password hash sync or pass-through authentication to protect on-premises Active Directory Domain Services (AD DS) accounts from being locked out by attackers. By setting smart lockout policies in Microsoft Entra ID appropriately, attacks can be filtered out before they reach on-premises AD DS.
 

MODIFIED docs/identity/hybrid/connect/how-to-connect-sync-service-manager-ui-connectors.md

Modified by Josh Villagomez on Jun 3, 2026 2:34 PM
📖 View on learn.microsoft.com

+1 / -2 lines changed

Commit: Apply suggestion from @omondiatieno

Changes:

Before

After

 
> [!WARNING]
> Deleting a connector or connector space is **$\color{red} unsupported$**. Performing these actions may have serious consequences and damage your hybrid identity environment. These actions should **never** be a troubleshooting step.
>
 
### Configure Run Profiles

 
> [!WARNING]
> Deleting a connector or connector space is **not supported** and can have serious consequences for your hybrid identity environment. Don't use these actions as a troubleshooting step.
 
### Configure Run Profiles

MODIFIED docs/external-id/customers/how-to-sign-in-with-passkey.md

Modified by Ken Withee on Jun 3, 2026 8:29 PM
📖 View on learn.microsoft.com

+1 / -1 lines changed

Commit: Fix link to passkey management sample app

Changes:

Before

After

- View their registered passkeys.
- Delete a passkey.
 
For a complete reference implementation, see the [passkey management sample app on GitHub](https://github.com/Azure-Samples/ms-eeid-passkey-sample-app). The sample is a React single-page application (SPA) that demonstrates how to sign in users with Microsoft Entra External ID and manage passkey credentials by using the Microsoft Graph API.
 
## User experience

- View their registered passkeys.
- Delete a passkey.
 
For a complete reference implementation, see the [passkey management sample app on GitHub](https://github.com/Azure-Samples/ms-identity-ciam-native-javascript-samples/tree/main/passkey-sample). The sample is a React single-page application (SPA) that demonstrates how to sign in users with Microsoft Entra External ID and manage passkey credentials by using the Microsoft Graph API.
 
## User experience

MODIFIED docs/identity/saas-apps/officespace-software-provisioning-tutorial.md

Modified by Regan Downer on Jun 3, 2026 3:50 PM
📖 View on learn.microsoft.com

+1 / -1 lines changed

Commit: Apply suggestion from @v-regandowner

Changes:

Before

After

 
	![Screenshot of Provisioning tab automatic.](common/application-provisioning.png)
 
1. In the **Tenant URL** field, input your OfficeSpace Software Tenant URL (the format should be [https://(YOURTENANTNAME).officespacesoftware.com/api/scim/v2/](https://(YOURTENANTNAME).officespacesoftware.com/api/scim/v2/) ) and Secret Token. Select **Test Connection** to ensure Microsoft Entra ID can connect to OfficeSpace Software. If the connection fails, ensure your OfficeSpace Software account has the required admin permissions and try again.
 
   ![Screenshot of Provisioning test connection.](common/provisioning-test-connection.png)

 
	![Screenshot of Provisioning tab automatic.](common/application-provisioning.png)
 
1. In the **Tenant URL** field, input your OfficeSpace Software Tenant URL (the format should be 'https://(YOURTENANTNAME).officespacesoftware.com/api/scim/v2/') and Secret Token. Select **Test Connection** to ensure Microsoft Entra ID can connect to OfficeSpace Software. If the connection fails, ensure your OfficeSpace Software account has the required admin permissions and try again.
 
   ![Screenshot of Provisioning test connection.](common/provisioning-test-connection.png)

MODIFIED docs/agent-id/agent-access-packages.md

Modified by Regan Downer on Jun 3, 2026 3:02 PM
📖 View on learn.microsoft.com

+1 / -1 lines changed

Commit: Apply suggestion from @Dickson-Mwendia

Changes:

Before

After

1. Select **Next: Resource roles**. On the **Resource roles** tab, you select the resource roles to include in the access package. Access packages for agent identities can have security group memberships, directory roles, or API permissions as resource roles. For more information, see [add a group](/entra/id-governance/entitlement-management-access-package-resources#add-a-group-or-team-resource-role), [add a Microsoft Entra role](/entra/id-governance/entitlement-management-access-package-resources#add-a-microsoft-entra-role-assignment), and [add an API permission](/entra/id-governance/entitlement-management-access-package-resources#add-an-api-permission-preview). Don't add application roles, SAP roles, or SharePoint Online site roles to an access package for agent identities.
 
    > [!TIP]
    > If you're not sure which resource roles to include, you can skip adding them while creating the access package, and then [add them](/entra/id-governance/entitlement-management-access-package-resources) later. For API permissions, resource ownership validation occurs both during onboarding the permissions to an access package and again when adding permissions to an access package. This additional validation helps ensure that only authorized resource owners can introduce or expand access to API Permissions through access packages.
 
1. Select **Next: Requests**. On the **Requests** tab, you create the first policy to specify who can request the access package. in the **Who can get access** section, select **For users, service principals, and agent identities in your directory**. In **Select specific scope**, select the option of **All agents**.

1. Select **Next: Resource roles**. On the **Resource roles** tab, you select the resource roles to include in the access package. Access packages for agent identities can have security group memberships, directory roles, or API permissions as resource roles. For more information, see [add a group](/entra/id-governance/entitlement-management-access-package-resources#add-a-group-or-team-resource-role), [add a Microsoft Entra role](/entra/id-governance/entitlement-management-access-package-resources#add-a-microsoft-entra-role-assignment), and [add an API permission](/entra/id-governance/entitlement-management-access-package-resources#add-an-api-permission-preview). Don't add application roles, SAP roles, or SharePoint Online site roles to an access package for agent identities.
 
    > [!TIP]
    > If you're not sure which resource roles to include, you can skip adding them while creating the access package, and then [add them](/entra/id-governance/entitlement-management-access-package-resources) later. For API permissions, resource ownership validation occurs both when you onboard permissions to an access package and when you add them to an access package. This validation helps ensure that only authorized resource owners can introduce or expand access to API permissions through access packages.
 
1. Select **Next: Requests**. On the **Requests** tab, you create the first policy to specify who can request the access package. in the **Who can get access** section, select **For users, service principals, and agent identities in your directory**. In **Select specific scope**, select the option of **All agents**.

📋 Microsoft Entra Documentation Changes

📊 Summary

📝 Modified Documentation Files