Adding ACS retirement clarifications directly to the articles

VesaJuvonen · VesaJuvonen · commit 5e98126629dd · 2018-04-24T10:54:38.000+03:00
diff --git a/docs/general-development/access-sharepoint-from-mobile-and-native-device-apps.md b/docs/general-development/access-sharepoint-from-mobile-and-native-device-apps.md
@@ -74,7 +74,6 @@ You can build these apps on the ASP.NET platform or a non-Microsoft stack. If yo
     
     
 These apps **gain authorized access to SharePoint data by using access tokens** that are issued by the Azure Control Service (ACS) in compliance with the OAuth Authentication Code flow. For more, see [Authorization Code OAuth flow for SharePoint Add-ins](http://msdn.microsoft.com/library/e89e91c7-ea39-49b9-af5a-7f047a7e2ab7%28Office.15%29.aspx).
-  
-    
-    
 
+> [!IMPORTANT]
+> Azure Access Control (ACS), a service of Azure Active Directory (Azure AD), will be retired on November 7, 2018. This retirement does not impact SharePoint add-in model which is using `https://accounts.accesscontrol.windows.net` hostname, which is not impacted by this retirement. See more details on this from [Impact of Azure Access Control retirement for SharePoint add-ins](https://dev.office.com/blogs/impact-of-azure-access-control-deprecation-for-sharepoint-add-ins).
diff --git a/docs/scenario-guidance/Security.md b/docs/scenario-guidance/Security.md
@@ -94,6 +94,9 @@ _**Applies to:** Office 365_
 
 When using SharePoint Online you can define applications in Azure AD and these applications can be granted permissions to SharePoint, but also to all the other services in Office 365. This model is the preferred model in case you’re using SharePoint Online, if you’re using SharePoint on-premises you have to use the SharePoint Only model via based Azure ACS.
 
+> [!IMPORTANT]
+> Azure Access Control (ACS), a service of Azure Active Directory (Azure AD), will be retired on November 7, 2018. This retirement does not impact SharePoint add-in model which is using `https://accounts.accesscontrol.windows.net` hostname, which is not impacted by this retirement. See more details on this from [Impact of Azure Access Control retirement for SharePoint add-ins](https://dev.office.com/blogs/impact-of-azure-access-control-deprecation-for-sharepoint-add-ins).
+
 #### Related resources
 
 ##### Articles
diff --git a/docs/schema/startpage-element-propertiesdefinition-complextypesharepoint-add-in-manifest.md b/docs/schema/startpage-element-propertiesdefinition-complextypesharepoint-add-in-manifest.md
@@ -53,6 +53,9 @@ The token is automatically replaced by the actual protocol and ___domain (and port,
 
 If the add-in uses OAuth, the ___domain part of the StartPage value must exactly match the **Add-in Domain** specified when the SharePoint Add-in was registered with Microsoft Azure Access Control Service (ACS). For more information see [Register SharePoint Add-ins](../sp-add-ins/register-sharepoint-add-ins.md).
 
+> [!IMPORTANT]
+> Azure Access Control (ACS), a service of Azure Active Directory (Azure AD), will be retired on November 7, 2018. This retirement does not impact SharePoint add-in model which is using `https://accounts.accesscontrol.windows.net` hostname, which is not impacted by this retirement. See more details on this from [Impact of Azure Access Control retirement for SharePoint add-ins](https://dev.office.com/blogs/impact-of-azure-access-control-deprecation-for-sharepoint-add-ins).
+
 ## Element information
 
 <table>
diff --git a/docs/solution-guidance/Extending-SharePoint-Online-for-Germany-China-USGovernment-environments.md b/docs/solution-guidance/Extending-SharePoint-Online-for-Germany-China-USGovernment-environments.md
@@ -8,6 +8,8 @@ When your Office 365 tenant is hosted in an specific environment like the German
 
 _**Applies to:** Office 365 hosted in the Germany, China or US Government environments_
 
+> [!IMPORTANT]
+> Azure Access Control (ACS), a service of Azure Active Directory (Azure AD), will be retired on November 7, 2018. This retirement does not impact SharePoint add-in model which is using `https://accounts.accesscontrol.windows.net` hostname, which is not impacted by this retirement. See more details on this from [Impact of Azure Access Control retirement for SharePoint add-ins](https://dev.office.com/blogs/impact-of-azure-access-control-deprecation-for-sharepoint-add-ins).
 
 ## Introduction
 <a name="introduction"> </a>
diff --git a/docs/solution-guidance/app-only-elevated-privileges-sharepoint-add-in.md b/docs/solution-guidance/app-only-elevated-privileges-sharepoint-add-in.md
@@ -122,6 +122,9 @@ The following article demonstrates how to use AllowAppOnlyPolicy with ACS.
 
 - [SharePoint 2013 App Only Policy Made Easy (Kirk Evans - MSDN Blog Post)](http://blogs.msdn.com/b/kaevans/archive/2013/02/23/sharepoint-2013-app-only-policy-made-easy.aspx)
 
+> [!IMPORTANT]
+> Azure Access Control (ACS), a service of Azure Active Directory (Azure AD), will be retired on November 7, 2018. This retirement does not impact SharePoint add-in model which is using `https://accounts.accesscontrol.windows.net` hostname, which is not impacted by this retirement. See more details on this from [Impact of Azure Access Control retirement for SharePoint add-ins](https://dev.office.com/blogs/impact-of-azure-access-control-deprecation-for-sharepoint-add-ins).
+
 Service Account
 ---------------
 In this pattern, the SharePointOnlineCredentials class is used to establish the context of a user that executes code.
diff --git a/docs/solution-guidance/elevated-privileges-in-sharepoint-add-ins.md b/docs/solution-guidance/elevated-privileges-in-sharepoint-add-ins.md
@@ -53,7 +53,12 @@ Using the app-only policy requires that your add-in use either low-trust or high
 
 ### Low-trust authorization
 
-Your add-in can use low-trust authorization when using the Microsoft Azure Access Control Service (ACS) to establish trust between your provider-hosted add-in and either your Office 365 site or your on-premises SharePoint farm. You can learn more at [Three authorization systems for SharePoint Add-ins 2013](https://msdn.microsoft.com/en-us/library/office/dn790706.aspx). To get a reference to the [ClientContext](https://msdn.microsoft.com/en-us/library/office/microsoft.sharepoint.client.clientcontext.aspx) object, your add-in should:
+Your add-in can use low-trust authorization when using the Microsoft Azure Access Control Service (ACS) to establish trust between your provider-hosted add-in and either your Office 365 site or your on-premises SharePoint farm. You can learn more at [Three authorization systems for SharePoint Add-ins 2013](https://msdn.microsoft.com/en-us/library/office/dn790706.aspx). 
+
+> [!IMPORTANT]
+> Azure Access Control (ACS), a service of Azure Active Directory (Azure AD), will be retired on November 7, 2018. This retirement does not impact SharePoint add-in model which is using `https://accounts.accesscontrol.windows.net` hostname, which is not impacted by this retirement. See more details on this from [Impact of Azure Access Control retirement for SharePoint add-ins](https://dev.office.com/blogs/impact-of-azure-access-control-deprecation-for-sharepoint-add-ins).
+
+To get a reference to the [ClientContext](https://msdn.microsoft.com/en-us/library/office/microsoft.sharepoint.client.clientcontext.aspx) object, your add-in should:
 
 1. Get the access token by using TokenHelper.GetAppOnlyAccessToken.
 
diff --git a/docs/solution-guidance/how-to-provide-add-in-app-only-tenant-administrative-permissions-in-sharepoint-online.md b/docs/solution-guidance/how-to-provide-add-in-app-only-tenant-administrative-permissions-in-sharepoint-online.md
@@ -7,6 +7,9 @@ How to provide add-in app only tenant administrative permissions in SharePoint O
 
 When you are developing SharePoint add-ins and want to register them using the ACS model (appregnew.aspx and appinv.aspx), you will need to follow a special process, when an add-in is requesting tenant admin permissions and in app-only mode. 
 
+> [!IMPORTANT]
+> Azure Access Control (ACS), a service of Azure Active Directory (Azure AD), will be retired on November 7, 2018. This retirement does not impact SharePoint add-in model which is using `https://accounts.accesscontrol.windows.net` hostname, which is not impacted by this retirement. See more details on this from [Impact of Azure Access Control retirement for SharePoint add-ins](https://dev.office.com/blogs/impact-of-azure-access-control-deprecation-for-sharepoint-add-ins).
+
 Steps to provide tenant admin permission for app only add-in:
 
 - Register app id for the add-in under normal site collection in the tenant where add-in will be deployed. 
diff --git a/docs/solution-guidance/multigeo-sampleapplicationsetup.md b/docs/solution-guidance/multigeo-sampleapplicationsetup.md
@@ -86,6 +86,9 @@ When using app-only you'll need to grant the created app principal **full contro
 ##### Create the principal
 Navigate to a site in your tenant (e.g. https://contoso.sharepoint.com) and then call the appregnew.aspx page (e.g. https://contoso.sharepoint.com/_layouts/15/appregnew.aspx). In this page click on the Generate button to generate a client id and client secret and fill the remaining information like shown in the screen-shot below.
 
+> [!IMPORTANT]
+> Azure Access Control (ACS), a service of Azure Active Directory (Azure AD), will be retired on November 7, 2018. This retirement does not impact SharePoint add-in model which is using `https://accounts.accesscontrol.windows.net` hostname, which is not impacted by this retirement. See more details on this from [Impact of Azure Access Control retirement for SharePoint add-ins](https://dev.office.com/blogs/impact-of-azure-access-control-deprecation-for-sharepoint-add-ins).
+
 ![Register ACS app principal](media/multigeo/multigeopermissions_registerprincipal1.png)
 
 > **Important**
diff --git a/docs/solution-guidance/security-apponly-azureacs.md b/docs/solution-guidance/security-apponly-azureacs.md
@@ -1,6 +1,9 @@
 # Granting access using SharePoint App-Only
 SharePoint App-Only is the older, but still very relevant, model of setting up app-principals. This model works for both SharePoint Online and SharePoint 2013/2016 on-premises and is ideal to prepare your applications for migration from SharePoint on-premises to SharePoint online. Below steps show how to setup an app principal with tenant full control permissions, but obviously you could also grant just read permissions using this approach.
 
+> [!IMPORTANT]
+> Azure Access Control (ACS), a service of Azure Active Directory (Azure AD), will be retired on November 7, 2018. This retirement does not impact SharePoint add-in model which is using `https://accounts.accesscontrol.windows.net` hostname, which is not impacted by this retirement. See more details on this from [Impact of Azure Access Control retirement for SharePoint add-ins](https://dev.office.com/blogs/impact-of-azure-access-control-deprecation-for-sharepoint-add-ins).
+
 ## Setting up an app-only principal with tenant permissions
 Navigate to a site in your tenant (e.g. https://contoso.sharepoint.com) and then call the appregnew.aspx page (e.g. https://contoso.sharepoint.com/_layouts/15/appregnew.aspx). In this page click on the Generate button to generate a client id and client secret and fill the remaining information like shown in the screen-shot below.
 
diff --git a/docs/solution-guidance/security-apponly-azuread.md b/docs/solution-guidance/security-apponly-azuread.md
@@ -1,5 +1,8 @@
 # Granting access via Azure AD App-Only
-When using SharePoint Online you can define applications in Azure AD and these applications can be granted permissions to SharePoint, but also to all the other services in Office 365. This model is the preferred model in case you’re using SharePoint Online, if you’re using SharePoint on-premises you have to use the SharePoint Only model via based Azure ACS as described in [here](security-apponly-azureacs.md "link to Azure ACS app only article").
+When using SharePoint Online you can define applications in Azure AD and these applications can be granted permissions to SharePoint, but also to all the other services in Office 365. This model is the preferred model in case you’re using SharePoint Online, if you’re using SharePoint on-premises you have to use the SharePoint Only model via based Azure ACS as described in [here](security-apponly-azureacs.md).
+
+> [!IMPORTANT]
+> Azure Access Control (ACS), a service of Azure Active Directory (Azure AD), will be retired on November 7, 2018. This retirement does not impact SharePoint add-in model which is using `https://accounts.accesscontrol.windows.net` hostname, which is not impacted by this retirement. See more details on this from [Impact of Azure Access Control retirement for SharePoint add-ins](https://dev.office.com/blogs/impact-of-azure-access-control-deprecation-for-sharepoint-add-ins).
 
 ## Setting up an Azure AD app for app-only access
 In Azure AD when doing app-only you typically use a certificate to request access: anyone having the certificate and its private key can use the app and the permissions granted to the app. Below steps walk you through the setup of this model.
diff --git a/docs/solution-guidance/security-apponly.md b/docs/solution-guidance/security-apponly.md
@@ -20,5 +20,5 @@ App-Only does not work in following cases:
 > [!IMPORTANT]
 > If the above scenarios are critical for you it's recommended to define a service account, grant that one permissions and then use it in your application. See the [Governance.EnsurePolicy](https://github.com/SharePoint/PnP/tree/master/Solutions/Governance.EnsurePolicy) sample to learn more on how you can grant tenant wide permissions for a service account. Also the article explaining an [alternative model for web app policies in SharePoint Online](security-webapppolicies.md) does contain a lot of information on this topic.
 
-
-
+> [!IMPORTANT]
+> Azure Access Control (ACS), a service of Azure Active Directory (Azure AD), will be retired on November 7, 2018. This retirement does not impact SharePoint add-in model which is using `https://accounts.accesscontrol.windows.net` hostname, which is not impacted by this retirement. See more details on this from [Impact of Azure Access Control retirement for SharePoint add-ins](https://dev.office.com/blogs/impact-of-azure-access-control-deprecation-for-sharepoint-add-ins).
diff --git a/docs/sp-add-ins/add-in-permissions-in-sharepoint.md b/docs/sp-add-ins/add-in-permissions-in-sharepoint.md
@@ -15,6 +15,9 @@ Users can grant only the permissions that they have. The user must grant all the
 
 The permissions that the add-in has been granted are also stored in the content database of the SharePoint farm or SharePoint Online tenancy. They are not stored with a secure token service, such as Microsoft Azure Access Control Service (ACS). When a user first grants an add-in permissions, SharePoint obtains information about the add-in from ACS. SharePoint then stores the basic information about the add-in in the add-in management service and the content database along with the add-in's permissions. For more information about ACS, see [Creating SharePoint Add-ins that use low-trust authorization](creating-sharepoint-add-ins-that-use-low-trust-authorization.md).
 
+> [!IMPORTANT]
+> Azure Access Control (ACS), a service of Azure Active Directory (Azure AD), will be retired on November 7, 2018. This retirement does not impact SharePoint add-in model which is using `https://accounts.accesscontrol.windows.net` hostname, which is not impacted by this retirement. See more details on this from [Impact of Azure Access Control retirement for SharePoint add-ins](https://dev.office.com/blogs/impact-of-azure-access-control-deprecation-for-sharepoint-add-ins).
+
 If an object to which an add-in was granted permission is deleted, the corresponding grants are also deleted. When an object to which an add-in was granted permission is recycled, SharePoint does not modify the corresponding grant. This is so that if the object is restored from the Recycle Bin, the grant is still intact.
 
 When an add-in is removed, all the permissions granted to that add-in at the scope from which it was removed are revoked. This is to ensure that the add-in can't use its credentials to continue accessing protected SharePoint resources remotely after a user removes the add-in from SharePoint.
diff --git a/docs/sp-add-ins/authorization-and-authentication-of-sharepoint-add-ins.md b/docs/sp-add-ins/authorization-and-authentication-of-sharepoint-add-ins.md
@@ -60,7 +60,7 @@ You may have already heard that OAuth 2.0 plays an important role in the authent
 
 If you plan to build a SharePoint Add-in that runs in a remote web application and communicates back to SharePoint by using server-side code, you need to use OAuth. 
 
-If the remote web application is off-premises, you would use [the low-trust authorization system](creating-sharepoint-add-ins-that-use-low-trust-authorization.md), in which Azure ACS is the access token issuer. 
+If the remote web application is off-premises, you would use [the low-trust authorization system](creating-sharepoint-add-ins-that-use-low-trust-authorization.md), in which Azure ACS is the access token issuer.
 
 If it is on-premises, you would typically use [the high-trust system](creating-sharepoint-add-ins-that-use-high-trust-authorization.md), in which the add-in itself and a digital certificate are the access token issuers.
 
diff --git a/docs/sp-add-ins/authorization-code-oauth-flow-for-sharepoint-add-ins.md b/docs/sp-add-ins/authorization-code-oauth-flow-for-sharepoint-add-ins.md
@@ -11,6 +11,9 @@ ms.prod: sharepoint
 > [!NOTE] 
 > This article assumes that you are familiar with [Creating SharePoint Add-ins that use low-trust authorization](creating-sharepoint-add-ins-that-use-low-trust-authorization.md) and with the concepts and principles behind OAuth. For more information about OAuth, see [OAuth.net](http://oauth.net/) and [Web Authorization Protocol (oauth)](http://datatracker.ietf.org/doc/active/#oauth).
 
+> [!IMPORTANT]
+> Azure Access Control (ACS), a service of Azure Active Directory (Azure AD), will be retired on November 7, 2018. This retirement does not impact SharePoint add-in model which is using `https://accounts.accesscontrol.windows.net` hostname, which is not impacted by this retirement. See more details on this from [Impact of Azure Access Control retirement for SharePoint add-ins](https://dev.office.com/blogs/impact-of-azure-access-control-deprecation-for-sharepoint-add-ins).
+
 In some scenarios, an add-in can request permission to access SharePoint resources on the fly; that is, an add-in can request permission to access SharePoint resources dynamically at runtime, instead of at add-in installation time. This type of add-in does not have to be launched from, or even installed on, SharePoint. For example, it could be a native device add-in, an add-in that is launched from any website, or an Office Add-in launched from an Office application that wants to access resources on SharePoint on the fly.
 
 > [!NOTE] 
diff --git a/docs/sp-add-ins/context-token-oauth-flow-for-sharepoint-add-ins.md b/docs/sp-add-ins/context-token-oauth-flow-for-sharepoint-add-ins.md
@@ -5,11 +5,13 @@ ms.date: 12/28/2017
 ms.prod: sharepoint
 ---
 
-
 # Context Token OAuth flow for SharePoint Add-ins
 
 In SharePoint, the OAuth authentication and authorization flow for a provider-hosted, low-trust, add-in involves a series of interactions among your add-in, SharePoint, the authorization server, and the browser at runtime. The authorization server in this scenario is Microsoft Azure Access Control Service (ACS).
 
+> [!IMPORTANT]
+> Azure Access Control (ACS), a service of Azure Active Directory (Azure AD), will be retired on November 7, 2018. This retirement does not impact SharePoint add-in model which is using `https://accounts.accesscontrol.windows.net` hostname, which is not impacted by this retirement. See more details on this from [Impact of Azure Access Control retirement for SharePoint add-ins](https://dev.office.com/blogs/impact-of-azure-access-control-deprecation-for-sharepoint-add-ins).
+
 With a provider-hosted add-in, you have a remote web application or service that is separate from SharePoint, and not part of the SharePoint farm or SharePoint Online tenancy. It can be hosted in the cloud or on an on-premises server. In this article, the remote component is called Contoso.com.
  
 > [!NOTE] 
diff --git a/docs/sp-add-ins/create-and-use-access-tokens-in-provider-hosted-high-trust-sharepoint-add-ins.md b/docs/sp-add-ins/create-and-use-access-tokens-in-provider-hosted-high-trust-sharepoint-add-ins.md
@@ -5,7 +5,6 @@ ms.date: 12/29/2017
 ms.prod: sharepoint
 ---
 
-
 # Create and use access tokens in provider-hosted high-trust SharePoint Add-ins
 
 > [!IMPORTANT] 
diff --git a/docs/sp-add-ins/create-provider-hosted-sharepoint-add-ins-to-access-sap-data-by-using-the-sap-ga.md b/docs/sp-add-ins/create-provider-hosted-sharepoint-add-ins-to-access-sap-data-by-using-the-sap-ga.md
@@ -50,6 +50,9 @@ The process involves an OAuth "flow" in which the application, which can be a Sh
 > [!TIP] 
 > If your SharePoint Add-in accesses SharePoint in addition to accessing SAP Gateway for Microsoft, it needs to use *both* systems: Azure AD to get an access token to SAP Gateway for Microsoft, and the ACS authorization system to get an access token to SharePoint. The tokens from the two sources are not interchangeable. For more information, see [Add SharePoint access to the ASP.NET application (optional)](#SharePoint).
 
+> [!IMPORTANT]
+> Azure Access Control (ACS), a service of Azure Active Directory (Azure AD), will be retired on November 7, 2018. This retirement does not impact SharePoint add-in model which is using `https://accounts.accesscontrol.windows.net` hostname, which is not impacted by this retirement. See more details on this from [Impact of Azure Access Control retirement for SharePoint add-ins](https://dev.office.com/blogs/impact-of-azure-access-control-deprecation-for-sharepoint-add-ins).
+
 For a detailed description and diagram of the OAuth flow used by OAuth 2.0 in Azure AD, see [Authorize access to web applications using OAuth 2.0 and Azure Active Directory](https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-protocols-oauth-code). 
 
 For a similar description and a diagram of the flow for accessing SharePoint, see [the steps in the Context Token flow](context-token-oauth-flow-for-sharepoint-add-ins.md#OAuth_ProcessFlowSteps).
diff --git a/docs/sp-add-ins/creating-sharepoint-add-ins-that-use-low-trust-authorization.md b/docs/sp-add-ins/creating-sharepoint-add-ins-that-use-low-trust-authorization.md
diff --git a/docs/sp-add-ins/creating-sharepoint-add-ins-that-use-the-cross-___domain-library.md b/docs/sp-add-ins/creating-sharepoint-add-ins-that-use-the-cross-___domain-library.md
diff --git a/docs/sp-add-ins/handle-security-tokens-in-provider-hosted-low-trust-sharepoint-add-ins.md b/docs/sp-add-ins/handle-security-tokens-in-provider-hosted-low-trust-sharepoint-add-ins.md
diff --git a/docs/sp-add-ins/register-sharepoint-add-ins.md b/docs/sp-add-ins/register-sharepoint-add-ins.md
diff --git a/docs/sp-add-ins/three-authorization-systems-for-sharepoint-add-ins.md b/docs/sp-add-ins/three-authorization-systems-for-sharepoint-add-ins.md
