-If you don't already have one, start by setting up a SendGrid account (Azure customers can unlock 25,000 free emails each month). For setup instructions, see the [Create a SendGrid Account](https://docs.sendgrid.com/for-developers/partners/microsoft-azure-2021#create-a-sendgrid-account) section of [How to send email using SendGrid with Azure](https://docs.sendgrid.com/for-developers/partners/microsoft-azure-2021#create-a-twilio-sendgrid-accountcreate-a-twilio-sendgrid-account).

-1. Install the latest version of MSOnline PowerShell Module on a Windows workstation or server.

-For more information, see [Azure Active Directory V2 PowerShell Module](https://www.powershellgallery.com/packages/AzureAD/2.0.2.140)

-2. Connect to the AzureAD PowerShell module and execute the following commands:

-Connect-msolservice #Enter Admin credentials of the Azure portal

-$webApp = Get-MsolServicePrincipal ΓÇôAppPrincipalId ΓÇ£<ClientId of Azure AD Application>ΓÇ¥

-Add-MsolRoleMember -RoleName "Company Administrator" -RoleMemberType ServicePrincipal -RoleMemberObjectId $webApp.ObjectId

-| [Groups](../active-directory/fundamentals/active-directory-groups-create-azure-portal.md) | Groups can be used to manage administrative and user accounts.| Groups can be used to manage administrative accounts. [Consumer accounts](user-overview.md#consumer-user) can't be member of any group, so you can't perform [group-based assignment of enterprise applications](../active-directory/manage-apps/assign-user-or-group-access-portal.md).|

-> **Other Azure resources in your tenant:** <br>In an Azure AD B2C tenant, you can't provision other Azure resources such as virtual machines, Azure web apps, or Azure functions. You must create these resources in your Azure AD tenant.

-## Restrict non-admin users from creating Azure AD B2C tenants (preview)

-## Check tenant creation permission (preview)

-description: Learn more about the benefits of migrating a Classic deployment of Azure Active Directory Domain Services to the Resource Manager deployment model

-# Benefits of migration from the Classic to Resource Manager deployment model in Azure Active Directory Domain Services

-Azure Active Directory Domain Services (Azure AD DS) lets you migrate an existing managed domain that uses the Classic deployment model to the Resource Manager deployment model. Azure AD DS managed domains that use the Resource Manager deployment model provide additional features such as fine-grained password policy, audit logs, and account lockout protection.

-This article outlines the benefits for migration. To get started, see [Migrate Azure AD Domain Services from the Classic virtual network model to Resource Manager][howto-migrate].

-> [!NOTE]

-> In 2017, Azure AD Domain Services became available to host in an Azure Resource Manager network. Since then, we have been able to build a more secure service using the Azure Resource Manager's modern capabilities. Because Azure Resource Manager deployments fully replace classic deployments, Azure AD DS classic virtual network deployments will be retired on March 1, 2023.

->

-> For more information, see the [official deprecation notice](https://azure.microsoft.com/updates/we-are-retiring-azure-ad-domain-services-classic-vnet-support-on-march-1-2023/)

-## Migration benefits

-The migration process takes an existing managed domain that uses the Classic deployment model and moves to use the Resource Manager deployment model. When you migrate a managed domain from the Classic to Resource Manager deployment model, you avoid the need to rejoin machines to the managed domain or delete the managed domain and create one from scratch. VMs continue to be joined to the managed domain at the end of the migration process.

-After migration, Azure AD DS provides many features that are only available for domains using Resource Manager deployment model, such as the following:

-* [Fine-grained password policy support][password-policy].

-* Faster synchronization speeds between Azure AD and Azure AD Domain Services.

-* Two new [attributes that synchronize from Azure AD][attributes] - *manager* and *employeeID*.

-* Access to higher-powered domain controllers when you [upgrade the SKU][skus].

-* AD account lockout protection.

-* [Email notifications for alerts on your managed domain][email-alerts].

-* [Use Azure Workbooks and Azure monitor to view audit logs and sign-in activity][workbooks].

-* In supported regions, [Azure Availability Zones][availability-zones].

-* Integrations with other Azure products such as [Azure Files][azure-files], [HD Insights][hd-insights], and [Azure Virtual Desktop][avd].

-* Support has access to more telemetry and can help troubleshoot more effectively.

-* Encryption at rest using [Azure Managed Disks][managed-disks] for the data on the managed domain controllers.

-Managed domains that use a Resource Manager deployment model help you stay up-to-date with the latest new features. New features aren't available for managed domains that use the Classic deployment model.

-## Next steps

-To get started, see [Migrate Azure AD Domain Services from the Classic virtual network model to Resource Manager][howto-migrate].

-<!-- LINKS - INTERNAL -->

-[password-policy]: password-policy.md

-[skus]: change-sku.md

-[email-alerts]: notifications.md

-[workbooks]: use-azure-monitor-workbooks.md

-[azure-files]: ../storage/files/storage-files-identity-auth-active-directory-domain-service-enable.md

-[hd-insights]: ../hdinsight/domain-joined/apache-domain-joined-configure-using-azure-adds.md

-[avd]: ../virtual-desktop/overview.md

-[availability-zones]: ../reliability/availability-zones-overview.md

-[howto-migrate]: migrate-from-classic-vnet.md

-[attributes]: synchronization.md#attribute-synchronization-and-mapping-to-azure-ad-ds

-[managed-disks]: ../virtual-machines/managed-disks-overview.md

-description: Learn how to migrate an existing Azure AD Domain Services managed domain from the Classic virtual network model to a Resource Manager-based virtual network.

-# Migrate Azure Active Directory Domain Services from the Classic virtual network model to Resource Manager

-Starting April 1, 2023, Azure Active Directory Domain Services (Azure AD DS) has shut down all IaaS virtual machines that host domain controller services for customers who use the Classic virtual network model. Azure AD Domain Services offers a best-effort offline migration solution for customers currently using the Classic virtual network model to the Resource Manager virtual network model. Azure AD DS managed domains that use the Resource Manager deployment model have more features, such as fine-grained password policy, audit logs, and account lockout protection.

-This article outlines considerations for migration, followed by the required steps to successfully migrate an existing managed domain. For some of the benefits, see [Benefits of migration from the Classic to Resource Manager deployment model in Azure AD DS][migration-benefits].

-> [!NOTE]

-> In 2017, Azure AD Domain Services became available to host in an Azure Resource Manager network. Since then, we have been able to build a more secure service using the Azure Resource Manager's modern capabilities. Because Azure Resource Manager deployments fully replace classic deployments, Azure AD DS classic virtual network deployments will be retired on March 1, 2023.

->

-> For more information, see the [official deprecation notice](https://azure.microsoft.com/updates/we-are-retiring-azure-ad-domain-services-classic-vnet-support-on-march-1-2023/).

-## Overview of the migration process

-The offline migration process copies the underlying virtual disks for the domain controllers from the Classic managed domain to create the VMs using the Resource Manager deployment model. The managed domain is then recreated, which includes the LDAPS and DNS configuration. Synchronization to Azure AD is restarted, and LDAP certificates are restored. There's no need to rejoin any machines to a managed domainΓÇôthey continue to be joined to the managed domain and run without changes.

-## Before you begin

-As you prepare for migration, there are some considerations around the availability of authentication and management services. The managed domain remains unavailable until the migration completes successfully.

-> [!IMPORTANT]

-> Read all of this migration article and guidance before you start the migration process. The migration process affects the availability of the Azure AD DS domain controllers for periods of time. Users, services, and applications can't authenticate against the managed domain during the migration process.

-### IP addresses

-The domain controller IP addresses for a managed domain change after migration. This change includes the public IP address for the secure LDAP endpoint. The new IP addresses are inside the address range for the new subnet in the Resource Manager virtual network.

-Azure AD DS typically uses the first two available IP addresses in the address range, but this isn't guaranteed. You can't currently specify the IP addresses to use after migration.

-### Account lockout

-Managed domains that run on Classic virtual networks don't have AD account lockout policies in place. If VMs are exposed to the internet, attackers could use password-spray methods to brute-force their way into accounts. There's no account lockout policy to stop those attempts. For managed domains that use the Resource Manager deployment model and virtual networks, AD account lockout policies protect against these password-spray attacks.

-By default, five (5) bad password attempts in two (2) minutes lock out an account for 30 minutes.

-A locked out account can't be used to sign in, which may interfere with the ability to manage the managed domain or applications managed by the account. After a managed domain is migrated, accounts can experience what feels like a permanent lockout due to repeated failed attempts to sign in. Two common scenarios after migration include the following:

-* A service account that's using an expired password.

- * The service account repeatedly tries to sign in with an expired password, which locks out the account. To fix this, locate the application or VM with expired credentials and update the password.

-* A malicious entity is using brute-force attempts to sign in to accounts.

- * When VMs are exposed to the internet, attackers often try common username and password combinations as they attempt to sign. These repeated failed sign-in attempts can lock out the accounts. It's not recommended to use administrator accounts with generic names such as *admin* or *administrator*, for example, to minimize administrative accounts from being locked out.

- * Minimize the number of VMs that are exposed to the internet. You can use [Azure Bastion][azure-bastion] to securely connect to VMs using the Azure portal.

-If you suspect that some accounts may be locked out after migration, the final migration steps outline how to enable auditing or change the fine-grained password policy settings.

-### Restrictions on available virtual networks

-There are some restrictions on the virtual networks that a managed domain can be migrated to. The destination Resource Manager virtual network must meet the following requirements:

-* The Resource Manager virtual network must be in the same Azure subscription as the Classic virtual network that Azure AD DS is currently deployed in.

-* The Resource Manager virtual network must be in the same region as the Classic virtual network that Azure AD DS is currently deployed in.

-* The Resource Manager virtual network's subnet should have at least 3-5 available IP addresses.

-* The Resource Manager virtual network's subnet should be a dedicated subnet for Azure AD DS, and shouldn't host any other workloads.

-For more information on virtual network requirements, see [Virtual network design considerations and configuration options][network-considerations].

-You must also create a network security group to restrict traffic in the virtual network for the managed domain. An Azure standard load balancer is created during the migration process that requires these rules to be place. This network security group secures Azure AD DS and is required for the managed domain to work correctly.

-For more information on what rules are required, see [Azure AD DS network security groups and required ports](network-considerations.md#network-security-groups-and-required-ports).

-## Migration steps

-The migration to the Resource Manager deployment model and virtual network is split into four main steps:

-| Step | Performed through | Estimated time | Downtime |

-||--|--|--|

-| [Step 1 - Update and locate the new virtual network](#update-and-verify-virtual-network-settings) | Azure portal | 15 minutes | |

-| [Step 2 - Perform offline migration](#perform-offline-migration) | PowerShell | 1 ΓÇô 3 hours on average | One domain controller is available once this command is completed. |

-| [Step 3 - Test and wait for the replica domain controller](#test-and-verify-connectivity-after-the-migration)| PowerShell and Azure portal | 1 hour or more, depending on the number of tests | Both domain controllers are available and should function normally, downtime ends. |

-| [Step 4 - Optional configuration steps](#optional-post-migration-configuration-steps) | Azure portal and VMs | N/A | |

-> [!IMPORTANT]

-> To avoid additional downtime, read all of this migration article and guidance before you start the migration process. The migration process affects the availability of the Azure AD DS domain controllers for a period of time. Users, services, and applications can't authenticate against the managed domain during the migration process.

-## Update and verify virtual network settings

-Before you begin the migration process, complete the following initial checks and updates. These steps can happen at any time before the migration and don't affect the operation of the managed domain.

-1. Update your local Azure PowerShell environment to the latest version. To complete the migration steps, you need at least version *2.3.2*.

- For information about how to check and update your PowerShell version, see [Azure PowerShell overview][azure-powershell].

-1. Create, or choose an existing, Resource Manager virtual network.

- Make sure that network settings don't block ports required for Azure AD DS. Ports must be open on both the Classic virtual network and the Resource Manager virtual network. These settings include route tables (although it's not recommended to use route tables) and network security groups.

- Azure AD DS needs a network security group to secure the ports needed for the managed domain and block all other incoming traffic. This network security group acts as an extra layer of protection to lock down access to the managed domain.

- The following network security group Inbound rules are required for the managed domain to provide authentication and management services. Don't edit or delete these network security group rules for the virtual network subnet your managed domain is deployed into.

- | Source | Source service tag | Source port ranges | Destination | Service | Destination port ranges | Protocol | Action | Required | Purpose |

- |:--:|:-:|::|:-:|:-:|:--:|:--:|::|:--:|:--|

- | Service tag | AzureActiveDirectoryDomainServices | * | Any | WinRM | 5986 | TCP | Allow | Yes | Management of your domain |

- | Service tag | CorpNetSaw | * | Any | RDP | 3389 | TCP | Allow | Optional | Debugging for support |

-

- Make a note of the target resource group, target virtual network, and target virtual network subnet. These resource names are used during the migration process.

- > [!NOTE]

- > The **CorpNetSaw** service tag isn't available by using Azure portal, and the network security group rule for **CorpNetSaw** has to be added by using [PowerShell](powershell-create-instance.md#create-a-network-security-group).

-1. Check the managed domain health in the Azure portal. If you have any alerts for the managed domain, resolve them before you start the migration process.

-1. Optionally, if you plan to move other resources to the Resource Manager deployment model and virtual network, confirm that those resources can be migrated. For more information, see [Platform-supported migration of IaaS resources from Classic to Resource Manager][migrate-iaas].

- > [!NOTE]

- > Don't convert the Classic virtual network to a Resource Manager virtual network. If you do, there's no option to roll back or restore the managed domain.

-## Perform offline migration

-Azure PowerShell is used to perform offline migration of the managed domain:

-1. Install the `Migrate-Aaads` script from the [PowerShell Gallery][powershell-script]. This PowerShell migration script is a digitally signed by the Azure AD engineering team.

- ```powershell

- Install-Script -Name Migrate-Aadds

- ```

-2. Create a variable to hold the credentials for by the migration script using the [Get-Credential][get-credential] cmdlet.

- The user account you specify needs [Application Administrator](../active-directory/roles/permissions-reference.md#application-administrator) and [Groups Administrator](../active-directory/roles/permissions-reference.md#groups-administrator) Azure AD roles in your tenant to enable Azure AD DS and [Domain Services Contributor](../role-based-access-control/built-in-roles.md#contributor) Azure role to create the required Azure AD DS resources.

- When prompted, enter an appropriate user account and password:

- ```powershell

- $creds = Get-Credential

- ```

-

-3. Define a variable for your Azure subscription ID. If needed, you can use the [Get-AzSubscription](/powershell/module/az.accounts/get-azsubscription) cmdlet to list and view your subscription IDs. Provide your own subscription ID in the following command:

- ```powershell

- $subscriptionId = 'yourSubscriptionId'

- ```

-4. Now run the `Migrate-Aadds` cmdlet using the *-Offline* parameter. Provide the *-ManagedDomainFqdn* for your own managed domain, such as *aaddscontoso.com*. Specify the target resource group that contains the virtual network you want to migrate Azure AD DS to, such as *myResourceGroup*. Provide the target virtual network, such as *myVnet*, and the subnet, such as *DomainServices*. This step can take 1 to 3 hours to complete.

- ```powershell

- Migrate-Aadds `

- -Offline `

- -ManagedDomainFqdn aaddscontoso.com `

- -VirtualNetworkResourceGroupName myResourceGroup `

- -VirtualNetworkName myVnet `

- -VirtualSubnetName DomainServices `

- -Credentials $creds `

- -SubscriptionId $subscriptionId

- ```

-> [!IMPORTANT]

-> As part of the offline migration workflow, you cannot convert the Classic virtual network to a Resource Manager virtual network.

-Every two minutes during the migration process, a progress indicator reports the current status, as shown in the following example output:

-

-The migration process continues to run, even if you close out the PowerShell script. In the Azure portal, the status of the managed domain reports as *Migrating*.

-When the migration successfully completes, you can view your first domain controller's IP address in the Azure portal or through Azure PowerShell. A time estimate on the second domain controller being available is also shown.

-At this stage, you can optionally move other existing resources from the Classic deployment model and virtual network. Or, you can keep the resources on the Classic deployment model and peer the virtual networks to each other after the Azure AD DS migration is complete.

-## Test and verify connectivity after the migration

-It can take some time for the second domain controller to successfully deploy and be available for use in the managed domain. The second domain controller should be available 1-2 hours after the migration cmdlet finishes. With the Resource Manager deployment model, the network resources for the managed domain are shown in the Azure portal or Azure PowerShell. To check if the second domain controller is available, look at the **Properties** page for the managed domain in the Azure portal. If two IP addresses shown, the second domain controller is ready.

-After the second domain controller is available, complete the following configuration steps for network connectivity with VMs:

-* **Update DNS server settings** To let other resources on the Resource Manager virtual network resolve and use the managed domain, update the DNS settings with the IP addresses of the new domain controllers. The Azure portal can automatically configure these settings for you.

- To learn more about how to configure the Resource Manager virtual network, see [Update DNS settings for the Azure virtual network][update-dns].

-* **Restart domain-joined VMs (optional)** As the DNS server IP addresses for the Azure AD DS domain controllers change, you can restart any domain-joined VMs so they then use the new DNS server settings. If applications or VMs have manually configured DNS settings, manually update them with the new DNS server IP addresses of the domain controllers that are shown in the Azure portal. Rebooting domain-joined VMs prevents connectivity issues caused by IP addresses that donΓÇÖt refresh.

-Now test the virtual network connection and name resolution. On a VM that's connected to the Resource Manager virtual network, or peered to it, try the following network communication tests:

-1. Check if you can ping the IP address of one of the domain controllers, such as `ping 10.1.0.4`

- * The IP addresses of the domain controllers are shown on the **Properties** page for the managed domain in the Azure portal.

-1. Verify name resolution of the managed domain, such as `nslookup aaddscontoso.com`

- * Specify the DNS name for your own managed domain to verify that the DNS settings are correct and resolves.

-To learn more about other network resources, see [Network resources used by Azure AD DS][network-resources].

-## Optional post-migration configuration steps

-When the migration process is successfully complete, some optional configuration steps include enabling audit logs or e-mail notifications, or updating the fine-grained password policy.

-### Subscribe to audit logs using Azure Monitor

-Azure AD DS exposes audit logs to help troubleshoot and view events on the domain controllers. For more information, see [Enable and use audit logs][security-audits].

-You can use templates to monitor important information exposed in the logs. For example, the audit log workbook template can monitor possible account lockouts on the managed domain.

-### Configure email notifications

-To be notified when a problem is detected on the managed domain, update the email notification settings in the Azure portal. For more information, see [Configure notification settings][notifications].

-### Update fine-grained password policy

-If needed, you can update the fine-grained password policy to be less restrictive than the default configuration. You can use the audit logs to determine if a less restrictive setting makes sense, then configure the policy as needed. Use the following high-level steps to review and update the policy settings for accounts that are repeatedly locked out after migration:

-1. [Configure password policy][password-policy] for fewer restrictions on the managed domain and observe the events in the audit logs.

-1. If any service accounts are using expired passwords as identified in the audit logs, update those accounts with the correct password.

-1. If a VM is exposed to the internet, review for generic account names like *administrator*, *user*, or *guest* with high sign-in attempts. Where possible, update those VMs to use less generically named accounts.

-1. Use a network trace on the VM to locate the source of the attacks and block those IP addresses from being able to attempt sign-ins.

-1. When there are minimal lockout issues, update the fine-grained password policy to be as restrictive as necessary.

-## Troubleshooting

-If you have problems after migration to the Resource Manager deployment model, review some of the following common troubleshooting areas:

-* [Troubleshoot domain-join problems][troubleshoot-domain-join]

-* [Troubleshoot account lockout problems][troubleshoot-account-lockout]

-* [Troubleshoot account sign-in problems][troubleshoot-sign-in]

-* [Troubleshoot secure LDAP connectivity problems][tshoot-ldaps]

-## Next steps

-With your managed domain migrated to the Resource Manager deployment model, [create and domain-join a Windows VM][join-windows] and then [install management tools][tutorial-create-management-vm].

-<!-- INTERNAL LINKS -->

-[azure-bastion]: ../bastion/bastion-overview.md

-[network-considerations]: network-considerations.md

-[azure-powershell]: /powershell/azure/

-[network-ports]: network-considerations.md#network-security-groups-and-required-ports

-[Connect-AzAccount]: /powershell/module/az.accounts/connect-azaccount

-[Set-AzContext]: /powershell/module/az.accounts/set-azcontext

-[Get-AzResource]: /powershell/module/az.resources/get-azresource

-[Set-AzResource]: /powershell/module/az.resources/set-azresource

-[network-resources]: network-considerations.md#network-resources-used-by-azure-ad-ds

-[update-dns]: tutorial-create-instance.md#update-dns-settings-for-the-azure-virtual-network

-[azure-support]: ../active-directory/fundamentals/active-directory-troubleshooting-support-howto.md

-[security-audits]: security-audit-events.md

-[notifications]: notifications.md

-[password-policy]: password-policy.md

-[secure-ldap]: tutorial-configure-ldaps.md

-[migrate-iaas]: ../virtual-machines/migration-classic-resource-manager-overview.md

-[join-windows]: join-windows-vm.md

-[tutorial-create-management-vm]: tutorial-create-management-vm.md

-[troubleshoot-domain-join]: troubleshoot-domain-join.md

-[troubleshoot-account-lockout]: troubleshoot-account-lockout.md

-[troubleshoot-sign-in]: troubleshoot-sign-in.md

-[tshoot-ldaps]: tshoot-ldaps.md

-[get-credential]: /powershell/module/microsoft.powershell.security/get-credential

-[migration-benefits]: concepts-migration-benefits.md

-<!-- EXTERNAL LINKS -->

-[powershell-script]: https://www.powershellgallery.com/packages/Migrate-Aadds/

-> Password policies are only available for managed domains created using the Resource Manager deployment model. For older managed domains created using Classic, [migrate from the Classic virtual network model to Resource Manager][migrate-from-classic].

- * The managed domain must have been created using the Resource Manager deployment model. If needed, [Migrate from the Classic virtual network model to Resource Manager][migrate-from-classic].

-[tutorial-create-management-vm]: tutorial-create-management-vm.md

-[migrate-from-classic]: migrate-from-classic-vnet.md

-| DNS Server|Audits changes to DNS environments. This category includes the following subcategories: <br>- [DNSServerAuditsDynamicUpdates (preview)](https://learn.microsoft.com/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn800669(v=ws.11)#audit-and-analytic-event-logging)<br>- [DNSServerAuditsGeneral (preview)](https://learn.microsoft.com/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn800669(v=ws.11)#audit-and-analytic-event-logging)|

-<!-- LINKS - Internal -->

-[migrate-azure-adds]: migrate-from-classic-vnet.md

- - AppRoleAssignmentsComplex isn't compatible with setting scope to "Sync All users and groups."

->[!NOTE]

->Hardware OATH tokens and security questions can only be enabled today by using these legacy policies. In the future, these methods will be available in the Authentication methods policy.

->Controls in the Authentication methods policy for Hardware OATH tokens and security questions are coming soon, but not yet available. If you are using hardware OATH tokens, which are currently in public preview, you should hold off on migrating OATH tokens and do not complete the migration process. If you are using security questions, and don't want to disable them, make sure to keep them enabled in the legacy SSPR policy until the new control is available in the future.

-| Microsoft Authenticator | Yes | MFA and SSPR |

-

-Once properly formatted as a CSV file, a global administrator can then sign in to the Azure portal, navigate to **Azure Active Directory** > **Security** > **Multifactor authentication** > **OATH tokens**, and upload the resulting CSV file.

-The following table provides a list of the features that are available in the various versions of Azure AD Multi-Factor Authentication. Plan out your needs for securing user authentication, then determine which approach meets those requirements. For example, although Azure AD Free provides security defaults that provide Azure AD Multi-Factor Authentication, only the mobile authenticator app can be used for the authentication prompt, not a phone call or SMS. This approach may be a limitation if you can't ensure the mobile authentication app is installed on a user's personal device. See [Azure AD Free tier](#azure-ad-free-tier) later in this topic for more details.

-| Phone call as a second factor | | ΓùÅ | ΓùÅ | ΓùÅ | ΓùÅ |

-| Identity Protection (Risky sign-ins, risky users) | | | | | ΓùÅ |

-| Access Reviews | | | | | ΓùÅ |

-| Entitlements Management | | | | | ΓùÅ |

-| Privileged Identity Management (PIM), just-in-time access | | | | | ΓùÅ |

-| Lifecycle Workflows (preview) | | | | | ΓùÅ |

-# How to enable Microsoft Authenticator Lite for Outlook mobile (preview)

->This is an important security enhancement for users authenticating via telecom transports. The 'Microsoft managed' setting for this feature will be set to enabled on May 26th, 2023. This will enable the feature for all users in tenants where the feature is set to Microsoft managed. If you wish to change the state of this feature, please do so before May 26th, 2023.

-By default, Authenticator Lite is [Microsoft managed](concept-authentication-default-enablement.md#microsoft-managed-settings) and disabled during preview. After general availability, the Microsoft managed state default value will change to enable Authenticator Lite.

-## Known Issues (Public preview)

-### Conditional Access Registration Policies

-CA policies for registration do not currently apply in Outlook registration flows.

-The following diagram shows the process of this migration.

-

-To create new conditional access policies, you'll need to assign those policies to groups. You can use existing Azure AD security groups or Microsoft 365 Groups for this purpose. You can also create or sync new ones.

-> [!NOTE]

-> Claims rules require on-premises security group. Before making changes to claims rules, back them up.

-#### Back up existing rules

-Before configuring new claims rules, back up your existing rules. You'll need to restore these rules as a part of your cleanup steps.

-Depending on your configuration, you may also need to copy the existing rule and append the new rules being created for the migration.

-To view existing global rules, run:

-To view existing relying party trusts, run the following command and replace RPTrustName with the name of the relying party trust claims rule:

-

- > [!IMPORTANT]

-> Backup your existing claims rules

->[!NOTE]

-> The **federatedIdpMfaBehavior** setting is an evolved version of the **SupportsMfa** property of the [Set-MsolDomainFederationSettings MSOnline v1 PowerShell cmdlet](/powershell/module/msonline/set-msoldomainfederationsettings).

-For domains that have already set the **SupportsMfa** property, these rules determine how **federatedIdpMfaBehavior** and **SupportsMfa** work together:

-You can also check the status of your **SupportsMfa** flag with [Get-MsolDomainFederationSettings](/powershell/module/msonline/get-msoldomainfederationsettings):

-Get-MsolDomainFederationSettings ΓÇôDomainName yourdomain.com

-> [!NOTE]

-> Users who MUST register their combined security information from a non-trusted location or device can be issued a Temporary Access Pass or alternatively, temporarily excluded from the policy.

-

-description: Step-by-step guidance to move from MFA Server on-premises to Azure AD MFA and Azure AD user authentication

-Multi-factor authentication (MFA) helps secure your infrastructure and assets from bad actors.

-Microsoft's Multi-Factor Authentication Server (MFA Server) is no longer offered for new deployments.

-Customers who are using MFA Server should move to Azure AD Multi-Factor Authentication (Azure AD MFA).

-As users are migrated to cloud authentication, they'll start using Azure AD MFA as defined by your existing Conditional Access policies.

-#### Back up existing rules

-Before configuring new claims rules, back up your existing rules.

-You'll need to restore claims rules as a part of your cleanup steps.

-To view existing global rules, run:

-To view existing relying party trusts, run the following command and replace RPTrustName with the name of the relying party trust claims rule:

-

-The following PowerShell cmdlets invoke Azure AD MFA for users in the group when they aren't on the corporate network.

-You must replace `"YourGroupSid"` with the SID found by running the preceding cmdlet.

->Backup your existing claims rules before proceeding.

-In order to configure Azure AD MFA for AD FS, you must configure each AD FS server.

-If multiple AD FS servers are in your farm, you can configure them remotely using Azure AD PowerShell.

-If you migrate all your application authentication along with your MFA and user authentication, you'll be able to remove significant portions of your on-premises infrastructure, reducing costs and risks.

-## Known Issues

-### Federated Accounts

-The [Azure AD MFA NPS Extension health check script](/samples/azure-samples/azure-mfa-nps-extension-health-check/azure-mfa-nps-extension-health-check/) performs a basic health check when troubleshooting the NPS extension. Run the script and choose option **1** to isolate the cause of the potential issue.

-To collect debug logs for support diagnostics, run the [Azure AD MFA NPS Extension health check script](/samples/azure-samples/azure-mfa-nps-extension-health-check/azure-mfa-nps-extension-health-check/) on the NPS server and choose option **4** to collect logs.

-At the end, zip the contents of the C:\NPS folder and attach the zipped file to the support case.

-| Software |<li>Windows Server 2016</li><li>Windows Server 2012 R2</li><li>Windows Server 2012</li><li>Windows Server 2008/R2 (with [ESU](/lifecycle/faq/extended-security-updates) only)</li><li>Windows 10</li><li>Windows 8.1, all editions</li><li>Windows 8, all editions</li><li>Windows 7, all editions (with [ESU](/lifecycle/faq/extended-security-updates) only)</li><li>Microsoft .NET 4.0 Framework</li><li>IIS 7.0 or greater if installing the user portal or web service SDK</li> |

- 

-www-authenticate =Bearer realm="", authorization_uri="https://login.microsoftonline.com/common/oauth2/authorize", error="insufficient_claims", claims="eyJhY2Nlc3NfdG9rZW4iOnsiYWNycyI6eyJlc3NlbnRpYWwiOnRydWUsInZhbHVlIjoiYzEifX19"

- odatatype = "microsoft.graph.provideClaimsForToken";

-|`email` | String | The `email` claim is present by default for guest accounts that have an email address. Your app can request the email claim for managed users (those from the same tenant as the resource) using the `email` [optional claim](active-directory-optional-claims.md). On the v2.0 endpoint, your app can also request the `email` OpenID Connect scope - you don't need to request both the optional claim and the scope to get the claim.|

-Shared device mode allows you to configure an iOS 13 or higher device to be more easily and securely shared by employees. Employees can sign in and access customer information quickly. When they're finished with their shift or task, they can sign out of the device, and it's immediately ready for use by the next employee.

-Shared device mode also provides Microsoft identity-backed management of the device.

-This feature uses the [Microsoft Authenticator app](https://support.microsoft.com/account-billing/how-to-use-the-microsoft-authenticator-app-9783c865-0308-42fb-a519-8cf666fe0acc) to manage the users on the device and to distribute the [Microsoft Enterprise SSO plug-in for Apple devices](apple-sso-plugin.md).

-## Create a shared device mode app

-To create a shared device mode app, developers and cloud device admins work together:

-1. **Application developers** write a single-account app (multiple-account apps aren't supported in shared device mode) and write code to handle things like shared device sign-out.

-1. **Device administrators** prepare the device to be shared by using a mobile device management (MDM) provider like Microsoft Intune to manage the devices in their organization. The MDM pushes the Microsoft Authenticator app to the devices and turns on "Shared Mode" for each device through a profile update to the device. This Shared Mode setting is what changes the behavior of the supported apps on the device. This configuration from the MDM provider sets the shared device mode for the device and enables the [Microsoft Enterprise SSO plug-in for Apple devices](apple-sso-plugin.md) which is required for shared device mode.

-1. [**Required during Public Preview only**] A user with [Cloud Device Administrator](../roles/permissions-reference.md#cloud-device-administrator) role must then launch the [Microsoft Authenticator app](https://support.microsoft.com/account-billing/how-to-use-the-microsoft-authenticator-app-9783c865-0308-42fb-a519-8cf666fe0acc) and join their device to the organization.

- To configure the membership of your organizational roles in the Azure portal: **Azure Active Directory** > **Roles and Administrators** > **Cloud Device Administrator**

-The following sections help you update your application to support shared device mode.

-## Use Intune to enable shared device mode & SSO extension

-> [!NOTE]

-> The following step is required only during public preview.

-Your device needs to be configured to support shared device mode. It must have iOS 13+ installed and be MDM-enrolled. MDM configuration also needs to enable [Microsoft Enterprise SSO plug-in for Apple devices](apple-sso-plugin.md). To learn more about SSO extensions, see the [Apple video](https://developer.apple.com/videos/play/tech-talks/301/).

-1. In the Intune Configuration Portal, tell the device to enable the [Microsoft Enterprise SSO plug-in for Apple devices](apple-sso-plugin.md) with the following configuration:

- - **Type**: Redirect

- - **Extension ID**: com.microsoft.azureauthenticator.ssoextension

- - **Team ID**: (this field isn't needed for iOS)

- - **URLs**:

- - `https://login.microsoftonline.com`

- - `https://login.microsoft.com`

- - `https://sts.windows.net`

- - `https://login.partner.microsoftonline.cn`

- - `https://login.chinacloudapi.cn`

- - `https://login.microsoftonline.de`

- - `https://login.microsoftonline.us`

- - `https://login.usgovcloudapi.net`

- - `https://login-us.microsoftonline.com`

- - **Additional Data to configure**:

- - Key: sharedDeviceMode

- - Type: Boolean

- - Value: true

- For more information about configuring with Intune, see the [Intune configuration documentation](/intune/configuration/ios-device-features-settings).

-1. Next, configure your MDM to push the Microsoft Authenticator app to your device through an MDM profile.

- Set the following configuration options to turn on Shared Device mode:

- - Configuration 1:

- - Key: sharedDeviceMode

- - Type: Boolean

- - Value: true

-Detecting shared device mode is important for your application. Many applications will require a change in their user experience (UX) when the application is used on a shared device. For example, your application might have a "Sign-Up" feature, which isn't appropriate for a frontline worker because they likely already have an account. You may also want to add extra security to your application's handling of data if it's in shared device mode.

-The following code removes the signed-in account and clears cached tokens from not only the app, but also from the device that's in shared device mode. It doesn't, however, clear the _data_ from your application. You must clear the data from your application, as well as clear any cached data your application may be displaying to the user.

-The [Microsoft Enterprise SSO plug-in for Apple devices](apple-sso-plugin.md) clears state only for applications. It doesn't clear state on the Safari browser. You can use the optional signoutFromBrowser property shown in code snippets above to trigger a browser signout in Safari. This will cause the browser to briefly launch on the device.

-To receive the account change broadcast, you'll need to register a broadcast receiver. When an account change broadcast is received, immediately [get the signed in user and determine if a user has changed on the device](#get-the-signed-in-user-and-determine-if-a-user-has-changed-on-the-device). If a change is detected, initiate data cleanup for previously signed-in account. It's recommended to properly stop any operations and do data cleanup.

-NSString *const MSID_SHARED_MODE_CURRENT_ACCOUNT_CHANGED_NOTIFICATION_KEY = @"SHARED_MODE_CURRENT_ACCOUNT_CHANGED";

- (CFStringRef)MSID_SHARED_MODE_CURRENT_ACCOUNT_CHANGED_NOTIFICATION_KEY,ΓÇ»

-For more information about the available options for CFNotificationAddObserver or to see the corresponding method signatures in Swift, see:

-For iOS, your app will require a background permission to remain active in the background and listen to Darwin notifications. The background capability must be added to support a different background operation ΓÇô your app may be subject to rejection from the Apple App Store if it has a background capability only to listen for Darwin notifications. If your app is already configured to complete background operations, you can add the listener as part of that operation. For more information about iOS background capabilities, see [Configuring background execution modes](https://developer.apple.com/documentation/xcode/configuring-background-execution-modes)

-Using the [microsoft-identity-express](https://github.com/Azure-Samples/microsoft-identity-express) package, the web app gets the user's access token from the incoming requests header. microsoft-identity-express detects that the web app is hosted on App Service and gets the access token from the App Service authentication/authorization module. The access token is then passed down to the Microsoft Graph SDK client to make an authenticated request to the `/me` endpoint.

-> The microsoft-identity-express package isn't required in your web app for basic authentication/authorization or to authenticate requests with Microsoft Graph. It's possible to [securely call downstream APIs](../../app-service/tutorial-auth-aad.md#call-api-securely-from-server-code) with only the App Service authentication/authorization module enabled.

->

-> However, the App Service authentication/authorization is designed for more basic authentication scenarios. Later, when your web app needs to handle more complex scenarios, you can disable the App Service authentication/authorization module and microsoft-identity-express will already be a part of your app.

-| Admin revokes all refresh tokens for a user [via PowerShell](/powershell/module/azuread/revoke-azureaduserallrefreshtoken) | Revoked | Revoked | Revoked | Revoked | Revoked |

-> In this quickstart, you download and run a code sample that demonstrates how a Angular single-page application (SPA) can sign in users with Azure Active Directory for customers.

-> 1. Unzip the sample app, `cd` into the folder that contains `package.json`, then run the following commands:

-> npm install && npm start

->

-> 1. Unzip the sample app, `cd` into the folder that contains `package.json`, then run the following commands:

-> npm install && npm start

-> 1. Unzip the sample app, `cd` into the app root folder, then run the following command:

-> npm install && npm start

-> * Register the application in the Azure portal

-> * Create an Angular project with `npm`

-> * Add code to support user sign-in and sign-out

-> * Add code to call Microsoft Graph API

-> * Test the app

-* [Node.js](https://nodejs.org/en/download/) for running a local web server.

-* [Visual Studio Code](https://code.visualstudio.com/download) or other editor for modifying project files.

-|Library|Description|

-|||

-|[MSAL Angular](https://github.com/AzureAD/microsoft-authentication-library-for-js/tree/dev/lib/msal-angular)|Microsoft Authentication Library for JavaScript Angular Wrapper|

-|[MSAL Browser](https://github.com/AzureAD/microsoft-authentication-library-for-js/tree/dev/lib/msal-browser)|Microsoft Authentication Library for JavaScript v2 browser package |

-1. Enter a **Name** for the application, such as *Angular-SPA-auth-code*.

- 1. You may need to switch terminal types. Select the down arrow next to the **+** icon in the terminal and select **Command Prompt**.

-1. Run the following commands to create a new Angular project with the name *msal-angular-tutorial*, install Angular Material component libraries, MSAL Browser, MSAL Angular and generate home and profile components.

- ```cmd

- npm install -g @angular/cli

- ng new msal-angular-tutorial --routing=true --style=css --strict=false

- cd msal-angular-tutorial

- npm install @angular/material @angular/cdk

- npm install @azure/msal-browser @azure/msal-angular

- ng generate component home

- ng generate component profile

- ```

-1. Open *src/app/app.module.ts*. The `MsalModule` and `MsalInterceptor` need to be added to `imports` along with the `isIE` constant. You'll also add the material modules. Replace the entire contents of the file with the following snippet:

- ```javascript

- import { BrowserModule } from '@angular/platform-browser';

- import { BrowserAnimationsModule } from '@angular/platform-browser/animations';

- import { NgModule } from '@angular/core';

- import { MatButtonModule } from '@angular/material/button';

- import { MatToolbarModule } from '@angular/material/toolbar';

- import { MatListModule } from '@angular/material/list';

- import { AppRoutingModule } from './app-routing.module';

- import { AppComponent } from './app.component';

- import { HomeComponent } from './home/home.component';

- import { ProfileComponent } from './profile/profile.component';

- import { MsalModule, MsalRedirectComponent} from '@azure/msal-angular';

- import { PublicClientApplication } from '@azure/msal-browser';

- const isIE = window.navigator.userAgent.indexOf('MSIE ') > -1 || window.navigator.userAgent.indexOf('Trident/') > -1;

- @NgModule({

- declarations: [

- AppComponent,

- HomeComponent,

- ProfileComponent

- ],

- imports: [

- BrowserModule,

- BrowserAnimationsModule,

- AppRoutingModule,

- MatButtonModule,

- MatToolbarModule,

- MatListModule,

- MsalModule.forRoot( new PublicClientApplication({

- auth: {

- clientId: 'Enter_the_Application_Id_here', // Application (client) ID from the app registration

- authority: 'Enter_the_Cloud_Instance_Id_Here/Enter_the_Tenant_Info_Here', // The Azure cloud instance and the app's sign-in audience (tenant ID, common, organizations, or consumers)

- redirectUri: 'Enter_the_Redirect_Uri_Here'// This is your redirect URI

- },

- cache: {

- cacheLocation: 'localStorage',

- storeAuthStateInCookie: isIE, // Set to true for Internet Explorer 11

- }

- }), null, null)

- ],

- providers: [],

- bootstrap: [AppComponent, MsalRedirectComponent]

- })

- export class AppModule { }

- ```

- - `clientId` - The identifier of the application, also referred to as the client. Replace `Enter_the_Application_Id_Here` with the **Application (client) ID** value that was recorded earlier from the overview page of the registered application.

- - `authority` - This is composed of two parts:

- - The *Instance* is endpoint of the cloud provider. For the main or global Azure cloud, enter `https://login.microsoftonline.com`. Check with the different available endpoints in [National clouds](authentication-national-cloud.md#azure-ad-authentication-endpoints).

- - The *Tenant ID* is the identifier of the tenant where the application is registered. Replace the `_Enter_the_Tenant_Info_Here` with the **Directory (tenant) ID** value that was recorded earlier from the overview page of the registered application.

- - `redirectUri` - the location where the authorization server sends the user once the app has been successfully authorized and granted an authorization code or access token. Replace `Enter_the_Redirect_Uri_Here` with `http://localhost:4200`.

-1. Open *src/app/app-routing.module.ts* and add routes to the *home* and *profile* components. Replace the entire contents of the file with the following snippet:

- ```javascript

- import { NgModule } from '@angular/core';

- import { Routes, RouterModule } from '@angular/router';

- import { BrowserUtils } from '@azure/msal-browser';

- import { HomeComponent } from './home/home.component';

- import { ProfileComponent } from './profile/profile.component';

- const routes: Routes = [

- {

- path: 'profile',

- component: ProfileComponent,

- },

- {

- path: '',

- component: HomeComponent

- },

- ];

- const isIframe = window !== window.parent && !window.opener;

- @NgModule({

- imports: [RouterModule.forRoot(routes, {

- // Don't perform initial navigation in iframes or popups

- initialNavigation: !BrowserUtils.isInIframe() && !BrowserUtils.isInPopup() ? 'enabledNonBlocking' : 'disabled' // Set to enabledBlocking to use Angular Universal

- })],

- exports: [RouterModule]

- })

- export class AppRoutingModule { }

- ```

-1. Open *src/app/app.component.html* and replace the existing code with the following:

- ```HTML

- <mat-toolbar color="primary">

- <a class="title" href="/">{{ title }}</a>

- <div class="toolbar-spacer"></div>

- <a mat-button [routerLink]="['profile']">Profile</a>

- <button mat-raised-button *ngIf="!loginDisplay" (click)="login()">Login</button>

- </mat-toolbar>

- <div class="container">

- <!--This is to avoid reload during acquireTokenSilent() because of hidden iframe -->

- <router-outlet *ngIf="!isIframe"></router-outlet>

- </div>

- ```

-1. Open *src/style.css* to define the CSS:

- ```css

- @import '~@angular/material/prebuilt-themes/deeppurple-amber.css';

- html, body { height: 100%; }

- body { margin: 0; font-family: Roboto, "Helvetica Neue", sans-serif; }

- .container { margin: 1%; }

- ```

-4. Open *src/app/app.component.css* to add CSS styling to the application:

- ```css

- .toolbar-spacer {

- flex: 1 1 auto;

- }

-

- a.title {

- color: white;

- }

- ```

-1. Open *src/app/app.component.ts* and replace the contents of the file to the following to sign in a user using a pop-up window:

- ```javascript

- import { MsalService } from '@azure/msal-angular';

- import { Component, OnInit } from '@angular/core';

- @Component({

- selector: 'app-root',

- templateUrl: './app.component.html',

- styleUrls: ['./app.component.css']

- })

- export class AppComponent implements OnInit {

- title = 'msal-angular-tutorial';

- isIframe = false;

- loginDisplay = false;

- constructor(private authService: MsalService) { }

- ngOnInit() {

- this.isIframe = window !== window.parent && !window.opener;

- }

- login() {

- this.authService.loginPopup()

- .subscribe({

- next: (result) => {

- console.log(result);

- this.setLoginDisplay();

- },

- error: (error) => console.log(error)

- });

- }

- setLoginDisplay() {

- this.loginDisplay = this.authService.instance.getAllAccounts().length > 0;

- }

- }

- ```

-1. Update *src/app/app.module.ts* to bootstrap the `MsalRedirectComponent`. This is a dedicated redirect component, which handles redirects. Change the `MsalModule` import and `AppComponent` bootstrap to resemble the following:

- ```javascript

- ...

- import { MsalModule, MsalRedirectComponent } from '@azure/msal-angular'; // Updated import

- ...

- bootstrap: [AppComponent, MsalRedirectComponent] // MsalRedirectComponent bootstrapped here

- ...

- ```

-2. Open *src/https://docsupdatetracker.net/index.html* and replace the entire contents of the file with the following snippet, which adds the `<app-redirect>` selector:

- ```HTML

- <!doctype html>

- <html lang="en">

- <head>

- <meta charset="utf-8">

- <title>msal-angular-tutorial</title>

- <base href="/">

- <meta name="viewport" content="width=device-width, initial-scale=1">

- <link rel="icon" type="image/x-icon" href="favicon.ico">

- </head>

- <body>

- <app-root></app-root>

- <app-redirect></app-redirect>

- </body>

- </html>

- ```

-3. Open *src/app/app.component.ts* and replace the code with the following to sign in a user using a full-frame redirect:

- ```javascript

- import { MsalService } from '@azure/msal-angular';

- import { Component, OnInit } from '@angular/core';

- @Component({

- selector: 'app-root',

- templateUrl: './app.component.html',

- styleUrls: ['./app.component.css']

- })

- export class AppComponent implements OnInit {

- title = 'msal-angular-tutorial';

- isIframe = false;

- loginDisplay = false;

- constructor(private authService: MsalService) { }

- ngOnInit() {

- this.isIframe = window !== window.parent && !window.opener;

- }

- login() {

- this.authService.loginRedirect();

- }

- setLoginDisplay() {

- this.loginDisplay = this.authService.instance.getAllAccounts().length > 0;

- }

- }

- ```

-4. Navigate to *src/app/home/home.component.ts* and replace the entire contents of the file with the following snippet to subscribe to the `LOGIN_SUCCESS` event:

- ```javascript

- import { Component, OnInit } from '@angular/core';

- import { MsalBroadcastService, MsalService } from '@azure/msal-angular';

- import { EventMessage, EventType, InteractionStatus } from '@azure/msal-browser';

- import { filter } from 'rxjs/operators';

- @Component({

- selector: 'app-home',

- templateUrl: './home.component.html',

- styleUrls: ['./home.component.css']

- })

- export class HomeComponent implements OnInit {

- constructor(private authService: MsalService, private msalBroadcastService: MsalBroadcastService) { }

- ngOnInit(): void {

- this.msalBroadcastService.msalSubject$

- .pipe(

- filter((msg: EventMessage) => msg.eventType === EventType.LOGIN_SUCCESS),

- )

- .subscribe((result: EventMessage) => {

- console.log(result);

- });

- }

- }

- ```

-1. Add the `MsalBroadcastService` to *src/app/app.component.ts* and subscribe to the `inProgress$` observable to check if interaction is complete and an account is signed in before rendering UI. Your code should now look like this:

- ```javascript

- import { Component, OnInit, OnDestroy } from '@angular/core';

- import { MsalService, MsalBroadcastService } from '@azure/msal-angular';

- import { InteractionStatus } from '@azure/msal-browser';

- import { Subject } from 'rxjs';

- import { filter, takeUntil } from 'rxjs/operators';

- @Component({

- selector: 'app-root',

- templateUrl: './app.component.html',

- styleUrls: ['./app.component.css']

- })

- export class AppComponent implements OnInit, OnDestroy {

- title = 'msal-angular-tutorial';

- isIframe = false;

- loginDisplay = false;

- private readonly _destroying$ = new Subject<void>();

- constructor(private broadcastService: MsalBroadcastService, private authService: MsalService) { }

- ngOnInit() {

- this.isIframe = window !== window.parent && !window.opener;

- this.broadcastService.inProgress$

- .pipe(

- filter((status: InteractionStatus) => status === InteractionStatus.None),

- takeUntil(this._destroying$)

- )

- .subscribe(() => {

- this.setLoginDisplay();

- })

- }

- login() {

- this.authService.loginRedirect();

- }

- setLoginDisplay() {

- this.loginDisplay = this.authService.instance.getAllAccounts().length > 0;

- }

- ngOnDestroy(): void {

- this._destroying$.next(undefined);

- this._destroying$.complete();

- }

- }

- ```

-2. Update the code in *src/app/home/home.component.ts* to also check for interaction to be completed before updating UI. Your code should now look like this:

- ```javascript

- import { Component, OnInit } from '@angular/core';

- import { MsalBroadcastService, MsalService } from '@azure/msal-angular';

- import { EventMessage, EventType, InteractionStatus } from '@azure/msal-browser';

- import { filter } from 'rxjs/operators';

- @Component({

- selector: 'app-home',

- templateUrl: './home.component.html',

- styleUrls: ['./home.component.css']

- })

- export class HomeComponent implements OnInit {

- loginDisplay = false;

- constructor(private authService: MsalService, private msalBroadcastService: MsalBroadcastService) { }

- ngOnInit(): void {

- this.msalBroadcastService.msalSubject$

- .pipe(

- filter((msg: EventMessage) => msg.eventType === EventType.LOGIN_SUCCESS),

- )

- .subscribe((result: EventMessage) => {

- console.log(result);

- });

-

- this.msalBroadcastService.inProgress$

- .pipe(

- filter((status: InteractionStatus) => status === InteractionStatus.None)

- )

- .subscribe(() => {

- this.setLoginDisplay();

- })

- }

-

- setLoginDisplay() {

- this.loginDisplay = this.authService.instance.getAllAccounts().length > 0;

- }

- }

- ```

-3. Replace the code in *src/app/home/home.component.html* with the following conditional displays:

- ```HTML

- <div *ngIf="!loginDisplay">

- <p>Please sign-in to see your profile information.</p>

- </div>

- <div *ngIf="loginDisplay">

- <p>Login successful!</p>

- <p>Request your profile information by clicking Profile above.</p>

- </div>

- ```

-1. Add the `MsalGuard` class as a provider in your application in *src/app/app.module.ts*, and add the configurations for the `MsalGuard`. Scopes needed for acquiring tokens later can be provided in the `authRequest`, and the type of interaction for the Guard can be set to `Redirect` or `Popup`. Your code should look like the following:

- ```javascript

- import { BrowserModule } from '@angular/platform-browser';

- import { BrowserAnimationsModule } from '@angular/platform-browser/animations';

- import { NgModule } from '@angular/core';

- import { MatButtonModule } from '@angular/material/button';

- import { MatToolbarModule } from '@angular/material/toolbar';

- import { MatListModule } from '@angular/material/list';

- import { AppRoutingModule } from './app-routing.module';

- import { AppComponent } from './app.component';

- import { HomeComponent } from './home/home.component';

- import { ProfileComponent } from './profile/profile.component';

- import { MsalModule, MsalRedirectComponent, MsalGuard } from '@azure/msal-angular'; // MsalGuard added to imports

- import { PublicClientApplication, InteractionType } from '@azure/msal-browser'; // InteractionType added to imports

- const isIE = window.navigator.userAgent.indexOf('MSIE ') > -1 || window.navigator.userAgent.indexOf('Trident/') > -1;

- @NgModule({

- declarations: [

- AppComponent,

- HomeComponent,

- ProfileComponent

- ],

- imports: [

- BrowserModule,

- BrowserAnimationsModule,

- AppRoutingModule,

- MatButtonModule,

- MatToolbarModule,

- MatListModule,

- MsalModule.forRoot( new PublicClientApplication({

- auth: {

- clientId: 'Enter_the_Application_Id_here',

- authority: 'Enter_the_Cloud_Instance_Id_Here/Enter_the_Tenant_Info_Here',

- redirectUri: 'Enter_the_Redirect_Uri_Here'

- },

- cache: {

- cacheLocation: 'localStorage',

- storeAuthStateInCookie: isIE,

- }

- }), {

- interactionType: InteractionType.Redirect, // MSAL Guard Configuration

- authRequest: {

- scopes: ['user.read']

- }

- }, null)

- ],

- providers: [

- MsalGuard // MsalGuard added as provider here

- ],

- bootstrap: [AppComponent, MsalRedirectComponent]

- })

- export class AppModule { }

- ```

-2. Set the `MsalGuard` on the routes you wish to protect in *src/app/app-routing.module.ts*:

- ```javascript

- import { NgModule } from '@angular/core';

- import { Routes, RouterModule } from '@angular/router';

- import { HomeComponent } from './home/home.component';

- import { ProfileComponent } from './profile/profile.component';

- import { MsalGuard } from '@azure/msal-angular';

- const routes: Routes = [

- {

- path: 'profile',

- component: ProfileComponent,

- canActivate: [MsalGuard]

- },

- {

- path: '',

- component: HomeComponent

- },

- ];

- const isIframe = window !== window.parent && !window.opener;

- @NgModule({

- imports: [RouterModule.forRoot(routes, {

- initialNavigation: !isIframe ? 'enabled' : 'disabled' // Don't perform initial navigation in iframes

- })],

- exports: [RouterModule]

- })

- export class AppRoutingModule { }

- ```

-3. Adjust the login calls in *src/app/app.component.ts* to take the `authRequest` set in the guard configurations into account. Your code should now look like the following:

- ```javascript

- import { Component, OnInit, OnDestroy, Inject } from '@angular/core';

- import { MsalService, MsalBroadcastService, MSAL_GUARD_CONFIG, MsalGuardConfiguration } from '@azure/msal-angular';

- import { InteractionStatus, RedirectRequest } from '@azure/msal-browser';

- import { Subject } from 'rxjs';

- import { filter, takeUntil } from 'rxjs/operators';

- @Component({

- selector: 'app-root',

- templateUrl: './app.component.html',

- styleUrls: ['./app.component.css']

- })

- export class AppComponent implements OnInit, OnDestroy {

- title = 'msal-angular-tutorial';

- isIframe = false;

- loginDisplay = false;

- private readonly _destroying$ = new Subject<void>();

- constructor(@Inject(MSAL_GUARD_CONFIG) private msalGuardConfig: MsalGuardConfiguration, private broadcastService: MsalBroadcastService, private authService: MsalService) { }

- ngOnInit() {

- this.isIframe = window !== window.parent && !window.opener;

- this.broadcastService.inProgress$

- .pipe(

- filter((status: InteractionStatus) => status === InteractionStatus.None),

- takeUntil(this._destroying$)

- )

- .subscribe(() => {

- this.setLoginDisplay();

- })

- }

- login() {

- if (this.msalGuardConfig.authRequest){

- this.authService.loginRedirect({...this.msalGuardConfig.authRequest} as RedirectRequest);

- } else {

- this.authService.loginRedirect();

- }

- }

- setLoginDisplay() {

- this.loginDisplay = this.authService.instance.getAllAccounts().length > 0;

- }

- ngOnDestroy(): void {

- this._destroying$.next(undefined);

- this._destroying$.complete();

- }

- }

- ```

-1. Add the `Interceptor` class as a provider to your application in *src/app/app.module.ts*, with its configurations. Your code should now look like the following:

- ```javascript

- import { BrowserModule } from '@angular/platform-browser';

- import { BrowserAnimationsModule } from '@angular/platform-browser/animations';

- import { NgModule } from '@angular/core';

- import { HTTP_INTERCEPTORS, HttpClientModule } from "@angular/common/http"; // Import

- import { MatButtonModule } from '@angular/material/button';

- import { MatToolbarModule } from '@angular/material/toolbar';

- import { MatListModule } from '@angular/material/list';

- import { AppRoutingModule } from './app-routing.module';

- import { AppComponent } from './app.component';

- import { HomeComponent } from './home/home.component';

- import { ProfileComponent } from './profile/profile.component';

- import { MsalModule, MsalRedirectComponent, MsalGuard, MsalInterceptor } from '@azure/msal-angular'; // Import MsalInterceptor

- import { InteractionType, PublicClientApplication } from '@azure/msal-browser';

- const isIE = window.navigator.userAgent.indexOf('MSIE ') > -1 || window.navigator.userAgent.indexOf('Trident/') > -1;

- @NgModule({

- declarations: [

- AppComponent,

- HomeComponent,

- ProfileComponent

- ],

- imports: [

- BrowserModule,

- BrowserAnimationsModule,

- AppRoutingModule,

- MatButtonModule,

- MatToolbarModule,

- MatListModule,

- HttpClientModule,

- MsalModule.forRoot( new PublicClientApplication({

- auth: {

- clientId: 'Enter_the_Application_Id_Here',

- authority: 'Enter_the_Cloud_Instance_Id_Here/Enter_the_Tenant_Info_Here',

- redirectUri: 'Enter_the_Redirect_Uri_Here',

- },

- cache: {

- cacheLocation: 'localStorage',

- storeAuthStateInCookie: isIE,

- }

- }), {

- interactionType: InteractionType.Redirect,

- authRequest: {

- scopes: ['user.read']

- }

- }, {

- interactionType: InteractionType.Redirect, // MSAL Interceptor Configuration

- protectedResourceMap: new Map([

- ['Enter_the_Graph_Endpoint_Here/v1.0/me', ['user.read']]

- ])

- })

- ],

- providers: [

- {

- provide: HTTP_INTERCEPTORS,

- useClass: MsalInterceptor,

- multi: true

- },

- MsalGuard

- ],

- bootstrap: [AppComponent, MsalRedirectComponent]

- })

- export class AppModule { }

- ```

- The protected resources are provided as a `protectedResourceMap`. The URLs you provide in the `protectedResourceMap` collection are case-sensitive. For each resource, add scopes being requested to be returned in the access token.

- For example:

- * `["user.read"]` for Microsoft Graph

- * `["<Application ID URL>/scope"]` for custom web APIs (that is, `api://<Application ID>/access_as_user`)

-

- Modify the values in the `protectedResourceMap` as described here:

- - `Enter_the_Graph_Endpoint_Here` is the instance of the Microsoft Graph API the application should communicate with. For the **global** Microsoft Graph API endpoint, replace this string with `https://graph.microsoft.com`. For endpoints in **national** cloud deployments, see [National cloud deployments](/graph/deployments) in the Microsoft Graph documentation.

-2. Replace the code in *src/app/profile/profile.component.ts* to retrieve a user's profile with an HTTP request, and replace the `GRAPH_ENDPOINT` with the Microsoft Graph endpoint:

- ```JavaScript

- import { Component, OnInit } from '@angular/core';

- import { HttpClient } from '@angular/common/http';

- const GRAPH_ENDPOINT = 'Enter_the_Graph_Endpoint_Here/v1.0/me';

- type ProfileType = {

- givenName?: string,

- surname?: string,

- userPrincipalName?: string,

- id?: string

- };

- @Component({

- selector: 'app-profile',

- templateUrl: './profile.component.html',

- styleUrls: ['./profile.component.css']

- })

- export class ProfileComponent implements OnInit {

- profile!: ProfileType;

- constructor(

- private http: HttpClient

- ) { }

- ngOnInit() {

- this.getProfile();

- }

- getProfile() {

- this.http.get(GRAPH_ENDPOINT)

- .subscribe(profile => {

- this.profile = profile;

- });

- }

- }

- ```

-3. Replace the UI in *src/app/profile/profile.component.html* to display profile information:

- ```HTML

- <div>

- <p><strong>First Name: </strong> {{profile?.givenName}}</p>

- <p><strong>Last Name: </strong> {{profile?.surname}}</p>

- <p><strong>Email: </strong> {{profile?.userPrincipalName}}</p>

- <p><strong>Id: </strong> {{profile?.id}}</p>

- </div>

- ```

-1. Update the code in *src/app/app.component.html* to conditionally display a `Logout` button:

- ```HTML

- <mat-toolbar color="primary">

- <a class="title" href="/">{{ title }}</a>

-

- <div class="toolbar-spacer"></div>

-

- <a mat-button [routerLink]="['profile']">Profile</a>

-

- <button mat-raised-button *ngIf="!loginDisplay" (click)="login()">Login</button>

- <button mat-raised-button *ngIf="loginDisplay" (click)="logout()">Logout</button>

-

- </mat-toolbar>

- <div class="container">

- <!--This is to avoid reload during acquireTokenSilent() because of hidden iframe -->

- <router-outlet *ngIf="!isIframe"></router-outlet>

- </div>

- ```

-1. Update the code in *src/app/app.component.ts* to sign out a user using redirects:

- ```javascript

- import { Component, OnInit, OnDestroy, Inject } from '@angular/core';

- import { MsalService, MsalBroadcastService, MSAL_GUARD_CONFIG, MsalGuardConfiguration } from '@azure/msal-angular';

- import { InteractionStatus, RedirectRequest } from '@azure/msal-browser';

- import { Subject } from 'rxjs';

- import { filter, takeUntil } from 'rxjs/operators';

-

- @Component({

- selector: 'app-root',

- templateUrl: './app.component.html',

- styleUrls: ['./app.component.css']

- })

- export class AppComponent implements OnInit, OnDestroy {

- title = 'msal-angular-tutorial';

- isIframe = false;

- loginDisplay = false;

- private readonly _destroying$ = new Subject<void>();

-

- constructor(@Inject(MSAL_GUARD_CONFIG) private msalGuardConfig: MsalGuardConfiguration, private broadcastService: MsalBroadcastService, private authService: MsalService) { }

-

- ngOnInit() {

- this.isIframe = window !== window.parent && !window.opener;

-

- this.broadcastService.inProgress$

- .pipe(

- filter((status: InteractionStatus) => status === InteractionStatus.None),

- takeUntil(this._destroying$)

- )

- .subscribe(() => {

- this.setLoginDisplay();

- })

- }

-

- login() {

- if (this.msalGuardConfig.authRequest){

- this.authService.loginRedirect({...this.msalGuardConfig.authRequest} as RedirectRequest);

- } else {

- this.authService.loginRedirect();

- }

- }

-

- logout() { // Add log out function here

- this.authService.logoutRedirect({

- postLogoutRedirectUri: 'http://localhost:4200'

- });

- }

-

- setLoginDisplay() {

- this.loginDisplay = this.authService.instance.getAllAccounts().length > 0;

- }

-

- ngOnDestroy(): void {

- this._destroying$.next(undefined);

- this._destroying$.complete();

- }

- }

- ```

-1. Update the code in *src/app/app.component.ts* to sign out a user using pop-ups:

- ```javascript

- import { Component, OnInit, OnDestroy, Inject } from '@angular/core';

- import { MsalService, MsalBroadcastService, MSAL_GUARD_CONFIG, MsalGuardConfiguration } from '@azure/msal-angular';

- import { InteractionStatus, PopupRequest } from '@azure/msal-browser';

- import { Subject } from 'rxjs';

- import { filter, takeUntil } from 'rxjs/operators';

-

- @Component({

- selector: 'app-root',

- templateUrl: './app.component.html',

- styleUrls: ['./app.component.css']

- })

- export class AppComponent implements OnInit, OnDestroy {

- title = 'msal-angular-tutorial';

- isIframe = false;

- loginDisplay = false;

- private readonly _destroying$ = new Subject<void>();

-

- constructor(@Inject(MSAL_GUARD_CONFIG) private msalGuardConfig: MsalGuardConfiguration, private broadcastService: MsalBroadcastService, private authService: MsalService) { }

-

- ngOnInit() {

- this.isIframe = window !== window.parent && !window.opener;

-

- this.broadcastService.inProgress$

- .pipe(

- filter((status: InteractionStatus) => status === InteractionStatus.None),

- takeUntil(this._destroying$)

- )

- .subscribe(() => {

- this.setLoginDisplay();

- })

- }

-

- login() {

- if (this.msalGuardConfig.authRequest){

- this.authService.loginPopup({...this.msalGuardConfig.authRequest} as PopupRequest)

- .subscribe({

- next: (result) => {

- console.log(result);

- this.setLoginDisplay();

- },

- error: (error) => console.log(error)

- });

- } else {

- this.authService.loginPopup()

- .subscribe({

- next: (result) => {

- console.log(result);

- this.setLoginDisplay();

- },

- error: (error) => console.log(error)

- });

- }

- }

-

- logout() { // Add log out function here

- this.authService.logoutPopup({

- mainWindowRedirectUri: "/"

- });

- }

-

- setLoginDisplay() {

- this.loginDisplay = this.authService.instance.getAllAccounts().length > 0;

- }

-

- ngOnDestroy(): void {

- this._destroying$.next(undefined);

- this._destroying$.complete();

- }

- }

- ```

- ```bash

- npm install

- npm start

- ```

- :::image type="content" source="media/tutorial-v2-angular-auth-code/angular-01-not-signed-in.png" alt-text="Web browser displaying sign-in dialog":::

- :::image type="content" source="media/tutorial-v2-javascript-auth-code/spa-02-consent-dialog.png" alt-text="Content dialog displayed in web browser":::

-1. After consenting, the following If you consent to the requested permissions, the web application shows a successful login page.

- :::image type="content" source="media/tutorial-v2-angular-auth-code/angular-02-signed-in.png" alt-text="Results of a successful sign-in in the web browser":::

- :::image type="content" source="media/tutorial-v2-angular-auth-code/angular-03-profile-data.png" alt-text="Profile information from Microsoft Graph displayed in the browser":::

->[!NOTE]

->The user might be prompted for additional consents as you increase the number of scopes.

-> [!div class="nextstepaction"]

-> 1. Unzip the sample app, `cd` into the app root folder, then run the following command:

-> 1. Unzip the sample app, `cd` into the folder that contains `package.json`, then run the following command:

-> npm install && npm start

-| **Operating Systems** | Windows 10 or newer, iOS, Android, macOS, Ubuntu 20.04/22.04 |

-| | Linux - Intune Agent |

-user.assignedPlans -all (assignedPlan.servicePlanId -eq "")

-## Identity governance

-Identity Governance in a customer tenant enables you to mitigate access risk by protecting, monitoring, and auditing access to your critical assets. It includes identity access lifecycle capabilities that help you manage access over time as needs change. Identity Governance also helps you scale efficiently to be able to develop and enforce access policy and controls on an ongoing basis.

-Start using Identity Governance in the [Microsoft Entra admin center](https://entra.microsoft.com) by selecting the **Identity Governance** tile. On the Identity Governance page, find information for getting started with capabilities such as Entitlement Management, access reviews, and Privileged Identity Management.

-# What is Azure Active Directory for customers?

-Azure Active Directory (Azure AD) for customers is MicrosoftΓÇÖs new customer identity and access management (CIAM) solution. For organizations and businesses that want to make their public-facing applications available to consumers, Azure AD makes it easy to add CIAM features like self-service registration, personalized sign-in experiences, and customer account management. Because these CIAM capabilities are built into Azure AD, you also benefit from platform features like enhanced security, compliance, and scalability.

-#Customer intent: As a dev, devops, or it admin, I want to set up the customer tenant free trial.

-|-|--||

-1. Open your browser and visit [https://aka.ms/ciam-free-trial](https://aka.ms/ciam-free-trial?wt.mc_id=ciamcustomertenantfreetrial_linkclick_content_cnl).

-description: Azure Active Directory B2B invited guest user properties and states before and after invitation redemption

-* [What is Azure AD B2B collaboration?](what-is-b2b.md)

-* [B2B collaboration user claims mapping](claims-mapping.md)

-|[Azure AD Domain Services virtual network deployments](../../active-directory-domain-services/migrate-from-classic-vnet.md)|Retirement|Mar 1, 2023|

-[RocketReach SSO](../saas-apps/rocketreach-sso-tutorial.md), [Arena EU](../saas-apps/arena-eu-tutorial.md), [Zola](../saas-apps/zola-tutorial.md), [FourKites SAML2.0 SSO for Tracking](../saas-apps/fourkites-tutorial.md), [Syniverse Customer Portal](../saas-apps/syniverse-customer-portal-tutorial.md), [Rimo](https://rimo.app/), [Q Ware CMMS](https://qware.app/), [Mapiq (OIDC)](https://app.mapiq.com/), [NICE Cxone](../saas-apps/nice-cxone-tutorial.md), [dominKnow|ONE](../saas-apps/dominknowone-tutorial.md), [Waynbo for Azure AD](https://webportal-eu.waynbo.com/Login), [innDex](https://web.inndex.co.uk/azure/authorize), [Profiler Software](https://www.profiler.net.au/), [Trotto go links](https://trot.to/_/auth/login), [AsignetSSOIntegration](../saas-apps/asignet-sso-tutorial.md).

-[UserZoom](../saas-apps/userzoom-tutorial.md), [AMX Mobile](https://www.amxsolutions.co.uk/), [i-Sight](../saas-apps/isight-tutorial.md), [Method InSight](https://digital.methodrecycling.com/), [Chronus SAML](../saas-apps/chronus-saml-tutorial.md), [Attendant Console for Microsoft Teams](https://attendant.anywhere365.io/), [Skopenow](../saas-apps/skopenow-tutorial.md), [Fidelity PlanViewer](../saas-apps/fidelity-planviewer-tutorial.md), [Lyve Cloud](../saas-apps/lyve-cloud-tutorial.md), [Framer](../saas-apps/framer-tutorial.md), [Authomize](../saas-apps/authomize-tutorial.md), [gamba!](../saas-apps/gamba-tutorial.md), [Datto File Protection Single Sign On](../saas-apps/datto-file-protection-tutorial.md), [LONEALERT](https://portal.lonealert.co.uk/auth/azure/saml/signin), [Payfactors](https://pf.payfactors.com/client/auth/login), [deBroome Brand Portal](../saas-apps/debroome-brand-portal-tutorial.md), [TeamSlide](../saas-apps/teamslide-tutorial.md), [Sensera Systems](https://sitecloud.senserasystems.com/), [YEAP](https://prismaonline.propay.be/logon/login.aspx), [Monaca Education](https://monaca.education/j), [OpenForms](https://login.openforms.com/Login).

-### General Availability - Azure AD single Sign-on and device-based Conditional Access support in Firefox on Windows 10/11

-[mySCView](https://www.myscview.com/), [Talentech](https://talentech.com/contact/), [Bipsync](https://www.bipsync.com/), [OroTimesheet](https://app.orotimesheet.com/login.php), [Mio](https://app.m.io/auth/install/microsoft?scopetype=hub), [Sovelto Easy](https://login.soveltoeasy.fi/), [Supportbench](https://account.supportbench.net/agent/login/),[Bienvenue Formation](https://formation.bienvenue.pro/login), [AIDA Healthcare SSO](https://aidaforparents.com/login/organizations), [International SOS Assistance Products](../saas-apps/international-sos-assistance-products-tutorial.md), [NAVEX One](../saas-apps/navex-one-tutorial.md), [LabLog](../saas-apps/lablog-tutorial.md), [Oktopost SAML](../saas-apps/oktopost-saml-tutorial.md), [EPHOTO DAM](../saas-apps/ephoto-dam-tutorial.md), [Notion](../saas-apps/notion-tutorial.md), [Syndio](../saas-apps/syndio-tutorial.md), [Yello Enterprise](../saas-apps/yello-enterprise-tutorial.md), [Timeclock 365 SAML](../saas-apps/timeclock-365-saml-tutorial.md), [Nalco E-data](https://www.ecolab.com/), [Vacancy Filler](https://app.vacancy-filler.co.uk/VFMVC/Account/Login), [Synerise AI Growth Ecosystem](../saas-apps/synerise-ai-growth-ecosystem-tutorial.md), [Imperva Data Security](../saas-apps/imperva-data-security-tutorial.md), [Illusive Networks](../saas-apps/illusive-networks-tutorial.md), [Proware](../saas-apps/proware-tutorial.md), [Splan Visitor](../saas-apps/splan-visitor-tutorial.md), [Aruba User Experience Insight](../saas-apps/aruba-user-experience-insight-tutorial.md), [Contentsquare SSO](../saas-apps/contentsquare-sso-tutorial.md), [Perimeter 81](../saas-apps/perimeter-81-tutorial.md), [Burp Suite Enterprise Edition](../saas-apps/burp-suite-enterprise-edition-tutorial.md)

-Some SAML applications require SPNameQualifier to be returned in the assertion subject when requested. Now Azure AD responds correctly when a SPNameQualifier is requested in the request NameID policy. This also works for SP initiated sign-in, and IdP initiated sign-in will follow. To learn more about SAML protocol in Azure Active Directory, see [Single Sign-On SAML protocol](../develop/single-sign-on-saml-protocol.md).

-Users in this role can enable, configure and manage services and settings related to enabling hybrid identity in Azure AD. This role grants the ability to configure Azure AD to one of the three supported authentication methods&#8212;Password hash synchronization (PHS), Pass-through authentication (PTA) or Federation (AD FS or 3rd party federation provider)&#8212;and to deploy related on-premises infrastructure to enable them. On-premises infrastructure includes Provisioning and PTA agents. This role grants the ability to enable Seamless Single Sign-On (S-SSO) to enable seamless authentication on non-Windows 10 devices or non-Windows Server 2016 computers. In addition, this role grants the ability to see sign-in logs and to access health and analytics for monitoring and troubleshooting purposes. [Learn more.](../roles/permissions-reference.md#hybrid-identity-administrator)

-Azure AD for Microsoft Edge on iOS and Android now supports Azure AD Single Sign-On and Conditional Access:

-For more information about conditional access and SSO with Microsoft Edge, see the [Microsoft Edge Mobile Support for Conditional Access and Single Sign-on Now Generally Available](https://techcommunity.microsoft.com/t5/Intune-Customer-Success/Microsoft-Edge-Mobile-Support-for-Conditional-Access-and-Single/ba-p/988179) blog post. For more information about how to set up your client apps using [app-based conditional access](../conditional-access/app-based-conditional-access.md) or [device-based conditional access](../conditional-access/require-managed-devices.md), see [Manage web access using a Microsoft Intune policy-protected browser](/intune/apps/app-configuration-managed-browser).

-For more information, see [Preview - Migrate Azure AD Domain Services from the Classic virtual network model to Resource Manager](../../active-directory-domain-services/migrate-from-classic-vnet.md).

-The Global Reader role works with the new Microsoft 365 Admin Center, Exchange Admin Center, Teams Admin Center, Security Center, Compliance Center, Azure portal, and the Device Management Admin Center.

-Filter and transform group names in token claims configuration using regular expression. Many application configurations on ADFS and other IdPs rely on the ability to create authorization claims based on the content of Group Names using regular expression functions in the claim rules. Azure AD now has the capability to use a regular expression match and replace function to create claim content based on Group **onpremisesSAMAccount** names. This functionality will allow those applications to be moved to Azure AD for authentication using the same group management patterns. For more information, see: [Configure group claims for applications by using Azure Active Directory](../hybrid/how-to-connect-fed-group-claims.md).

-Azure AD now has the capability to filter the groups included in the token using substring match on the display name or **onPremisesSAMAccountName** attributes of the group object. Only Groups the user is a member of will be included in the token. This was a blocker for some of our customers to migrate their apps from ADFS to Azure AD. This feature will unblock those challenges.

-Post-authentication anomalous activity detection for workload identities. This detection focuses specifically on detection of post authenticated anomalous behavior performed by a workload identity (service principal). Post-authentication behavior will be assessed for anomalies based on an action and/or sequence of actions occurring for the account. Based on the scoring of anomalies identified, the offline detection may score the account as low, medium, or high risk. The risk allocation from the offline detection will be available within the Risky workload identities reporting blade. A new detection type identified as Anomalous service principal activity will appear in filter options. For more information, see: [Securing workload identities](../identity-protection/concept-workload-identity-risk.md).

-Accidental deletion of users in any system could be disastrous. WeΓÇÖre excited to announce the general availability of the accidental deletions prevention capability as part of the Azure AD provisioning service. When the number of deletions to be processed in a single provisioning cycle spikes above a customer defined threshold, the Azure AD provisioning service will pause, provide you with visibility into the potential deletions, and allow you to accept or reject the deletions. This functionality has historically been available for Azure AD Connect, and Azure AD Connect Cloud Sync. It's now available across the various provisioning flows, including both HR-driven provisioning and application provisioning.

-## October 2022

-### General Availability - Azure AD certificate-based authentication

-**Type:** New feature

-**Service category:** Other

-**Product capability:** User Authentication

-

-Azure AD certificate-based authentication (CBA) enables customers to allow or require users to authenticate with X.509 certificates against their Azure Active Directory (Azure AD) for applications and browser sign-in. This feature enables customers to adopt a phishing resistant authentication and authenticate with an X.509 certificate against their Enterprise Public Key Infrastructure (PKI). For more information, see: [Overview of Azure AD certificate-based authentication (Preview)](../authentication/concept-certificate-based-authentication.md).

-

-### General Availability - Audited BitLocker Recovery

-**Type:** New feature

-**Service category:** Device Access Management

-**Product capability:** Device Lifecycle Management

-

-BitLocker keys are sensitive security items. Audited BitLocker recovery ensures that when BitLocker keys are read, an audit log is generated so that you can trace who accesses this information for given devices. For more information, see: [View or copy BitLocker keys](../devices/device-management-azure-portal.md#view-or-copy-bitlocker-keys).

-

-### General Availability - More device properties supported for Dynamic Device groups

-**Type:** Changed feature

-**Service category:** Group Management

-**Product capability:** Directory

-

-You can now create or update dynamic device groups using the following properties:

-For more information on how to use this feature, see: [Dynamic membership rule for device groups](../enterprise-users/groups-dynamic-membership.md#rules-for-devices)

-

-Lifecycle Workflows allows you to automate the lifecycle management process for your organization by creating workflows that contain both built-in tasks, and custom task extensions. These workflows, and the tasks within them, all fall into categories based on the Joiner-Mover-Leaver(JML) model of lifecycle management. To make this process even more efficient, Lifecycle Workflows also provide you templates, which you can use to accelerate the set up, creation, and configuration of common lifecycle management processes. You can create workflows based on these templates as is, or you can customize them even further to match the requirements for users within your organization. In this article you'll get the complete list of workflow templates, common template parameters, default template parameters for specific templates, and the list of compatible tasks for each template. For full task definitions, see [Lifecycle Workflow tasks and definitions](lifecycle-workflow-tasks.md).

-The **Onboard new-hire employee** template is designed to configure tasks that will be completed on an employee's start date.

-|Event User attribute | EmployeeHireDate | ❌ |

-The **Real-time employee termination** template is designed to configure tasks that will be completed immediately when an employee is terminated.

-The **Pre-Offboarding of an employee** template is designed to configure tasks that will be completed before an employee's last day of work.

-The **Offboard an employee** template is designed to configure tasks that will be completed on an employee's last day of work.

-|Tasks|Tasks are the actions that will be taken when a workflow is executed.|

-|Execution conditions| Defines when(trigger), and for who(scope), a scheduled workflow will run. For more information on these two parameters, see [Trigger details](understanding-lifecycle-workflows.md#trigger-details) and [Configure Scope](understanding-lifecycle-workflows.md#configure-scope).|

-Creating a workflow via the Azure portal requires the use of a template. A Lifecycle Workflow template is a framework that is used for pre-defined tasks, and helps automate the creation of a workflow.

-In this section you'll learn what each section tells you, and what actions you'll be able to take from this information.

-When selecting a workflow, the overview provides you a list of basic details in the **Basic Information** section. These basic details provide you information such as the workflow category, its ID, when it was modified, and when it's scheduled to run again. This information is important in providing quick details surrounding its current usage for administrative purposes. Basic information is also live data, meaning any quick change action that you take place on the overview page, is shown immediately within this section.

-The trigger of a workflow defines when a scheduled workflow will run for users in scope for the workflow. The trigger is a combination of a time-based attribute, and an offset value. For example, if the attribute is employeeHireDate and offsetInDays is -1, then the workflow should trigger one day before the employee hire date. The value can range between -180 and 180 days.

-The time-based attribute can be either one of two values, which are automatically chosen based on the template in which you select during the creation of your workflow. The two values can be:

-These two values must be set within Azure AD for users. For more information on this process, see [How to synchronize attributes for Lifecycle workflows](how-to-lifecycle-workflow-sync-attributes.md)

-The scope defines for who the scheduled workflow will run. Configuring this parameter allows you to further narrow down the users for whom the workflow is to be executed.

-Once scheduling is enabled, the workflow will be evaluated every three hours to determine whether or not it should run based on the execution conditions.

-## Emit cloud-only group display name in token (Preview)

-4. To emit group display name just for cloud groups, in the **Source attribute** dropdown select the **Cloud-only group display names (Preview)**:

-5. For a hybrid setup, to emit on-premises group attribute for synced groups and display name for cloud groups, you can select the desired on-premises sources attribute and check the checkbox **Emit group name for cloud-only groups (Preview)**:

-Not all releases of Azure AD Connect are made available for auto-upgrade. The release status indicates whether a release is made available for auto-upgrade or for download only. If auto-upgrade was enabled on your Azure AD Connect server, that server automatically upgrades to the latest version of Azure AD Connect that's released for auto-upgrade. Not all Azure AD Connect configurations are eligible for auto-upgrade.

-Auto-upgrade is meant to push all important updates and critical fixes to you. It isn't necessarily the latest version because not all versions will require or include a fix to a critical security issue. (This example is just one of many.) Critical issues are usually addressed with a new version provided via auto-upgrade. If there are no such issues, there are no updates pushed out by using auto-upgrade. In general, if you're using the latest auto-upgrade version, you should be good.

-To read more about auto-upgrade, see [Azure AD Connect: Automatic upgrade](how-to-connect-install-automatic-upgrade.md).

-8/2/2022: Released for download and auto-upgrade.

-7/6/2022: Released for download, will be made available for auto-upgrade soon.

-12/15/2021: Released for download only, not available for auto-upgrade

-10/13/2021: Released for download and auto-upgrade

-9/30/2021: Released for download only, not available for auto-upgrade

-9/21/2021: Released for download and auto-upgrade

-9/14/2021: Released for download only, not available for auto-upgrade

-8/19/2021: Released for download only, not available for auto-upgrade

-8/19/2021: Released for download only, not available for auto-upgrade

-8/19/2021: Released for download only, not available for auto-upgrade

-8/17/2021: Released for download only, not available for auto-upgrade

-8/10/2021: Released for download only, not available for auto-upgrade

-8/10/2021: Released for download only, not available for auto-upgrade

-7/20/2021: Released for download only, not available for auto-upgrade

-3/31/2021: Released for download only, not available for auto-upgrade

-3/19/2021: Released for download, not available for auto-upgrade

-Simulating the atypical travel condition is difficult because the algorithm uses machine learning to weed out false-positives such as atypical travel from familiar devices, or sign-ins from VPNs that are used by other users in the directory. Additionally, the algorithm requires a sign-in history of 14 days and 10 logins of the user before it begins generating risk detections. Because of the complex machine learning models and above rules, there's a chance that the following steps won't lead to a risk detection. You might want to replicate these steps for multiple Azure AD accounts to simulate this detection.

-### SAML request signature verification (preview)

-description: Learn how to migrate your Okta-federated applications to managed authentication under Azure AD. See how to migrate federation in a staged manner.

-In this tutorial, you'll learn how to federate your existing Office 365 tenants with Okta for single sign-on (SSO) capabilities.

-You can migrate federation to Azure Active Directory (Azure AD) in a staged manner to ensure a good authentication experience for users. In a staged migration, you can also test reverse federation access back to any remaining Okta SSO applications.

-Customers who have federated their Office 365 domains with Okta might not currently have a valid authentication method configured in Azure AD. Before you migrate to managed authentication, validate Azure AD Connect and configure it to allow user sign-in.

-Set up the sign-in method that's best suited for your environment:

-Seamless SSO can be deployed to password hash synchronization or pass-through authentication to create a seamless authentication experience for users in Azure AD.

-Follow the [deployment guide](../hybrid/how-to-connect-sso-quick-start.md#step-1-check-the-prerequisites) to ensure that you deploy all necessary prerequisites of seamless SSO to your users.

-For this example, you configure password hash synchronization and seamless SSO.

-Follow these steps to configure Azure AD Connect for password hash synchronization:

-1. On your Azure AD Connect server, open the **Azure AD Connect** app and then select **Configure**.

- 

-1. Select **Change user sign-in**, and then select **Next**.

- 

-1. Enter your global administrator credentials.

-1. Currently, the server is configured for federation with Okta. Change the selection to **Password Hash Synchronization**. Then select **Enable single sign-on**.

-1. Select **Next**.

-Follow these steps to enable seamless SSO:

-1. Enter the domain administrator credentials for the local on-premises system. Then select **Next**.

- 

-1. On the final page, select **Configure** to update the Azure AD Connect server.

- 

-1. Ignore the warning for hybrid Azure AD join for now. You'll reconfigure the device options after you disable federation from Okta.

- 

-In Azure AD, you can use a [staged rollout of cloud authentication](../hybrid/how-to-connect-staged-rollout.md) to test defederating users before you test defederating an entire domain. Before you deploy, review the [prerequisites](../hybrid/how-to-connect-staged-rollout.md#prerequisites).

-After you enable password hash sync and seamless SSO on the Azure AD Connect server, follow these steps to configure a staged rollout:

-1. In the [Azure portal](https://portal.azure.com/#home), select **View** or **Manage Azure Active Directory**.

- 

-1. On the **Azure Active Directory** menu, select **Azure AD Connect**. Then confirm that **Password Hash Sync** is enabled in the tenant.

-1. Select **Enable staged rollout for managed user sign-in**.

- 

-1. Your **Password Hash Sync** setting might have changed to **On** after the server was configured. If the setting isn't enabled, enable it now.

- Notice that **Seamless single sign-on** is set to **Off**. If you attempt to enable it, you get an error because it's already enabled for users in the tenant.

-1. Select **Manage groups**.

- 

-1. Follow the instructions to add a group to the password hash sync rollout. In the following example, the security group starts with 10 members.

- 

-1. After you add the group, wait for about 30 minutes while the feature takes effect in your tenant. When the feature has taken effect, your users are no longer redirected to Okta when they attempt to access Office 365 services.

-Users who have converted to managed authentication might still need to access applications in Okta. To allow users easy access to those applications, you can register an Azure AD application that links to the Okta home page.

-To configure the enterprise application registration for Okta:

-1. On the left menu, under **Manage**, select **Enterprise applications**.

- 

-1. On the **All applications** menu, select **New application**.

-1. Select **Create your own application**. On the menu that opens, name the Okta app and select **Register an application you're working on to integrate with Azure AD**. Then select **Create**.

- :::image type="content" source="media/migrate-okta-federation-to-azure-active-directory/register-application.png" alt-text="Screenshot that shows the Create your own application menu. The app name is visible. The option to integrate with Azure A D is turned on." lightbox="media/migrate-okta-federation-to-azure-active-directory/register-application.png":::

-1. Select **Accounts in any organizational directory (Any Azure AD Directory - Multitenant)**, and then select **Register**.

- 

-1. On the Azure AD menu, select **App registrations**. Then open the newly created registration.

- 

-1. Record your tenant ID and application ID.

- >You'll need the tenant ID and application ID to configure the identity provider in Okta.

- 

-1. On the left menu, select **Certificates & secrets**. Then select **New client secret**. Give the secret a generic name and set its expiration date.

-1. Record the value and ID of the secret.

- >The value and ID aren't shown later. If you fail to record this information now, you'll have to regenerate a secret.

- 

-1. On the left menu, select **API permissions**. Grant the application access to the OpenID Connect (OIDC) stack.

-1. Select **Add a permission** > **Microsoft Graph** > **Delegated permissions**.

- :::image type="content" source="media/migrate-okta-federation-to-azure-active-directory/delegated-permissions.png" alt-text="Screenshot that shows the A P I permissions page of the Azure portal. A delegated permission for reading is visible." lightbox="media/migrate-okta-federation-to-azure-active-directory/delegated-permissions.png":::

-1. In the OpenID permissions section, add **email**, **openid**, and **profile**. Then select **Add permissions**.

- :::image type="content" source="media/migrate-okta-federation-to-azure-active-directory/add-permissions.png" alt-text="Screenshot that shows the A P I permissions page of the Azure portal. Permissions for email, openid, profile, and reading are visible." lightbox="media/migrate-okta-federation-to-azure-active-directory/add-permissions.png":::

-1. Select **Grant admin consent for \<tenant domain name>** and wait until the **Granted** status appears.

- 

-1. On the left menu, select **Branding**. For **Home page URL**, add your user's application home page.

- 

-1. In the Okta administration portal, select **Security** > **Identity Providers** to add a new identity provider. Select **Add Microsoft**.

- 

-1. On the **Identity Provider** page, copy your application ID to the **Client ID** field. Copy the client secret to the **Client Secret** field.

-1. Select **Show Advanced Settings**. By default, this configuration ties the user principal name (UPN) in Okta to the UPN in Azure AD for reverse-federation access.

- >If your UPNs in Okta and Azure AD don't match, select an attribute that's common between users.

-1. Finish your selections for autoprovisioning. By default, if no match is found for an Okta user, the system attempts to provision the user in Azure AD. If you've migrated provisioning away from Okta, select **Redirect to Okta sign-in page**.

- 

- Now that you've created the identity provider (IDP), you need to send users to the correct IDP.

-1. On the **Identity Providers** menu, select **Routing Rules** > **Add Routing Rule**. Use one of the available attributes in the Okta profile.

-1. To direct sign-ins from all devices and IPs to Azure AD, set up the policy as the following image shows.

- In this example, the **Division** attribute is unused on all Okta profiles, so it's a good choice for IDP routing.

- 

-1. Now that you've added the routing rule, record the redirect URI so you can add it to the application registration.

- 

-1. On your application registration, on the left menu, select **Authentication**. Then select **Add a platform** > **Web**.

- :::image type="content" source="media/migrate-okta-federation-to-azure-active-directory/add-platform.png" alt-text="Screenshot of the Authentication page in the Azure portal. Add a platform and a Configure platforms menu are visible." lightbox="media/migrate-okta-federation-to-azure-active-directory/add-platform.png":::

-1. Add the redirect URI that you recorded in the IDP in Okta. Then select **Access tokens** and **ID tokens**.

- 

-1. In the admin console, select **Directory** > **People**. Select your first test user to edit the profile.

-1. In the profile, add **ToAzureAD** as in the following image. Then select **Save**.

- 

-1. Try to sign in to the [Microsoft 356 portal](https://portal.office.com) as the modified user. If your user isn't part of the managed authentication pilot, your action enters a loop. To exit the loop, add the user to the managed authentication experience.

-After you configure the Okta app in Azure AD and you configure the IDP in the Okta portal, assign the application to users.

-1. In the Azure portal, select **Azure Active Directory** > **Enterprise applications**.

-1. Select the app registration you created earlier and go to **Users and groups**. Add the group that correlates with the managed authentication pilot.

- >You can add users and groups only from the **Enterprise applications** page. You can't add users from the **App registrations** menu.

- 

-1. After about 15 minutes, sign in as one of the managed authentication pilot users and go to [My Apps](https://myapplications.microsoft.com).

- 

-1. Select the **Okta Application Access** tile to return the user to the Okta home page.

-After you configure the Okta reverse-federation app, have your users conduct full testing on the managed authentication experience. We recommend that you set up company branding to help your users recognize the tenant they're signing in to. For more information, see [Add branding to your organization's Azure AD sign-in page](../fundamentals/customize-branding.md).

->[!IMPORTANT]

->Identify any additional Conditional Access policies you might need before you completely defederate the domains from Okta. To secure your environment before the full cut-off, see [Okta sign-on policies to Azure AD Conditional Access migration](migrate-okta-sign-on-policies-to-azure-active-directory-conditional-access.md).

-When your organization is comfortable with the managed authentication experience, you can defederate your domain from Okta. To begin, use the following commands to connect to MSOnline PowerShell. If you don't already have the MSOnline PowerShell module, download it by entering `install-module MSOnline`.

-Connect-Msolservice

-Set-msoldomainauthentication

-After you set the domain to managed authentication, you've successfully defederated your Office 365 tenant from Okta while maintaining user access to the Okta home page.

-description: Learn how to migrate user provisioning from Okta to Azure Active Directory (Azure AD). See how to use Azure AD Connect server or Azure AD cloud provisioning.

-# Tutorial: Migrate Okta sync provisioning to Azure AD Connect-based synchronization

-In this tutorial, you'll learn how your organization can migrate user provisioning from Okta to Azure Active Directory (Azure AD) and migrate either User Sync or Universal Sync to Azure AD Connect. This capability enables further provisioning into Azure AD and Office 365.

-Migrating synchronization platforms isn't a small change. Each step of the process mentioned in this article should be validated against your own environment before you remove Azure AD Connect from staging mode or enable the Azure AD cloud provisioning agent.

-When you switch from Okta provisioning to Azure AD, you have two choices. You can use either an Azure AD Connect server or Azure AD cloud provisioning. To understand the differences between the two, read the [comparison article from Microsoft](../cloud-sync/what-is-cloud-sync.md#comparison-between-azure-ad-connect-and-cloud-sync).

-Azure AD cloud provisioning is the most familiar migration path for Okta customers who use Universal Sync or User Sync. The cloud provisioning agents are lightweight. You can install them on or near domain controllers like the Okta directory sync agents. Don't install them on the same server.

-Use an Azure AD Connect server if your organization needs to take advantage of any of the following technologies when you synchronize users:

->[!NOTE]

->Take all prerequisites into consideration when you install Azure AD Connect or Azure AD cloud provisioning. To learn more before you continue with installation, see [Prerequisites for Azure AD Connect](../hybrid/how-to-connect-install-prerequisites.md).

-ImmutableID is the core attribute used to tie synchronized objects to their on-premises counterparts. Okta takes the Active Directory objectGUID of an on-premises object and converts it to a Base64-encoded string. By default, it then stamps that string to the ImmutableID field in Azure AD.

-You can connect to Azure AD PowerShell and examine the current ImmutableID value. If you've never used the Azure AD PowerShell module, run

-`Install-Module AzureAD` in an administrative PowerShell session before you run the following commands:

-Connect-AzureAD

-If you already have the module, you might receive a warning to update to the latest version if it's out of date.

-After the module is installed, import it and follow these steps to connect to the Azure AD service:

-1. Enter your global administrator credentials in the authentication window.

- 

-1. After you connect to the tenant, verify the settings for your ImmutableID values. The following example uses the Okta default approach of converting the objectGUID into the ImmutableID.

- 

-1. There are several ways to manually confirm the conversion from objectGUID to Base64 on-premises. To test an individual value, use these commands:

- Get-ADUser onpremupn | fl objectguid

- 

-## Mass validation methods for objectGUID

-Before you move to Azure AD Connect, it's critical to validate that the ImmutableID values in Azure AD exactly match their on-premises values.

-The following command gets *all* on-premises Azure AD users and exports a list of their objectGUID values and ImmutableID values already calculated to a CSV file.

-1. Run this command in PowerShell on an on-premises domain controller:

- Get-ADUser -Filter * -Properties objectGUID | Select-Object

- 

-1. Run this command in an Azure AD PowerShell session to list the already synchronized values:

- Get-AzureADUser -all $true | Where-Object {$_.dirsyncenabled -like

- 

- After you have both exports, confirm that each user's ImmutableID values match.

- >If your ImmutableID values in the cloud don't match objectGUID values, you've modified the defaults for Okta sync. You've likely chosen another attribute to determine ImmutableID values. Before you move on to the next section, it's critical to identify which source attribute is populating ImmutableID values. Ensure that you update the attribute Okta is syncing before you disable Okta sync.

-After you've prepared your list of source and destination targets, it's time to install an Azure AD Connect server. If you've opted to use Azure AD Connect cloud provisioning, skip this section.

-1. Download and install Azure AD Connect on your chosen server by following the instructions in [Custom installation of Azure Active Directory Connect](../hybrid/how-to-connect-install-custom.md).

-1. In the left panel, select **Identifying users**.

-1. On the **Uniquely identifying your users** page, under **Select how users should be identified with Azure AD**, select **Choose a specific attribute**. Then select **mS-DS-ConsistencyGUID** if you haven't modified the Okta defaults.

- >This step is critical. Ensure that the attribute that you select for a source anchor is what *currently* populates your existing Azure AD users. If you select the wrong attribute, you need to uninstall and reinstall Azure AD Connect to reselect this option.

- 

-1. Select **Next**.

-1. In the left panel, select **Configure**.

-1. On the **Ready to configure** page, select **Enable staging mode**. Then select **Install**.

- 

-1. After the configuration is complete, select **Exit**.

- Before you exit the staging mode, verify that the ImmutableID values match properly.

-1. Open **Synchronization Service** as an administrator.

- 

-1. Find the **Full Synchronization** to the domain.onmicrosoft.com connector space. Check that there are users under the **Connectors with Flow Updates** tab.

-1. Verify there are no deletions pending in the export. Select the **Connectors** tab, and then highlight the domain.onmicrosoft.com connector space. Then select **Search Connector Space**.

-1. In the **Search Connector Space** dialog, under **Scope**, select **Pending Export**.

-1. Select **Delete** and then select **Search**. If all objects have matched properly, there should be zero matching records for **Deletes**. Record any objects pending deletion and their on-premises values.

- 

-1. Clear **Delete**, and select **Add** and **Modify**. Then select **Search**. You should see update functions for all users currently being synchronized to Azure AD via Okta. Add any new objects that Okta isn't currently syncing, but that exist in the organizational unit (OU) structure that was selected during the Azure AD Connect installation.

- 

-1. To see what Azure AD Connect will communicate with Azure AD, double-click an update.

-1. If there are any **add** functions for a user who already exists in Azure AD, their on-premises account doesn't match their cloud account. AD Connect has determined it will create a new object and record any new adds that are unexpected. Make sure to correct the ImmutableID value in Azure AD before you exit the staging mode.

- In this example, Okta stamped the **mail** attribute to the user's account, even though the on-premises value wasn't properly filled in. When Azure AD Connect takes over John Smith's account, the **mail** attribute is deleted from his object.

- Verify that your updates still include all attributes expected in Azure AD. If multiple attributes are being deleted, you might need to manually populate these on-premises AD values before you remove the staging mode.

- 

- >Before you continue to the next step, ensure all user attributes are syncing properly and appear on the **Pending Export** tab as expected. If they're deleted, make sure their ImmutableID values match and the user is in one of the selected OUs for synchronization.

-After you've prepared your list of source and destination targets, install and configure Azure AD cloud sync agents by following the instructions in [Tutorial: Integrate a single forest with a single Azure AD tenant](../cloud-sync/tutorial-single-forest.md). If you've opted to use an Azure AD Connect server, skip this section.

-After you've verified the Azure AD Connect installation and your pending exports are in order, it's time to disable Okta provisioning to Azure AD.

-1. Go to your Okta portal, select **Applications**, and then select your Okta app used to provision users to Azure AD. Open the **Provisioning** tab and select the **Integration** section.

- 

-1. Select **Edit**, clear the **Enable API integration** option, and select **Save**.

- 

- >If you have multiple Office 365 apps that handle provisioning to Azure AD, ensure they're all switched off.

-After you disable Okta provisioning, the Azure AD Connect server is ready to begin synchronizing objects. If you've chosen to go with Azure AD cloud sync agents, skip this section.

-1. Run the installation wizard from the desktop again and select **Configure**.

- 

-1. Select **Configure staging mode** and then select **Next**. Enter your global administrator credentials.

- 

-1. Clear **Enable staging mode** and select **Next**.

-1. Select **Configure** to continue.

-1. After the configuration finishes, open the **Synchronization Service** as an administrator. View the **Export** on the domain.onmicrosoft.com connector. Verify that all additions, updates, and deletions are done as expected.

- 

-You've now successfully migrated to Azure AD Connect server-based provisioning. You can update and expand the feature set of Azure AD Connect by rerunning the installation wizard.

-After you disable Okta provisioning, the Azure AD cloud sync agent is ready to begin synchronizing objects.

-1. Browse to **Azure Active Directory** > **Azure AD Connect** > **Cloud Sync** > **Configuration** profile, select **Enable**.

-1. Return to the provisioning menu and select **Logs**.

-1. Check that the provisioning connector has properly updated in-place objects. The cloud sync agents are nondestructive. Their updates fail if a match isn't found.

-1. If a user is mismatched, make the necessary updates to bind the ImmutableID values. Then restart the cloud provisioning sync.

-For more information about migrating from Okta to Azure AD, see these resources:

-|Cloudflare, Inc.|[Tutorial: Configure Cloudflare with Azure AD for secure hybrid access](cloudflare-azure-ad-integration.md)|

-You rely on Azure AD to provide identity and access management for your vital systems. To ensure Azure AD is available when business operations require it, Microsoft does not plan downtime for Azure AD system maintenance. Instead, maintenance is performed as the service runs, without customer impact.

-The SLA attainment is truncated at three places after the decimal. Numbers are not rounded up, so actual SLA attainment is higher than indicated.

-The Azure AD SLA is measured in a way that reflects customer authentication experience, rather than simply reporting on whether the system is available to outside connections. This means that the calculation is based on whether:

-The numbers above are a global total of Azure AD authentications across all customers and geographies.

-All incidents that seriously impact Azure AD performance are documented in the [Azure status history](https://azure.status.microsoft/status/history/). Not all events documented in Azure status history are serious enough to cause Azure AD to go below its SLA. You can view information about the impact of incidents, as well as a root cause analysis of what caused the incident and what steps Microsoft took to prevent future incidents.

-In this tutorial, you'll learn how to integrate Bugsnag with Azure Active Directory (Azure AD). When you integrate Bugsnag with Azure AD, you can:

- Alternatively, you can also use the [Enterprise App Configuration Wizard](https://portal.office.com/AdminPortal/home?Q=Docs#/azureadappintegration). In this wizard, you can add an application to your tenant, add users/groups to the app, assign roles, as well as walk through the SSO configuration as well. [Learn more about Microsoft 365 wizards.](/microsoft-365/admin/misc/azure-ad-setup-guides)

-In this section, you'll create a test user in the Azure portal called B.Simon.

-In this section, you'll enable B.Simon to use Azure single sign-on by granting access to Bugsnag.

-1. If you are expecting a role to be assigned to the users, you can select it from the **Select a role** dropdown. If no role has been set up for this app, you see "Default Access" role selected.

-To configure single sign-on on **Bugsnag** side, you need to send the **App Federation Metadata Url** to [Bugsnag support team](mailto:support@bugsnag.com). They set this setting to have the SAML SSO connection set properly on both sides.

-In this section, a user called Britta Simon is created in Bugsnag. Bugsnag supports just-in-time user provisioning, which is enabled by default. There is no action item for you in this section. If a user doesn't already exist in Bugsnag, a new one is created after authentication.

-You can also use Microsoft My Apps to test the application in any mode. When you click the Bugsnag tile in the My Apps, if configured in SP mode you would be redirected to the application sign on page for initiating the login flow and if configured in IDP mode, you should be automatically signed in to the Bugsnag for which you set up the SSO. For more information about the My Apps, see [Introduction to the My Apps](https://support.microsoft.com/account-billing/sign-in-and-start-apps-from-the-my-apps-portal-2f3b1bae-0e5a-4a86-a33e-876fbd2a4510).

-description: Learn how to configure Azure Active Directory to automatically provision and de-provision user accounts to SAP Cloud Platform Identity Authentication.

-# Tutorial: Configure SAP Cloud Platform Identity Authentication for automatic user provisioning

-The objective of this tutorial is to demonstrate the steps to be performed in SAP Cloud Platform Identity Authentication and Azure Active Directory (Azure AD) to configure Azure AD to automatically provision and de-provision users to SAP Cloud Platform Identity Authentication.

-* [A SAP Cloud Platform Identity Authentication tenant](https://www.sap.com/products/cloud-platform.html)

-* A user account in SAP Cloud Platform Identity Authentication with Admin permissions.

-## Assigning users to SAP Cloud Platform Identity Authentication

-Before configuring and enabling automatic user provisioning, you should decide which users in Azure AD need access to SAP Cloud Platform Identity Authentication. Once decided, you can assign these users to SAP Cloud Platform Identity Authentication by following the instructions here:

-## Important tips for assigning users to SAP Cloud Platform Identity Authentication

-* It is recommended that a single Azure AD user is assigned to SAP Cloud Platform Identity Authentication to test the automatic user provisioning configuration. Additional users may be assigned later.

-* When assigning a user to SAP Cloud Platform Identity Authentication, you must select any valid application-specific role (if available) in the assignment dialog. Users with the **Default Access** role are excluded from provisioning.

-## Setup SAP Cloud Platform Identity Authentication for provisioning

-1. Sign in to your [SAP Cloud Platform Identity Authentication Admin Console](https://sapmsftintegration.accounts.ondemand.com/admin). Navigate to **Users & Authorizations > Administrators**.

- 

-> The administrator user in SAP Cloud Platform Identity Authentication must be of type **System**. Creating a normal administrator user can lead to *unauthorized* errors while provisioning.

- 

-4. You will receive an email to activate your account and set a password for **SAP Cloud Platform Identity Authentication Service**.

-4. Copy the **User ID** and **Password**. These values will be entered in the Admin Username and Admin Password fields respectively in the Provisioning tab of your SAP Cloud Platform Identity Authentication application in the Azure portal.

-## Add SAP Cloud Platform Identity Authentication from the gallery

-Before configuring SAP Cloud Platform Identity Authentication for automatic user provisioning with Azure AD, you need to add SAP Cloud Platform Identity Authentication from the Azure AD application gallery to your list of managed SaaS applications.

-**To add SAP Cloud Platform Identity Authentication from the Azure AD application gallery, perform the following steps:**

-4. In the search box, enter **SAP Cloud Platform Identity Authentication**, select **SAP Cloud Platform Identity Authentication** in the results panel, and then click the **Add** button to add the application.

- 

-## Configuring automatic user provisioning to SAP Cloud Platform Identity Authentication

-This section guides you through the steps to configure the Azure AD provisioning service to create, update, and disable users in SAP Cloud Platform Identity Authentication based on users assignments in Azure AD.

-> You may also choose to enable SAML-based single sign-on for SAP Cloud Platform Identity Authentication, following the instructions provided in the [SAP Cloud Platform Identity Authentication Single sign-on tutorial](./sap-hana-cloud-platform-identity-authentication-tutorial.md). Single sign-on can be configured independently of automatic user provisioning, though these two features compliment each other

-### To configure automatic user provisioning for SAP Cloud Platform Identity Authentication in Azure AD:

-2. In the applications list, select **SAP Cloud Platform Identity Authentication**.

- 

-5. Under the **Admin Credentials** section, input `https://<tenantID>.accounts.ondemand.com/service/scim ` in **Tenant URL**. Input the **User ID** and **Password** values retrieved earlier in **Admin Username** and **Admin Password** respectively. Click **Test Connection** to ensure Azure AD can connect to SAP Cloud Platform Identity Authentication. If the connection fails, ensure your SAP Cloud Platform Identity Authentication account has Admin permissions and try again.

-8. Under the **Mappings** section, select **Synchronize Azure Active Directory Users to SAP Cloud Platform Identity Authentication**.

- 

-9. Review the user attributes that are synchronized from Azure AD to SAP Cloud Platform Identity Authentication in the **Attribute Mapping** section. The attributes selected as **Matching** properties are used to match the user accounts in SAP Cloud Platform Identity Authentication for update operations. Select the **Save** button to commit any changes.

- 

-11. To enable the Azure AD provisioning service for SAP Cloud Platform Identity Authentication, change the **Provisioning Status** to **On** in the **Settings** section.

-12. Define the users that you would like to provision to SAP Cloud Platform Identity Authentication by choosing the desired values in **Scope** in the **Settings** section.

-This operation starts the initial synchronization of all users defined in **Scope** in the **Settings** section. The initial sync takes longer to perform than subsequent syncs, which occur approximately every 40 minutes as long as the Azure AD provisioning service is running. You can use the **Synchronization Details** section to monitor progress and follow links to provisioning activity report, which describes all actions performed by the Azure AD provisioning service on SAP Cloud Platform Identity Authentication.

-* SAP Cloud Platform Identity Authentication's SCIM endpoint requires certain attributes to be of specific format. You can know more about these attributes and their specific format [here](https://help.sap.com/viewer/6d6d63354d1242d185ab4830fc04feb1/Cloud/en-US/b10fc6a9a37c488a82ce7489b1fab64c.html#).

-description: Learn how to configure single sign-on between Azure Active Directory and SAP Cloud Platform.

-# Tutorial: Azure AD SSO integration with SAP Cloud Platform

-In this tutorial, you'll learn how to integrate SAP Cloud Platform with Azure Active Directory (Azure AD). When you integrate SAP Cloud Platform with Azure AD, you can:

-* Control in Azure AD who has access to SAP Cloud Platform.

-* Enable your users to be automatically signed-in to SAP Cloud Platform with their Azure AD accounts.

-* SAP Cloud Platform single sign-on (SSO) enabled subscription.

->You need to deploy your own application or subscribe to an application on your SAP Cloud Platform account to test single sign on. In this tutorial, an application is deployed in the account.

-* SAP Cloud Platform supports **SP** initiated SSO.

-## Add SAP Cloud Platform from the gallery

-To configure the integration of SAP Cloud Platform into Azure AD, you need to add SAP Cloud Platform from the gallery to your list of managed SaaS apps.

-1. In the **Add from the gallery** section, type **SAP Cloud Platform** in the search box.

-1. Select **SAP Cloud Platform** from results panel and then add the app. Wait a few seconds while the app is added to your tenant.

-## Configure and test Azure AD SSO for SAP Cloud Platform

-Configure and test Azure AD SSO with SAP Cloud Platform using a test user called **B.Simon**. For SSO to work, you need to establish a link relationship between an Azure AD user and the related user in SAP Cloud Platform.

-To configure and test Azure AD SSO with SAP Cloud Platform, perform the following steps:

-2. **[Configure SAP Cloud Platform SSO](#configure-sap-cloud-platform-sso)** - to configure the Single Sign-On settings on application side.

- 1. **[Create SAP Cloud Platform test user](#create-sap-cloud-platform-test-user)** - to have a counterpart of Britta Simon in SAP Cloud Platform that is linked to the Azure AD representation of user.

-1. In the Azure portal, on the **SAP Cloud Platform** application integration page, find the **Manage** section and select **single sign-on**.

- a. In the **Identifier** textbox you will provide your SAP Cloud Platform's type a URL using one of the following patterns:

- c. In the **Sign On URL** textbox, type the URL used by your users to sign into your **SAP Cloud Platform** application. This is the account-specific URL of a protected resource in your SAP Cloud Platform application. The URL is based on the following pattern: `https://<applicationName><accountName>.<landscape host>.ondemand.com/<path_to_protected_resource>`

- >This is the URL in your SAP Cloud Platform application that requires the user to authenticate.

- > These values are not real. Update these values with the actual Identifier,Reply URL and Sign on URL. Contact [SAP Cloud Platform Client support team](https://help.sap.com/viewer/65de2977205c403bbc107264b8eccf4b/Cloud/5dd739823b824b539eee47b7860a00be.html) to get Sign-On URL and Identifier. Reply URL you can get from trust management section which is explained later in the tutorial.

-In this section, you'll enable B.Simon to use Azure single sign-on by granting access to SAP Cloud Platform.

-1. In the applications list, select **SAP Cloud Platform**.

-## Configure SAP Cloud Platform SSO

-1. In a different web browser window, sign on to the SAP Cloud Platform Cockpit at `https://account.<landscape host>.ondemand.com/cockpit`(for example: https://account.hanatrial.ondemand.com/cockpit).

- c. As **Local Provider Name**, leave the default value. Copy this value and paste it into the **Identifier** field in the Azure AD configuration for SAP Cloud Platform.

- a. Download the SAP Cloud Platform metadata file by clicking **Get Metadata**.

- b. Open the downloaded SAP Cloud Platform metadata XML file, and then locate the **ns3:AssertionConsumerService** tag.

- c. Copy the value of the **Location** attribute, and then paste it into the **Reply URL** field in the Azure AD configuration for SAP Cloud Platform.

-Using groups on SAP Cloud Platform allows you to dynamically assign one or more users to one or more roles in your SAP Cloud Platform applications, determined by values of attributes in the SAML 2.0 assertion.

-For example, if the assertion contains the attribute "*contract=temporary*", you may want all affected users to be added to the group "*TEMPORARY*". The group "*TEMPORARY*" may contain one or more roles from one or more applications deployed in your SAP Cloud Platform account.

-Use assertion-based groups when you want to simultaneously assign many users to one or more roles of applications in your SAP Cloud Platform account. If you want to assign only a single or small number of users to specific roles, we recommend assigning them directly in the ΓÇ£**Authorizations**ΓÇ¥ tab of the SAP Cloud Platform cockpit.

-### Create SAP Cloud Platform test user

-In order to enable Azure AD users to log in to SAP Cloud Platform, you must assign roles in the SAP Cloud Platform to them.

-1. Log in to your **SAP Cloud Platform** cockpit.

-* Click on **Test this application** in Azure portal. This will redirect to SAP Cloud Platform Sign-on URL where you can initiate the login flow.

-* Go to SAP Cloud Platform Sign-on URL directly and initiate the login flow from there.

-* You can use Microsoft My Apps. When you click the SAP Cloud Platform tile in the My Apps, you should be automatically signed in to the SAP Cloud Platform for which you set up the SSO. For more information about the My Apps, see [Introduction to the My Apps](https://support.microsoft.com/account-billing/sign-in-and-start-apps-from-the-my-apps-portal-2f3b1bae-0e5a-4a86-a33e-876fbd2a4510).

-Once you configure SAP Cloud Platform you can enforce session control, which protects exfiltration and infiltration of your organizationΓÇÖs sensitive data in real time. Session control extends from Conditional Access. [Learn how to enforce session control with Microsoft Defender for Cloud Apps](/cloud-app-security/proxy-deployment-any-app).

-1. In the Azure portal, on the **Veracode** application integration page, find the **Manage** section. Select **single sign-on**.

-1. On the **Select a single sign-on method** page, select **SAML**.

-1. On the **Basic SAML Configuration** section, the application is pre-configured and the necessary URLs are already pre-populated with Azure. Select **Save**.

-1. On the **Set up Veracode** section, copy the appropriate URL(s) based on your requirement.

-1. Select the **SAML** tab.

- b. For **Assertion Signing Certificate**, select **Choose File** to upload your downloaded certificate from the Azure portal.

- c. Note the values of the three URLs (**SAML Assertion URL**, **SAML Audience URL**, **Relay state URL**).

- d. Click **Save**.

-1. Take the values of the **SAML Assertion URL**, **SAML Audience URL** and **Relay state URL** and update them in the Azure Active Directory settings for the Veracode integration.

-1. In the **Basic Settings** section, for **User Data Updates**, select **Prefer Veracode User Data**.

-Once you configure Veracode you can enforce session control, which protects exfiltration and infiltration of your organizationΓÇÖs sensitive data in real time. Session control extends from Conditional Access. [Learn how to enforce session control with Microsoft Defender for Cloud Apps](/cloud-app-security/proxy-deployment-any-app).

-1. Sign in to the [Azure portal](https://portal.azure.com). Select **Enterprise Applications**, then select **All applications**.

-* [Learn how to review logs and get reports on provisioning activity](../app-provisioning/check-status-user-account-provisioning.md)

-| **AC-2(2)**<br>The information system automatically [*FedRAMP Selection: disables*] temporary and emergency accounts after [*FedRAMP Assignment: 24 hours from last use*].<p><p>**AC-02(3)**<br>The information system automatically disables inactive accounts after [*FedRAMP Assignment: thirty-five (35) days for user accounts*].<p><p>**AC-2 (3) Additional FedRAMP Requirements and Guidance:**<br>**Requirement:** The service provider defines the time period for non-user accounts (e.g., accounts associated with devices). The time periods are approved and accepted by the JAB/AO. Where user management is a function of the service, reports of activity of consumer users shall be made available. | **Employ automated mechanisms to support automatically removing or disabling temporary and emergency accounts after 24 hours from last use and all customer-controlled accounts after 35 days of inactivity.**<p>Implement account management automation with Microsoft Graph and Azure AD PowerShell. Use Microsoft Graph to monitor sign-in activity and Azure AD PowerShell to take action on accounts within the required time frame. <p>Determine inactivity<br><li>[Manage inactive user accounts in Azure AD](../reports-monitoring/howto-manage-inactive-user-accounts.md)<br><li>[Manage stale devices in Azure AD](../devices/manage-stale-devices.md)<p>Remove or disable accounts<br><li>[Working with users in Microsoft Graph](/graph/api/resources/users)<br><li>[Get a user](/graph/api/user-get?tabs=http)<br><li>[Update user](/graph/api/user-update?tabs=http)<br><li>[Delete a user](/graph/api/user-delete?tabs=http)<p>Work with devices in Microsoft Graph<br><li>[Get device](/graph/api/device-get?tabs=http)<br><li>[Update device](/graph/api/device-update?tabs=http)<br><li>[Delete device](/graph/api/device-delete?tabs=http)<p>Use [Azure AD PowerShell](/powershell/module/azuread/)<br><li>[Get-AzureADUser](/powershell/module/azuread/get-azureaduser)<br><li>[Set-AzureADUser](/powershell/module/azuread/set-azureaduser)<br><li>[Get-AzureADDevice](/powershell/module/azuread/get-azureaddevice)<br><li>[Set-AzureADDevice](/powershell/module/azuread/set-azureaddevice) |

-| **AC-2(5)**<br>The organization requires that users log out when [*FedRAMP Assignment: inactivity is anticipated to exceed fifteen (15) minutes*].<p><p>**AC-2 (5) Additional FedRAMP Requirements and Guidance:**<br>**Guidance:** Should use a shorter timeframe than AC-12 | **Implement device log-out after a 15-minute period of inactivity.**<p>Implement device lock by using a conditional access policy that restricts access to compliant devices. Configure policy settings on the device to enforce device lock at the OS level with mobile device management (MDM) solutions such as Intune. Endpoint Manager or group policy objects can also be considered in hybrid deployments. For unmanaged devices, configure the Sign-In Frequency setting to force users to reauthenticate.<P>Conditional access<br><li>[Require device to be marked as compliant](../conditional-access/require-managed-devices.md)<br><li>[User sign-in frequency](../conditional-access/howto-conditional-access-session-lifetime.md)<p>MDM policy<br><li>Configure devices for maximum minutes of inactivity until the screen locks and requires a password to unlock ([Android](/mem/intune/configuration/device-restrictions-android), [iOS](/mem/intune/configuration/device-restrictions-ios), [Windows 10](/mem/intune/configuration/device-restrictions-windows-10)). |

-| **AC-2(11)**<br>The information system enforces [*Assignment: organization-defined circumstances and/or usage conditions*] for [*Assignment: organization-defined information system accounts*]. | **Enforce usage of customer-controlled accounts to meet customer-defined conditions or circumstances.**<p>Create conditional access policies to enforce access control decisions across users and devices.<p>Conditional access<br><li>[Create a conditional access policy](../authentication/tutorial-enable-azure-mfa.md?bc=%2fazure%2factive-directory%2fconditional-access%2fbreadcrumb%2ftoc.json&toc=%2fazure%2factive-directory%2fconditional-access%2ftoc.json)<br><li>[What is conditional access?](../conditional-access/overview.md) |

-| **AC-2(13)**<br>The organization disables accounts of users posing a significant risk within [*FedRAMP Assignment: one (1) hour*] of discovery of the risk.|**Disable customer-controlled accounts of users that pose a significant risk within one hour.**<p>In Azure AD Identity Protection, configure and enable a user risk policy with the threshold set to High. Create conditional access policies to block access for risky users and risky sign-ins. Configure risk policies to allow users to self-remediate and unblock subsequent sign-in attempts.<p>Identity protection<br><li>[What is Azure AD Identity Protection?](../identity-protection/overview-identity-protection.md)<p>Conditional access<br><li>[What is conditional access?](../conditional-access/overview.md)<br><li>[Create a conditional access policy](../authentication/tutorial-enable-azure-mfa.md?bc=%2fazure%2factive-directory%2fconditional-access%2fbreadcrumb%2ftoc.json&toc=%2fazure%2factive-directory%2fconditional-access%2ftoc.json)<br><li>[Conditional access: User risk-based conditional access](../conditional-access/howto-conditional-access-policy-risk-user.md)<br><li>[Conditional access: Sign-in risk-based conditional access](../conditional-access/howto-conditional-access-policy-risk-user.md)<br><li>[Self-remediation with risk policy](../identity-protection/howto-identity-protection-remediate-unblock.md) |

-| **AC-8 System Use Notification**<p><p>**The information system:**<br>**(a.)** Displays to users [*Assignment: organization-defined system use notification message or banner (FedRAMP Assignment: see additional Requirements and Guidance)*] before granting access to the system that provides privacy and security notices consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance and states that:<br>(1.) Users are accessing a U.S. Government information system;<br>(2.) Information system usage may be monitored, recorded, and subject to audit;<br>(3.) Unauthorized use of the information system is prohibited and subject to criminal and civil penalties; and<br>(4.) Use of the information system indicates consent to monitoring and recording;<p><p>**(b.)** Retains the notification message or banner on the screen until users acknowledge the usage conditions and take explicit actions to log on to or further access the information system; and<p><p>**(c.)** For publicly accessible systems:<br>(1.) Displays system use information [*Assignment: organization-defined conditions (FedRAMP Assignment: see additional Requirements and Guidance)*], before granting further access;<br>(2.) Displays references, if any, to monitoring, recording, or auditing that are consistent with privacy accommodations for such systems that generally prohibit those activities; and<br>(3.) Includes a description of the authorized uses of the system.<p><p>**AC-8 Additional FedRAMP Requirements and Guidance:**<br>**Requirement:** The service provider shall determine elements of the cloud environment that require the System Use Notification control. The elements of the cloud environment that require System Use Notification are approved and accepted by the JAB/AO.<br>**Requirement:** The service provider shall determine how System Use Notification is going to be verified and provide appropriate periodicity of the check. The System Use Notification verification and periodicity are approved and accepted by the JAB/AO.<br>**Guidance:** If performed as part of a Configuration Baseline check, then the % of items requiring setting that are checked and that pass (or fail) check can be provided.<br>**Requirement:** If not performed as part of a Configuration Baseline check, then there must be documented agreement on how to provide results of verification and the necessary periodicity of the verification by the service provider. The documented agreement on how to provide verification of the results are approved and accepted by the JAB/AO. | **Display and require user acknowledgment of privacy and security notices before granting access to information systems.**<p>With Azure AD, you can deliver notification or banner messages for all apps that require and record acknowledgment before granting access. You can granularly target these terms of use policies to specific users (Member or Guest). You can also customize them per application via conditional access policies.<p>Terms of use<br><li>[Azure Active Directory terms of use](../conditional-access/terms-of-use.md)<br><li>[View report of who has accepted and declined](../conditional-access/terms-of-use.md) |

-| **AC-10 Concurrent Session Control**<br>The information system limits the number of concurrent sessions for each [*Assignment: organization-defined account and/or account type*] to [*FedRAMP Assignment: three (3) sessions for privileged access and two (2) sessions for non-privileged access*].|**Limit concurrent sessions to three sessions for privileged access and two for nonprivileged access.** <p>Nowadays, users connect from multiple devices, sometimes simultaneously. Limiting concurrent sessions leads to a degraded user experience and provides limited security value. A better approach to address the intent behind this control is to adopt a zero-trust security posture. Conditions are explicitly validated before a session is created and continually validated throughout the life of a session. <p>In addition, use the following compensating controls. <p>Use conditional access policies to restrict access to compliant devices. Configure policy settings on the device to enforce user sign-in restrictions at the OS level with MDM solutions such as Intune. Endpoint Manager or group policy objects can also be considered in hybrid deployments.<p> Use Privileged Identity Management to further restrict and control privileged accounts. <p> Configure smart account lockout for invalid sign-in attempts.<p>**Implementation guidance** <p>Zero trust<br><li> [Securing identity with Zero Trust](/security/zero-trust/identity)<br><li>[Continuous access evaluation in Azure AD](../conditional-access/concept-continuous-access-evaluation.md)<p>Conditional access<br><li>[What is conditional access in Azure AD?](../conditional-access/overview.md)<br><li>[Require device to be marked as compliant](../conditional-access/require-managed-devices.md)<br><li>[User sign-in frequency](../conditional-access/howto-conditional-access-session-lifetime.md)<p>Device policies<br><li>[Use PowerShell scripts on Windows 10 devices in Intune](/mem/intune/apps/intune-management-extension)<br><li>[Other smart card Group Policy settings and registry keys](/windows/security/identity-protection/smart-cards/smart-card-group-policy-and-registry-settings)<br><li>[Microsoft Endpoint Manager overview](/mem/endpoint-manager-overview)<p>Resources<br><li>[What is Azure AD Privileged Identity Management?](../privileged-identity-management/pim-configure.md)<br><li>[Protect user accounts from attacks with Azure Active Directory smart lockout](../authentication/howto-password-smart-lockout.md)<p>See AC-12 for more session reevaluation and risk mitigation guidance. |

-| **AC-11 Session Lock**<br>**The information system:**<br>**(a)** Prevents further access to the system by initiating a session lock after [*FedRAMP Assignment: fifteen (15) minutes*] of inactivity or upon receiving a request from a user; and<br>**(b)** Retains the session lock until the user reestablishes access using established identification and authentication procedures.<p><p>**AC-11(1)**<br>The information system conceals, via the session lock, information previously visible on the display with a publicly viewable image. | **Implement a session lock after a 15-minute period of inactivity or upon receiving a request from a user. Retain the session lock until the user reauthenticates. Conceal previously visible information when a session lock is initiated.**<p> Implement device lock by using a conditional access policy to restrict access to compliant devices. Configure policy settings on the device to enforce device lock at the OS level with MDM solutions such as Intune. Endpoint Manager or group policy objects can also be considered in hybrid deployments. For unmanaged devices, configure the Sign-In Frequency setting to force users to reauthenticate.<p>Conditional access<br><li>[Require device to be marked as compliant](../conditional-access/require-managed-devices.md)<br><li>[User sign-in frequency](../conditional-access/howto-conditional-access-session-lifetime.md)<p>MDM policy<br><li>Configure devices for maximum minutes of inactivity until the screen locks ([Android](/mem/intune/configuration/device-restrictions-android), [iOS](/mem/intune/configuration/device-restrictions-ios), [Windows 10](/mem/intune/configuration/device-restrictions-windows-10)). |

-| **AC-12 Session Termination**<br>The information system automatically terminates a user session after [*Assignment: organization-defined conditions or trigger events requiring session disconnect*].| **Automatically terminate user sessions when organizational defined conditions or trigger events occur.**<p>Implement automatic user session reevaluation with Azure AD features such as risk-based conditional access and continuous access evaluation. You can implement inactivity conditions at a device level as described in AC-11.<p>Resources<br><li>[Sign-in risk-based conditional access](../conditional-access/howto-conditional-access-policy-risk.md)<br><li>[User risk-based conditional access](../conditional-access/howto-conditional-access-policy-risk-user.md)<br><li>[Continuous access evaluation](../conditional-access/concept-continuous-access-evaluation.md)

-| **AC-20 Use of External Information Systems**<br>The organization establishes terms and conditions, consistent with any trust relationships established with other organizations owning, operating, and/or maintaining external information systems, allowing authorized individuals to:<br>**(a.)** Access the information system from external information systems; and<br>**(b.)** Process, store, or transmit organization-controlled information using external information systems.<p><p>**AC-20(1)**<br>The organization permits authorized individuals to use an external information system to access the information system or to process, store, or transmit organization-controlled information only when the organization:<br>**(a.)** Verifies the implementation of required security controls on the external system as specified in the organizationΓÇÖs information security policy and security plan; or<br>**(b.)** Retains approved information system connection or processing agreements with the organizational entity hosting the external information system. | **Establish terms and conditions that allow authorized individuals to access the customer-deployed resources from external information systems such as unmanaged devices and external networks.**<p>Require terms of use acceptance for authorized users who access resources from external systems. Implement conditional access policies to restrict access from external systems. Conditional access policies might also be integrated with Defender for Cloud Apps to provide controls for cloud and on-premises applications from external systems. Mobile application management in Intune can protect organization data at the application level, including custom apps and store apps, from managed devices that interact with external systems. An example would be accessing cloud services. You can use app management on organization-owned devices and personal devices.<P>Terms and conditions<br><li>[Terms of use: Azure Active Directory](../conditional-access/terms-of-use.md)<p>Conditional access<br><li>[Require device to be marked as compliant](../conditional-access/require-managed-devices.md)<br><li>[Conditions in conditional access policy: Device state (preview)](../conditional-access/concept-conditional-access-conditions.md)<br><li>[Protect with Microsoft Defender for Cloud Apps Conditional Access App Control](/cloud-app-security/proxy-intro-aad)<br><li>[Location condition in Azure Active Directory conditional access](../conditional-access/location-condition.md)<p>MDM<br><li>[What is Microsoft Intune?](/mem/intune/fundamentals/what-is-intune)<br><li>[What is Defender for Cloud Apps?](/cloud-app-security/what-is-cloud-app-security)<br><li>[What is app management in Microsoft Intune?](/mem/intune/apps/app-management)<p>Resource<br><li>[Integrate on-premises apps with Defender for Cloud Apps](../app-proxy/application-proxy-integrate-with-microsoft-cloud-application-security.md) |

-| IA-8| Identification and authentication (non-organizational users) |

-| **IA-2(1)**<br>The information system implements multifactor authentication for network access to privileged accounts.<br><br>**IA-2(3)**<br>The information system implements multifactor authentication for local access to privileged accounts. | **Multifactor authentication for all access to privileged accounts.** <p>Configure the following elements for a complete solution to ensure all access to privileged accounts requires multifactor authentication.<p>Configure conditional access policies to require multifactor authentication for all users.<br> Implement Azure AD Privileged Identity Management to require multifactor authentication for activation of privileged role assignment prior to use.<p>With Privileged Identity Management activation requirement in place, privilege account activation isn't possible without network access, so local access is never privileged.<p>Multifactor authentication and Privileged Identity Management<br> <li>[Conditional access: Require multifactor authentication for all users](../conditional-access/howto-conditional-access-policy-all-users-mfa.md)<br> <li>[Configure Azure AD role settings in Privileged Identity Management](../privileged-identity-management/pim-how-to-change-default-settings.md?tabs=new) |

-| **IA-2(2)**<br>The information system implements multifactor authentication for network access to non-privileged accounts.<br><br>**IA-2(4)**<br>The information system implements multifactor authentication for local access to non-privileged accounts. | **Implement multi-factor authentication for all access to non-privileged accounts**<p>Configure the following elements as an overall solution to ensure all access to non-privileged accounts requires MFA.<p> Configure Conditional Access policies to require MFA for all users.<br> Configure device management policies via MDM (such as Microsoft Intune), Microsoft Endpoint Manager (MEM) or group policy objects (GPO) to enforce use of specific authentication methods.<br> Configure Conditional Access policies to enforce device compliance.<p>Microsoft recommends using a multi-factor cryptographic hardware authenticator (e.g., FIDO2 security keys, Windows Hello for Business (with hardware TPM), or smart card) to achieve AAL3. If your organization is completely cloud-based, we recommend using FIDO2 security keys or Windows Hello for Business.<p>Windows Hello for Business hasn't been validated at the required FIPS 140 Security Level and as such federal customers would need to conduct risk assessment and evaluation before accepting it as AAL3. For more information regarding Windows Hello for Business FIPS 140 validation, see [Microsoft NIST AALs](nist-overview.md).<p>Guidance regarding MDM policies differ slightly based on authentication methods, they're broken out below. <p>Smart Card / Windows Hello for Business<br> [Passwordless Strategy - Require Windows Hello for Business or smart card](/windows/security/identity-protection/hello-for-business/passwordless-strategy)<br> [Require device to be marked as compliant](../conditional-access/require-managed-devices.md)<br> [Conditional Access - Require MFA for all users](../conditional-access/howto-conditional-access-policy-all-users-mfa.md)<p> Hybrid Only<br> [Passwordless Strategy - Configure user accounts to disallow password authentication](/windows/security/identity-protection/hello-for-business/passwordless-strategy)<p> Smart Card Only<br>[Create a Rule to Send an Authentication Method Claim](/windows-server/identity/ad-fs/operations/create-a-rule-to-send-an-authentication-method-claim)<br>[Configure Authentication Policies](/windows-server/identity/ad-fs/operations/configure-authentication-policies)<p>FIDO2 Security Key<br> [Passwordless Strategy - Excluding the password credential provider](/windows/security/identity-protection/hello-for-business/passwordless-strategy)<br> [Require device to be marked as compliant](../conditional-access/require-managed-devices.md)<br> [Conditional Access - Require MFA for all users](../conditional-access/howto-conditional-access-policy-all-users-mfa.md)<p>Authentication Methods<br> [Azure Active Directory passwordless sign-in (preview) | FIDO2 security keys](../authentication/concept-authentication-passwordless.md)<br> [Passwordless security key sign-in Windows - Azure Active Directory](../authentication/howto-authentication-passwordless-security-key-windows.md)<br> [ADFS: Certificate Authentication with Azure AD & Office 365](/archive/blogs/samueld/adfs-certauth-aad-o365)<br> [How Smart Card Sign-in Works in Windows (Windows 10)](/windows/security/identity-protection/smart-cards/smart-card-how-smart-card-sign-in-works-in-windows)<br> [Windows Hello for Business Overview (Windows 10)](/windows/security/identity-protection/hello-for-business/hello-overview)<p>Additional Resources:<br> [Policy CSP - Windows Client Management](/windows/client-management/mdm/policy-configuration-service-provider)<br> [Use PowerShell scripts on Windows 10 devices in Intune](/mem/intune/apps/intune-management-extension)<br> [Plan a passwordless authentication deployment with Azure AD](../authentication/howto-authentication-passwordless-deployment.md)<br> |

-| **IA-2(8)**<br>The information system implements replay-resistant authentication mechanisms for network access to privileged accounts. | **Implement replay-resistant authentication mechanisms for network access to privileged accounts.**<p>Configure conditional access policies to require multifactor authentication for all users. All Azure AD authentication methods at authentication assurance level 2 and 3 use either nonce or challenges and are resistant to replay attacks.<p>References<br> <li>[Conditional access: Require multifactor authentication for all users](../conditional-access/howto-conditional-access-policy-all-users-mfa.md)<br> <li>[Achieving NIST authenticator assurance levels with the Microsoft identity platform](nist-overview.md) |

-| **IA-2(11)**<br>The information system implements multifactor authentication for remote access to privileged and non-privileged accounts such that one of the factors is provided by a device separate from the system gaining access and the device meets [*FedRAMP Assignment: FIPS 140-2, NIAP* Certification, or NSA approval*].<br><br>*National Information Assurance Partnership (NIAP)<br>**Additional FedRAMP Requirements and Guidance:**<br>**Guidance:** PIV = separate device. Please refer to NIST SP 800-157 Guidelines for Derived Personal Identity Verification (PIV) Credentials. FIPS 140-2 means validated by the Cryptographic Module Validation Program (CMVP). | **Implement Azure AD multifactor authentication to access customer-deployed resources remotely so that one of the factors is provided by a device separate from the system gaining access where the device meets FIPS-140-2, NIAP certification, or NSA approval.**<p>See guidance for IA-02(1-4). Azure AD authentication methods to consider at AAL3 meeting the separate device requirements are:<p> FIDO2 security keys<br> <li>Windows Hello for Business with hardware TPM (TPM is recognized as a valid "something you have" factor by NIST 800-63B Section 5.1.7.1.)<br> <li>Smart card<p>References<br><li>[Achieving NIST authenticator assurance levels with the Microsoft identity platform](nist-overview.md)<br> <li>[NIST 800-63B Section 5.1.7.1](https://pages.nist.gov/800-63-3/sp800-63b.html) |

-| **IA-2(12)*<br>The information system accepts and electronically verifies Personal Identity Verification (PIV) credentials.<br><br>**IA-2 (12) Additional FedRAMP Requirements and Guidance:**<br>**Guidance:** Include Common Access Card (CAC), i.e., the DoD technical implementation of PIV/FIPS 201/HSPD-12. | **Accept and verify personal identity verification (PIV) credentials. This control isn't applicable if the customer doesn't deploy PIV credentials.**<p>Configure federated authentication by using Active Directory Federation Services (AD FS) to accept PIV (certificate authentication) as both primary and multifactor authentication methods and issue the multifactor authentication (MultipleAuthN) claim when PIV is used. Configure the federated domain in Azure AD with setting **federatedIdpMfaBehavior** to `enforceMfaByFederatedIdp` (recommended) or SupportsMfa to `$True` to direct multifactor authentication requests originating at Azure AD to AD FS. Alternatively, you can use PIV for sign-in on Windows devices and later use integrated Windows authentication along with seamless single sign-on. Windows Server and client verify certificates by default when used for authentication. <p>Resources<br><li>[What is federation with Azure AD?](../hybrid/whatis-fed.md)<br> <li>[Configure AD FS support for user certificate authentication](/windows-server/identity/ad-fs/operations/configure-user-certificate-authentication)<br> <li>[Configure authentication policies](/windows-server/identity/ad-fs/operations/configure-authentication-policies)<br> <li>[Secure resources with Azure AD multifactor authentication and AD FS](../authentication/howto-mfa-adfs.md)<br><li>[Set-MsolDomainFederationSettings](/powershell/module/msonline/set-msoldomainfederationsettings)<br> <li>[Azure AD Connect: Seamless single sign-on](../hybrid/how-to-connect-sso.md) |

-| **IA-3 Device Identification and Authentication**<br>The information system uniquely identifies and authenticates [*Assignment: organization-defined specific and/or types of devices] before establishing a [Selection (one or more): local; remote; network*] connection. | **Implement device identification and authentication prior to establishing a connection.**<p>Configure Azure AD to identify and authenticate Azure AD Registered, Azure AD Joined, and Azure AD Hybrid joined devices.<p> Resources<br><li>[What is a device identity?](../devices/overview.md)<br> <li>[Plan an Azure AD devices deployment](../devices/plan-device-deployment.md)<br><li>[Require managed devices for cloud app access with conditional access](../conditional-access/require-managed-devices.md) |

-| **IA-04 Identifier Management**<br>The organization manages information system identifiers for users and devices by:<br>**(a.)** Receiving authorization from [*FedRAMP Assignment at a minimum, the ISSO (or similar role within the organization)*] to assign an individual, group, role, or device identifier;<br>**(b.)** Selecting an identifier that identifies an individual, group, role, or device;<br>**(c.)** Assigning the identifier to the intended individual, group, role, or device;<br>**(d.)** Preventing reuse of identifiers for [*FedRAMP Assignment: at least two (2) years*]; and<br>**(e.)** Disabling the identifier after [*FedRAMP Assignment: thirty-five (35) days (see additional requirements and guidance)*]<br>**IA-4e Additional FedRAMP Requirements and Guidance:**<br>**Requirement:** The service provider defines the time period of inactivity for device identifiers.<br>**Guidance:** For DoD clouds, see DoD cloud website for specific DoD requirements that go above and beyond FedRAMP.<br><br>**IA-4(4)**<br>The organization manages individual identifiers by uniquely identifying each individual as [*FedRAMP Assignment: contractors; foreign nationals*]. | **Disable account identifiers after 35 days of inactivity and prevent their reuse for two years. Manage individual identifiers by uniquely identifying each individual (for example, contractors and foreign nationals).**<p>Assign and manage individual account identifiers and status in Azure AD in accordance with existing organizational policies defined in AC-02. Follow AC-02(3) to automatically disable user and device accounts after 35 days of inactivity. Ensure that organizational policy maintains all accounts that remain in the disabled state for at least two years. After this time, you can remove them. <p>Determine inactivity<br> <li>[Manage inactive user accounts in Azure AD](../reports-monitoring/howto-manage-inactive-user-accounts.md)<br> <li>[Manage stale devices in Azure AD](../devices/manage-stale-devices.md)<br> <li>[See AC-02 guidance](fedramp-access-controls.md) |

-| **IA-5(1)**<br>The information system, for password-based authentication:<br>**(a.)** Enforces minimum password complexity of [*Assignment: organization-defined requirements for case sensitivity, number of characters, mix of upper-case letters, lower-case letters, numbers, and special characters, including minimum requirements for each type*];<br>**(b.)** Enforces at least the following number of changed characters when new passwords are created: [*FedRAMP Assignment: at least fifty percent (50%)*];<br>**(c.)** Stores and transmits only cryptographically-protected passwords;<br>**(d.) Enforces password minimum and maximum lifetime restrictions of [*Assignment: organization- defined numbers for lifetime minimum, lifetime maximum*];<br>**(e.)** Prohibits password reuse for [*FedRAMP Assignment: twenty-four (24)*] generations; and<br>**(f.)** Allows the use of a temporary password for system logons with an immediate change to a permanent password.<br><br>**IA-5 (1) a and d Additional FedRAMP Requirements and Guidance:**<br>**Guidance:** If password policies are compliant with NIST SP 800-63B Memorized Secret (Section 5.1.1) Guidance, the control may be considered compliant. | **Implement password-based authentication requirements.**<p>Per NIST SP 800-63B Section 5.1.1: Maintain a list of commonly used, expected, or compromised passwords.<p>With Azure AD password protection, default global banned password lists are automatically applied to all users in an Azure AD tenant. To support your business and security needs, you can define entries in a custom banned password list. When users change or reset their passwords, these banned password lists are checked to enforce the use of strong passwords.<p>We strongly encourage passwordless strategies. This control is only applicable to password authenticators, so removing passwords as an available authenticator renders this control not applicable.<p>NIST reference documents<br><li>[NIST Special Publication 800-63B](https://pages.nist.gov/800-63-3/sp800-63b.html)<br><li>[NIST Special Publication 800-53 Revision 5](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf) - IA-5 - Control enhancement (1)<p>Resource<br><li>[Eliminate bad passwords using Azure AD password protection](../authentication/concept-password-ban-bad.md) |

-| **IA-5(2)**<br>The information system, for PKI-based authentication:<br>**(a.)** Validates certifications by constructing and verifying a certification path to an accepted trust anchor including checking certificate status information;<br>**(b.)** Enforces authorized access to the corresponding private key;<br>**(c.)** Maps the authenticated identity to the account of the individual or group; and<br>**(d.)** Implements a local cache of revocation data to support path discovery and validation in case of inability to access revocation information via the network. | **Implement PKI-based authentication requirements.**<p>Federate Azure AD via AD FS to implement PKI-based authentication. By default, AD FS validates certificates, locally caches revocation data, and maps users to the authenticated identity in Active Directory. <p> Resources<br> <li>[What is federation with Azure AD?](../hybrid/whatis-fed.md)<br> <li>[Configure AD FS support for user certificate authentication](/windows-server/identity/ad-fs/operations/configure-user-certificate-authentication) |

-| **IA-5(4)**<br>The organization employs automated tools to determine if password authenticators are sufficiently strong to satisfy [*FedRAMP Assignment: complexity as identified in IA-5 (1) Control Enhancement (H) Part A*].<br><br>**IA-5(4) Additional FedRAMP Requirements and Guidance:**<br>**Guidance:** If automated mechanisms which enforce password authenticator strength at creation are not used, automated mechanisms must be used to audit strength of created password authenticators. | **Employ automated tools to validate password strength requirements.** <p>Azure AD implements automated mechanisms that enforce password authenticator strength at creation. This automated mechanism can also be extended to enforce password authenticator strength for on-premises Active Directory. Revision 5 of NIST 800-53 has withdrawn IA-04(4) and incorporated the requirement into IA-5(1).<p>Resources<br> <li>[Eliminate bad passwords using Azure AD password protection](../authentication/concept-password-ban-bad.md)<br> <li>[Azure AD password protection for Active Directory Domain Services](../authentication/concept-password-ban-bad-on-premises.md)<br><li>[NIST Special Publication 800-53 Revision 5](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf) - IA-5 - Control enhancement (4) |

-| **IA-5(13)**<br>The information system prohibits the use of cached authenticators after [*Assignment: organization-defined time period*]. | **Enforce the expiration of cached authenticators.**<p>Cached authenticators are used to authenticate to the local machine when the network isn't available. To limit the use of cached authenticators, configure Windows devices to disable their use. Where this action isn't possible or practical, use the following compensating controls:<p>Configure conditional access session controls by using application-enforced restrictions for Office applications.<br> Configure conditional access by using application controls for other applications.<p>Resources<br> <li>[Interactive logon number of previous logons to cache](/windows/security/threat-protection/security-policy-settings/interactive-logon-number-of-previous-logons-to-cache-in-case-domain-controller-is-not-available)<br> <li>[Session controls in conditional access policy: Application enforced restrictions](../conditional-access/concept-conditional-access-session.md)<br><li>[Session controls in conditional access policy: Conditional access application control](../conditional-access/concept-conditional-access-session.md) |

-| **IA-7 Cryptographic Module Authentication**<br>The information system implements mechanisms for authentication to a cryptographic module that meet the requirements of applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance for such authentication. | **Implement mechanisms for authentication to a cryptographic module that meets applicable federal laws.**<p>The FedRAMP High Impact level requires the AAL3 authenticator. All authenticators supported by Azure AD at AAL3 provide mechanisms to authenticate operator access to the module as required. For example, in a Windows Hello for Business deployment with hardware TPM, configure the level of TPM owner authorization.<p> Resources<br><li>For more information, see IA-02 (2 and 4).<br> <li>[Achieving NIST authenticator assurance levels with the Microsoft identity platform](nist-overview.md) <br> <li>[TPM Group Policy settings](/windows/security/information-protection/tpm/trusted-platform-module-services-group-policy-settings) |

-| **IA-8 Identification and Authentication (Non-Organizational Users)**<br>The information system uniquely identifies and authenticates non-organizational users (or processes acting on behalf of non-organizational users). | **The information system uniquely identifies and authenticates non-organizational users (or processes acting for non-organizational users).**<p>Azure AD uniquely identifies and authenticates non-organizational users homed in the organizations tenant or in external directories by using Federal Identity, Credential, and Access Management (FICAM)-approved protocols.<p>Resources<br><li>[What is B2B collaboration in Azure Active Directory?](../external-identities/what-is-b2b.md)<br> <li>[Direct federation with an identity provider for B2B](../external-identities/direct-federation.md)<br> <li>[Properties of a B2B guest user](../external-identities/user-properties.md) |

-| **AU-2 Audit Events**<br>**The organization:**<br>**(a.)** Determines that the information system is capable of auditing the following events: [*FedRAMP Assignment: [Successful and unsuccessful account logon events, account management events, object access, policy change, privilege functions, process tracking, and system events. For Web applications: all administrator activity, authentication checks, authorization checks, data deletions, data access, data changes, and permission changes*];<br>**(b.)** Coordinates the security audit function with other organizational entities requiring audit-related information to enhance mutual support and to help guide the selection of auditable events;<br>**(c.)** Provides a rationale for why the auditable events are deemed to be adequate to support after-the-fact investigations of security incidents; and<br>**(d.)** Determines that the following events are to be audited within the information system: [*FedRAMP Assignment: organization-defined subset of the auditable events defined in AU-2 a. to be audited continually for each identified event*].<br><br>**AU-2 Additional FedRAMP Requirements and Guidance:**<br>**Requirement:** Coordination between service provider and consumer shall be documented and accepted by the JAB/AO.<br><br>**AU-3 Content and Audit Records**<br>The information system generates audit records containing information that establishes what type of event occurred, when the event occurred, where the event occurred, the source of the event, the outcome of the event, and the identity of any individuals or subjects associated with the event.<br><br>**AU-3(1)**<br>The information system generates audit records containing the following additional information: [*FedRAMP Assignment: organization-defined additional, more detailed information*].<br><br>**AU-3 (1) Additional FedRAMP Requirements and Guidance:**<br>**Requirement:** The service provider defines audit record types [*FedRAMP Assignment: session, connection, transaction, or activity duration; for client-server transactions, the number of bytes received and bytes sent; additional informational messages to diagnose or identify the event; characteristics that describe or identify the object or resource being acted upon; individual identities of group account users; full-text of privileged commands*]. The audit record types are approved and accepted by the JAB/AO.<br>**Guidance:** For client-server transactions, the number of bytes sent and received gives bidirectional transfer information that can be helpful during an investigation or inquiry.<br><br>**AU-3(2)**<br>The information system provides centralized management and configuration of the content to be captured in audit records generated by [*FedRAMP Assignment: all network, data storage, and computing devices*]. | Ensure the system is capable of auditing events defined in AU-2 Part a. Coordinate with other entities within the organization's subset of auditable events to support after-the-fact investigations. Implement centralized management of audit records.<p>All account lifecycle operations (account creation, modification, enabling, disabling, and removal actions) are audited within the Azure AD audit logs. All authentication and authorization events are audited within Azure AD sign-in logs, and any detected risks are audited in the Identity Protection logs. You can stream each of these logs directly into a security information and event management (SIEM) solution such as Microsoft Sentinel. Alternatively, use Azure Event Hubs to integrate logs with third-party SIEM solutions.<p>Audit events<li> [Audit activity reports in the Azure Active Directory portal](../reports-monitoring/concept-audit-logs.md)<li> [Sign-in activity reports in the Azure Active Directory portal](../reports-monitoring/concept-sign-ins.md)<li>[How To: Investigate risk](../identity-protection/howto-identity-protection-investigate-risk.md)<p>SIEM integrations<li> [Microsoft Sentinel : Connect data from Azure Active Directory (Azure AD)](../../sentinel/connect-azure-active-directory.md)<li>[Stream to Azure event hub and other SIEMs](../reports-monitoring/tutorial-azure-monitor-stream-logs-to-event-hub.md) |

-| **IR-4 Incident Handling**<br>**The organization:**<br>**(a.)** Implements an incident handling capability for security incidents that includes preparation, detection and analysis, containment, eradication, and recovery;<br>**(b.)** Coordinates incident handling activities with contingency planning activities; and<br>**(c.)** Incorporates lessons learned from ongoing incident handling activities into incident response procedures, training, and testing/exercises, and implements the resulting changes accordingly.<br>**IR-4 Additional FedRAMP Requirements and Guidance:**<br>**Requirement:** The service provider ensures that individuals conducting incident handling meet personnel security requirements commensurate with the criticality/sensitivity of the information being processed, stored, and transmitted by the information system.<br><br>**IR-04(1)**<br>The organization employs automated mechanisms to support the incident handling process.<br><br>**IR-04(2)**<br>The organization includes dynamic reconfiguration of [*FedRAMP Assignment: all network, data storage, and computing devices*] as part of the incident response capability.<br><br>**IR-04(3)**<br>The organization identifies [*Assignment: organization-defined classes of incidents*] and [*Assignment: organization-defined actions to take in response to classes of incident*] to ensure continuation of organizational missions and business functions.<br><br>**IR-04(4)**<br>The organization correlates incident information and individual incident responses to achieve an organization-wide perspective on incident awareness and response.<br><br>**IR-04(6)**<br>The organization implements incident handling capability for insider threats.<br><br>**IR-04(8)**<br>The organization implements incident handling capability for insider threats.<br>The organization coordinates with [*FedRAMP Assignment: external organizations including consumer incident responders and network defenders and the appropriate consumer incident response team (CIRT)/ Computer Emergency Response Team (CERT) (such as US-CERT, DoD CERT, IC CERT)*] to correlate and share [*Assignment: organization-defined incident information*] to achieve a cross- organization perspective on incident awareness and more effective incident responses.<br><br>**IR-05 Incident Monitoring**<br>The organization tracks and documents information system security incidents.<br><br>**IR-05(1)**<br>The organization employs automated mechanisms to assist in the tracking of security incidents and in the collection and analysis of incident information. | Implement incident handling and monitoring capabilities. This includes Automated Incident Handling, Dynamic Reconfiguration, Continuity of Operations, Information Correlation, Insider Threats, Correlation with External Organizations, and Incident Monitoring and Automated Tracking. <p>The audit logs record all configuration changes. Authentication and authorization events are audited within the sign-in logs, and any detected risks are audited in the Identity Protection logs. You can stream each of these logs directly into a SIEM solution, such as Microsoft Sentinel. Alternatively, use Azure Event Hubs to integrate logs with third-party SIEM solutions. Automate dynamic reconfiguration based on events within the SIEM by using Microsoft Graph or Azure AD PowerShell.<p>Audit events<br><li>[Audit activity reports in the Azure Active Directory portal](../reports-monitoring/concept-audit-logs.md)<li>[Sign-in activity reports in the Azure Active Directory portal](../reports-monitoring/concept-sign-ins.md)<li>[How To: Investigate risk](../identity-protection/howto-identity-protection-investigate-risk.md)<p>SIEM integrations<li>[Microsoft Sentinel : Connect data from Azure Active Directory (Azure AD)](../../sentinel/connect-azure-active-directory.md)<li>[Stream to Azure event hub and other SIEMs](../reports-monitoring/tutorial-azure-monitor-stream-logs-to-event-hub.md)<p>Dynamic reconfiguration<li>[AzureAD Module](/powershell/module/azuread/)<li>[Overview of Microsoft Graph](/graph/overview?view=graph-rest-1.0&preserve-view=true) |

-description: Get guidance on understanding other Zero Trust requirements outlined in US government OMB memorandum 22-09.

-# Other areas of Zero Trust addressed in memorandum 22-09

-Another automation integration point is Azure AD PowerShell modules. Use PowerShell to perform common tasks or configurations in Azure AD, or incorporate into Azure functions or Azure Automation runbooks.

-If using the `node-image` cluster auto-upgrade channel or the `NodeImage` node OS auto-upgrade channel, Linux [unattended upgrades][unattended-upgrades] are disabled by default. You can't change node OS auto-upgrade channel value if your cluster auto-upgrade channel is `node-image`. In order to set the node OS auto-upgrade channel values, make sure the [cluster auto-upgrade channel][Autoupgrade] isn't `node-image`.

-The nodeosupgradechannel isn't supported on Windows OS nodepools. Azure Linux support is now rolled out and is expected to be available in all regions soon.

-> Node OS image auto-upgrade won't affect the cluster's Kubernetes version, but it still still requires the cluster to be in a supported version to function properly.

-| `None`| Your nodes won't have security updates applied automatically. This means you're solely responsible for your security updates|N/A|

-| `Unmanaged`|OS updates are applied automatically through the OS built-in patching infrastructure. Newly allocated machines are unpatched initially and will be patched at some point by the OS's infrastructure|Ubuntu applies security patches through unattended upgrade roughly once a day around 06:00 UTC. Windows and Azure Linux don't apply security patches automatically, so this option behaves equivalently to `None`|

-| `SecurityPatch`|AKS regularly updates the node's virtual hard disk (VHD) with patches from the image maintainer labeled "security only". There maybe disruptions when the security patches are applied to the nodes. When the patches are applied, the VHD is updated and existing machines are upgraded to that VHD, honoring maintenance windows and surge settings. This option incurs the extra cost of hosting the VHDs in your node resource group. If you use this channel, Linux [unattended upgrades][unattended-upgrades] are disabled by default.|N/A|

- - To create an ADLS account using the driver in dynamic provisioning, you need to specify `isHnsEnabled: "true"` in the storage class parameters.

- - To enable blobfuse access to an ADLS account in static provisioning, you need to specify the mount option `--use-adls=true` in the persistent volume.

-|fsType | File System Type | `ext4`, `ext3`, `ext2`, `xfs`| Yes | `ext4` for Linux|

-description: Learn how to provision Azure NetApp Files volumes on an Azure Kubernetes Service cluster.

-# Provision Azure NetApp Files volumes on Azure Kubernetes Service

-A persistent volume represents a piece of storage that has been provisioned for use with Kubernetes pods. A persistent volume can be used by one or many pods, and can be dynamically or statically provisioned. This article shows you how to create [Azure NetApp Files][anf] volumes to be used by pods on an Azure Kubernetes Service (AKS) cluster.

-[Azure NetApp Files][anf] is an enterprise-class, high-performance, metered file storage service running on Azure. Kubernetes users have two options for using Azure NetApp Files volumes for Kubernetes workloads:

-* Create Azure NetApp Files volumes **statically**. In this scenario, the creation of volumes is external to AKS. Volumes are created using the Azure CLI or from the Azure portal, and are then exposed to Kubernetes by the creation of a `PersistentVolume`. Statically created Azure NetApp Files volumes have many limitations (for example, inability to be expanded, needing to be over-provisioned, and so on). Statically created volumes are not recommended for most use cases.

-* Create Azure NetApp Files volumes **on-demand**, orchestrating through Kubernetes. This method is the **preferred** way to create multiple volumes directly through Kubernetes, and is achieved using [Astra Trident][astra-trident]. Astra Trident is a CSI-compliant dynamic storage orchestrator that helps provision volumes natively through Kubernetes.

-* To use dynamic provisioning with Azure NetApp Files, install and configure [Astra Trident][astra-trident] version 19.07 or higher.

-## Configure Azure NetApp Files

-1. Register the *Microsoft.NetApp* resource provider by running the following command:

-2. When you create an Azure NetApp account for use with AKS, you can create the account in an existing resource group or create a new one in the same region as the AKS cluster.

-The following command creates an account named *myaccount1* in the *myResourceGroup* resource group and *eastus* region:

- --resource-group myResourceGroup \

- --location eastus \

- --account-name myaccount1

-3. Create a new capacity pool by using [az netappfiles pool create][az-netappfiles-pool-create]. The following example creates a new capacity pool named *mypool1* with 4 TB in size and *Premium* service level:

- --resource-group myResourceGroup \

- --location eastus \

- --account-name myaccount1 \

- --pool-name mypool1 \

- --size 4 \

- --service-level Premium

-4. Create a subnet to [delegate to Azure NetApp Files][anf-delegate-subnet] using [az network vnet subnet create][az-network-vnet-subnet-create]. Specify the resource group hosting the existing virtual network for your AKS cluster.

- > Ensure that the `address-prefixes` are set correctly and without any conflicts

- RESOURCE_GROUP=myResourceGroup

- VNET_NAME=$(az network vnet list --resource-group $RESOURCE_GROUP --query [].name -o tsv)

- VNET_ID=$(az network vnet show --resource-group $RESOURCE_GROUP --name $VNET_NAME --query "id" -o tsv)

- SUBNET_NAME=MyNetAppSubnet

- --address-prefixes 10.225.0.0/24

- ```

- Volumes can either be provisioned statically or dynamically. Both options are covered further in the next sections.

-## Provision Azure NetApp Files volumes statically

-1. Create a volume using the [az netappfiles volume create][az-netappfiles-volume-create] command. Update `RESOURCE_GROUP`, `LOCATION`, `ANF_ACCOUNT_NAME` (Azure NetApp account name), `POOL_NAME`, and `SERVICE_LEVEL` with the correct values.

- ```azurecli-interactive

- RESOURCE_GROUP=myResourceGroup

- LOCATION=eastus

- ANF_ACCOUNT_NAME=myaccount1

- POOL_NAME=mypool1

- SERVICE_LEVEL=Premium

- VNET_NAME=$(az network vnet list --resource-group $RESOURCE_GROUP --query [].name -o tsv)

- VNET_ID=$(az network vnet show --resource-group $RESOURCE_GROUP --name $VNET_NAME --query "id" -o tsv)

- SUBNET_NAME=MyNetAppSubnet

- SUBNET_ID=$(az network vnet subnet show --resource-group $RESOURCE_GROUP --vnet-name $VNET_NAME --name $SUBNET_NAME --query "id" -o tsv)

- VOLUME_SIZE_GiB=100 # 100 GiB

- UNIQUE_FILE_PATH="myfilepath2" # Note that file path needs to be unique within all ANF Accounts

-

- az netappfiles volume create \

- --resource-group $RESOURCE_GROUP \

- --location $LOCATION \

- --account-name $ANF_ACCOUNT_NAME \

- --pool-name $POOL_NAME \

- --name "myvol1" \

- --service-level $SERVICE_LEVEL \

- --vnet $VNET_ID \

- --subnet $SUBNET_ID \

- --usage-threshold $VOLUME_SIZE_GiB \

- --file-path $UNIQUE_FILE_PATH \

- --protocol-types "NFSv3"

- ```

-### Create the persistent volume

-1. List the details of your volume using [az netappfiles volume show][az-netappfiles-volume-show]

- ```azurecli-interactive

- az netappfiles volume show \

- --resource-group $RESOURCE_GROUP \

- --account-name $ANF_ACCOUNT_NAME \

- --pool-name $POOL_NAME \

- --volume-name "myvol1" -o JSON

- ```

- The following output resembles the output of the previous command:

- ```output

- {

- ...

- "creationToken": "myfilepath2",

- ...

- "mountTargets": [

- {

- ...

- "ipAddress": "10.0.0.4",

- ...

- }

- ],

- ...

- }

- ```

-2. Create a `pv-nfs.yaml` defining a persistent volume by copying the following manifest. Replace `path` with the *creationToken* and `server` with *ipAddress* from the previous step.

- ```yaml

-

- apiVersion: v1

- kind: PersistentVolume

- metadata:

- name: pv-nfs

- spec:

- capacity:

- storage: 100Gi

- accessModes:

- - ReadWriteMany

- mountOptions:

- - vers=3

- nfs:

- server: 10.0.0.4

- path: /myfilepath2

- ```

-3. Create the persistent volume using the [kubectl apply][kubectl-apply] command:

- ```bash

- kubectl apply -f pv-nfs.yaml

- ```

-4. Verify the *Status* of the PersistentVolume is *Available* using the [kubectl describe][kubectl-describe] command:

- ```bash

- kubectl describe pv pv-nfs

- ```

-### Create a persistent volume claim

-1. Create a `pvc-nfs.yaml` defining a PersistentVolume by copying the following manifest:

- ```yaml

- apiVersion: v1

- kind: PersistentVolumeClaim

- metadata:

- name: pvc-nfs

- spec:

- accessModes:

- - ReadWriteMany

- storageClassName: ""

- resources:

- requests:

- storage: 1Gi

- ```

-2. Create the persistent volume claim using the [kubectl apply][kubectl-apply] command:

- ```bash

- kubectl apply -f pvc-nfs.yaml

- ```

-3. Verify the *Status* of the persistent volume claim is *Bound* using the [kubectl describe][kubectl-describe] command:

- ```bash

- kubectl describe pvc pvc-nfs

- ```

-### Mount with a pod

-1. Create a `nginx-nfs.yaml` defining a pod that uses the persistent volume claim by using the following manifest:

- ```yaml

- kind: Pod

- apiVersion: v1

- metadata:

- name: nginx-nfs

- spec:

- containers:

- - image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine

- name: nginx-nfs

- command:

- - "/bin/sh"

- - "-c"

- - while true; do echo $(date) >> /mnt/azure/outfile; sleep 1; done

- volumeMounts:

- - name: disk01

- mountPath: /mnt/azure

- volumes:

- - name: disk01

- persistentVolumeClaim:

- claimName: pvc-nfs

- ```

-2. Create the pod using the [kubectl apply][kubectl-apply] command:

- ```bash

- kubectl apply -f nginx-nfs.yaml

- ```

-3. Verify the pod is *Running* using the [kubectl describe][kubectl-describe] command:

- ```bash

- kubectl describe pod nginx-nfs

- ```

-4. Verify your volume has been mounted on the pod by using [kubectl exec][kubectl-exec] to connect to the pod, and then use `df -h` to check if the volume is mounted.

- ```bash

- kubectl exec -it nginx-nfs -- sh

- ```

- ```output

- / # df -h

- Filesystem Size Used Avail Use% Mounted on

- ...

- 10.0.0.4:/myfilepath2 100T 384K 100T 1% /mnt/azure

- ...

- ```

-## Provision Azure NetApp Files volumes dynamically

-### Install and configure Astra Trident

-To dynamically provision volumes, you need to install Astra Trident. Astra Trident is NetApp's dynamic storage provisioner that is purpose-built for Kubernetes. Simplify the consumption of storage for Kubernetes applications using Astra Trident's industry-standard [Container Storage Interface (CSI)][kubernetes-csi-driver] driver. Astra Trident deploys on Kubernetes clusters as pods and provides dynamic storage orchestration services for your Kubernetes workloads.

-Before proceeding to the next section, you need to:

-1. **Install Astra Trident**. Trident can be installed using the Trident operator (manually or using [Helm][trident-helm-chart]) or [`tridentctl`][tridentctl]. The instructions provided later in this article explain how Astra Trident can be installed using the operator. To learn more about these installation methods and how they work, see the [Install Guide][trident-install-guide].

-2. **Create a backend**. To instruct Astra Trident about the Azure NetApp Files subscription and where it needs to create volumes, a backend is created. This step requires details about the account that was created in the previous step.

-#### Install Astra Trident using the operator

-This section walks you through the installation of Astra Trident using the operator.

-1. Run the [kubectl create][kubectl-create] command to create the *trident* namespace:

- ```bash

- kubectl create ns trident

-2. Run the [kubectl apply][kubectl-apply] command to deploy the Trident operator using the bundle file:

- ```bash

- kubectl apply -f https://raw.githubusercontent.com/NetApp/trident/v23.01.1/deploy/bundle_pre_1_25.yaml -n trident

- ```

- ```bash

- kubectl apply -f https://raw.githubusercontent.com/NetApp/trident/v23.01.1/deploy/bundle_post_1_25.yaml -n trident

- ```

- The output of the command resembles the following example:

- ```output

- serviceaccount/trident-operator created

- clusterrole.rbac.authorization.k8s.io/trident-operator created

- clusterrolebinding.rbac.authorization.k8s.io/trident-operator created

- deployment.apps/trident-operator created

- podsecuritypolicy.policy/tridentoperatorpods created

- ```

-3. Run the following command to create a `TridentOrchestrator` to install Astra Trident.

- ```bash

- kubectl apply -f https://raw.githubusercontent.com/NetApp/trident/v23.01.1/deploy/crds/tridentorchestrator_cr.yaml

- ```

- The output of the command resembles the following example:

- ```output

- tridentorchestrator.trident.netapp.io/trident created

- ```

- The operator installs by using the parameters provided in the `TridentOrchestrator` spec. You can learn about the configuration parameters and example backends from the [Trident install guide][trident-install-guide] and [backend guide][trident-backend-install-guide].

-4. To confirm Astra Trident was installed successfully, run the following [kubectl describe][kubectl-describe] command:

- ```bash

- kubectl describe torc trident

- ```

- The output of the command resembles the following example:

- ```output

- Name: trident

- Namespace:

- Labels: <none>

- Annotations: <none>

- API Version: trident.netapp.io/v1

- Kind: TridentOrchestrator

- ...

- Spec:

- Debug: true

- Namespace: trident

- Status:

- Current Installation Params:

- IPv6: false

- Autosupport Hostname:

- Autosupport Image: netapp/trident-autosupport:23.01

- Autosupport Proxy:

- Autosupport Serial Number:

- Debug: true

- Enable Node Prep: false

- Image Pull Secrets:

- Image Registry:

- k8sTimeout: 30

- Kubelet Dir: /var/lib/kubelet

- Log Format: text

- Silence Autosupport: false

- Trident Image: netapp/trident:23.01.1

- Message: Trident installed

- Namespace: trident

- Status: Installed

- Version: v23.01.1

- Events:

- Type Reason Age From Message

- - - - -

- Normal Installing 74s trident-operator.netapp.io Installing Trident

- Normal Installed 67s trident-operator.netapp.io Trident installed

- ```

-### Create a backend

-1. Before creating a backend, you need to update [backend-anf.yaml][backend-anf.yaml] to include details about the Azure NetApp Files subscription, such as:

- * `subscriptionID` for the Azure subscription where Azure NetApp Files will be enabled.

- * `tenantID`, `clientID`, and `clientSecret` from an [App Registration][azure-ad-app-registration] in Azure Active Directory (AD) with sufficient permissions for the Azure NetApp Files service. The App Registration includes the `Owner` or `Contributor` role that's predefined by Azure.

- * An Azure location that contains at least one delegated subnet.

- In addition, you can choose to provide a different service level. Azure NetApp Files provides three [service levels](../azure-netapp-files/azure-netapp-files-service-levels.md): Standard, Premium, and Ultra.

-2. After Astra Trident is installed, create a backend that points to your Azure NetApp Files subscription by running the following command.

- ```bash

- kubectl apply -f backend-anf.yaml -n trident

- ```

- The output of the command resembles the following example:

- ```output

- secret/backend-tbc-anf-secret created

- tridentbackendconfig.trident.netapp.io/backend-tbc-anf created

- ```

-

- 3. To confirm backend was set with correct credentials and sufficient permissions, run the following [kubectl describe][kubectl-describe] command:

- ```bash

- kubectl describe tridentbackendconfig.trident.netapp.io/backend-tbc-anf -n trident

- ```

-### Create a StorageClass

-A storage class is used to define how a unit of storage is dynamically created with a persistent volume. To consume Azure NetApp Files volumes, a storage class must be created.

-1. Create a file named `anf-storageclass.yaml` and copy in the following manifest:

- ```yaml

- apiVersion: storage.k8s.io/v1

- kind: StorageClass

- metadata:

- name: azure-netapp-files

- provisioner: csi.trident.netapp.io

- parameters:

- backendType: "azure-netapp-files"

- fsType: "nfs"

- ```

-2. Create the storage class using the [kubectl apply][kubectl-apply] command:

- ```bash

- kubectl apply -f anf-storageclass.yaml

- ```

- The output of the command resembles the following example:

- ```output

- storageclass/azure-netapp-files created

- ```

-3. Run the [kubectl get][kubectl-get] command to view the status of the storage class:

- ```bash

- kubectl get sc

- NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE

- azure-netapp-files csi.trident.netapp.io Delete Immediate false 3s

- ```

-### Create a persistent volume claim

-A persistent volume claim (PVC) is a request for storage by a user. Upon the creation of a persistent volume claim, Astra Trident automatically creates an Azure NetApp Files volume and makes it available for Kubernetes workloads to consume.

-1. Create a file named `anf-pvc.yaml` and copy the following manifest. In this example, a 1-TiB volume is created that with *ReadWriteMany* access.

- ```yaml

- kind: PersistentVolumeClaim

- apiVersion: v1

- metadata:

- name: anf-pvc

- spec:

- accessModes:

- - ReadWriteMany

- resources:

- requests:

- storage: 1Ti

- storageClassName: azure-netapp-files

- ```

-2. Create the persistent volume claim with the [kubectl apply][kubectl-apply] command:

- ```bash

- kubectl apply -f anf-pvc.yaml

- ```

- The output of the command resembles the following example:

- ```output

- persistentvolumeclaim/anf-pvc created

- ```

-3. To view information about the persistent volume claim, run the [kubectl get][kubectl-get] command:

- ```bash

- kubectl get pvc

- ```

- The output of the command resembles the following example:

- ```bash

- kubectl get pvc -n trident

- NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE

- anf-pvc Bound pvc-bffa315d-3f44-4770-86eb-c922f567a075 1Ti RWO azure-netapp-files 62s

- ```

-### Use the persistent volume

-After the PVC is created, a pod can be spun up to access the Azure NetApp Files volume. The following manifest can be used to define an NGINX pod that mounts the Azure NetApp Files volume created in the previous step. In this example, the volume is mounted at `/mnt/data`.

-1. Create a file named `anf-nginx-pod.yaml` and copy the following manifest:

- ```yml

- kind: Pod

- apiVersion: v1

- metadata:

- name: nginx-pod

- spec:

- containers:

- - name: nginx

- image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine

- resources:

- requests:

- cpu: 100m

- memory: 128Mi

- limits:

- cpu: 250m

- memory: 256Mi

- volumeMounts:

- - mountPath: "/mnt/data"

- name: volume

- volumes:

- - name: volume

- persistentVolumeClaim:

- claimName: anf-pvc

- ```

-2. Create the pod using the [kubectl apply][kubectl-apply] command:

- ```bash

- kubectl apply -f anf-nginx-pod.yaml

- ```

- The output of the command resembles the following example:

- ```output

- pod/nginx-pod created

- ```

- Kubernetes has created a pod with the volume mounted and accessible within the `nginx` container at `/mnt/data`. You can confirm by checking the event logs for the pod using [kubectl describe][kubectl-describe] command:

- ```bash

- kubectl describe pod nginx-pod

- ```

- The output of the command resembles the following example:

- ```output

- [...]

- Volumes:

- volume:

- Type: PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)

- ClaimName: anf-pvc

- ReadOnly: false

- default-token-k7952:

- Type: Secret (a volume populated by a Secret)

- SecretName: default-token-k7952

- Optional: false

- [...]

- Events:

- Type Reason Age From Message

- - - - -

- Normal Scheduled 15s default-scheduler Successfully assigned trident/nginx-pod to brameshb-non-root-test

- Normal SuccessfulAttachVolume 15s attachdetach-controller AttachVolume.Attach succeeded for volume "pvc-bffa315d-3f44-4770-86eb-c922f567a075"

- Normal Pulled 12s kubelet Container image "mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine" already present on machine

- Normal Created 11s kubelet Created container nginx

- Normal Started 10s kubelet Started container nginx

- ```

-Nodes use the [kubenet][kubenet] Kubernetes plugin. You can let the Azure platform create and configure the virtual networks for you, or choose to deploy your AKS cluster into an existing virtual network subnet.

-[kubenet]: https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/

-* Review the [prerequisites](./configure-azure-cni.md#prerequisites) for configuring basic Azure CNI networking in AKS, as the same prerequisites apply to this article.

-* Review the [deployment parameters](./configure-azure-cni.md#deployment-parameters) for configuring basic Azure CNI networking in AKS, as the same parameters apply.

-The [deployment parameters](./configure-azure-cni.md#deployment-parameters) for configuring basic Azure CNI networking in AKS are all valid, with two exceptions:

- :::image type="content" source="media/configure-azure-cni-dynamic-ip-allocation/ip-subnet-usage.png" alt-text="A diagram of the Azure portal's workbook blade is shown, and metrics for an AKS cluster's subnet IP usage are displayed.":::

- #!/bin/sh

- for PVC in $(kubectl get pvc -n $namespace | awk '{ print $1}'); do

- #!/bin/sh

- #!/bin/sh

- #!/bin/sh

- image: k8s.gcr.io/e2e-test-images/busybox:1.29-1

- image: k8s.gcr.io/e2e-test-images/busybox:1.29-1

- image: k8s.gcr.io/e2e-test-images/busybox:1.29-1

-az k8s-extension create --name aml-compute --extension-type Microsoft.AzureML.Kubernetes --scope cluster --cluster-name <clusterName> --resource-group <resourceGroupName> --cluster-type managedClusters --configuration-settings enableInference=True allowInsecureConnections=True

-# Use Draft and the DevX extension for Visual Studio Code with Azure Kubernetes Service (AKS) (preview)

-In the Standard tier, the Uptime SLA feature is enabled by default per cluster. For more information, see [SLA for AKS](https://azure.microsoft.com/support/legal/sla/kubernetes-service/v1_1/).

-The default expiration time for the service principal credentials is one year. If your credentials are older than one year, you can [reset the existing credentials](update-credentials.md#reset-the-existing-service-principal-credentials) or [create a new service principal](update-credentials.md#create-a-new-service-principal).

-[update-credentials]: update-credentials.md

-Azure Kubernetes Service (AKS) is a managed Kubernetes service that lets you quickly deploy and manage Kubernetes clusters. In this tutorial, you will:

-* Deploy an AKS cluster using the Azure CLI with OpenID Connect Issuer and managed identity.

-* Create an Azure Active Directory workload identity and Kubernetes service account

-* Configure the managed identity for token federation

-This tutorial assumes a basic understanding of Kubernetes concepts. For more information, see [Kubernetes core concepts for Azure Kubernetes Service (AKS)][kubernetes-concepts].

-[az account][az-account] command.

-An [Azure resource group][azure-resource-group] is a logical group in which Azure resources are deployed and managed. When you create a resource group, you're prompted to specify a location. This location is:

-* The storage location of your resource group metadata.

-* Where your resources run in Azure if you don't specify another region during resource creation.

-Create a resource group using the [az group create][az-group-create] command.

-```azurecli-interactive

-az group create --name myResourceGroup --location eastus

-```

-The following output example resembles successful creation of the resource group:

-```json

-{

- "id": "/subscriptions/<guid>/resourceGroups/myResourceGroup",

- "location": "eastus",

- "managedBy": null,

- "name": "myResourceGroup",

- "properties": {

- "provisioningState": "Succeeded"

- },

- "tags": null

-}

-```

-To help simplify steps to configure the identities required, the steps below define

-environmental variables for reference on the cluster.

-Run the following commands to create these variables. Replace the default values for `RESOURCE_GROUP`, `LOCATION`, `SERVICE_ACCOUNT_NAME`, `SUBSCRIPTION`, `USER_ASSIGNED_IDENTITY_NAME`, and `FEDERATED_IDENTITY_CREDENTIAL_NAME`.

-```bash

-export RESOURCE_GROUP="myResourceGroup"

-export LOCATION="westcentralus"

-export SERVICE_ACCOUNT_NAMESPACE="default"

-export SERVICE_ACCOUNT_NAME="workload-identity-sa"

-export SUBSCRIPTION="$(az account show --query id --output tsv)"

-export USER_ASSIGNED_IDENTITY_NAME="myIdentity"

-export FEDERATED_IDENTITY_CREDENTIAL_NAME="myFedIdentity"

-export KEYVAULT_NAME="azwi-kv-tutorial"

-export KEYVAULT_SECRET_NAME="my-secret"

-```

-## Create AKS cluster

-Create an AKS cluster using the [az aks create][az-aks-create] command with the `--enable-oidc-issuer` parameter to use the OIDC Issuer. The following example creates a cluster named *myAKSCluster* with one node in the *myResourceGroup*:

-```azurecli-interactive

-az aks create -g "${RESOURCE_GROUP}" -n myAKSCluster --node-count 1 --enable-oidc-issuer --enable-workload-identity

-```

-After a few minutes, the command completes and returns JSON-formatted information about the cluster.

-> [!NOTE]

-> When you create an AKS cluster, a second resource group is automatically created to store the AKS resources. For more information, see [Why are two resource groups created with AKS?][aks-two-resource-groups].

-To get the OIDC Issuer URL and save it to an environmental variable, run the following command. Replace the default value for the arguments `-n`, which is the name of the cluster:

-```azurecli-interactive

-export AKS_OIDC_ISSUER="$(az aks show -n myAKSCluster -g "${RESOURCE_GROUP}" --query "oidcIssuerProfile.issuerUrl" -otsv)"

-```

-Use the Azure CLI [az keyvault create][az-keyvault-create] command to create a Key Vault in the resource group created earlier.

-```azurecli-interactive

-az keyvault create --resource-group "${RESOURCE_GROUP}" --location "${LOCATION}" --name "${KEYVAULT_NAME}"

-```

-The output of this command shows properties of the newly created key vault. Take note of the two properties listed below:

-* **Name**: The Vault name you provided to the `--name` parameter above.

-* **vaultUri**: In the example, this is `https://<your-unique-keyvault-name>.vault.azure.net/`. Applications that use your vault through its REST API must use this URI.

-At this point, your Azure account is the only one authorized to perform any operations on this new vault.

-To add a secret to the vault, you need to run the Azure CLI [az keyvault secret set][az-keyvault-secret-set] command to create it. The password is the value you specified for the environment variable `KEYVAULT_SECRET_NAME` and stores the value of **Hello!** in it.

-```azurecli-interactive

-az keyvault secret set --vault-name "${KEYVAULT_NAME}" --name "${KEYVAULT_SECRET_NAME}" --value 'Hello!'

-```

-To add the Key Vault URL to the environment variable `KEYVAULT_URL`, you can run the Azure CLI [az keyvault show][az-keyvault-show] command.

-```bash

-export KEYVAULT_URL="$(az keyvault show -g "${RESOURCE_GROUP}" -n ${KEYVAULT_NAME} --query properties.vaultUri -o tsv)"

-```

-Use the Azure CLI [az account set][az-account-set] command to set a specific subscription to be the current active subscription. Then use the [az identity create][az-identity-create] command to create a managed identity.

-```azurecli-interactive

-az account set --subscription "${SUBSCRIPTION}"

-```

-```azurecli-interactive

-az identity create --name "${USER_ASSIGNED_IDENTITY_NAME}" --resource-group "${RESOURCE_GROUP}" --location "${LOCATION}" --subscription "${SUBSCRIPTION}"

-```

-Next, you need to set an access policy for the managed identity to access the Key Vault secret by running the following commands:

-```azurecli-interactive

-export USER_ASSIGNED_CLIENT_ID="$(az identity show --resource-group "${RESOURCE_GROUP}" --name "${USER_ASSIGNED_IDENTITY_NAME}" --query 'clientId' -otsv)"

-```

-```azurecli-interactive

-az keyvault set-policy --name "${KEYVAULT_NAME}" --secret-permissions get --spn "${USER_ASSIGNED_CLIENT_ID}"

-```

-Create a Kubernetes service account and annotate it with the client ID of the Managed Identity created in the previous step. Use the [az aks get-credentials][az-aks-get-credentials] command and replace the default value for the cluster name and the resource group name.

-```azurecli-interactive

-az aks get-credentials -n myAKSCluster -g "${RESOURCE_GROUP}"

-```

-Copy and paste the following multi-line input in the Azure CLI.

-```bash

-cat <<EOF | kubectl apply -f -

-apiVersion: v1

-kind: ServiceAccount

-metadata:

- annotations:

- azure.workload.identity/client-id: ${USER_ASSIGNED_CLIENT_ID}

- labels:

- azure.workload.identity/use: "true"

- name: ${SERVICE_ACCOUNT_NAME}

- namespace: ${SERVICE_ACCOUNT_NAMESPACE}

-EOF

-```

-The following output resembles successful creation of the identity:

-```output

-Serviceaccount/workload-identity-sa created

-```

-Use the [az identity federated-credential create][az-identity-federated-credential-create] command to create the federated identity credential between the managed identity, the service account issuer, and the subject.

-```azurecli-interactive

-az identity federated-credential create --name ${FEDERATED_IDENTITY_CREDENTIAL_NAME} --identity-name ${USER_ASSIGNED_IDENTITY_NAME} --resource-group ${RESOURCE_GROUP} --issuer ${AKS_OIDC_ISSUER} --subject system:serviceaccount:${SERVICE_ACCOUNT_NAMESPACE}:${SERVICE_ACCOUNT_NAME}

-```

-> [!NOTE]

-> It takes a few seconds for the federated identity credential to be propagated after being initially added. If a token request is made immediately after adding the federated identity credential, it might lead to failure for a couple of minutes as the cache is populated in the directory with old data. To avoid this issue, you can add a slight delay after adding the federated identity credential.

-Run the following to deploy a pod that references the service account created in the previous step.

-```bash

-cat <<EOF | kubectl apply -f -

-apiVersion: v1

-kind: Pod

-metadata:

- name: quick-start

- namespace: ${SERVICE_ACCOUNT_NAMESPACE}

- labels:

- azure.workload.identity/use: "true"

-spec:

- serviceAccountName: ${SERVICE_ACCOUNT_NAME}

- containers:

- - image: ghcr.io/azure/azure-workload-identity/msal-go

- name: oidc

- env:

- - name: KEYVAULT_URL

- value: ${KEYVAULT_URL}

- - name: SECRET_NAME

- value: ${KEYVAULT_SECRET_NAME}

- nodeSelector:

- kubernetes.io/os: linux

-EOF

-```

-The following output resembles successful creation of the pod:

-```output

-pod/quick-start created

-```

-To check whether all properties are injected properly with the webhook, use

-the [kubectl describe][kubelet-describe] command:

-```bash

-kubectl describe pod quick-start

-```

-To verify that pod is able to get a token and access the secret from the Key Vault, use the

-[kubectl logs][kubelet-logs] command:

-```bash

-kubectl logs quick-start

-```

-The following output resembles successful access of the token:

-```output

-I1013 22:49:29.872708 1 main.go:30] "successfully got secret" secret="Hello!"

-```

-If you plan to continue on to work with subsequent tutorials, you may wish to leave these resources in place.

-When no longer needed, you can run the following Kubectl and the Azure CLI commands to remove the resource group and all related resources.

-```bash

-kubectl delete pod quick-start

-```

-```bash

-kubectl delete sa "${SERVICE_ACCOUNT_NAME}" --namespace "${SERVICE_ACCOUNT_NAMESPACE}"

-```

-```azurecli-interactive

-az group delete --name "${RESOURCE_GROUP}"

-```

-In this tutorial, you deployed a Kubernetes cluster and then deployed a simple container application to

-test working with an Azure AD workload identity.

-[aks-tutorial]: ../tutorial-kubernetes-prepare-app.md

-AKS node image and add-on releases are decoupled from the primary AKS service release. You can select the specific area tab to track the release status.

-On the **AKS addon release page**, you can select a specific add-on name to track its release notes and SDP process.

-This article provides details about technical support policies and limitations for Azure Kubernetes Service (AKS). The article also details agent node management, managed control plane components, third-party open-source components, and security or patch management.

-* For information on features in preview, see the [AKS roadmap](https://github.com/Azure/AKS/projects/1).

-Base infrastructure as a service (IaaS) cloud components, such as compute or networking components, allow you access to low-level controls and customization options. By contrast, AKS provides a turnkey Kubernetes deployment that gives you the common set of configurations and capabilities you need for your cluster. As an AKS user, you have limited customization and deployment options. In exchange, you don't need to worry about or manage Kubernetes clusters directly.

-With AKS, you get a fully managed *control plane*. The control plane contains all of the components and services you need to operate and provide Kubernetes clusters to end users. All Kubernetes components are maintained and operated by Microsoft.

-* Kubernetes proxy or networking (except when [BYOCNI](use-byo-cni.md) is used)

-* Any additional [add-ons][add-ons] or system component running in the kube-system namespace

-AKS isn't a Platform-as-a-Service (PaaS) solution. Some components, such as agent nodes, have *shared responsibility*, where users must help maintain the AKS cluster. User input is required, for example, to apply an agent node operating system (OS) security patch.

-Because your agent nodes execute private code and store sensitive data, Microsoft Support can access them only in a very limited way. Microsoft Support can't sign in to, execute commands in, or view logs for these nodes without your express permission or assistance.

-Any modification done directly to the agent nodes using any of the IaaS APIs renders the cluster unsupportable. Any modification done to the agent nodes must be done using kubernetes-native mechanisms such as `Daemon Sets`.

-Similarly, while you may add any metadata to the cluster and nodes, such as tags and labels, changing any of the system created metadata will render the cluster unsupported.

-* Management, uptime, QoS, and operations of Kubernetes control plane services (Kubernetes control plane, API server, etcd, and coreDNS, for example).

-* Etcd data store. Support includes automated, transparent backups of all etcd data every 30 minutes for disaster planning and cluster state restoration. These backups aren't directly available to you or any users. They ensure data reliability and consistency. On-demand rollback or restore is not supported as a feature.

-> Any cluster actions taken by Microsoft/AKS are made with user consent under a built-in Kubernetes role `aks-service` and built-in role binding `aks-service-rolebinding`. This role enables AKS to troubleshoot and diagnose cluster issues, but can't modify permissions nor create roles or role bindings, or other high privilege actions. Role access is only enabled under active support tickets with just-in-time (JIT) access.

-Microsoft doesn't provide technical support for the following examples:

-* Custom or 3rd-party CNI plugins used in [BYOCNI](use-byo-cni.md) mode.

-Microsoft and users share responsibility for Kubernetes agent nodes where:

-> AKS agent nodes appear in the Azure portal as regular Azure IaaS resources. But these virtual machines are deployed into a custom Azure resource group (usually prefixed with MC_\*). You cannot change the base OS image or do any direct customizations to these nodes using the IaaS APIs or resources. Any custom changes that are not done via the AKS API will not persist through an upgrade, scale, update or reboot. Also any change to the nodes' extensions like the CustomScriptExtension one can lead to unexpected behavior and should be prohibited.

-AKS manages the lifecycle and operations of agent nodes on your behalf - modifying the IaaS resources associated with the agent nodes is **not supported**. An example of an unsupported operation is customizing a node pool virtual machine scale set by manually changing configurations through the virtual machine scale set portal or API.

-

-Using Kubernetes privileged `daemon sets` and init containers enables you to tune/modify or install 3rd party software on cluster agent nodes. Examples of such customizations include adding custom security scanning software or updating sysctl settings.

-While this path is recommended if the above requirements apply, AKS engineering and support cannot assist in troubleshooting or diagnosing modifications that render the node unavailable due to a custom deployed `daemon set`.

-If a security flaw is found in one or more of the managed components of AKS, the AKS team will patch all affected clusters to mitigate the issue. Alternatively, the team will give users upgrade guidance.

-For agent nodes affected by a security flaw, Microsoft will notify you with details on the impact and the steps to fix or mitigate the security issue (normally a node image upgrade or a cluster patch upgrade).

-## Stopped, de-allocated, and "Not Ready" nodes

-If you do not need your AKS workloads to run continuously, you can [stop the AKS cluster](start-stop-cluster.md#stop-an-aks-cluster) which stops all nodepools and the control plane, and start it again when needed. When you stop a cluster using the `az aks stop` command, the cluster state will be preserved for up to 12 months. After 12 months the cluster state and all of its resources will be deleted.

-Manually de-allocating all cluster nodes via the IaaS APIs/CLI/portal is not a supported way to stop an AKS cluster or nodepool. The cluster will be considered out of support and will be stopped by AKS after 30 days. The clusters will then be subject to the same 12 month preservation policy as a correctly stopped cluster.

-Clusters with 0 "Ready" nodes (or all "Not Ready") and 0 Running VMs will be stopped after 30 days.

-AKS reserves the right to archive control planes that have been configured out of support guidelines for extended periods equal to and beyond 30 days. AKS maintains backups of cluster etcd metadata and can readily reallocate the cluster. This reallocation can be initiated by any PUT operation bringing the cluster back into support, such as an upgrade or scale to active agent nodes.

-Features in public preview are fall under 'best effort' support as these features are in preview and not meant for production and are supported by the AKS technical support teams during business hours only. For more information, see:

-* [Azure Support FAQ](https://azure.microsoft.com/support/faq/)

-When a technical support issue is root-caused by one or more upstream bugs, AKS support and engineering teams will:

-* Provide potential workarounds or mitigation. If the issue can be mitigated, a [known issue](https://github.com/Azure/AKS/issues?q=is%3Aissue+is%3Aopen+label%3Aknown-issue) will be filed in the AKS repository. The known-issue filing explains:

-[add-ons]: integrations.md#add-ons

- * [AKS backup using Azure Backup][aks-azure-backup]

-docker tag /azure-vote-front:v1 /azure-vote-front:v2

-Part of the AKS cluster lifecycle involves performing periodic upgrades to the latest Kubernetes version. ItΓÇÖs important you apply the latest security releases, or upgrade to get the latest features. This article shows you how to check for, configure, and apply upgrades to your AKS cluster.

-For AKS clusters that use multiple node pools or Windows Server nodes, see [Upgrade a node pool in AKS][nodepool-upgrade]. To upgrade a specific node pool without doing a Kubernetes cluster upgrade, see [Upgrade a specific node pool][specific-nodepool].

-> Any upgrade operation, whether performed manually or automatically, will upgrade the node image version if not already on the latest. The latest version is contingent on a full AKS release and can be determined by visiting the [AKS release tracker][release-tracker].

-The Azure portal highlights all the deprecated APIs between your current version and newer, available versions you intend to migrate to. For more information, see [the Kubernetes API removal and deprecation process][k8s-deprecation].