Merge pull request #7780 from MicrosoftDocs/FromPrivateRepo

From private repo

Author: v-alje

.openpublishing.redirection.json

@@ -7356,7 +7356,7 @@
         },
         {
             "source_path": "articles/sql-database/sql-database-manage-single-databases-portal.md",
-            "redirect_url": "/azure/sql-database/sql-database-service-tiers",
+            "redirect_url": "/azure/sql-database/sql-database-service-tiers-vcore",
             "redirect_document_id": false
         },
         {
@@ -7421,7 +7421,7 @@
         },
         {
             "source_path": "articles/sql-database/sql-database-scale-on-the-fly.md",
-            "redirect_url": "/azure/sql-database/sql-database-service-tiers",
+            "redirect_url": "/azure/sql-database/sql-database-service-tiers-vcore",
             "redirect_document_id": false
         },
         {
@@ -7444,14 +7444,19 @@
             "redirect_url": "/azure/sql-database/sql-database-security-overview",
             "redirect_document_id": false
         },
+        {
+            "source_path": "articles/sql-database/sql-database-service-tiers.md",
+            "redirect_url": "/azure/sql-database/sql-database-service-tiers-vcore",
+            "redirect_document_id": false
+        },
         {
             "source_path": "articles/sql-database/sql-database-server-overview.md",
             "redirect_url": "/azure/sql-database/sql-database-servers-databases",
             "redirect_document_id": false
         },
         {
             "source_path": "articles/sql-database/sql-database-service-tier-advisor.md",
-            "redirect_url": "/azure/sql-database/sql-database-service-tiers",
+            "redirect_url": "/azure/sql-database/sql-database-service-tiers-vcore",
             "redirect_document_id": false
         },
         {
@@ -18702,6 +18707,7 @@
         {
             "source_path": "articles/machine-learning/desktop-workbench/support-for-aml-services.md",
             "redirect_url": "/azure/machine-learning/service/support-for-aml-services",
+            "redirect_document_id": false
         },
         {
             "source_path": "articles/stream-analytics/stream-analytics-add-outputs.md",

articles/active-directory/TOC.md

@@ -269,6 +269,7 @@
 ## Delegate access to resources
 ### [Administrator roles](active-directory-assign-admin-roles-azure-portal.md)
 #### [Assign admin roles](active-directory-users-assign-role-azure-portal.md)
+#### [Default user permissions](users-default-permissions.md)
 ### [Administrative units](active-directory-administrative-units-management.md)
 ### [Configure token lifetimes](active-directory-configurable-token-lifetimes.md)
 ### [Manage emergency access administrative accounts](active-directory-admin-manage-emergency-access-accounts.md)

articles/active-directory/active-directory-b2b-hybrid-organizations.md

@@ -11,7 +11,7 @@ tags: ''
 ms.service: active-directory
 ms.topic: article
 ms.workload: identity
-ms.date: 04/20/2018
+ms.date: 04/26/2018
 ms.author: twooley
 ms.reviewer: sasubram
 
@@ -21,11 +21,24 @@ ms.reviewer: sasubram
 
 Azure Active Directory (Azure AD) B2B collaboration makes it easy for you to give your external partners access to apps and resources in your organization. This is true even in a hybrid configuration where you have both on-premises and cloud-based resources. It doesn’t matter if you currently manage external partner accounts locally in your on-premises identity system, or if you manage the external accounts in the cloud as Azure AD B2B users. You can now grant these users access to resources in either location, using the same sign-in credentials for both environments.
 
+## Grant B2B users in Azure AD access to your on-premises apps
+
+If your organization uses Azure AD B2B collaboration capabilities to invite guest users from partner organizations to your Azure AD, you can now provide these B2B users access to on-premises apps.
+
+For apps that use SAML-based authentication, you can make these apps available to B2B users through the Azure portal, using Azure AD Application Proxy for authentication.
+
+For apps that use Integrated Windows Authentication (IWA) with Kerberos constrained delegation (KCD), you also use Azure AD Proxy for authentication. However, for authorization to work, a user object is required in the on-premises Windows Server Active Directory. There are two methods you can use to create local user objects that represent your B2B guest users.
+
+- You can use Microsoft Identity Manager (MIM) 2016 SP1 and the MIM management agent for Microsoft Graph.
+- You can use a PowerShell script. (This solution does not require MIM.)
+
+For details about how to implement these solutions, see [Grant B2B users in Azure AD access to your on-premises applications](active-directory-b2b-hybrid-cloud-to-on-premises.md).
+
 ## Grant locally-managed partner accounts access to cloud resources
 
 Before Azure AD, organizations with on-premises identity systems have traditionally managed partner accounts in their on-premises directory. If you’re such an organization, you want to make sure that your partners continue to have access as you move your apps and other resources to the cloud. Ideally, you want these users to use the same set of credentials to access both cloud and on-premises resources. 
 
-We now offer methods where you can use Azure AD Connect to sync these local accounts to the cloud as "guest users," where the accounts behave just like Azure AD B2B users. This solution works even if you have an on-premises identity system that lets your partners use their own external email addresses as their sign-in name.
+We now offer methods where you can use Azure AD Connect to sync these local accounts to the cloud as "guest users," where the accounts behave just like Azure AD B2B users.
 
 To help protect your company data, you can control access to just the right resources, and configure authorization policies that treat these guest users differently from your employees.
 
@@ -34,5 +47,6 @@ For implementation details, see [Grant locally-managed partner accounts access t
 ## Next steps
 
 - [Grant B2B users in Azure AD access to your on-premises applications](active-directory-b2b-hybrid-cloud-to-on-premises.md)
+- [Grant locally-managed partner accounts access to cloud resources using Azure AD B2B collaboration](active-directory-b2b-hybrid-on-premises-to-cloud.md)
 
 

articles/active-directory/active-directory-saas-adobe-echosign-tutorial.md

@@ -12,7 +12,7 @@ ms.workload: identity
 ms.tgt_pltfrm: na
 ms.devlang: na
 ms.topic: article
-ms.date: 06/24/2017
+ms.date: 04/26/2018
 ms.author: jeedes
 
 ---
@@ -127,40 +127,31 @@ In this section, you enable Azure AD single sign-on in the Azure portal and conf
 
 	![Configure Single Sign-On](./media/active-directory-saas-adobe-echosign-tutorial/tutorial_adobesign_configure.png) 
 
-
 7. In a different web browser window, log in to your Adobe Sign company site as an administrator.
 
-8. In the menu on the top, click **Account**, and then, in the navigation pane on the left side, click **SAML Settings** under **Account Settings**.
+8. In the SAML menu, click **Account Settings**, and then, click **SAML Settings**.
 
-   ![Account](./media/active-directory-saas-adobe-echosign-tutorial/ic789520.png "Account")
+	![Account](./media/active-directory-saas-adobe-echosign-tutorial/ic789520.png "Account")
 
-9. In the SAML Settings section, perform the following steps:
-   
-   ![SAML Settings](./media/active-directory-saas-adobe-echosign-tutorial/ic789521.png "SAML Settings")
+9. In the **SAML Settings** section, perform the following steps:
+  
+	![SAML Settings](./media/active-directory-saas-adobe-echosign-tutorial/ic789521.png "SAML Settings")
 
-   a. As **SAML Mode**, select **SAML Mandatory**.
+    a. As **SAML Mode**, select **SAML Mandatory**.
 
-   b. Select **Allow EchoSign Account Administrators to log in using their EchoSign Credentials**.
+    b. Select **Allow Adobe sign Account Administrators to log in using their  Adobe Sign Credentials**.
 
-   c. As **User Creation**, select **Automatically add users authenticated through SAML**.
-
-10. Move on, performing the following steps:
+    c. As **User Creation**, select **Automatically add users authenticated through SAML**.
 
-	   ![SAML Settings](./media/active-directory-saas-adobe-echosign-tutorial/ic789522.png "SAML Settings")
-
-	a. Paste **SAML Entity ID**, which you have copied from Azure portal into the **IdP Entity ID** textbox.
+	d. Paste **SAML Entity ID**, which you have copied from Azure portal into the **Entity ID/Issuer URL** textbox.
 
-	b. Paste **SAML Single Sign-On Service URL**, which you have copied from Azure portal into the **IdP Login URL** textbox.
+	e. Paste **SAML Single Sign-On Service URL**, which you have copied from Azure portal into the **Login URL/SSO Endpoint** textbox.
 
-    c. Paste **Sign-Out URL**, which you have copied from Azure portal into the **IdP Logout URL** textbox.
-
-	d. Open your downloaded **Certificate(Base64)** file in notepad, copy the content of it into your clipboard, and then paste it to the **IdP Certificate** textbox
+    f. Paste **Sign-Out URL**, which you have copied from Azure portal into the **Logout URL/SLO Endpoint** textbox.
 
-	e. Click **Save Changes**.
+	g. Open your downloaded **Certificate(Base64)** file in notepad, copy the content of it into your clipboard, and then paste it to the **IdP Certificate** textbox
 
-> [!TIP]
-> You can now read a concise version of these instructions inside the [Azure portal](https://portal.azure.com), while you are setting up the app!  After adding this app from the **Active Directory > Enterprise Applications** section, simply click the **Single Sign-On** tab and access the embedded documentation through the **Configuration** section at the bottom. You can read more about the embedded documentation feature here: [Azure AD embedded documentation]( https://go.microsoft.com/fwlink/?linkid=845985)
-> 
+	h. Click **Save Changes**.
 
 ### Creating an Azure AD test user
 The objective of this section is to create a test user in the Azure portal called Britta Simon.
@@ -206,15 +197,15 @@ To enable Azure AD users to log in to Adobe Sign, they must be provisioned into
 
 2. In the menu on the top, click **Account**, and then, in the navigation pane on the left side, click **Users & Groups**, and then, click **Create a new user**.
 
-   ![Account](./media/active-directory-saas-adobe-echosign-tutorial/ic789524.png "Account")
+	![Account](./media/active-directory-saas-adobe-echosign-tutorial/ic789524.png "Account")
 
 3. In the **Create New User** section, perform the following steps:
 
-   ![Create User](./media/active-directory-saas-adobe-echosign-tutorial/ic789525.png "Create User")
+	![Create User](./media/active-directory-saas-adobe-echosign-tutorial/ic789525.png "Create User")
 
-   a. Type the **Email Address**, **First Name**, and **Last Name** of a valid AAD account you want to provision into the related textboxes.
+    a. Type the **Email Address**, **First Name**, and **Last Name** of a valid AAD account you want to provision into the related textboxes.
 
-   b. Click **Create User**.
+    b. Click **Create User**.
 
 >[!NOTE]
 >The Azure Active Directory account holder receives an email that includes a link to confirm the account before it becomes active. 

articles/active-directory/active-directory-saas-clever-tutorial.md

@@ -13,7 +13,7 @@ ms.workload: identity
 ms.tgt_pltfrm: na
 ms.devlang: na
 ms.topic: article
-ms.date: 04/18/2018
+ms.date: 04/27/2018
 ms.author: jeedes
 
 ---
@@ -108,12 +108,12 @@ In this section, you enable Azure AD single sign-on in the Azure portal and conf
 
     a. In the **Sign-on URL** textbox, type a URL using the following pattern: `https://clever.com/in/<companyname>`
 
-	b. In the **Identifier** textbox, type a URL using the following pattern: `https://clever.com/<companyname>`
+	b. In the **Identifier** textbox, type the URL: `https://clever.com/oauth/saml/metadata.xml`
 
 	> [!NOTE]
-	> These values are not real. Update these values with the actual Sign-On URL and Identifier. Contact [Clever Client support team](https://clever.com/about/contact/) to get these values.
+	> Sign-on URL value is not real. Update this value with the actual Sign-On URL. Contact [Clever Client support team](https://clever.com/about/contact/) to get this value.
 
-4. On the **SAML Signing Certificate** section, click the copy button to copy **App Federation Metadata Url** and paste it into notepad.
+4. On the **SAML Signing Certificate** section, click the copy button to copy **App Federation Metadata Url** and paste it into Notepad.
 
     ![Configure Single Sign-On](./media/active-directory-saas-clever-tutorial/tutorial_metadataurl.png)
 
@@ -127,7 +127,8 @@ In this section, you enable Azure AD single sign-on in the Azure portal and conf
 
 	| Attribute Name  | Attribute Value |
 	| --------------- | -------------------- |
-	| clever.student.credentials.district\_username  | user.userprincipalname |
+	| clever.teacher.credentials.district_username|user.userprincipalname|
+	| clever.student.credentials.district_username| user.userprincipalname |
 	| Firstname  | user.givenname |
 	| Lastname  | user.surname |
 
@@ -155,19 +156,22 @@ In this section, you enable Azure AD single sign-on in the Azure portal and conf
 
 	![Instant Login](./media/active-directory-saas-clever-tutorial/ic798984.png "Instant Login")
 
+	> [!NOTE]
+	> Before you can Test single sign-on, You have to contact [Clever Client support team](https://clever.com/about/contact/) to enable Office 365 SSO in the back end.
+
 10. On the **Instant Login** page, perform the following steps:
-      
+    
 	  ![Instant Login](./media/active-directory-saas-clever-tutorial/ic798985.png "Instant Login")
-	  
+	
 	  a. Type the **Login URL**.
-	  
+	
 	  >[!NOTE]
 	  >The **Login URL** is a custom value. Contact [Clever Client support team](https://clever.com/about/contact/) to get this value.
-	  
+	
 	  b. As **Identity System**, select **ADFS**.
 
 	  c. In the **Metadata URL** textbox, paste **App Federation Metadata Url** value which you have copied from the Azure portal.
-	  
+	
 	  d. Click **Save**.
 
 ### Create an Azure AD test user

articles/active-directory/connect-health/active-directory-aadconnect-health-adfs.md

@@ -12,7 +12,7 @@ ms.workload: identity
 ms.tgt_pltfrm: na
 ms.devlang: na
 ms.topic: get-started-article
-ms.date: 04/28/2018
+ms.date: 04/26/2018
 ms.author: billmath
 ms.custom: H1Hack27Feb2017
 ---
@@ -111,7 +111,7 @@ The report provides the following information:
 >
 >
 
-## Risky IP Report 
+## Risky IP Report (Public Preview)
 AD FS customers may expose password authentication endpoints to the internet to provide authentication services for end users to access SaaS applications such as Office 365. In this case, it is possible for a bad actor to attempt logins against your AD FS system to guess an end user’s password and get access to application resources. AD FS provides the extranet account lockout functionality to prevent these types of attacks since AD FS in Windows Server 2012 R2. If you are on a lower version, we strongly recommend that you upgrade your AD FS system to Windows Server 2016. <br />
 Additionally, it is possible for a single IP address to attempt multiple logins against multiple users. In these cases, the number of attempts per user may be under the threshold for account lockout protection in AD FS. Azure AD Connect Health now provides the “Risky IP report” that detects this condition and notifies administrators when this occurs. The following are the key benefits for this report: 
 - Detection of IP addresses that exceed a threshold of failed password-based logins
@@ -151,7 +151,7 @@ For example, the below report item indicates from the 6pm to 7pm hour window on
 
 ![Azure AD Connect Health Portal](./media/active-directory-aadconnect-health-adfs/report4c.png)
 
-### Download Risky IP report (Public Preview)
+### Download Risky IP report 
 Using the **Download** functionality, the whole risky IP address list in the past 30 days can be exported from the Connect Health Portal
 The export result will include all the failed AD FS sign-in activities in each detection time window, so you can customize the filtering after the export. 
 Besides the highlighted aggregations in the portal, the export result also shows more details about failed sign-in activities per IP address:

articles/active-directory/develop/active-directory-authentication-scenarios.md

@@ -61,7 +61,7 @@ Now that you have an overview of the basics, read the sections below to understa
 
 ## Claims in Azure AD security tokens
 
-Security tokens issued by Azure AD contain claims, or assertions of information about the subject that has been authenticated. These claims can be used by the application for various tasks. For example, applications can use claims to validate the token, identify the subject's directory tenant, display user information, determine the subject's authorization, and so on. The claims present in any given security token are dependent upon the type of token, the type of credential used to authenticate the user, and the application configuration. A brief description of each type of claim emitted by Azure AD is provided in the table below. For more information, refer to [Supported token and claim types](active-directory-token-and-claims.md).
+Security tokens (access and id tokens) issued by Azure AD contain claims, or assertions of information about the subject that has been authenticated. These claims can be used by the application for various tasks. For example, applications can use claims to validate the token, identify the subject's directory tenant, display user information, determine the subject's authorization, and so on. The claims present in any given security token are dependent upon the type of token, the type of credential used to authenticate the user, and the application configuration. A brief description of each type of claim emitted by Azure AD is provided in the table below. For more information, refer to [Supported token and claim types](active-directory-token-and-claims.md).
 
 | Claim | Description |
 | --- | --- |