Merge pull request #183117 from MicrosoftDocs/master

12/16 PM Publish

Author: huypub

.github/workflows/stale.yml

@@ -14,12 +14,12 @@ jobs:
       with:
         repo-token: ${{ secrets.GITHUB_TOKEN }}
         days-before-pr-stale: 14
-        days-before-pr-close: 9999
+        days-before-pr-close: 90
         stale-pr-label: inactive
         close-pr-label: auto-close
         exempt-pr-labels: keep-open
         operations-per-run: 1200
-        ascending: false
+        ascending: true
         # start-date: '2021-03-19'
         stale-pr-message: >
           This pull request has been inactive for at least 14 days.

articles/active-directory/develop/TOC.yml

@@ -150,6 +150,8 @@
     href: authentication-flows-app-scenarios.md
   - name: Applications and service principals
     href: app-objects-and-service-principals.md
+  - name: Workload identities
+    href: workload-identities-overview.md
   - name: Workload identity federation
     href: workload-identity-federation.md
   - name: Identity platform best practices

articles/active-directory/develop/developer-glossary.md

@@ -261,6 +261,7 @@ The `error` field has several possible values - review the protocol documentatio
 | AADSTS90022 | AuthenticatedInvalidPrincipalNameFormat - The principal name format is not valid, or does not meet the expected `name[/host][@realm]` format. The principal name is required, host and realm are optional and may be set to null. |
 | AADSTS90023 | InvalidRequest - The authentication service request is not valid. |
 | AADSTS9002313 | InvalidRequest - Request is malformed or invalid. - The issue here is because there was something wrong with the request to a certain endpoint. The suggestion to this issue is to get a fiddler trace of the error occurring and looking to see if the request is actually properly formatted or not. |
+| AADSTS9002332 | Application '{principalId}'({principalName}) is configured for use by Azure Active Directory users only. Please do not use the /consumers endpoint to serve this request. |
 | AADSTS90024 | RequestBudgetExceededError - A transient error has occurred. Try again. |
 | AADSTS90027 | We are unable to issue tokens from this API version on the MSA tenant. Please contact the application vendor as they need to use version 2.0 of the protocol to support this.|
 | AADSTS90033 | MsodsServiceUnavailable - The Microsoft Online Directory Service (MSODS) is not available. |

articles/active-directory/develop/media/workload-identities-overview/identity-types.png

