Merge branch 'MicrosoftDocs:master' into master

Author: inward-eye

articles/active-directory/develop/workload-identity-federation-create-trust-github.md

@@ -10,7 +10,7 @@ ms.service: active-directory
 ms.subservice: develop
 ms.topic: how-to
 ms.workload: identity
-ms.date: 10/18/2021
+ms.date: 01/28/2022
 ms.author: ryanwi
 ms.custom: aaddev
 ms.reviewer: keyam, udayh, vakarand
@@ -44,7 +44,7 @@ In the **Federated credential scenario** drop-down box select **GitHub actions d
 
 Specify the **Organization** and **Repository** for your GitHub Actions workflow.  
 
-For **Entity type**, select **Environment**, **Branch**, **Pull request**, or **Tag** and specify the value.
+For **Entity type**, select **Environment**, **Branch**, **Pull request**, or **Tag** and specify the value. The values must exactly match the configuration in the [GitHub workflow](https://docs.github.com/actions/using-workflows/workflow-syntax-for-github-actions#on).  For more info, read the [examples](#entity-type-examples).
 
 Add a **Name** for the federated credential.
 
@@ -60,6 +60,67 @@ Click **Add** to configure the federated credential.
 > [!IMPORTANT]
 > The **Organization**, **Repository**, and **Entity type** values must exactly match the configuration on the GitHub workflow configuration. Otherwise, Microsoft identity platform will look at the incoming external token and reject the exchange for an access token.  You won't get an error, the exchange fails without error.
 
+### Entity type examples
+
+#### Branch example
+
+For a workflow triggered by a push or pull request event on the main branch:
+
+```yml
+on:
+  push:
+    branches: [ main ]
+  pull_request:
+    branches: [ main ]
+```
+
+Specify an **Entity type** of **Branch** and a **GitHub branch name** of "main".
+
+#### Environment example
+
+For Jobs tied to an environment named "production":
+
+```yml
+on:
+  push:
+    branches:
+      - main
+
+jobs:
+  deployment:
+    runs-on: ubuntu-latest
+    environment: production
+    steps:
+      - name: deploy
+        # ...deployment-specific steps
+```
+
+Specify an **Entity type** of **Environment** and a **GitHub environment name** of "production".
+
+#### Tag example
+
+For example, for a workflow triggered by a push to the tag named "v2":
+
+```yml
+on:
+  push:
+    # Sequence of patterns matched against refs/heads
+    branches:    
+      - main
+      - 'mona/octocat'
+      - 'releases/**'
+    # Sequence of patterns matched against refs/tags
+    tags:        
+      - v2
+      - v1.*
+```
+
+Specify an **Entity type** of **Tag** and a **GitHub tag name** of "v2".
+
+#### Pull request example
+
+For a workflow triggered by a pull request event, specify an **Entity type** of **Pull request**.
+
 # [Microsoft Graph](#tab/microsoft-graph)
 Launch [Azure Cloud Shell](https://portal.azure.com/#cloudshell/) and sign in to your tenant.
 
@@ -145,6 +206,6 @@ az rest -m DELETE  -u 'https://graph.microsoft.com/beta/applications/f6475511-fd
 Before configuring your GitHub Actions workflow, get the *tenant-id* and *client-id* values of your app registration.  You can find these values in the Azure portal. Go to the list of [registered applications](https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/RegisteredApps) and select your app registration.  In **Overview**->**Essentials**, find the **Application (client) ID** and **Directory (tenant) ID**. Set these values in your GitHub environment to use in the Azure login action for your workflow.  
 
 ## Next steps
-[Configure a GitHub Actions workflow](/azure/developer/github/connect-from-azure) to get an access token from Microsoft identity provider and access Azure resources.
+For an end-to-end example, read [Deploy to App Service using GitHub Actions](/azure/app-service/deploy-github-actions?tabs=openid).
 
 Read the [GitHub Actions documentation](https://docs.github.com/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-azure) to learn more about configuring your GitHub Actions workflow to get an access token from Microsoft identity provider and access Azure resources.

articles/active-directory/manage-apps/media/f5-big-ip-kerberos-easy-button/scenario-architecture.png

@@ -4,7 +4,7 @@ description: Learn how to install and configure an On-premises data gateway to c
 author: minewiskan
 ms.service: azure-analysis-services
 ms.topic: conceptual
-ms.date: 11/17/2021
+ms.date: 01/31/2022
 ms.author: owend
 ms.reviewer: minewiskan 
 ms.custom: devx-track-azurepowershell
@@ -20,7 +20,7 @@ To learn more about how Azure Analysis Services works with the gateway, see [Con
 
 **Minimum Requirements:**
 
-* .NET 4.5 Framework
+* .NET 4.8 Framework
 * 64-bit version of Windows 8 / Windows Server 2012 R2 (or later)
 
 **Recommended:**

articles/analysis-services/analysis-services-gateway-install.md

@@ -5,7 +5,7 @@ services: application-gateway
 author: vhorne
 ms.service: application-gateway
 ms.topic: conceptual
-ms.date: 11/30/2021
+ms.date: 01/31/2022
 ms.author: victorh
 ---
 
@@ -23,29 +23,29 @@ Application Gateway integration with Key Vault offers many benefits, including:
 - Stronger security, because TLS/SSL certificates aren't directly handled by the application development team. Integration allows a separate security team to:
   * Set up application gateways.
   * Control application gateway lifecycles.
-  * Grant permissions to selected application gateways to access certificates that are stored in your key vault.
-- Support for importing existing certificates into your key vault. Or use Key Vault APIs to create and manage new certificates with any of the trusted Key Vault partners.
-- Support for automatic renewal of certificates that are stored in your key vault.
+  * Grant permissions to selected application gateways to access certificates that are stored in your Key Vault.
+- Support for importing existing certificates into your Key Vault. Or use Key Vault APIs to create and manage new certificates with any of the trusted Key Vault partners.
+- Support for automatic renewal of certificates that are stored in your Key Vault.
 
 ## Supported certificates
 
-Application Gateway currently supports software-validated certificates only. Hardware security module (HSM)-validated certificates are not supported. 
+Application Gateway currently supports software-validated certificates only. Hardware security module (HSM)-validated certificates aren’t supported. 
 
 After Application Gateway is configured to use Key Vault certificates, its instances retrieve the certificate from Key Vault and install them locally for TLS termination. The instances poll Key Vault at four-hour intervals to retrieve a renewed version of the certificate, if it exists. If an updated certificate is found, the TLS/SSL certificate that's currently associated with the HTTPS listener is automatically rotated.
 
 > [!TIP]
 > Any change to Application Gateway will force a check against Key Vault to see if any new versions of certificates are available. This includes, but not limited to, changes to Frontend IP Configurations, Listeners, Rules, Backend Pools, Resource Tags, and more. If an updated certificate is found, the new certificate will immediately be presented.
 
-Application Gateway uses a secret identifier in Key Vault to reference the certificates. For Azure PowerShell, the Azure CLI, or Azure Resource Manager, we strongly recommend that you use a secret identifier that doesn't specify a version. This way, Application Gateway will automatically rotate the certificate if a newer version is available in your key vault. An example of a secret URI without a version is `https://myvault.vault.azure.net/secrets/mysecret/`.
+Application Gateway uses a secret identifier in Key Vault to reference the certificates. For Azure PowerShell, the Azure CLI, or Azure Resource Manager, we strongly recommend that you use a secret identifier that doesn't specify a version. This way, Application Gateway will automatically rotate the certificate if a newer version is available in your Key Vault. An example of a secret URI without a version is `https://myvault.vault.azure.net/secrets/mysecret/`.
 
 The Azure portal supports only Key Vault certificates, not secrets. Application Gateway still supports referencing secrets from Key Vault, but only through non-portal resources like PowerShell, the Azure CLI, APIs, and Azure Resource Manager templates (ARM templates).
 
 > [!WARNING]
-> Azure Application Gateway currently supports only Key Vault accounts in the same subscription as the Application Gateway resource. Choosing a key vault under a different subscription than your Application Gateway will result in a failure.
+> Azure Application Gateway currently supports only Key Vault accounts in the same subscription as the Application Gateway resource. Choosing a Key Vault under a different subscription than your Application Gateway will result in a failure.
 
 ## Certificate settings in Key Vault
 
-For TLS termination, Application Gateway only supports certificates in Personal Information Exchange (PFX) format. You can either import an existing certificate or create a new one in your key vault. To avoid any failures, ensure that the certificate's status is set to **Enabled** in Key Vault.
+For TLS termination, Application Gateway only supports certificates in Personal Information Exchange (PFX) format. You can either import an existing certificate or create a new one in your Key Vault. To avoid any failures, ensure that the certificate's status is set to **Enabled** in Key Vault.
 
 ## How integration works
 
@@ -64,29 +64,32 @@ You can either create a new user-assigned managed identity or reuse an existing
 
 ### Delegate user-assigned managed identity to Key Vault
 
-Define access policies to use the user-assigned managed identity with your key vault:
+Define access policies to use the user-assigned managed identity with your Key Vault:
 
 1. In the Azure portal, go to **Key Vault**.
-1. Select the key vault that contains your certificate.
+1. Select the Key Vault that contains your certificate.
 1. If you're using the permission model **Vault access policy**: Select **Access Policies**, select **+ Add Access Policy**, select **Get** for **Secret permissions**, and choose your user-assigned managed identity for **Select principal**. Then select **Save**.
 
-   If you're using the permission model **Azure role-based access control**: Select **Access control (IAM)** and [Add a role assignment](../active-directory/managed-identities-azure-resources/how-manage-user-assigned-managed-identities.md#assign-a-role-to-a-user-assigned-managed-identity) for the user-assigned managed identity to the Azure key vault for the role **Key Vault Secrets User**.
+   If you're using the permission model **Azure role-based access control**: Select **Access control (IAM)** and [Add a role assignment](../active-directory/managed-identities-azure-resources/how-manage-user-assigned-managed-identities.md#assign-a-role-to-a-user-assigned-managed-identity) for the user-assigned managed identity to the Azure Key Vault for the role **Key Vault Secrets User**.
 
 ### Verify Firewall Permissions to Key Vault
 
-As of March 15, 2021, Key Vault recognizes Application Gateway as a trusted service by leveraging User Managed Identities for authentication to Azure Key Vault.  With the use of service endpoints and enabling the trusted services option for key vault's firewall, you can build a secure network boundary in Azure. You can deny access to traffic from all networks (including internet traffic) to Key Vault but still make Key Vault accessible for an Application Gateway resource under your subscription.
+As of March 15, 2021, Key Vault recognizes Application Gateway as a trusted service by leveraging User Managed Identities for authentication to Azure Key Vault.  With the use of service endpoints and enabling the trusted services option for Key Vault's firewall, you can build a secure network boundary in Azure. You can deny access to traffic from all networks (including internet traffic) to Key Vault but still make Key Vault accessible for an Application Gateway resource under your subscription.
 
-When you're using a restricted key vault, use the following steps to configure Application Gateway to use firewalls and virtual networks: 
+When you're using a restricted Key Vault, use the following steps to configure Application Gateway to use firewalls and virtual networks:
 
-1. In the Azure portal, in your key vault, select **Networking**.
-1. On the **Firewalls and virtual networks** tab, select **Private endpoint and selected networks**.
+> [!TIP]
+> The following steps are not required if your Key Vault has a Private Endpoint enabled. The application gateway can access the Key Vault using the private IP address.
+
+1. In the Azure portal, in your Key Vault, select **Networking**.
+1. On the **Firewalls and virtual networks** tab, select **Selected networks**.
 1. For **Virtual networks**, select **+ Add existing virtual networks**, and then add the virtual network and subnet for your Application Gateway instance. During the process, also configure the `Microsoft.KeyVault` service endpoint by selecting its checkbox.
-1. Select **Yes** to allow trusted services to bypass the key vault's firewall.
-  
-![Screenshot that shows selections for configuring Application Gateway to use firewalls and virtual networks.](media/key-vault-certs/key-vault-firewall.png)
+1. Select **Yes** to allow trusted services to bypass the Key Vault's firewall.
+
+   ![Screenshot that shows selections for configuring Application Gateway to use firewalls and virtual networks.](media/key-vault-certs/key-vault-firewall.png)
 
 > [!Note]
-> If you deploy the Application Gateway instance via an ARM template by using either the Azure CLI or PowerShell, or via an Azure application deployed from the Azure portal, the SSL certificate is stored in the key vault as a Base64-encoded PFX file. You must complete the steps in [Use Azure Key Vault to pass secure parameter value during deployment](../azure-resource-manager/templates/key-vault-parameter.md). 
+> If you deploy the Application Gateway instance via an ARM template by using either the Azure CLI or PowerShell, or via an Azure application deployed from the Azure portal, the SSL certificate is stored in the Key Vault as a Base64-encoded PFX file. You must complete the steps in [Use Azure Key Vault to pass secure parameter value during deployment](../azure-resource-manager/templates/key-vault-parameter.md). 
 >
 > It's particularly important to set `enabledForTemplateDeployment` to `true`. The certificate might or might not have a password. In the case of a certificate with a password, the following example shows a possible configuration for the `sslCertificates` entry in `properties` for the ARM template configuration for Application Gateway. 
 >
@@ -102,7 +105,7 @@ When you're using a restricted key vault, use the following steps to configure A
 > ]
 > ```
 >
-> The values of `appGatewaySSLCertificateData` and `appGatewaySSLCertificatePassword` are looked up from the key vault, as described in [Reference secrets with dynamic ID](../azure-resource-manager/templates/key-vault-parameter.md#reference-secrets-with-dynamic-id). Follow the references backward from `parameters('secretName')` to see how the lookup happens. If the certificate is passwordless, omit the `password` entry.
+> The values of `appGatewaySSLCertificateData` and `appGatewaySSLCertificatePassword` are looked up from the Key Vault, as described in [Reference secrets with dynamic ID](../azure-resource-manager/templates/key-vault-parameter.md#reference-secrets-with-dynamic-id). Follow the references backward from `parameters('secretName')` to see how the lookup happens. If the certificate is passwordless, omit the `password` entry.
 
 ### Configure Application Gateway Listener
 
@@ -111,26 +114,26 @@ Navigate to your Application Gateway in the Azure portal and select the **Listen
 
 Under **Choose a certificate**, select **Create new** and then select **Choose a certificate from Key Vault** under **Https settings**.
 
-For Cert name, type a friendly name for the certificate to be referenced in Key Vault.  Choose your Managed identity, Key vault, and Certificate.
+For Cert name, type a friendly name for the certificate to be referenced in Key Vault.  Choose your Managed identity, Key Vault, and Certificate.
 
 Once selected, select  **Add** (if creating) or **Save** (if editing) to apply the referenced Key Vault certificate to the listener.
 
 #### Key Vault Azure role-based access control permission model
-Application Gateway supports certificates referenced in Key Vault via the Role-based access control permission model. The first few steps to reference the key vault must be completed via ARM, Bicep, CLI, or  PowerShell.
+Application Gateway supports certificates referenced in Key Vault via the Role-based access control permission model. The first few steps to reference the Key Vault must be completed via ARM template, Bicep, CLI, or  PowerShell.
 
 > [!Note]
 > Specifying Azure Key Vault certificates that are subject to the role-based access control permission model is not supported via the portal.
 
-In this example, we will use PowerShell to reference a new Key Vault certificate.
+In this example, we’ll use PowerShell to reference a new Key Vault certificate.
 ```
 # Get the Application Gateway we want to modify
 $appgw = Get-AzApplicationGateway -Name MyApplicationGateway -ResourceGroupName MyResourceGroup
 # Specify the resource id to the user assigned managed identity - This can be found by going to the properties of the managed identity
 Set-AzApplicationGatewayIdentity -ApplicationGateway $appgw -UserAssignedIdentityId "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/MyResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/MyManagedIdentity"
-# Get the secret ID from key vault
+# Get the secret ID from Key Vault
 $secret = Get-AzKeyVaultSecret -VaultName "MyKeyVault" -Name "CertificateName"
 $secretId = $secret.Id # https://<keyvaultname>.vault.azure.net/secrets/<hash>
-# Specify the secret ID from key vault 
+# Specify the secret ID from Key Vault 
 Add-AzApplicationGatewaySslCertificate -KeyVaultSecretId $secretId -ApplicationGateway $appgw -Name $secret.Name
 # Commit the changes to the Application Gateway
 Set-AzApplicationGateway -ApplicationGateway $appgw
@@ -151,7 +154,7 @@ Set-AzApplicationGateway -ApplicationGateway $appgw
 
 Once the commands have been executed, you can navigate to your Application Gateway in the Azure portal and select the Listeners tab.  Click Add Listener (or select an existing) and specify the Protocol to HTTPS.
 
-Under *Choose a certificate* select the certificate named in the previous steps.  Once selected, select  *Add* (if creating) or *Save* (if editing) to apply the referenced Key Vault certificate to the listener.
+Under **Choose a certificate** select the certificate named in the previous steps.  Once selected, select  *Add* (if creating) or *Save* (if editing) to apply the referenced Key Vault certificate to the listener.
 
 ## Investigating and resolving Key Vault errors