staging

billmath · billmath · commit a0d21ffc2f15 · 2022-11-11T10:20:26.000-05:00
diff --git a/articles/active-directory/hybrid/plan-hybrid-identity-design-considerations-identity-adoption-strategy.md b/articles/active-directory/hybrid/plan-hybrid-identity-design-considerations-identity-adoption-strategy.md
@@ -25,17 +25,17 @@ In this task, you define the hybrid identity adoption strategy for your hybrid i
 * [Determine multi-factor authentication requirements](plan-hybrid-identity-design-considerations-multifactor-auth-requirements.md)
 
 ## Define business needs strategy
-The first task addresses determining the organizations business needs.  This can be very broad and scope creep can occur if you are not careful.  In the beginning, keep it simple but always remember to plan for a design that will accommodate and facilitate change in the future.  Regardless of whether it is a simple design or a complex one, Azure Active Directory is the Microsoft Identity platform that supports Microsoft 365, Microsoft Online Services, and cloud aware applications.
+The first task addresses determining the organizations business needs.  This task can be broad and scope creep can occur if you are not careful.  In the beginning, keep it simple but always remember to plan for a design that will accommodate and facilitate change in the future.  Regardless of whether it is a simple design or a complex one, Azure Active Directory is the Microsoft Identity platform that supports Microsoft 365, Microsoft Online Services, and cloud aware applications.
 
 ## Define an integration strategy
-Microsoft has three main integration scenarios: cloud identities, synchronized identities, and federated identities.  You should plan on adopting one of these integration strategies.  The strategy you choose can vary and the decisions in choosing one may include, what type of user experience you want to provide, do you have an existing infrastructure, and what is the most cost effective.  
+Microsoft has three main integration scenarios: cloud identities, synchronized identities, and federated identities.  You should plan on adopting one of these integration strategies.  The strategy you choose can vary. Decisions in choosing one may include, what type of user experience you want to provide, do you have an existing infrastructure, and what is the most cost effective.  
 
 ![integration scenarios](./media/plan-hybrid-identity-design-considerations/integration-scenarios.png)
 
 The scenarios defined in the above figure are:
 
 * **Cloud identities**: identities that exist solely in the cloud.  In the case of Azure AD, they would reside specifically in your Azure AD directory.
-* **Synchronized**: identities that exist on-premises and in the cloud.  Using Azure AD Connect, users are either created or joined with existing Azure AD accounts.  The user’s password hash is synchronized from the on-premises environment to the cloud in what is called a password hash.  When using synchronized the one caveat is that if a user is disabled in the on-premises environment, it can take up to three hours for that account status to show up in Azure AD.  This behavior is due to the synchronization time interval.
+* **Synchronized**: identities that exist on-premises and in the cloud.  Using Azure AD Connect, users are either created or joined with existing Azure AD accounts.  The user’s password hash is synchronized from the on-premises environment to the cloud in what is called a password hash.  Remember that if a user is disabled in the on-premises environment, it can take up to three hours for that account status to show up in Azure AD.  This behavior is due to the synchronization time interval.
 * **Federated**: identities exist both on-premises and in the cloud.  Using Azure AD Connect, users are either created or joined with existing Azure AD accounts.  
 
 > [!NOTE]
@@ -49,7 +49,7 @@ The following table helps in determining the advantages and disadvantages of eac
 | --- | --- | --- |
 | **Cloud identities** |Easier to manage for small organization. <br> Nothing to install on-premises. No extra hardware needed<br>Easily disabled if the user leaves the company |Users will need to sign in when accessing workloads in the cloud <br> Passwords may or may not be the same for cloud and on-premises identities |
 | **Synchronized** |On-premises password authenticates both on-premises and cloud directories <br>Easier to manage for small, medium, or large organizations <br>Users can have single sign-on (SSO) for some resources <br> Microsoft preferred method for synchronization <br> Easier to manage |Some customers may be reluctant to synchronize their directories with the cloud due specific company’s policies |
