Merge branch 'main' of https://github.com/MicrosoftDocs/azure-docs-pr into rolyon-aadroles-roles-microsoft-hardware-warranty

Author: rolyon

.openpublishing.redirection.json

@@ -9,6 +9,11 @@
             "source_path_from_root": "/articles/api-management/developer-portal-use-community-widgets.md",
             "redirect_url": "/azure/api-management/developer-portal-extend-custom-functionality",
             "redirect_document_id": false
+        },       
+        {
+            "source_path":  "articles/sentinel/whats-new-archive.md",
+            "redirect_url":  "/azure/sentinel/whats-new",
+            "redirect_document_id":  false   
         },
         {
             "source_path":  "articles/backup/sap-hana-db-manage.md",

articles/active-directory/authentication/howto-authentication-temporary-access-pass.md

@@ -169,7 +169,9 @@ If MFA is required for the resource tenant, the guest user needs to perform MFA
 ### Expiration
 
 An expired or deleted Temporary Access Pass can’t be used for interactive or non-interactive authentication. 
-Users need to reauthenticate with different authentication methods after the Temporary Access Pass is expired or deleted. 
+Users need to reauthenticate with different authentication methods after the Temporary Access Pass is expired or deleted.
+
+The token lifetime (session token, refresh token, access token, etc.) obtained via a Temporary Access Pass login will be limited to the Temporary Access Pass lifetime. As a result, a Temporary Access Pass expiring will lead to the expiration of the associated token.
 
 ## Delete an expired Temporary Access Pass
 

articles/active-directory/develop/app-objects-and-service-principals.md

@@ -9,7 +9,7 @@ ms.service: active-directory
 ms.subservice: develop
 ms.topic: conceptual
 ms.workload: identity
-ms.date: 07/20/2022
+ms.date: 11/02/2022
 ms.author: ryanwi
 ms.custom: contperf-fy21q4-portal, aaddev, identityplatformtop40
 ms.reviewer: sureshja

articles/active-directory/develop/application-model.md

@@ -9,7 +9,7 @@ ms.service: active-directory
 ms.subservice: develop
 ms.topic: conceptual
 ms.workload: identity
-ms.date: 09/27/2021
+ms.date: 11/02/2022
 ms.author: ryanwi
 ms.reviewer: jmprieur, saeeda, sureshja, ludwignick
 ms.custom: aaddev, identityplatformtop40, scenarios:getting-started

articles/active-directory/develop/authentication-vs-authorization.md

@@ -9,7 +9,7 @@ ms.service: active-directory
 ms.subservice: develop
 ms.topic: conceptual
 ms.workload: identity
-ms.date: 08/26/2022
+ms.date: 11/02/2022
 ms.author: ryanwi
 ms.reviewer: jmprieur, saeeda, sureshja, ludwignick
 ms.custom: aaddev, identityplatformtop40, scenarios:getting-started

articles/active-directory/develop/howto-modify-supported-accounts.md

@@ -9,10 +9,10 @@ ms.service: active-directory
 ms.subservice: develop
 ms.topic: how-to
 ms.workload: identity
-ms.date: 11/15/2020
+ms.date: 11/02/2022
 ms.author: ryanwi
 ms.custom: aaddev
-ms.reviewer: marsma, aragra, lenalepa, sureshja
+ms.reviewer: aragra, sureshja
 # Customer intent: As an application developer, I need to know how to modify which account types can sign in to or access my application or API.
 ---
 
@@ -33,14 +33,17 @@ To specify a different setting for the account types supported by an existing ap
 1. Sign in to the <a href="https://portal.azure.com/" target="_blank">Azure portal</a>.
 1. If you have access to multiple tenants, use the **Directories + subscriptions** filter :::image type="icon" source="./media/common/portal-directory-subscription-filter.png" border="false"::: in the top menu to switch to the tenant in which the app is registered.
 1. Search for and select **Azure Active Directory**.
-1. Under **Manage**, select **App registrations**, then select your application.
-1. Now, specify who can use the application, sometimes referred to as the *sign-in audience*.
-
-    | Supported account types | Description |
-    |-------------------------|-------------|
-    | **Accounts in this organizational directory only** | Select this option if you're building an application for use only by users (or guests) in *your* tenant.<br><br>Often called a *line-of-business* (LOB) application, this is a **single-tenant** application in the Microsoft identity platform. |
-    | **Accounts in any organizational directory** | Select this option if you'd like users in *any* Azure AD tenant to be able to use your application. This option is appropriate if, for example, you're building a software-as-a-service (SaaS) application that you intend to provide to multiple organizations.<br><br>This is known as a **multi-tenant** application in the Microsoft identity platform. |
-1. Select **Save**.
+1. Under **Manage**, select **App registrations**, select your application, and then select **Manifest** to use the manifest editor.
+1. Download the manifest JSON file locally.
+1. Now, specify who can use the application, sometimes referred to as the *sign-in audience*.  Find the *signInAudience* property in the manifest JSON file and set it to one of the following property values:
+
+    | Property value | Supported account types | Description |
+    |----------------|-------------------------|-------------|
+    | **AzureADMyOrg** | Accounts in this organizational directory only (Microsoft only - Single tenant) |All user and guest accounts in your directory can use your application or API. Use this option if your target audience is internal to your organization. |
+    | **AzureADMultipleOrgs** | Accounts in any organizational directory (Any Azure AD directory - Multitenant) | All users with a work or school account from Microsoft can use your application or API. This includes schools and businesses that use Office 365. Use this option if your target audience is business or educational customers and to enable multitenancy. |
+    | **AzureADandPersonalMicrosoftAccount** | Accounts in any organizational directory (Any Azure AD directory - Multitenant) and personal Microsoft accounts (e.g. Skype, Xbox) | All users with a work or school, or personal Microsoft account can use your application or API. It includes schools and businesses that use Office 365 as well as personal accounts that are used to sign in to services like Xbox and Skype. Use this option to target the widest set of Microsoft identities and to enable multitenancy.|
+    | **PersonalMicrosoftAccount** | Personal Microsoft accounts only | Personal accounts that are used to sign in to services like Xbox and Skype. Use this option to target the widest set of Microsoft identities.|
+1. Save your changes to the JSON file locally, then select **Upload** in the manifest editor to upload the updated manifest JSON file.
 
 ### Why changing to multi-tenant can fail
 

articles/active-directory/develop/single-and-multi-tenant-apps.md

@@ -9,7 +9,7 @@ ms.service: active-directory
 ms.subservice: develop
 ms.topic: conceptual
 ms.workload: identity
-ms.date: 10/13/2021
+ms.date: 11/02/2022
 ms.author: ryanwi
 ms.reviewer: justhu
 ms.custom: aaddev

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

@@ -7,7 +7,7 @@ ms.service: active-directory
 ms.subservice: develop
 ms.workload: identity
 ms.topic: conceptual
-ms.date: 12/06/2021
+ms.date: 11/02/2022
 ms.author: ryanwi
 ms.reviewer: udayh, ilanas
 ms.custom: aaddev 

articles/active-directory/hybrid/reference-connect-version-history.md

@@ -77,6 +77,19 @@ If you want all the latest features and updates, check this page and install wha
 
 To read more about auto-upgrade, see [Azure AD Connect: Automatic upgrade](how-to-connect-install-automatic-upgrade.md).
 
+## 2.1.19.0
+
+### Release status: 
+11/2/2022: Released for download
+
+### Functional changes
+
+ - We added a new attribute 'employeeLeaveDateTime' for syncing to Azure AD 
+
+### Bug fixes
+
+ - we fixed a bug where Azure AD Connect Password writeback stopped with error code "SSPR_0029 ERROR_ACCESS_DENIED"
+
 ## 2.1.18.0
 
 ### Release status: 

articles/aks/use-pod-security-policies.md

@@ -8,8 +8,8 @@ ms.date: 03/25/2021
 
 # Preview - Secure your cluster using pod security policies in Azure Kubernetes Service (AKS)
 
-[!Important]
-The feature described in this document, pod security policy (preview), will begin deprecation with Kubernetes version 1.21, with its removal in version 1.25. AKS will mark Pod Security Policy as "Deprecated" in the AKS API on 04-01-2023. You can now Migrate Pod Security Policy to Pod Security Admission Controller ahead of the deprecation.
+> [!Important]
+> The feature described in this article, pod security policy (preview), will be deprecated starting with Kubernetes version 1.21, and it will be removed in version 1.25. AKS will mark the pod security policy as Deprecated with the AKS API on 04-01-2023. You can migrate pod security policy to pod security admission controller before the deprecation deadline.
 
 After pod security policy (preview) is deprecated, you must have already migrated to Pod Security Admission controller or disabled the feature on any existing clusters using the deprecated feature to perform future cluster upgrades and stay within Azure support.