Merge pull request #252921 from MicrosoftDocs/main

9/26/2023 PM Publish

Author: Taojunshen

articles/active-directory/devices/hybrid-join-plan.md

@@ -64,11 +64,8 @@ For devices running the Windows desktop operating system, supported versions are
 
 ### Windows down-level devices
 
-- Windows 8.1
-- Windows 7 support ended on January 14, 2020. For more information, see [Support for Windows 7 has ended](https://support.microsoft.com/en-us/help/4057281/windows-7-support-ended-on-january-14-2020)
 - Windows Server 2012 R2
 - Windows Server 2012
-- Windows Server 2008 R2 for support information on Windows Server 2008 and 2008 R2, see [Prepare for Windows Server 2008 end of support](https://www.microsoft.com/cloud-platform/windows-server-2008)
 
 As a first planning step, you should review your environment and determine whether you need to support Windows down-level devices.
 

articles/active-directory/enterprise-users/groups-self-service-management.md

@@ -10,7 +10,7 @@ ms.service: active-directory
 ms.subservice: enterprise-users
 ms.workload: identity
 ms.topic: how-to
-ms.date: 09/08/2023
+ms.date: 09/26/2023
 ms.author: barclayn
 ms.reviewer: krbain
 ms.custom: it-pro, seo-update-azuread-jan, has-azure-ad-ps-ref
@@ -48,6 +48,9 @@ Groups created in | Security group default behavior | Microsoft 365 group defaul
 
 2. Select **All groups** > **Groups**, and then select **General** settings.
 
+ > [!NOTE]
+ > This setting only restricts access of group information in **My Groups**. It does not restrict access to group information via other methods like Microsoft Graph API calls or the Entra Admin Center
+
  ![Microsoft Entra groups general settings.](./media/groups-self-service-management/groups-settings-general.png)
    > [!NOTE]
    > In June 2024, the setting **Restrict users access to My Groups** will change to **Restrict users ability to see and edit security groups in My Groups.** If the setting is currently set to ‘Yes,’ end users will be able to access My Groups in June 2024, but will not be able to see security groups.

articles/ai-services/TOC.yml

@@ -79,6 +79,8 @@
       href: security-features.md
     - name: Authenticate requests
       href: authentication.md
+    - name: Disable local authentication
+      href: disable-local-auth.md
     - name: Rotate keys
       href: rotate-keys.md
     - name: Use environment variables

articles/ai-services/authentication.md

@@ -18,7 +18,7 @@ Each request to an Azure AI service must include an authentication header. This
 
 * Authenticate with a [single-service](#authenticate-with-a-single-service-resource-key) or [multi-service](#authenticate-with-a-multi-service-resource-key) resource key
 * Authenticate with a [token](#authenticate-with-an-access-token)
-* Authenticate with [Azure Active Directory (AAD)](#authenticate-with-an-access-token)
+* Authenticate with [Azure Active Directory (AAD)](#authenticate-with-azure-active-directory)
 
 ## Prerequisites
 
@@ -40,7 +40,7 @@ Let's quickly review the authentication headers available for use with Azure AI
 
 The first option is to authenticate a request with a resource key for a specific service, like Translator. The keys are available in the Azure portal for each resource that you've created. To use a resource key to authenticate a request, it must be passed along as the `Ocp-Apim-Subscription-Key` header.
 
-These sample requests demonstrates how to use the `Ocp-Apim-Subscription-Key` header. Keep in mind, when using this sample you'll need to include a valid resource key.
+These sample requests demonstrate how to use the `Ocp-Apim-Subscription-Key` header. Keep in mind, when using this sample you'll need to include a valid resource key.
 
 This is a sample call to the Translator service:
 ```cURL
@@ -160,7 +160,129 @@ curl -X POST 'https://api.cognitive.microsofttranslator.com/translate?api-versio
 --data-raw '[{ "text": "How much for the cup of coffee?" }]' | json_pp
 ```
 
-[!INCLUDE [](../../includes/cognitive-services-azure-active-directory-authentication.md)]
+## Authenticate with Azure Active Directory
+
+> [!IMPORTANT]
+> Azure AD authentication always needs to be used together with custom subdomain name of your Azure resource. [Regional endpoints](./cognitive-services-custom-subdomains.md#is-there-a-list-of-regional-endpoints) do not support Azure AD authentication.
+
+In the previous sections, we showed you how to authenticate against Azure AI services using a single-service or multi-service subscription key. While these keys provide a quick and easy path to start development, they fall short in more complex scenarios that require Azure [role-based access control (Azure RBAC)](../../articles/role-based-access-control/overview.md). Let's take a look at what's required to authenticate using Azure Active Directory (Azure AD).
+
+In the following sections, you'll use either the Azure Cloud Shell environment or the Azure CLI to create a subdomain, assign roles, and obtain a bearer token to call the Azure AI services. If you get stuck, links are provided in each section with all available options for each command in Azure Cloud Shell/Azure CLI.
+
+> [!IMPORTANT]
+> If your organization is doing authentication through Azure AD, you should [disable local authentication](./disable-local-auth.md) (authentication with keys) so that users in the organization must always use Azure AD.
+
+### Create a resource with a custom subdomain
+
+The first step is to create a custom subdomain. If you want to use an existing Azure AI services resource which does not have custom subdomain name, follow the instructions in [Azure AI services custom subdomains](./cognitive-services-custom-subdomains.md#how-does-this-impact-existing-resources) to enable custom subdomain for your resource.
+
+1. Start by opening the Azure Cloud Shell. Then [select a subscription](/powershell/module/az.accounts/set-azcontext):
+
+   ```powershell-interactive
+   Set-AzContext -SubscriptionName <SubscriptionName>
+   ```
+
+2. Next, [create an Azure AI services resource](/powershell/module/az.cognitiveservices/new-azcognitiveservicesaccount) with a custom subdomain. The subdomain name needs to be globally unique and cannot include special characters, such as: ".", "!", ",".
+
+   ```powershell-interactive
+   $account = New-AzCognitiveServicesAccount -ResourceGroupName <RESOURCE_GROUP_NAME> -name <ACCOUNT_NAME> -Type <ACCOUNT_TYPE> -SkuName <SUBSCRIPTION_TYPE> -Location <REGION> -CustomSubdomainName <UNIQUE_SUBDOMAIN>
+   ```
+
+3. If successful, the **Endpoint** should show the subdomain name unique to your resource.
+
+
+### Assign a role to a service principal
+
+Now that you have a custom subdomain associated with your resource, you're going to need to assign a role to a service principal.
+
+> [!NOTE]
+> Keep in mind that Azure role assignments may take up to five minutes to propagate.
+
+1. First, let's register an [Azure AD application](/powershell/module/Az.Resources/New-AzADApplication).
+
+   ```powershell-interactive
+   $SecureStringPassword = ConvertTo-SecureString -String <YOUR_PASSWORD> -AsPlainText -Force
+
+   $app = New-AzureADApplication -DisplayName <APP_DISPLAY_NAME> -IdentifierUris <APP_URIS> -PasswordCredentials $SecureStringPassword
+   ```
+
+   You're going to need the **ApplicationId** in the next step.
+
+2. Next, you need to [create a service principal](/powershell/module/az.resources/new-azadserviceprincipal) for the Azure AD application.
+
+   ```powershell-interactive
+   New-AzADServicePrincipal -ApplicationId <APPLICATION_ID>
+   ```
+
+   >[!NOTE]
+   > If you register an application in the Azure portal, this step is completed for you.
+
+3. The last step is to [assign the "Cognitive Services User" role](/powershell/module/az.Resources/New-azRoleAssignment) to the service principal (scoped to the resource). By assigning a role, you're granting service principal access to this resource. You can grant the same service principal access to multiple resources in your subscription.
+   >[!NOTE]
+   > The ObjectId of the service principal is used, not the ObjectId for the application.
+   > The ACCOUNT_ID will be the Azure resource Id of the Azure AI services account you created. You can find Azure resource Id from "properties" of the resource in Azure portal.
+
+   ```azurecli-interactive
+   New-AzRoleAssignment -ObjectId <SERVICE_PRINCIPAL_OBJECTID> -Scope <ACCOUNT_ID> -RoleDefinitionName "Cognitive Services User"
+   ```
+
+### Sample request
+
+In this sample, a password is used to authenticate the service principal. The token provided is then used to call the Computer Vision API.
+
+1. Get your **TenantId**:
+   ```powershell-interactive
+   $context=Get-AzContext
+   $context.Tenant.Id
+   ```
+
+2. Get a token:
+   > [!NOTE]
+   > If you're using Azure Cloud Shell, the `SecureClientSecret` class isn't available. 
+
+   #### [PowerShell](#tab/powershell)
+   ```powershell-interactive
+   $authContext = New-Object "Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationContext" -ArgumentList "https://login.windows.net/<TENANT_ID>"
+   $secureSecretObject = New-Object "Microsoft.IdentityModel.Clients.ActiveDirectory.SecureClientSecret" -ArgumentList $SecureStringPassword   
+   $clientCredential = New-Object "Microsoft.IdentityModel.Clients.ActiveDirectory.ClientCredential" -ArgumentList $app.ApplicationId, $secureSecretObject
+   $token=$authContext.AcquireTokenAsync("https://cognitiveservices.azure.com/", $clientCredential).Result
+   $token
+   ```
+   
+   #### [Azure Cloud Shell](#tab/azure-cloud-shell)
+   ```Azure Cloud Shell
+   $authContext = New-Object "Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationContext" -ArgumentList "https://login.windows.net/<TENANT_ID>"
+   $clientCredential = New-Object "Microsoft.IdentityModel.Clients.ActiveDirectory.ClientCredential" -ArgumentList $app.ApplicationId, <YOUR_PASSWORD>
+   $token=$authContext.AcquireTokenAsync("https://cognitiveservices.azure.com/", $clientCredential).Result
+   $token
+   ``` 
+
+   ---
+
+3. Call the Computer Vision API:
+   ```powershell-interactive
+   $url = $account.Endpoint+"vision/v1.0/models"
+   $result = Invoke-RestMethod -Uri $url  -Method Get -Headers @{"Authorization"=$token.CreateAuthorizationHeader()} -Verbose
+   $result | ConvertTo-Json
+   ```
+
+Alternatively, the service principal can be authenticated with a certificate. Besides service principal, user principal is also supported by having permissions delegated through another Azure AD application. In this case, instead of passwords or certificates, users would be prompted for two-factor authentication when acquiring token.
+
+## Authorize access to managed identities
+ 
+Azure AI services support Azure Active Directory (Azure AD) authentication with [managed identities for Azure resources](../../articles/active-directory/managed-identities-azure-resources/overview.md). Managed identities for Azure resources can authorize access to Azure AI services resources using Azure AD credentials from applications running in Azure virtual machines (VMs), function apps, virtual machine scale sets, and other services. By using managed identities for Azure resources together with Azure AD authentication, you can avoid storing credentials with your applications that run in the cloud.  
+
+### Enable managed identities on a VM
+
+Before you can use managed identities for Azure resources to authorize access to Azure AI services resources from your VM, you must enable managed identities for Azure resources on the VM. To learn how to enable managed identities for Azure Resources, see:
+
+- [Azure portal](../../articles/active-directory/managed-identities-azure-resources/qs-configure-portal-windows-vm.md)
+- [Azure PowerShell](../../articles/active-directory/managed-identities-azure-resources/qs-configure-powershell-windows-vm.md)
+- [Azure CLI](../../articles/active-directory/managed-identities-azure-resources/qs-configure-cli-windows-vm.md)
+- [Azure Resource Manager template](../../articles/active-directory/managed-identities-azure-resources/qs-configure-template-windows-vm.md)
+- [Azure Resource Manager client libraries](../../articles/active-directory/managed-identities-azure-resources/qs-configure-sdk-windows-vm.md)
+
+For more information about managed identities, see [Managed identities for Azure resources](../../articles/active-directory/managed-identities-azure-resources/overview.md).
 
 ## Use Azure key vault to securely access credentials
 

articles/ai-services/disable-local-auth.md

@@ -0,0 +1,30 @@
+---
+title: Disable local authentication in Azure AI Services
+titleSuffix: Azure AI services
+description: "This article describes disabling local authentication in Azure AI Services."
+services: cognitive-services
+author: PatrickFarley
+manager: nitinme
+ms.service: cognitive-services
+ms.topic: how-to
+ms.date: 09/22/2023
+ms.author: pafarley
+---
+
+# Disable local authentication in Azure AI Services
+
+Azure AI Services provides Azure Active Directory (Azure AD) authentication support for all resources. This gives organizations control to disable local authentication methods and enforce Azure AD authentication. This feature provides you with seamless integration when you require centralized control and management of identities and resource credentials.
+
+You can disable local authentication using the Azure policy [Cognitive Services accounts should have local authentication methods disabled](https://ms.portal.azure.com/#view/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F71ef260a-8f18-47b7-abcb-62d0673d94dc). You can set it at the subscription level or resource group level to enforce the policy for a group of services.
+
+Disabling local authentication doesn't take effect immediately. Allow a few minutes for the service to block future authentication requests.
+
+You can use PowerShell to determine whether the local authentication policy is currently enabled. First sign in with the `Connect-AzAccount` command. Then use the cmdlet **[Get-AzCognitiveServicesAccount](/powershell/module/az.cognitiveservices/get-azcognitiveservicesaccount)** to retrieve your resource, and check the property `DisableLocalAuth`. A value of `true` means local authentication is disabled.
+
+
+## Re-enable local authentication
+
+To enable local authentication, execute the PowerShell cmdlet **[Set-AzCognitiveServicesAccount](/powershell/module/az.cognitiveservices/set-azcognitiveservicesaccount)** with the parameter `-DisableLocalAuth false`.  Allow a few minutes for the service to accept the change to allow local authentication requests.
+
+## Next steps
+- [Authenticate requests to Azure AI services](./authentication.md)

articles/aks/TOC.yml

@@ -343,6 +343,8 @@
           href: ../defender-for-cloud/defender-for-containers-enable.md?tabs=aks-deploy-portal%2Ck8s-deploy-asc%2Ck8s-verify-asc%2Ck8s-remove-arc%2Caks-removeprofile-api&pivots=defender-for-container-aks?toc=/azure/aks/toc.json&bc=/azure/aks/breadcrumb/toc.json
         - name: Image security
           items:
+            - name: Validate signed images with Image Integrity
+              href: image-integrity.md
             - name: Remove vulnerable images with ImageCleaner
               href: image-cleaner.md
             - name: Scan images in your CI/CD Workflow

articles/aks/configure-kubenet.md

@@ -50,6 +50,7 @@ With *Azure CNI*, each pod receives an IP address in the IP subnet and can commu
 
 * An additional hop is required in the design of kubenet, which adds minor latency to pod communication.
 * Route tables and user-defined routes are required for using kubenet, which adds complexity to operations.
+  * For more information, see [Customize cluster egress with a user-defined routing table in AKS](./egress-udr.md) and [Customize cluster egress with outbound types in AKS](./egress-outboundtype.md).
 * Direct pod addressing isn't supported for kubenet due to kubenet design.
 * Unlike Azure CNI clusters, multiple kubenet clusters can't share a subnet.
 * AKS doesn't apply Network Security Groups (NSGs) to its subnet and doesn't modify any of the NSGs associated with that subnet. If you provide your own subnet and add NSGs associated with that subnet, you must ensure the security rules in the NSGs allow traffic between the node and pod CIDR. For more details, see [Network security groups][aks-network-nsg].
@@ -86,7 +87,7 @@ The following considerations help outline when each network model may be the mos
 * Most of the pod communication is within the cluster.
 * You don't need advanced AKS features, such as virtual nodes or Azure Network Policy.
 
-***Use *Azure CNI* when**:
+**Use *Azure CNI* when**:
 
 * You have available IP address space.
 * Most of the pod communication is to resources outside of the cluster.
@@ -247,7 +248,7 @@ kubenet networking requires organized route table rules to successfully route re
 > [!NOTE]
 > When you create and use your own VNet and route table with the kubenet network plugin, you need to use a [user-assigned control plane identity][bring-your-own-control-plane-managed-identity]. For a system-assigned control plane identity, you can't retrieve the identity ID before creating a cluster, which causes a delay during role assignment.
 >
-> Both system-assigned and user-assigned managed identities are supported when you create and use your own VNet and route table with the azure network plugin. We highly recommend using a user-assigned managed identity for BYO scenarios.
+> Both system-assigned and user-assigned managed identities are supported when you create and use your own VNet and route table with the Azure network plugin. We highly recommend using a user-assigned managed identity for BYO scenarios.
 
 ### Add a route table with a user-assigned managed identity to your AKS cluster