-| **Federated** |Users can have single sign-on (SSO) <br>If a user is terminated or leaves, the account can be immediately disabled and access revoked,<br> Supports advanced scenarios that cannot be accomplished with synchronized |More steps to set up and configure <br> Higher maintenance <br> May require extra hardware for the STS infrastructure <br> May require extra hardware to install the federation server. Additional software is required if AD FS is used <br> Require extensive setup for SSO <br> Critical point of failure if the federation server is down, users won’t be able to authenticate |
+| **Federated** |Users can have single sign-on (SSO) <br>If a user is terminated or leaves, the account can be immediately disabled and access revoked,<br> Supports advanced scenarios that cannot be accomplished with synchronized |More steps to set up and configure <br> Higher maintenance <br> May require extra hardware for the STS infrastructure <br> May require extra hardware to install the federation server. Other software is required if AD FS is used <br> Require extensive setup for SSO <br> Critical point of failure if the federation server is down, users won’t be able to authenticate |
 
 ### Client experience
 The strategy that you use will dictate the user sign-in experience.  The following tables provide you with information on what the users should expect their sign-in experience to be.  Not all federated identity providers support SSO in all scenarios.
@@ -73,7 +73,7 @@ The strategy that you use will dictate the user sign-in experience.  The followi
 | Exchange ActiveSync |Prompt for credentials |single sign-on for Lync, prompted credentials for Exchange |
 | Mobile apps |Prompt for credentials |Prompt for credentials |
 
-If you have determined from task 1 that you have a third-party IdP or are going to use one to provide federation with Azure AD, you need to be aware of the following supported capabilities:
+If you have a third-party IdP or are going to use one to provide federation with Azure AD, you need to be aware of the following supported capabilities:
 
 * Any SAML 2.0 provider that is compliant for the SP-Lite profile can support authentication to Azure AD and associated applications
 * Supports passive authentication, which facilitates authentication to OWA, SPO, etc.
@@ -91,7 +91,7 @@ You must also be aware of what capabilities will not be available:
 > 
 
 ## Define synchronization strategy
-In this task you will define the tools that will be used to synchronize the organization’s on-premises data to the cloud and what topology you should use.  Because, most organizations use Active Directory, information on using Azure AD Connect to address the questions above is provided in some detail.  For environments that do not have Active Directory, there is information about using FIM 2010 R2 or MIM 2016 to help plan this strategy.  However, future releases of Azure AD Connect will support LDAP directories, so depending on your timeline, this information may be able to assist.
+This task defines the tools that will be used to synchronize the organization’s on-premises data to the cloud and what topology you should use.  Because, most organizations use Active Directory, information on using Azure AD Connect to address the questions above is provided in some detail.  For environments that do not have Active Directory, there is information about using FIM 2010 R2 or MIM 2016 to help plan this strategy.  However, future releases of Azure AD Connect will support LDAP directories, so depending on your timeline, this information may be able to assist.
 
 ### Synchronization tools
 Over the years, several synchronization tools have existed and used for various scenarios.  Currently Azure AD Connect is the go to tool of choice for all supported scenarios.  AAD Sync and DirSync are also still around and may even be present in your environment now. 
@@ -103,7 +103,7 @@ Over the years, several synchronization tools have existed and used for various
 
 ### Supported topologies
 When defining a synchronization strategy, the topology that is used must be determined. Depending on the information that was determined in step 2 you can determine which topology is the proper one to use. 
-The single forest, single Azure AD topology is the most common and consists of a single Active Directory forest and a single instance of Azure AD.  This topology is going to be used in a majority of the scenarios and is the expected topology when using Azure AD Connect Express installation as shown in the figure below.
+The single forest, single Azure AD topology is the most common and consists of a single Active Directory forest and a single instance of Azure AD.  This topology is going to be used in a most scenarios and is the expected topology when using Azure AD Connect Express installation as shown in the figure below.
 
 ![Supported topologies](./media/plan-hybrid-identity-design-considerations/single-forest.png)
 Single Forest Scenario
@@ -118,19 +118,19 @@ It is common for large and even small organizations to have multiple forests, as
 
 Multi-Forest Scenario
 
-If this is the case, then the multi-forest single Azure AD topology should be considered if the following items are true:
+The multi-forest single Azure AD topology should be considered if the following items are true:
 
-* Users have only 1 identity across all forests – the uniquely identifying users section below describes this in more detail.
+* Users have only 1 identity across all forests – the uniquely identifying users section below describes this scenario in more detail.
 * The user authenticates to the forest in which their identity is located
 * UPN and Source Anchor (immutable id) will come from this forest
