Merge pull request MicrosoftDocs#18669 from kgremban/aug4_appproxyqp4

Aug4 appproxyqp4

articles/active-directory/active-directory-application-proxy-claims-aware-apps.md

@@ -13,36 +13,44 @@ ms.workload: identity
 ms.tgt_pltfrm: na
 ms.devlang: na
 ms.topic: article
-ms.date: 05/03/2017
+ms.date: 08/04/2017
 ms.author: kgremban
 
 ---
-# Working with claims aware apps in Application Proxy
-Claims aware apps perform a redirection to the Security Token Service (STS), which in turn requests credentials from the user in exchange for a token before redirecting the user to the application. To enable Application Proxy to work with these redirects, the following steps need to be taken.
+# Working with claims-aware apps in Application Proxy
+[Claims-aware apps](https://msdn.microsoft.com/library/windows/desktop/bb736227.aspx) perform a redirection to the Security Token Service (STS). The STS requests credentials from the user in exchange for a token and then redirects the user to the application. There are a few ways to enable Application Proxy to work with these redirects. Use this article to configure your deployment for claims-aware apps. 
 
 ## Prerequisites
-Before performing this procedure, make sure that the STS the claims aware app redirects to is available outside of your on-premises network.
+Make sure that the STS that the claims-aware app redirects to is available outside of your on-premises network. You can make the STS available by exposing it through a proxy or by allowing outside connections. 
 
-## Azure classic portal configuration
-1. Publish your application according to the instructions described in [Publish applications with Application Proxy](active-directory-application-proxy-publish.md).
-2. In the list of applications, select the claims aware app and click **Configure**.
-3. If you chose **Passthrough** as your **Preauthentication Method**, make sure to select **HTTPS** as your **External URL** scheme.
-4. If you chose **Azure Active Directory** as your **Preauthentication Method**, select **None** as your **Internal Authentication Method**.
+## Publish your application
+
+1. Publish your application according to the instructions described in [Publish applications with Application Proxy](application-proxy-publish-azure-portal.md).
+2. Navigate to the application page in the portal and select **Single sign-on**.
+3. If you chose **Azure Active Directory** as your **Preauthentication Method**, select **Azure AD single sign-on disabled** as your **Internal Authentication Method**. If you chose **Passthrough** as your **Preauthentication Method**, you don't need to change anything.
+
+## Configure ADFS
+
+You can configure ADFS for claims-aware apps in one of two ways. The first is by using custom domains. The second is with WS-Federation. 
+
+### Option 1: Custom domains
+
+If all the internal URLs for your applications are fully qualified domain names (FQDNs), then you can configure [custom domains](active-directory-application-proxy-custom-domains.md) for your applications. Use the custom domains to create external URLs that are the same as the internal URLs. With this configuration, the redirects that the STS creates work the same whether your users are on-premises or remote. 
+
+### Option 2: WS-Federation
 
-## ADFS configuration
 1. Open ADFS Management.
 2. Go to **Relying Party Trusts**, right-click on the app you are publishing with Application Proxy, and choose **Properties**.  
 
    ![Relying Party Trusts right-click on app name - screenshot](./media/active-directory-application-proxy-claims-aware-apps/appproxyrelyingpartytrust.png)  
 
 3. On the **Endpoints** tab, under **Endpoint type**, select **WS-Federation**.
-4. Under **Trusted URL** enter the URL you entered in the Application Proxy under **External URL** and click **OK**.  
+4. Under **Trusted URL**, enter the URL you entered in the Application Proxy under **External URL** and click **OK**.  
 
    ![Add an Endpoint - set Trusted URL value - screenshot](./media/active-directory-application-proxy-claims-aware-apps/appproxyendpointtrustedurl.png)  
 
 ## Next steps
-* [Enable single-sign on](active-directory-application-proxy-sso-using-kcd.md)
-* [Troubleshoot issues you're having with Application Proxy](active-directory-application-proxy-troubleshoot.md)
+* [Enable single-sign on](application-proxy-sso-overview.md) for applications that aren't claims-aware
 * [Enable native client apps to interact with proxy applications](active-directory-application-proxy-native-client.md)
 
 

articles/active-directory/active-directory-application-proxy-connectors-azure-portal.md

@@ -12,10 +12,10 @@ ms.workload: identity
 ms.tgt_pltfrm: na
 ms.devlang: na
 ms.topic: article
-ms.date: 05/04/2017
+ms.date: 08/04/2017
 ms.author: kgremban
-
-ms.custom: H1Hack27Feb2017
+ms.reviewer: harshja
+ms.custom: H1Hack27Feb2017; it-pro
 ---
 
 # Publish applications on separate networks and locations using connector groups
@@ -24,50 +24,50 @@ ms.custom: H1Hack27Feb2017
 > * [Azure classic portal](active-directory-application-proxy-connectors.md)
 >
 
-## Azure AD Application Proxy and connector groups
+Customers utilize Azure AD's Application Proxy for more and more scenarios and applications. So we've made App Proxy even more flexible by enabling more topologies. You can create Application Proxy connector groups so that you can assign specific connectors to serve specific applications. This capability gives you more control and ways to optimize your Application Proxy deployment. 
 
-Customers utilize Azure AD's Application Proxy for more and more scenarios and applications. So we've made App Proxy even more flexible by enabling more topologies. You can create Application Proxy connector groups – a new capability to assign specific connectors to serve specific applications. This capability generates many use cases for Application Proxy that were not possible before. 
+Each Application Proxy connector is assigned to a connector group. All the connectors that belong to the same connector group act as a separate unit for high-availability and load balancing. All connectors belong to a connector group. If you don't create groups, then all your connectors are in a default group. Your admin can create new groups and assign connectors to them in the Azure portal. 
 
-The basic concept is that each Application Proxy connector is assigned to a connector group. All the connectors that belong to the same connector group act as a separate group for high-availability and load balancing. By default, all connectors belong to a default group. The admin can create new groups and change these assignments in the Azure portal. 
+All applications are assigned to a connector group. If you don't create groups, then all your applications are assigned to a default group. But if you organize your connectors into groups, you can set each application to work with a specific connector group. In this case, only the connectors in that group serve the application upon request. This feature is useful if your applications are hosted in different locations. You can create connector groups based on location, so that applications are always served by connectors that are physically close to them.
 
-By default, all applications are assigned to a default connector group. If your admin doesn’t change anything, the system continues to behave like it did before. If you change nothing, all the applications assigned to the default connector group include all the connectors. But if you organize your connectors into groups, you can set each application to work with a specific connector group. In this case, only the connectors in that group will serve the application upon request.
+>[!TIP] 
+>If you have a large Application Proxy deployment, don't assign any applications to the default connector group. That way, new connectors don't receive any live traffic until you assign them to an active connector group. This configuration also enables you to put connectors in an idle mode by moving them back to the default group, so that you can perform maintenance without impacting your users.
 
+## Prerequisites
+To group your connectors, you have to make sure you [installed multiple connectors](active-directory-application-proxy-enable.md). When you install a new connector, it automatically joins the **Default** connector group.
 
->[!NOTE] 
->Because new connectors are automatically assigned to a default connector group, for large deployments we recommend that you do not have applications assigned to the default group. Therefore once installed, new connectors will not receive any live traffic. Only after you assign the connector to one of the active groups, it can start serving live traffic. This also enables you to put connectors in an idle mode in order to enable maintenance.
->
+## Create connector groups
+Use these steps to create as many connector groups as you want. 
 
-## Prerequisite: Create your connector groups
-To group your connectors, you have to make sure you [installed multiple connectors](active-directory-application-proxy-enable.md). When you install a new connector, it automatically joins the **Default** connector group.
+1. Sign in to the [Azure portal](https://portal.azure.com).
+1. Select **Azure Active Directory** > **Enterprise applications** > **Application proxy**.
+2. Select **New connector group**. The New Connector Group blade appears.
 
-## Step 1: Create connector groups
-You can create as many connector groups as you want. Connector group creation is accomplished in the [Azure portal](https://portal.azure.com).
+   ![Select new connector group](./media/active-directory-application-proxy-connectors-azure-portal/new-group.png)
 
-1. Select **Azure Active Directory** to go to the management dashboard for your directory. From there, select **Enterprise applications** > **Application proxy**.
-2. Select the **Connector Groups** button. The New Connector Group blade appears.
 3. Give your new connector group a name, then use the dropdown menu to select which connectors belong in this group.
-4. Select **Save** when your connector Group is complete.
+4. Select **Save**.
 
-## Step 2: Assign applications to your connector groups
-The last step is to set each application to the connector group that will serve it.
+## Assign applications to your connector groups
+Use these steps for each application that you've published with Application Proxy. You can assign an application to a connector group when you first publish it, or you can use these steps to change the assignment whenever you want.   
 
 1. From the management dashboard for your directory, select **Enterprise applications** > **All applications** > the application you want to assign to a connector group > **Application Proxy**.
-2. Under **Connector group**, use the dropdown menu to select the group you want the application to use.
+2. Use the **Connector Group** dropdown menu to select the group you want the application to use.
 3. Select **Save** to apply the change.
 
 ## Use cases for connector groups 
 
 Connector groups are useful for various scenarios, including:
 
-###Sites with multiple interconnected datacenters
+### Sites with multiple interconnected datacenters
 
 Many organizations have a number of interconnected datacenters. In this case, you want to keep as much traffic within the datacenter as possible because cross-datacenter links are expensive and slow. You can deploy connectors in each datacenter to serve only the applications that reside within the datacenter. This approach minimizes cross-datacenter links and provides an entirely transparent experience to your users.
 
 ### Applications installed on isolated networks
 
-Applications can be hosted in networks that are not part of the main corporate network. You can use connector groups to install dedicated connectors on isolated networks to also isolate applications to the network. This usually happens when a third party vendor maintains a specific application for your organization. 
+Applications can be hosted in networks that are not part of the main corporate network. You can use connector groups to install dedicated connectors on isolated networks to also isolate applications to the network. This usually happens when a third-party vendor maintains a specific application for your organization. 
 
-Connector groups allow you to install dedicated connectors for those networks that publish only specific applications, making it easier and more secure to outsource application management to third party vendors.
+Connector groups allow you to install dedicated connectors for those networks that publish only specific applications, making it easier and more secure to outsource application management to third-party vendors.
 
 ### Applications installed on IaaS 
 
@@ -83,24 +83,24 @@ This can become an issue as many organizations use multiple cloud vendors, as th
 
 ### Multi-forest – different connector groups for each forest
 
-Most customers who have deployed Application Proxy are using its single-sign-on (SSO) capabilities by performing Kerberos Constrained Delegation (KCD). To acheive this, the connector’s machines need to be joined to a domain that can delegate the users toward the application. KCD supports cross-forest capabilities. But for companies who have distinct multi-forest environments with no trust between them, a single connector cannot be used for all forests. 
+Most customers who have deployed Application Proxy are using its single-sign-on (SSO) capabilities by performing Kerberos Constrained Delegation (KCD). To achieve this, the connector’s machines need to be joined to a domain that can delegate the users toward the application. KCD supports cross-forest capabilities. But for companies who have distinct multi-forest environments with no trust between them, a single connector cannot be used for all forests. 
 
-In this case, specific connectors can be deployed per forest, and set to serve applications that were published to serve only the users of that specific forest. Each connector group represents a different forest. While the tenant and most of the experience will be unified for all forests, users can be assigned to their forest applications using Azure AD groups.
+In this case, specific connectors can be deployed per forest, and set to serve applications that were published to serve only the users of that specific forest. Each connector group represents a different forest. While the tenant and most of the experience is unified for all forests, users can be assigned to their forest applications using Azure AD groups.
 
 ### Disaster Recovery sites
 
 There are two different approaches you can take with a disaster recovery (DR) site, depending on how your sites are implemented:
 
 * If your DR site is built in active-active mode where it is exactly like the main site and has the same networking and AD settings, you can create the connectors on the DR site in the same connector group as the main site. This enables Azure AD to detect failovers for you.
-* If your DR site is separate from the main site, you can create a different connector group in the DR site, and have either 1) additional applications or 2) manually divert the existing application to the DR connector group as needed.
+* If your DR site is separate from the main site, you can create a different connector group in the DR site, and either 1) have backup applications or 2) manually divert the existing application to the DR connector group as needed.
 
 ### Serve multiple companies from a single tenant
 
 There are many different ways to implement a model in which a single service provider deploys and maintains Azure AD related services for multiple companies. Connector groups help the admin segregate the connectors and applications into different groups. One way, which is suitable for small companies, is to have a single Azure AD tenant while the different companies have their own domain name and networks. This is also true for M&A scenarios and situations where a single IT division serves several companies for regulatory or business reasons. 
 
 ## Sample configurations
 
-Some examples that you can implement, include the followiong connector groups.
+Some examples that you can implement, include the following connector groups.
 
 ### Default configuration – no use for connector groups
 
@@ -125,8 +125,8 @@ In the example below, the company has two datacenters, A and B, with two connect
 ![AzureAD No Connector Groups](./media/application-proxy-publish-apps-separate-networks/application-proxy-sample-config-3.png)
 
 ## Next steps
-* [Enable Application Proxy](active-directory-application-proxy-enable.md)
-* [Enable single-sign on](active-directory-application-proxy-sso-using-kcd.md)
-* [Enable conditional access](active-directory-application-proxy-conditional-access.md)
-* [Troubleshoot issues you're having with Application Proxy](active-directory-application-proxy-troubleshoot.md)
+
+* [Understand Azure AD Application Proxy connectors](application-proxy-understand-connectors.md)
+* [Enable single-sign on](application-proxy-sso-overview.md)
+