Merge branch 'master' of https://github.com/Microsoft/azure-docs-pr into 0613-eventhub-quickstart

Author: mumian

.markdownlint.json

@@ -0,0 +1,42 @@
+{
+    "default": true,
+    "MD001": false,
+    "MD002": false,
+    "MD003": false,
+    "MD004": false,
+    "MD005": false,
+    "MD006": false,
+    "MD007": false,
+    "MD009": false,
+    "MD010": false,
+    "MD011": false,
+    "MD012": false,
+    "MD013": false,
+    "MD014": false,
+    "MD018": false,
+    "MD019": false,
+    "MD020": false,
+    "MD021": false,
+    "MD022": false,
+    "MD023": false,
+    "MD024": false,
+    "MD025": false,
+    "MD026": false,
+    "MD027": false,
+    "MD028": false,
+    "MD029": false,
+    "MD030": false,
+    "MD031": false,
+    "MD032": false,
+    "MD033": false,
+    "MD034": false,
+    "MD035": false,
+    "MD036": false,
+    "MD037": false,
+    "MD038": false,
+    "MD039": false,
+    "MD040": false,
+    "MD041": false,
+    "MD042": false,
+    "MD045": false
+}

articles/active-directory-b2c/active-directory-b2c-faqs.md

@@ -23,7 +23,7 @@ There are two common reasons for why the Azure AD extension is not working for y
 Azure AD and Azure AD B2C are separate product offerings and cannot coexist in the same tenant.  An Azure AD tenant represents an organization.  An Azure AD B2C tenant represents a collection of identities to be used with relying party applications.  With custom policies (in public preview), Azure AD B2C can federate to Azure AD allowing authentication of employees in an organization.
 
 ### Can I use Azure AD B2C to provide social login (Facebook and Google+) into Office 365?
-Azure AD B2C can't be used to authenticate users for Microsoft Office 365.  Azure AD is Microsoft's solution for managing employee access to SaaS apps and it has features designed for this purpose such as licensing and conditional access.  Azure AD B2C provides an identity and access management platform for building web and mobile applications.  When Azure AD B2C is configured to federate to an Azure AD tenant, the Azure AD tenant manages employee access to applications that rely on Azure AD B2C.
+Azure AD B2C can't be used to authenticate users for Microsoft Office 365.  Azure AD is Microsoft's solution for managing employee access to SaaS apps and it has features designed for this purpose such as licensing and Conditional Access.  Azure AD B2C provides an identity and access management platform for building web and mobile applications.  When Azure AD B2C is configured to federate to an Azure AD tenant, the Azure AD tenant manages employee access to applications that rely on Azure AD B2C.
 
 ### What are local accounts in Azure AD B2C? How are they different from work or school accounts in Azure AD?
 In an Azure AD tenant, users that belong to the tenant sign-in with an email address of the form `<xyz>@<tenant domain>`.  The `<tenant domain>` is one of the verified domains in the tenant or the initial `<...>.onmicrosoft.com` domain. This type of account is a work or school account.

articles/active-directory/authentication/concept-sspr-writeback.md