-* All forests are accessible by Azure AD Connect – this means it does not need to be domain joined and can be placed in a DMZ if this facilitates this.
+* All forests are accessible by Azure AD Connect – meaning it does not need to be domain joined and can be placed in a DMZ.
 * Users have only one mailbox
 * The forest that hosts a user’s mailbox has the best data quality for attributes visible in the Exchange Global Address List (GAL)
 * If there is no mailbox on the user, then any forest may be used to contribute values
 * If you have a linked mailbox, then there is also another account in a different forest used to sign in.
 
 > [!NOTE]
-> Objects that exist in both on-premises and in the cloud are “connected” via a unique identifier. In the context of Directory Synchronization, this unique identifier is referred to as the SourceAnchor. In the context of Single Sign-On, this is referred to as the ImmutableId. [Design concepts for Azure AD Connect](plan-connect-design-concepts.md#sourceanchor) for more considerations regarding the use of SourceAnchor.
+> Objects that exist in both on-premises and in the cloud are “connected” via a unique identifier. In the context of Directory Synchronization, this unique identifier is referred to as the SourceAnchor. In the context of Single Sign-On, this identifier is referred to as the ImmutableId. [Design concepts for Azure AD Connect](plan-connect-design-concepts.md#sourceanchor) for more considerations regarding the use of SourceAnchor.
 > 
 > 
 
@@ -140,15 +140,15 @@ If the above are not true and you have more than one active account or more than
 
 **Multi-forest multiple Azure AD scenario**
 
-It is recommended to have just a single directory in Azure AD for an organization but it is supported it a 1:1 relationship is kept between an Azure AD Connect sync server and an Azure AD directory.  For each instance of Azure AD, you need an installation of Azure AD Connect.  Also, Azure AD, by design is isolated and users in one instance of Azure AD will not be able to see users in another instance.
+It is recommended to have just a single directory in Azure AD for an organization. However, it is supported if a 1:1 relationship is kept between an Azure AD Connect sync server and an Azure AD directory.  For each instance of Azure AD, you need an installation of Azure AD Connect.  Also, Azure AD, by design is isolated and users in one instance of Azure AD, will not be able to see users in another instance.
 
 It is possible and supported to connect one on-premises instance of Active Directory to multiple Azure AD directories as shown in the figure below:
 
 ![single forest filtering](./media/plan-hybrid-identity-design-considerations/single-forest-flitering.png) 
 
 **Single-forest filtering scenario**
 
-To do this, the following must be true:
+The following statements must be true:
 
 * Azure AD Connect sync servers must be configured for filtering so they each have a mutually exclusive set of objects.  This done, for example, by scoping each server to a particular domain or OU.
 * A DNS domain can only be registered in a single Azure AD directory so the UPNs of the users in the on-premises AD must use separate namespaces
@@ -158,7 +158,7 @@ To do this, the following must be true:
   * Group write-back with default configuration
   * Device write-back
 
-The following is not supported and should not be chosen as an implementation:
+The following items are not supported and should not be chosen as an implementation:
 
 * It is not supported to have multiple Azure AD Connect sync servers connecting to the same Azure AD directory even if they are configured to synchronize mutually exclusive set of object
 * It is unsupported to sync the same user to multiple Azure AD directories. 
@@ -172,7 +172,7 @@ The following is not supported and should not be chosen as an implementation:
 > 
 
 ## Define multi-factor authentication strategy
-In this task you will define the multi-factor authentication strategy to use.  Azure AD Multi-Factor Authentication comes in two different versions.  One is a cloud-based and the other is on-premises based using the Azure MFA Server.  Based on the evaluation you did above you can determine which solution is the correct one for your strategy.  Use the table below to determine which design option best fulfills your company’s security requirement:
+In this task, you will define the multi-factor authentication strategy to use.  Azure AD Multi-Factor Authentication comes in two different versions.  One is a cloud-based and the other is on-premises based using the Azure MFA Server.  Based on the evaluation you did above you can determine which solution is the correct one for your strategy.  Use the table below to determine which design option best fulfills your company’s security requirement:
 
 Multi-factor design options:
 