@@ -0,0 +1,53 @@
+---
+title: Workload identities 
+titleSuffix: Microsoft identity platform
+description: 
+services: active-directory
+author: rwike77
+manager: CelesteDG
+
+ms.service: active-directory
+ms.subservice: develop
+ms.workload: identity
+ms.topic: conceptual
+ms.date: 12/06/2021
+ms.author: ryanwi
+ms.reviewer: udayh, ilanas
+ms.custom: aaddev 
+#Customer intent: As a developer, I want workload identities so I can authenticate with Azure AD and access Azure AD protected resources.
+---
+
+# What are workload identities?
+
+A workload identity is an identity used by a software workload (such as an application, service, script, or container) to authenticate and access other services and resources. The terminology is inconsistent across the industry, but generally a workload identity is something you need for your software entity to authenticate with some system.  For example, a workload identity could be a user account that your client authenticates as to access a MongoDB database.  A workload identity could also be an AWS service role attached to an EC2 instance with read-only access to an Amazon S3 bucket.
+
+In Azure Active Directory (Azure AD), workload identities are applications, service principals, and managed identities.  
+
+An [application](app-objects-and-service-principals.md#application-object) is an abstract entity, or template, defined by its application object.  The application object is the *global* representation of your application for use across all tenants. The application object describes how tokens are issued, the resources the application needs to access, and the actions that the application can take.
+
+A [service principal](app-objects-and-service-principals.md#service-principal-object) is the *local* representation, or application instance, of a global application object in a specific tenant. An application object is used as a template to create a service principal object in every tenant where the application is used.  The service principal object defines what the app can actually do in a specific tenant, who can access the app, and what resources the app can access.
+
+A [managed identity](/azure/active-directory/managed-identities-azure-resources/overview) is a special type of service principal that eliminates the need for developers to manage credentials.
+
+Here are some ways that workload identities in Azure AD are used:
+
+- An app that enables a web app to access Microsoft Graph based on admin or user consent. This access could be either on behalf of the user or on behalf of the application.
+- A managed identity used by a developer to provision their service with access to an Azure resource such as Azure Key Vault or Azure Storage.
+- A service principal used by a developer to enable a CI/CD pipeline to deploy a web app from GitHub to Azure App Service.
+
+## Workload identities, other machine identities, and human identities
+
+At a high level, there are two types of identities: human and machine/non-human identities. Workload identities and device identities together make up a group called machine (or non-human) identities.  Workload identities represent software workloads while device identities represent devices such as desktop computers, mobile, IoT sensors, and IoT managed devices. Machine identities are distinct from human identities, which represent people such as employees (internal workers and front line workers) and external users (customers, consultants, vendors, and partners).  
+
+:::image type="content" source="media/workload-identities-overview/identity-types.svg" alt-text="Shows different types of machine and human identities" border="false":::
+
+## Supported scenarios
+
+Here are some ways you can use workload identities:
+- Review service principals and applications that are assigned to privileged directory roles in Azure AD using [access reviews for service principals](/azure/active-directory/privileged-identity-management/pim-create-azure-ad-roles-and-resource-roles-review).
+- Access Azure AD protected resources without needing to manage secrets (for supported scenarios) using [workload identity federation](workload-identity-federation.md).
+- Apply Conditional Access policies to service principals owned by your organization using [Conditional Access for workload identities](/azure/active-directory/conditional-access/workload-identity).
+
+## Next steps
+
+Learn how to [secure access of workload identities](/azure/active-directory/conditional-access/workload-identity) with adaptive policies.

articles/active-directory/develop/media/workload-identities-overview/identity-types.svg

@@ -1,6 +1,6 @@
 ---
 title: Configure F5 BIG-IP Access Policy Manager for Kerberos authentication
-description: Learn how to configure F5’s BIG-IP Access Policy Manager (APM) with Azure Active Directory (Azure AD) for Secure hybrid Access (SHA) to Kerberos applications.
+description: Learn how to implement Secure Hybrid Access (SHA) with Single Sign-on (SSO) to Kerberos applications using F5’s BIG-IP advanced configuration.
 services: active-directory
 author: NishthaBabith-V
 manager: martinco
@@ -15,7 +15,7 @@ ms.collection: M365-identity-device-management
 
 # Tutorial: Configure F5 BIG-IP Access Policy Manager for Kerberos authentication
 
-In this tutorial, you’ll learn to configure F5’s BIG-IP Access Policy Manager (APM) with Azure Active Directory (Azure AD) for Secure hybrid Access (SHA) to Kerberos applications.
+In this tutorial, you’ll learn how to implement Secure Hybrid Access (SHA) with Single Sign-on (SSO) to Kerberos applications using F5’s BIG-IP advanced configuration. 
 
 Integrating a BIG-IP with Azure AD provides many benefits, including:
 

articles/active-directory/develop/reference-aadsts-error-codes.md

@@ -11,7 +11,7 @@ ms.topic: how-to
 ms.tgt_pltfrm: na
 ms.workload: identity
 ms.subservice: pim
-ms.date: 10/10/2021
+ms.date: 12/16/2021
 ms.author: curtand
 ms.reviewer: shaunliu
 ms.custom: pim
@@ -39,12 +39,12 @@ You can set up just-in-time access to permissions and roles beyond Azure AD and
 
 If you want to assign a group to an Azure AD or Azure Resource role and require elevation through a PIM process, there are two ways to do it:
 
-- **Assign the group persistently to a role**. You then grant users eligible member access to the group in PIM. Eligible users must then activate their membership to get into the group that is permanently assigned to the role. This path requires a role-assignable group to be enabled in PIM as a privileged access group for the Azure AD role.
-- **Assign the group as eligible for a role** through PIM. Everyone in the group must activate their assignment to get access to the role. This path requires a role-assignable group for the Azure AD role, and a security group for Azure resources.
+- **Assign the group persistently to a role**. You then grant users eligible member access to the group in PIM. Each eligible user must then activate their membership to get into the group that is permanently assigned to the role. This path requires a role-assignable group to be enabled in PIM as a privileged access group for the Azure AD role.
+- **Assign the group as eligible for a role** through PIM. Everyone in the group gets access to the role assignment at once when the group's assignment is activated. This path requires a role-assignable group for the Azure AD role, and a security group for Azure resources.
 
     ![Diagram showing two ways to assign role using privileged access groups in PIM.](./media/concept-privileged-access-versus-role-assignable/concept-privileged-access.png)
 
-Either of these methods will work for the end-to-end scenario. We recommend that you use the first method in most cases. You should use the second method only if you are trying to:
+Method one allows maximum granularity of permissions, and method two allows simple, one-step activation for a group of users. Either of these methods will work for the end-to-end scenario. We recommend that you use the second method in most cases. You should use the first method only if you are trying to:
 
 - Assign a group to multiple Azure AD or Azure resource roles and have users activate once to get access to multiple roles.
 - Maintain different activation policies for different sets of users to access an Azure AD or Azure resource role. For example, if you want some users to be approved before becoming a Global Administrator while allowing other users to be auto-approved, you can set up two privileged access groups, assign them both persistently (a "permanent" assignment in Privileged Identity Management) to the Global Administrator role and then use a different activation policy for the member role for each group.

articles/active-directory/develop/workload-identities-overview.md

@@ -38,10 +38,10 @@ To access AKS nodes, you connect using an SSH key pair (public and private), whi
 
 1. Go to [https://shell.azure.com](https://shell.azure.com) to open Cloud Shell in your browser.
 
-1. Run the `ssh-keygen` command. The following example creates an SSH key pair using RSA encryption and a bit length of 2048:
+1. Run the `ssh-keygen` command. The following example creates an SSH key pair using RSA encryption and a bit length of 4096:
 
     ```console
-    ssh-keygen -t rsa -b 2048
+    ssh-keygen -t rsa -b 4096
     ```
 
 For more information about creating SSH keys, see [Create and manage SSH keys for authentication in Azure][ssh-keys].