From d6078116076780b8ea991a4767a4ecb6b3d124da Mon Sep 17 00:00:00 2001 From: Paolo Matarazzo <74918781+paolomatarazzo@users.noreply.github.com> Date: Fri, 14 Oct 2022 14:03:09 -0400 Subject: [PATCH] update --- education/windows/federated-sign-in.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/education/windows/federated-sign-in.md b/education/windows/federated-sign-in.md index 2aeb49483d..0f769a31e1 100644 --- a/education/windows/federated-sign-in.md +++ b/education/windows/federated-sign-in.md @@ -33,7 +33,7 @@ To implement federated sign-in, the following prerequisites must be met: 1. An Azure AD tenant, with one or multiple domains federated to a third-party SAML 2.0 IdP. For more information, see [Use a SAML 2.0 Identity Provider (IdP) for Single Sign On][AZ-1] >[!NOTE] - >If your organization uses a third-party federation solution, you can configure single sign-on to Azure Active Directory if the solution is compatible with Azure Active Directory. For questions regarding compatibility, please contact your identity provider. If you would like to test your product for interoperability please refer to these [guidelines][MSFT-1]. + >If your organization uses a third-party federation solution, you can configure single sign-on to Azure Active Directory if the solution is compatible with Azure Active Directory. For questions regarding compatibility, please contact your identity provider. If you're an IdP, and would like to validate your solution for interoperability, please refer to these [guidelines][MSFT-1]. 1. Individual IdP accounts created: each user will require an account defined in the third-party IdP platform 1. Individual Azure AD accounts created: each user will require a matching account defined in Azure AD. These accounts are commonly created through automated solutions, for example: - [School Data Sync (SDS)][SDS-1]