Merge branch 'master' of https://github.com/MicrosoftDocs/azure-docs-pr into timlt1

Author: timlt

articles/active-directory/manage-apps/what-is-single-sign-on.md

@@ -42,7 +42,7 @@ The following table summarizes the single sign-on methods, and links to more det
 | [SAML](#saml-sso) | cloud and on-premises | Choose SAML whenever possible for existing applications that do not use OpenID Connect or OAuth. SAML works for applications that authenticate using one of the SAML protocols.|
 | [Password-based](#password-based-sso) | cloud and on-premises | Choose password-based when the application authenticates with username and password. Password-based single sign-on enables secure application password storage and replay using a web browser extension or mobile app. This method uses the existing sign-in process provided by the application, but enables an administrator to manage the passwords. |
 | [Linked](#linked-sign-on) | cloud and on-premises | Choose linked sign-on when the application is configured for single sign-on in another identity provider service. This option doesn't add single sign-on to the application. However, the application might already have single sign-on implemented using another service such as Active Directory Federation Services.|
-| [Disabled](#disabled-sso) | cloud and on-premises | Choose disabled single sign-on when the app isn't ready to be configured for single sign-on. Users need to enter their username and password every time they launch this application.|
+| [Disabled](#disabled-sso) | cloud and on-premises | Choose disabled single sign-on when the app isn't ready to be configured for single sign-on. This mode is the default when you create the app.|
 | [Integrated Windows Authentication (IWA)](#integrated-windows-authentication-iwa-sso) | on-premises only | Choose IWA single sign-on for applications that use [Integrated Windows Authentication (IWA)](/aspnet/web-api/overview/security/integrated-windows-authentication), or claims-aware applications. For IWA, the Application Proxy connectors use Kerberos Constrained Delegation (KCD) to authenticate users to the application. |
 | [Header-based](#header-based-sso) | on-premises only | Use header-based single sign-on when the application uses headers for authentication. Header-based single sign-on requires PingAccess for Azure AD. Application Proxy uses Azure AD to authenticate the user and then passes traffic through the connector service.  |
 
@@ -143,6 +143,8 @@ Use disabled single sign-on mode:
 - If you're testing other aspects of the application, or
 - As a layer of security to an on-premises application that doesn't require users to authenticate. With disabled, the user needs to authenticate.
 
+Note that if you have configured the application for SP-initiated SAML based single sign-on and you change the SSO mode to disable, it won't stop users from signing to the application outside the MyApps portal. To achieve this, you need to [disable the ability for users to sign-in](disable-user-sign-in-portal.md)
+
 ## Integrated Windows Authentication (IWA) SSO
 
 [Application Proxy](application-proxy.md) provides single sign-on (SSO) to applications that use [Integrated Windows Authentication (IWA)](/aspnet/web-api/overview/security/integrated-windows-authentication), or claims-aware applications. If your application uses IWA, Application Proxy authenticates to the application by using Kerberos Constrained Delegation (KCD). For a claims-aware application that trusts Azure Active Directory, single sign-on works because the user was already authenticated by using Azure AD.

articles/app-service/configure-encrypt-at-rest-using-cmk.md

@@ -0,0 +1,118 @@
+---
+title: Encrypt your application source at rest
+description: Encrypt your application data in Azure Storage and deploy it as a package file.
+ms.topic: article
+ms.date: 03/06/2020
+---
+
+# Encryption at rest using customer-managed keys
+
+Encrypting your web app's application data at rest requires an Azure Storage Account and an Azure Key Vault. These services are used when you run your app from a deployment package.
+
+  - [Azure Storage provides encryption at rest](../storage/common/storage-service-encryption.md). You can use system-provided keys or your own, customer-managed keys. This is where your application data is stored when it's not running in a web app in Azure.
+  - [Running from a deployment package](deploy-run-package.md) is a deployment feature of App Service. It allows you to deploy your site content from an Azure Storage Account using a Shared Access Signature (SAS) URL.
+  - [Key Vault references](app-service-key-vault-references.md) are a security feature of App Service. It allows you to import secrets at runtime as application settings. Use this to encrypt the SAS URL of your Azure Storage Account.
+
+## Set up encryption at rest
+
+### Create an Azure Storage account
+
+First, [create an Azure Storage account](../storage/common/storage-account-create.md) and [encrypt it with customer managed keys](../storage/common/storage-service-encryption.md#customer-managed-keys-with-azure-key-vault). Once the storage account is created, use the [Azure Storage Explorer](../vs-azure-tools-storage-manage-with-storage-explorer.md) to upload package files.
+
+Next, use the Storage Explorer to [generate an SAS](../vs-azure-tools-storage-manage-with-storage-explorer.md?tabs=windows#generate-a-sas-in-storage-explorer). 
+
+> [!NOTE]
+> Save this SAS URL, this is used later to enable secure access of the deployment package at runtime.
+
+### Configure running from a package from your storage account
+  
+Once you upload your file to Blob storage and have an SAS URL for the file, set the `WEBSITE_RUN_FROM_PACKAGE` application setting to the SAS URL. The following example does it by using Azure CLI:
+
+```
+az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings WEBSITE_RUN_FROM_PACKAGE="<your-SAS-URL>"
+```
+
+Adding this application setting causes your web app to restart. After the app has restarted, browse to it and make sure that the app has started correctly using the deployment package. If the application didn't start correctly, see the [Run from package troubleshooting guide](deploy-run-package.md#troubleshooting).
+
+### Encrypt the application setting using Key Vault references
+
+Now you can replace the value of the `WEBSITE_RUN_FROM_PACKAGE` application setting with a Key Vault reference to the SAS-encoded URL. This keeps the SAS URL encrypted in Key Vault, which provides an extra layer of security.
+
+1. Use the following [`az keyvault create`](/cli/azure/keyvault#az-keyvault-create) command to create a Key Vault instance.       
+
+    ```azurecli    
+    az keyvault create --name "Contoso-Vault" --resource-group <group-name> --location eastus    
+    ```    
+
+1. Follow [these instructions to grant your app access](app-service-key-vault-references.md#granting-your-app-access-to-key-vault) to your key vault:
+
+1. Use the following [`az keyvault secret set`](/cli/azure/keyvault/secret#az-keyvault-secret-set) command to add your external URL as a secret in your key vault:   
+
+    ```azurecli    
+    az keyvault secret set --vault-name "Contoso-Vault" --name "external-url" --value "<SAS-URL>"    
+    ```    
+
+1.  Use the following [`az webapp config appsettings set`](/cli/azure/webapp/config/appsettings#az-webapp-config-appsettings-set) command to create the `WEBSITE_RUN_FROM_PACKAGE` application setting with the value as a Key Vault reference to the external URL:
+
+    ```azurecli    
+    az webapp config appsettings set --settings WEBSITE_RUN_FROM_PACKAGE="@Microsoft.KeyVault(SecretUri=https://Contoso-Vault.vault.azure.net/secrets/external-url/<secret-version>"    
+    ```
+
+    The `<secret-version>` will be in the output of the previous `az keyvault secret set` command.
+
+Updating this application setting causes your web app to restart. After the app has restarted, browse to it make sure it has started correctly using the Key Vault reference.
+
+## How to rotate the access token
+
+It is best practice to periodically rotate the SAS key of your storage account. To ensure the web app does not inadvertently loose access, you must also update the SAS URL in Key Vault.
+
+1. Rotate the SAS key by navigating to your storage account in the Azure portal. Under **Settings** > **Access keys**, click the icon to rotate the SAS key.
+
+1. Copy the new SAS URL, and use the following command to set the updated SAS URL in your key vault:
+
+    ```azurecli    
+    az keyvault secret set --vault-name "Contoso-Vault" --name "external-url" --value "<SAS-URL>"    
+    ``` 
+
+1. Update the key vault reference in your application setting to the new secret version:
+
+    ```azurecli    
+    az webapp config appsettings set --settings WEBSITE_RUN_FROM_PACKAGE="@Microsoft.KeyVault(SecretUri=https://Contoso-Vault.vault.azure.net/secrets/external-url/<secret-version>"    
+    ```
+
+    The `<secret-version>` will be in the output of the previous `az keyvault secret set` command.
+
+## How to revoke the web app's data access
+
+There are two methods to revoke the web app's access to the storage account. 
+
+### Rotate the SAS key for the Azure Storage account
+
+If the SAS key for the storage account is rotated, the web app will no longer have access to the storage account, but it will continue to run with the last downloaded version of the package file. Restart the web app to clear the last downloaded version.
+
+### Remove the web app's access to Key Vault
+
+You can revoke the web app's access to the site data by disabling the web app's access to Key Vault. To do this, remove the access policy for the web app's identity. This is the same identity you created earlier while configuring key vault references.
+
+## Summary
+
+Your application files are now encrypted at rest in your storage account. When your web app starts, it retrieves the SAS URL from your key vault. Finally, the web app loads the application files from the storage account. 
+
+If you need to revoke the web app's access to your storage account, you can either revoke access to the key vault or rotate the storage account keys, which invalidates the SAS URL.
+
+## Frequently Asked Questions
+
+### Is there any additional charge for running my web app from the deployment package?
+
+Only the cost associated with the Azure Storage Account and any applicable egress charges.
+
+### How does running from the deployment package affect my web app?
+
+- Running your app from the deployment package makes `wwwroot/` read-only. Your app receives an error when it attempts to write to this directory.
+- TAR and GZIP formats are not supported.
+- This feature is not compatible with local cache.
+
+## Next steps
+
+- [Key Vault references for App Service](app-service-key-vault-references.md)
+- [Azure Storage encryption for data at rest](../storage/common/storage-service-encryption.md)

articles/app-service/deploy-run-package.md

@@ -59,33 +59,6 @@ az webapp config appsettings set --name <app-name> --resource-group <resource-gr
 
 If you publish an updated package with the same name to Blob storage, you need to restart your app so that the updated package is loaded into App Service.
 
-### Use Key Vault References
-
-For added security, you can use Key Vault References in conjunction with your external URL. This keeps the URL encrypted at rest and allows to leverage Key Vault for secret management and rotation. It is recommended to use Azure Blob storage so you can easily rotate the associated SAS key. Azure Blob storage is encrypted at rest, which keeps your application data secure when it is not deployed on App Service.
-
-1. Create an Azure Key Vault.
-
-    ```azurecli
-    az keyvault create --name "Contoso-Vault" --resource-group <group-name> --location eastus
-    ```
-
-1. Add your external URL as a secret in Key Vault.
-
-    ```azurecli
-    az keyvault secret set --vault-name "Contoso-Vault" --name "external-url" --value "<insert-your-URL>"
-    ```
-
-1. Create the `WEBSITE_RUN_FROM_PACKAGE` app setting and set the value as a Key Vault Reference to the external URL.
-
-    ```azurecli
-    az webapp config appsettings set --settings WEBSITE_RUN_FROM_PACKAGE="@Microsoft.KeyVault(SecretUri=https://Contoso-Vault.vault.azure.net/secrets/external-url/<secret-version>"
-    ```
-
-See the following articles for more information.
-
-- [Key Vault references for App Service](app-service-key-vault-references.md)
-- [Azure Storage encryption for data at rest](../storage/common/storage-service-encryption.md)
-
 ## Troubleshooting
 
 - Running directly from a package makes `wwwroot` read-only. Your app will receive an error if it tries to write files to this directory.

articles/app-service/toc.yml

@@ -175,6 +175,8 @@
       href: configure-ssl-certificate-in-code.md
     - name: Configure TLS mutual authentication
       href: app-service-web-configure-tls-mutual-auth.md
+    - name: Encrypt site data
+      href: configure-encrypt-at-rest-using-cmk.md
   - name: Scale app
     items:
     - name: Scale up server capacity

articles/automation/automation-child-runbooks.md

@@ -29,13 +29,13 @@ Which runbook types can call each other?
 
 * A [PowerShell runbook](automation-runbook-types.md#powershell-runbooks) and a [graphical runbook](automation-runbook-types.md#graphical-runbooks) can call each other inline, as both are PowerShell-based.
 * A [PowerShell Workflow runbook](automation-runbook-types.md#powershell-workflow-runbooks) and a graphical PowerShell Workflow runbook can call each other inline, as both are PowerShell Workflow-based.
-* The PowerShell types and the PowerShell Workflow types can’t call each other inline, and must use **Start-AzAutomationRunbook**.
+* The PowerShell types and the PowerShell Workflow types can't call each other inline, and must use `Start-AzAutomationRunbook`.
 
 When does publish order matter?
 
 The publish order of runbooks only matters for PowerShell Workflow and graphical PowerShell Workflow runbooks.
 
-When your runbook calls a graphical or PowerShell Workflow child runbook using inline execution, it uses the name of the runbook. The name must start with **.\\** to specify that the script is located in the local directory.
+When your runbook calls a graphical or PowerShell Workflow child runbook using inline execution, it uses the name of the runbook. The name must start with `.\\` to specify that the script is located in the local directory.
 
 ### Example
 
@@ -56,15 +56,15 @@ $output = .\PS-ChildRunbook.ps1 –VM $vm –RepeatCount 2 –Restart $true
 ## Starting a child runbook using a cmdlet
 
 > [!IMPORTANT]
-> If your runbook invokes a child runbook with the **Start-AzAutomationRunbook** cmdlet with the *Wait* parameter and the child runbook produces an object result, the operation might encounter an error. To work around the error, see [Child runbooks with object output](troubleshoot/runbooks.md#child-runbook-object) to learn how to implement the logic to poll for the results using the [Get-AzAutomationJobOutputRecord](/powershell/module/az.automation/get-azautomationjoboutputrecord) cmdlet.
+> If your runbook invokes a child runbook with the `Start-AzAutomationRunbook` cmdlet with the `Wait` parameter and the child runbook produces an object result, the operation might encounter an error. To work around the error, see [Child runbooks with object output](troubleshoot/runbooks.md#child-runbook-object) to learn how to implement the logic to poll for the results using the [Get-AzAutomationJobOutputRecord](/powershell/module/az.automation/get-azautomationjoboutputrecord) cmdlet.
 
-You can use **Start-AzAutomationRunbook** to start a runbook as described in [To start a runbook with Windows PowerShell](start-runbooks.md#start-a-runbook-with-powershell). There are two modes of use for this cmdlet. In one mode, the cmdlet returns the job ID when the job is created for the child runbook. In the other mode, which your script enables by specifying the *Wait* parameter, the cmdlet waits until the child job finishes and returns the output from the child runbook.
+You can use `Start-AzAutomationRunbook` to start a runbook as described in [To start a runbook with Windows PowerShell](start-runbooks.md#start-a-runbook-with-powershell). There are two modes of use for this cmdlet. In one mode, the cmdlet returns the job ID when the job is created for the child runbook. In the other mode, which your script enables by specifying the *Wait* parameter, the cmdlet waits until the child job finishes and returns the output from the child runbook.
 
 The job from a child runbook started with a cmdlet runs separately from the parent runbook job. This behavior results in more jobs than starting the runbook inline, and makes the jobs more difficult to track. The parent can start more than one child runbook asynchronously without waiting for each to complete. For this parallel execution calling the child runbooks inline, the parent runbook must use the [parallel keyword](automation-powershell-workflow.md#parallel-processing).
 
-Child runbook output does not return to the parent runbook reliably because of timing. In addition, variables such as *$VerbosePreference*, *$WarningPreference*, and others might not be propagated to the child runbooks. To avoid these issues, you can start the child runbooks as separate Automation jobs using **Start-AzAutomationRunbook** with the *Wait* parameter. This technique blocks the parent runbook until the child runbook is complete.
+Child runbook output does not return to the parent runbook reliably because of timing. In addition, variables such as `$VerbosePreference`, `$WarningPreference`, and others might not be propagated to the child runbooks. To avoid these issues, you can start the child runbooks as separate Automation jobs using `Start-AzAutomationRunbook` with the `Wait` parameter. This technique blocks the parent runbook until the child runbook is complete.
 
-If you don’t want the parent runbook to be blocked on waiting, you can start the child runbook using **Start-AzAutomationRunbook** without the *Wait* parameter. In this case, your runbook must use [Get-AzAutomationJob](/powershell/module/az.automation/get-azautomationjob) to wait for job completion. It must also use [Get-AzAutomationJobOutput](/powershell/module/az.automation/get-azautomationjoboutput) and [Get-AzAutomationJobOutputRecord](/powershell/module/az.automation/get-azautomationjoboutputrecord) to retrieve the results.
+If you don't want the parent runbook to be blocked on waiting, you can start the child runbook using `Start-AzAutomationRunbook` without the `Wait` parameter. In this case, your runbook must use [Get-AzAutomationJob](/powershell/module/az.automation/get-azautomationjob) to wait for job completion. It must also use [Get-AzAutomationJobOutput](/powershell/module/az.automation/get-azautomationjoboutput) and [Get-AzAutomationJobOutputRecord](/powershell/module/az.automation/get-azautomationjoboutputrecord) to retrieve the results.
 
 Parameters for a child runbook started with a cmdlet are provided as a hashtable, as described in [Runbook parameters](start-runbooks.md#runbook-parameters). Only simple data types can be used. If the runbook has a parameter with a complex data type, then it must be called inline.
 
@@ -74,7 +74,7 @@ If jobs within the same Automation account work with more than one subscription,
 
 ### Example
 
-The following example starts a child runbook with parameters and then waits for it to complete using the **Start-AzAutomationRunbook** cmdlet with the *Wait* parameter. Once completed, the example collects cmdlet output from the child runbook. To use **Start-AzAutomationRunbook**, the script must authenticate to your Azure subscription.
+The following example starts a child runbook with parameters and then waits for it to complete using the `Start-AzAutomationRunbook` cmdlet with the `Wait` parameter. Once completed, the example collects cmdlet output from the child runbook. To use `Start-AzAutomationRunbook`, the script must authenticate to your Azure subscription.
 
 ```azurepowershell-interactive
 # Ensure that the runbook does not inherit an AzContext