@@ -148,7 +148,6 @@ Passwords are written back in all the following situations:
    * Any administrator self-service force change password operation, for example, password expiration
    * Any administrator self-service password reset that originates from the [password reset portal](https://passwordreset.microsoftonline.com)
    * Any administrator-initiated end-user password reset from the [Azure portal](https://portal.azure.com)
-   * Any administrator-initiated end-user password reset from the [Microsoft 365 admin center](https://admin.microsoft.com)
 
 ## Unsupported writeback operations
 
@@ -158,6 +157,7 @@ Passwords are *not* written back in any of the following situations:
    * Any end user resetting their own password by using PowerShell version 1, version 2, or the Azure AD Graph API
 * **Unsupported administrator operations**
    * Any administrator-initiated end-user password reset from PowerShell version 1, version 2, or the Azure AD Graph API
+   * Any administrator-initiated end-user password reset from the [Microsoft 365 admin center](https://admin.microsoft.com)
 
 > [!WARNING]
 > Use of the checkbox "User must change password at next logon" in on-premises Active Directory administrative tools like Active Directory Users and Computers or the Active Directory Administrative Center is not supported. When changing a password on-premises do not check this option.

articles/active-directory/b2b/leave-the-organization.md

@@ -7,7 +7,7 @@ services: active-directory
 ms.service: active-directory
 ms.subservice: B2B
 ms.topic: conceptual
-ms.date: 03/13/2019
+ms.date: 06/13/2019
 
 ms.author: mimart
 author: msmimart
@@ -21,11 +21,14 @@ ms.collection: M365-identity-device-management
 
 An Azure Active Directory (Azure AD) B2B guest user can decide to leave an organization at any time if they no longer need to use apps from that organization or maintain any association. A user can leave an organization on their own, without having to contact an administrator.
 
+> [!NOTE]
+> A guest user can't leave an organization if their account is disabled in either the home tenant or the resource tenant. If their account is disabled, the guest user will need to contact the tenant admin, who can either delete the guest account or enable the guest account so the user can leave the organization.
+
 ## Leave an organization
 
 To leave an organization, follow these steps.
 
-1. Go to your Access Panel Profile page by doing one of the following:
+1. Go to your Access Panel Profile page by doing one of the following steps:
 
    - In the [Azure portal](https://portal.azure.com), click your name in the upper right and select **View account**.
    - Open your [Access Panel](https://myapps.microsoft.com), click your name in the upper right, and next to **Organizations**, select the settings icon (gear).
@@ -43,7 +46,7 @@ To leave an organization, follow these steps.
 
 ## Account removal
 
-When a user leaves an organization, the user account is "soft deleted" in the directory. By default, the user object moves to the **Deleted users** area in Azure AD but is not permanently deleted for 30 days. This soft deletion enables the administrator to restore the user account (including groups and permissions), if the user makes a request to restore the account within the 30-day period.
+When a user leaves an organization, the user account is "soft deleted" in the directory. By default, the user object moves to the **Deleted users** area in Azure AD but isn't permanently deleted for 30 days. This soft deletion enables the administrator to restore the user account (including groups and permissions), if the user makes a request to restore the account within the 30-day period.
 
 If desired, a tenant administrator can permanently delete the account at any time during the 30-day period. To do this:
 

articles/active-directory/conditional-access/controls.md

@@ -15,7 +15,7 @@ ms.devlang: na
 ms.topic: article
 ms.tgt_pltfrm: na
 ms.workload: identity
-ms.date: 03/23/2019
+ms.date: 06/15/2019
 ms.author: joflore
 ms.reviewer: calebb
 
@@ -124,11 +124,13 @@ Providers currently offering a compatible service include:
 
 - [Duo Security](https://duo.com/docs/azure-ca)
 - [Entrust Datacard](https://www.entrustdatacard.com/products/authentication/intellitrust)
+- [GSMA](https://mobileconnect.io/azure/)
 - [Ping Identity](https://documentation.pingidentity.com/pingid/pingidAdminGuide/index.shtml#pid_c_AzureADIntegration.html)
 - RSA
 - [SecureAuth](https://docs.secureauth.com/pages/viewpage.action?pageId=47238992#)
 - [Silverfort](https://www.silverfort.io/company/using-silverfort-mfa-with-azure-active-directory/)
 - [Symantec VIP](https://help.symantec.com/home/VIP_Integrate_with_Azure_AD)
+- [Thales (Gemalto)](https://resources.eu.safenetid.com/help/AzureMFA/Azure_Help/Index.htm)
 - [Trusona](https://www.trusona.com/docs/azure-ad-integration-guide)
 
 For more information on those services, contact the providers directly.

articles/active-directory/develop/TOC.yml

@@ -139,6 +139,8 @@
           href: scenario-protected-web-api-app-registration.md
         - name: Code configuration
           href: scenario-protected-web-api-app-configuration.md
+        - name: Verification of scopes or app roles
+          href: scenario-protected-web-api-verification-scope-app-roles.md
         - name: Move to production
           href: scenario-protected-web-api-production.md
       - name: Web API that calls web APIs

articles/active-directory/develop/scenario-protected-web-api-app-configuration.md

@@ -156,4 +156,4 @@ The validators are all associated with properties of the `TokenValidationParamet
 ## Next steps
 
 > [!div class="nextstepaction"]
-> [Move to production](scenario-protected-web-api-production.md)
+> [Verify scopes and app roles in your code](scenario-protected-web-api-verification-scope-app-roles.md)

articles/active-directory/develop/scenario-protected-web-api-app-registration.md

@@ -56,19 +56,20 @@ Scopes are usually of the form `resourceURI/scopeName`. For Microsoft Graph, the
 
 During app registration, you'll need to define the following parameters:
 
-- One resource URI - By default the application registration portal recommends that you to use `api://{clientId}`. This resource URI is unique, but it's not human readable. You can change it, but make sure that it's unique.
-- One or several scopes
+- The resource URI - By default the application registration portal recommends that you to use `api://{clientId}`. This resource URI is unique, but it's not human readable. You can change it, but make sure that it's unique.
+- One or more **scopes** (to client applications, they will show up as **delegated permissions** for your Web API)
+- One or more **app roles** (to client applications, they will show up as **application permissions** for your Web API)
 
-The scopes are also displayed on the consent screen that's presented to end-users who use your application. Therefore, you'll need to provide the corresponding strings that describe the scope:
+The scopes are also displayed on the consent screen that's presented to end users who use your application. Therefore, you'll need to provide the corresponding strings that describe the scope:
 
 - As seen by the end user
 - As seen by the tenant admin, who can grant admin consent
 
-### How to expose the API
+### How to expose delegated permissions (scopes)
 
 1. Select the **Expose an API** section in the application registration, and:
    1. Select **Add a scope**.
-   1. Accept the proposed Application ID URI (api://{clientId}) by selecting **Save and Continue**.
+   1. If requested, accept the proposed Application ID URI (api://{clientId}) by selecting **Save and Continue**.
    1. Enter the following parameters:
       - For **Scope name**, use `access_as_user`.
       - For **Who can consent**, make sure the **Admins and users** option is selected.
@@ -79,6 +80,59 @@ The scopes are also displayed on the consent screen that's presented to end-user
       - Keep **State** set to **Enabled**.
       - Select **Add scope**.
 
+### Case where your Web API is called by daemon application
+
+In this paragraph, you'll learn how to register your protected Web API so that it can be called securely by daemon applications:
+
+- you'll need to expose **application permissions**. You will only declare application permissions as daemon applications do not interact with users and therefore delegated permissions would not make sense.
+- tenant admins may require Azure AD to issue tokens for your Web App to only applications that have registered that they want to access one of the Web API apps permissions.
+
+#### How to expose application permissions (app roles)
+
+To Expose application permissions, you'll need to edit the manifest.
+
+1. In the application registration for your application, click **Manifest**.
+1. Edit the manifest by locating the `appRoles` setting and adding one or several application roles. The role definition is provided in the sample JSON block below.  Leave the `allowedMemberTypes` to "Application" only. Please make sure that the **id** is a unique guid and **displayName** and **Value** don't contain any spaces.
+1. Save the manifest.
+
+The content of `appRoles` should be the following (the `id` can be any unique GUID)
+
+```JSon
+"appRoles": [
+	{
+	"allowedMemberTypes": [ "Application" ],
+	"description": "Accesses the TodoListService-Cert as an application.",
+	"displayName": "access_as_application",
+	"id": "ccf784a6-fd0c-45f2-9c08-2f9d162a0628",
+	"isEnabled": true,
+	"lang": null,
+	"origin": "Application",
+	"value": "access_as_application"
+	}
+],
+```
+
+#### How to ensure that Azure AD issues tokens for your Web API only to allowed clients
+
+The Web API checks for the app role (that's the developer way of doing it). But you can even configure Azure Active Directory to issue a token for your Web API only to applications that were approved by the tenant admin to access your API. To add this additional security:
+
+1. On the app **Overview** page for your app registration, select the hyperlink with the name of your application in **Managed application in local directory**. The title for this field can be truncated. You could, for instance, read: `Managed application in ...`
+
+   > [!NOTE]
+   >
+   > When you select this link you will navigate to the **Enterprise Application Overview** page associated with the service principal for your application in the tenant where you created it. You can navigate back to the app registration page by using the back button of your browser.
+
+1. Select the **Properties** page in the **Manage** section of the Enterprise application pages
+1. If you want AAD to enforce access to your Web API from only certain clients, set **User assignment required?** to **Yes**.
+
+   > [!IMPORTANT]
+   >
+   > By setting **User assignment required?** to **Yes**, AAD will check the app role assignments of the clients when they request an access token for the Web API. If the client was not be assigned to any AppRoles, AAD would just return the following error: `invalid_client: AADSTS501051: Application xxxx is not assigned to a role for the xxxx`
+   >
+   > If you keep **User assignment required?** to **No**, <span style='background-color:yellow; display:inline'>Azure AD  won’t check the app role assignments when a client requests an access token for your Web API</span>. Therefore, any daemon client (that is any client using client credentials flow) would still be able to obtain an access token for the API just by specifying its audience. Any application, would be able to access the API without having to request permissions for it. Now, this is not then end of it, as your Web API can always, as explained in the next section, verify that the application has the right role (which was authorized by the tenant admin), by validating that the access token has a `roles` claim, and the right value for this claim (in our case `access_as_application`).
+
+1. Select **Save**
+
 ## Next steps
 
 > [!div class="nextstepaction"]