Merge pull request #182899 from MicrosoftDocs/master

Merge Master to Live, 4 AM

Author: PMEds28

.openpublishing.redirection.active-directory.json

@@ -10635,8 +10635,12 @@
             "source_path": "articles/active-directory/manage-apps/application-types.md",
             "redirect_url": "/azure/active-directory/manage-apps/application-list",
             "redirect_document_id": false
+        },
+        {
+            "source_path": "articles/active-directory/reports-monitoring/reference-basic-info-identifiers.md",
+            "redirect_url": "/azure/active-directory/reports-monitoring/reference-basic-info-sign-in-logs",
+            "redirect_document_id": false
         }
- 
 
     ]
 }

.openpublishing.redirection.json

@@ -24685,7 +24685,7 @@
     },
     {
       "source_path_from_root": "/articles/sentinel/connect-dns.md",
-      "redirect_url": "/azure/sentinel/data-connectors-reference#domain-name-server",
+      "redirect_url": "/azure/sentinel/data-connectors-reference#windows-dns-server-preview",
       "redirect_document_id": false
     },
     {

articles/active-directory/develop/TOC.yml

@@ -161,6 +161,8 @@
       href: zero-trust-for-developers.md
     - name: Best practices for least privileged access for apps
       href: secure-least-privileged-access.md
+    - name: Secure line-of-business applications using Zero Trust principles
+      href: secure-line-of-business-apps.md
     - name: Security best practices for Azure AD application registration
       href: security-best-practices-for-app-registration.md
   - name: Automatic user provisioning (SCIM)

articles/active-directory/develop/media/secure-line-of-business-apps/secure-hybrid-access.png

@@ -0,0 +1,74 @@
+---
+title: Secure identity in line-of-business applications using Zero Trust principles
+titleSuffix: Microsoft identity platform
+description: Learn our recommended approach for securing identity in the line of business applications you develop using a Zero Trust approach.
+services: active-directory
+author: knicholasa
+manager: martincoetzer
+
+ms.service: active-directory
+ms.subservice: develop
+ms.topic: conceptual
+ms.workload: identity
+ms.date: 09/09/2021
+ms.custom: template-concept
+ms.author: nichola
+ms.reviewer: cchiedo, kylemar, stsoneff
+
+# Customer intent: I am a technical decision maker (dev or IT pro) creating or maintaining a server-side line-of-business app. I want architecture-level recommendations on how I can protect my server-side line-of-business apps using a Zero Trust strategy for Identity
+---
+
+# Secure identity in line-of-business application using Zero Trust principles
+
+Zero Trust is a framework for organizational security designed to support modern work scenarios like remote collaboration and working from home. App developers should support Zero Trust principles for a couple reasons. First, developers should adopt security best practices that are designed for the modern environments. Second, customers will expect a secure solution that follows the Zero Trust principles they use to secure their organization. This guidance explains how app developers can implement a Zero Trust strategy for managing identity in line-of-business apps.
+
+Line-of-business apps are defined here as applications used by employees as part of their day-to-day work that are developed by or specifically for the organization. These applications were traditionally accessed from inside a secure corporate network. Now, employees increasingly access them from remote networks and their own devices. To support this new paradigm, apps should be accessible from the internet and not just from inside a corporate network.
+
+The guidance is structured around the key principles of Zero Trust: verify explicitly, use least-privileged access, and assume breach.
+
+## Verify explicitly
+
+A secure identity solution means that an app only provides access to authenticated users. Most developers are not identity experts. So it is important that you find a solution that makes it easy for you or your team to implement secure modern authentication. You can use one of the following solutions.
+
+- For a new application, use a cloud-hosted solution that handles authentication for you.
+- To update the security of an existing application, either use a Zero Trust network access (ZTNA) solution that uses modern authentication, or implement authentication using the Microsoft Authentication Library (MSAL) and use Azure Active Directory as your identity provider.
+
+These solutions are explained in more detail below.
+
+### Cloud-hosted solution
+
+Using a cloud hosted solution can provide modern authentication without needing to implement any lines of code. For example, [Microsoft 365](/microsoft-365/enterprise/about-microsoft-365-identity), Dynamics 365 and [Power Apps](/powerapps/maker/portals/configure/use-simplified-authentication-configuration) allow you to secure access with Azure Active Directory – giving you single sign-on and multifactor authentication for free.
+
+If you are building your own application, Azure App Service has [built in authentication and authorization](/azure/app-service/overview-authentication-authorization) that will protect your application without needing to use any particular language, SDK, or even code.
+
+We recommend this approach because it is easy and leaves the least room for error. For example, if you use Azure App Service to host your app you can focus on implementing the business logic of the app. [Registration with Azure Active Directory](/azure/app-service/configure-authentication-provider-aad) can be done automatically. However, you do have the flexibility to customize the authentication logic and choose an alternative identity provider if you want.
+
+### Zero Trust network access solution
+
+Zero Trust network access solutions provide secure remote access to individual on-premises applications. Azure AD works with partners to enable scalable Zero Trust network access that supports various authentication protocols. You can find a list of partners and integrations on the [secure hybrid access docs page](/azure/active-directory/manage-apps/secure-hybrid-access).
+
+[Azure AD Application Proxy](/azure/active-directory/app-proxy/application-proxy) is another solution which uses Azure AD to support modern authentication and remote access for on-premises applications that use header-based, Kerberos, SAML, and anonymous authentication. You can use this solution without having to modify your existing apps. With it, users can access the on-premises apps through an external URL or internal application portal. You can enable Azure AD security features and controls such as single sign-on, conditional access, and multifactor authentication.
+
+:::image type="content" source="./media/secure-line-of-business-apps/secure-hybrid-access.png" alt-text="Illustration of Secure Hybrid Access partner integrations and Application Proxy providing access to legacy and on-premises applications after authentication with Azure AD." border="false":::
+
+### Custom built – hosted anywhere
+
+Finally, you can implement secure authentication and authorization in your application using a trusted authentication library and Azure Active Directory. Our [Microsoft Authentication Library (MSAL)](/azure/active-directory/develop/msal-overview) is designed to make it easy to implement authentication and authorization – you implement minimal logic in your own app and the library handles the details of authentication for you. Using this approach makes sense if you have already implemented authentication logic in the app and are looking to update it to modern auth.
+
+However, using this approach takes extra care. IT admins will need to work with developers to plan and enable which security features to add. It also requires developers to learn how to implement the features you need, and a library that fits well to your development scenario. Finally, your application can still be discoverable. For example, someone may still be able to access the login page for your application – whereas if you use a Zero Trust network solution can hide the app completely from unauthenticated users.
+
+## Use least privileged access
+
+Any application can potentially be abused by bad actors who pretend to be someone they are not and use the application as an entry point to gain further access into the network. For this reason, it is important to design your application so that it is given the minimal privilege necessary to serve its purpose. By limiting what your app is capable of doing, you reduce the potential blast radius of attacks. This is especially important with line-of-business applications, which often need access to sensitive company information.
+
+To design your application for least privilege access, you can follow our guidance on [enhancing app security with the principle of least privilege](/azure/active-directory/develop/secure-least-privileged-access). The recommendations include revoking unused and reducible permissions, requiring that a human consents to the app's request to access protected data, building applications with least privilege in mind during all stages of development, and auditing your deployed applications periodically to identify over-privileged apps.
+
+## Assume breach
+
+Using the Zero Trust framework, applications are designed so that if a cybersecurity incident does occur, you are able to minimize the blast radius and respond swiftly.
+
+You should make your application auditable by logging authentication behavior. Azure App Service allows you to [enable application logging](/azure/app-service/overview-authentication-authorization#logging-and-tracing), as does [Azure AD Application Proxy](/azure/active-directory/app-proxy/application-proxy-connectors#under-the-hood). MSAL has instructions for how to implement logging for the various languages it supports, like [MSAL.NET](/azure/active-directory/develop/msal-logging-dotnet).
+
+## Next steps
+
+[Zero Trust guidance for identity](/security/zero-trust/develop/identity)

articles/active-directory/develop/secure-line-of-business-apps.md

@@ -247,7 +247,7 @@ The AADLoginForWindows extension must install successfully in order for the VM t
 
 1. RDP to the VM using the local administrator account and examine the `CommandExecution.log` file under:
 
-   `C:\WindowsAzure\Logs\Plugins\Microsoft.Azure.ActiveDirectory.AADLoginForWindows\0.3.1.0.`
+   `C:\WindowsAzure\Logs\Plugins\Microsoft.Azure.ActiveDirectory.AADLoginForWindows\1.0.0.1\`
 
    > [!NOTE]
    > If the extension restarts after the initial failure, the log with the deployment error will be saved as `CommandExecution_YYYYMMDDHHMMSSSSS.log`. 

articles/active-directory/devices/howto-vm-sign-in-azure-ad-windows.md

@@ -49,6 +49,7 @@ The rows in a downloaded CSV template are as follows:
 - We don't recommend adding new columns to the template. Any additional columns you add are ignored and not processed.
 - We recommend that you download the latest version of the CSV template as often as possible.
 - Make sure to check there is no unintended whitespace before/after any field. For **User principal name**, having such whitespace would cause import failure.
+- Ensure that values in **Initial password** comply with the currently active [password policy](../authentication/concept-sspr-policy.md#password-policies-that-only-apply-to-cloud-user-accounts).
 
 ## To create users in bulk
 

articles/active-directory/enterprise-users/users-bulk-add.md

@@ -23,7 +23,6 @@ By using filtering, you can control which objects appear in Azure Active Directo
 
 In some cases however, you're required make some changes to the default configuration. Here are some examples:
 
-* You plan to use the [multi-Azure AD directory topology](plan-connect-topologies.md#each-object-only-once-in-an-azure-ad-tenant). Then you need to apply a filter to control which objects are synchronized to a particular Azure AD directory.
 * You run a pilot for Azure or Microsoft 365 and you only want a subset of users in Azure AD. In the small pilot, it's not important to have a complete Global Address List to demonstrate the functionality.
 * You have many service accounts and other nonpersonal accounts that you don't want in Azure AD.
 * For compliance reasons, you don't delete any user accounts on-premises. You only disable them. But in Azure AD, you only want active accounts to be present.

articles/active-directory/hybrid/how-to-connect-sync-configure-filtering.md

@@ -135,56 +135,33 @@ You can also use this method to replace the active sync server. Prepare the new
 It's possible to have more than one staging server when you want to have multiple backups in different datacenters.
 
 ## Multiple Azure AD tenants
-We recommend having a single tenant in Azure AD for an organization.
-![Multiple forests and multiple tenants](./media/plan-connect-topologies/multi-tenant-1.png)
-Before you plan to use multiple Azure AD tenants, see the article [Administrative units management in Azure AD](../roles/administrative-units.md). It covers common scenarios where you can use a single tenant.
+We recommend having a single tenant in Azure AD for an organization. Before you plan to use multiple Azure AD tenants, see the article [Administrative units management in Azure AD](../roles/administrative-units.md). It covers common scenarios where you can use a single tenant.
 
-![Topology for multiple forests and multiple tenants](./media/plan-connect-topologies/multiforestmultidirectory.png)
+### (Public preview) Each object multiple times in an Azure AD tenant
 
-There's a 1:1 relationship between an Azure AD Connect sync server and an Azure AD tenant. For each Azure AD tenant, you need one Azure AD Connect sync server installation. The Azure AD tenant instances are isolated by design. That is, users in one tenant can't see users in the other tenant. If you want this separation, this is a supported configuration. Otherwise, you should use the single Azure AD tenant model.
+![Diagram that shows a topology of multiple Azure A D tenants.](./media/plan-connect-topologies/multi-tenant-1.png)
 
-### Each object only once in an Azure AD tenant
-![Filtered topology for a single forest](./media/plan-connect-topologies/singleforestfiltered.png)
+> [!NOTE]
+> This topology is currently in Public Preview. As the supported scenarios might still change, we recommend not deploying this topology in a production environment.
 
-In this topology, one Azure AD Connect sync server is connected to each Azure AD tenant. The Azure AD Connect sync servers must be configured for filtering so that each has a mutually exclusive set of objects to operate on. You can, for example, scope each server to a particular domain or organizational unit.
+This topology implements the following use cases:
 
-A DNS domain can be registered in only a single Azure AD tenant. The UPNs of the users in the on-premises Active Directory instance must also use separate namespaces. For example, in the preceding picture, three separate UPN suffixes are registered in the on-premises Active Directory instance: contoso.com, fabrikam.com, and wingtiptoys.com. The users in each on-premises Active Directory domain use a different namespace.
+* AADConnect can synchronize the same users, groups, and contacts from a single Active Directory to multiple Azure AD tenants. These tenants can be in different Azure environments, such as the Azure China environment or the Azure Government environment, but they could also be in the same Azure environment, such as two tenants that are both in Azure Commercial. 
+*	The same Source Anchor can be used for a single object in separate tenants (but not for multiple objects in the same tenant)
+*	You will need to deploy an AADConnect server or deploy an AADConnect Provisioning Agent for every Azure AD tenant you want to synchronize to - one AADConnect server cannot synchronize to more than one Azure AD tenant. Note that the Provisioning Agent is required for every forest you want to synchronize – but it is supported to have different sync scopes and different sync rules for different tenants.
+*	Only one Azure AD tenant sync can be configured to write back to Active Directory for the same object. This includes device and group writeback as well as Hybrid Exchange configurations – these features can only be configured in one tenant. The only exception here is Password Writeback – see below.
+*	It is supported to configure Password Hash Sync from Active Directory to multiple Azure AD tenants for the same user object. If Password Hash Sync is enabled for a tenant, then Password Writeback may be enabled as well, and this can be done on multiple tenants: if the password is changed on one tenant, then password writeback will update it in Active Directory, and Password Hash Sync will update the password in the other tenants.
+*	It is not supported to use the same custom domain name in more than one Azure AD tenant, with one exception: it is supported to use a custom domain name in the Azure Commercial environment and use that same domain name in the Azure GCCH environment. Note that the custom domain name MUST exist in Commercial before it can be verified in the GCCH environment.
+*	It is not supported to configure hybrid experiences such as Seamless SSO and Hybrid Azure AD Join on more than one tenant. Doing so would overwrite the configuration of the other tenant and would make it unusable. 
+*	You can synchronize device objects to more than one tenant but only one tenant can be configured to trust a device.
+* Each Azure AD Connect instance should be running on a domain-joined machine.
 
 >[!NOTE]
 >Global Address List Synchronization (GalSync) is not done automatically in this topology and requires an additional custom MIM implementation to ensure each tenant has a complete Global Address List (GAL) in Exchange Online and Skype for Business Online.
 
-
-This topology has the following restrictions on otherwise supported scenarios:
-
-* A maximum of 5 Azure Active Directory tenants can have Exchange Hybrid with the on-premises Active Directory instance. This scenario is described in [September 2020 Hybrid Configuration Wizard Update](https://techcommunity.microsoft.com/t5/exchange-team-blog/september-2020-hybrid-configuration-wizard-update/ba-p/1687698).
-* Exchange Server running Hybrid Configuration Wizard should be either 2016 CU18 or 2019 CU7 or later.
-* Each Azure AD Connect instance should be running on a domain-joined machine.
-* Azure AD Connect must be configured by using the Domain/OU filtering option to filter users from your on-premises directory. Using this option ensures that users appear only in a single online Exchange tenant.
-* Windows 10 devices can be associated with only one Azure AD tenant.
-* The single sign-on (SSO) option for password hash synchronization and pass-through authentication can be used with only one Azure AD tenant.
-
-The requirement for a mutually exclusive set of objects also applies to writeback. Some writeback features are not supported with this topology because they assume a single on-premises configuration. These features include:
-
-* Group writeback with default configuration.
-* Device writeback.
-
-### Each object multiple times in an Azure AD tenant
-![Unsupported topology for a single forest and multiple tenants](./media/plan-connect-topologies/singleforestmultidirectoryunsupported.png) ![Unsupported topology for a single forest and multiple connectors](./media/plan-connect-topologies/singleforestmulticonnectorsunsupported.png)
-
-These tasks are unsupported:
-
-* Sync the same user to multiple Azure AD tenants.
-* Make a configuration change so that users in one Azure AD tenant appear as contacts in another Azure AD tenant.
-* Modify Azure AD Connect sync to connect to multiple Azure AD tenants.
-
 ### GALSync by using writeback
 ![Unsupported topology for multiple forests and multiple directories, with GALSync focusing on Azure AD](./media/plan-connect-topologies/multiforestmultidirectorygalsync1unsupported.png) ![Unsupported topology for multiple forests and multiple directories, with GALSync focusing on on-premises Active Directory](./media/plan-connect-topologies/multiforestmultidirectorygalsync2unsupported.png)
 
-Azure AD tenants are isolated by design. These tasks are unsupported:
-
-* Change the configuration of Azure AD Connect sync to read data from another Azure AD tenant.
-* Export users as contacts to another on-premises Active Directory instance by using Azure AD Connect sync.
-
 ### GALSync with on-premises sync server
 ![GALSync in a topology for multiple forests and multiple directories](./media/plan-connect-topologies/multiforestmultidirectorygalsync.png)