Merge pull request #110189 from iainfoulds/azuread-authentication-metadatacleanup

[AzureAD-Authentication] Metadata cleanup

Author: v-shils

articles/active-directory/authentication/active-directory-certificate-based-authentication-android.md

@@ -5,7 +5,7 @@ description: Learn about the supported scenarios and the requirements for config
 services: active-directory
 ms.service: active-directory
 ms.subservice: authentication
-ms.topic: article
+ms.topic: how-to
 ms.date: 11/21/2019
 
 ms.author: iainfou
@@ -65,7 +65,7 @@ As a best practice, you should update your organization's ADFS error pages with
 
 For more information, see [Customizing the AD FS Sign-in Pages](https://technet.microsoft.com/library/dn280950.aspx).
 
-Some Office apps (with modern authentication enabled) send ‘*prompt=login*’ to Azure AD in their request. By default, Azure AD translates ‘*prompt=login*’ in the request to ADFS as ‘*wauth=usernamepassworduri*’ (asks ADFS to do U/P Auth) and ‘*wfresh=0*’ (asks ADFS to ignore SSO state and do a fresh authentication). If you want to enable certificate-based authentication for these apps, you need to modify the default Azure AD behavior. Set the ‘*PromptLoginBehavior*’ in your federated domain settings to ‘*Disabled*‘.
+Some Office apps (with modern authentication enabled) send '*prompt=login*' to Azure AD in their request. By default, Azure AD translates '*prompt=login*' in the request to ADFS as '*wauth=usernamepassworduri*' (asks ADFS to do U/P Auth) and '*wfresh=0*' (asks ADFS to ignore SSO state and do a fresh authentication). If you want to enable certificate-based authentication for these apps, you need to modify the default Azure AD behavior. Set the '*PromptLoginBehavior*' in your federated domain settings to '*Disabled*'.
 You can use the [MSOLDomainFederationSettings](/powershell/module/msonline/set-msoldomainfederationsettings?view=azureadps-1.0) cmdlet to perform this task:
 
 `Set-MSOLDomainFederationSettings -domainname <domain> -PromptLoginBehavior Disabled`

articles/active-directory/authentication/active-directory-certificate-based-authentication-get-started.md

@@ -5,7 +5,7 @@ description: Learn how to configure certificate-based authentication in your env
 services: active-directory
 ms.service: active-directory
 ms.subservice: authentication
-ms.topic: article
+ms.topic: how-to
 ms.date: 11/21/2019
 
 ms.author: iainfou
@@ -37,7 +37,7 @@ To configure certificate-based authentication, the following statements must be
 - The root certificate authority and any intermediate certificate authorities must be configured in Azure Active Directory.
 - Each certificate authority must have a certificate revocation list (CRL) that can be referenced via an internet-facing URL.
 - You must have at least one certificate authority configured in Azure Active Directory. You can find related steps in the [Configure the certificate authorities](#step-2-configure-the-certificate-authorities) section.
-- For Exchange ActiveSync clients, the client certificate must have the user’s routable email address in Exchange online in either the Principal Name or the RFC822 Name value of the Subject Alternative Name field. Azure Active Directory maps the RFC822 value to the Proxy Address attribute in the directory.
+- For Exchange ActiveSync clients, the client certificate must have the user's routable email address in Exchange online in either the Principal Name or the RFC822 Name value of the Subject Alternative Name field. Azure Active Directory maps the RFC822 value to the Proxy Address attribute in the directory.
 - Your client device must have access to at least one certificate authority that issues client certificates.
 - A client certificate for client authentication must have been issued to your client.
 

articles/active-directory/authentication/active-directory-certificate-based-authentication-ios.md

@@ -5,7 +5,7 @@ description: Learn about the supported scenarios and the requirements for config
 services: active-directory
 ms.service: active-directory
 ms.subservice: authentication
-ms.topic: article
+ms.topic: conceptual
 ms.date: 01/15/2018
 
 ms.author: iainfou
@@ -67,7 +67,7 @@ As a best practice, you should update your organization's ADFS error pages with
 
 For more information, see [Customizing the AD FS Sign-in Pages](https://technet.microsoft.com/library/dn280950.aspx).
 
-Some Office apps (with modern authentication enabled) send ‘*prompt=login*’ to Azure AD in their request. By default, Azure AD translates ‘*prompt=login*’ in the request to ADFS as ‘*wauth=usernamepassworduri*’ (asks ADFS to do U/P Auth) and ‘*wfresh=0*’ (asks ADFS to ignore SSO state and do a fresh authentication). If you want to enable certificate-based authentication for these apps, you need to modify the default Azure AD behavior. Just set the ‘*PromptLoginBehavior*’ in your federated domain settings to ‘*Disabled*‘.
+Some Office apps (with modern authentication enabled) send '*prompt=login*' to Azure AD in their request. By default, Azure AD translates '*prompt=login*' in the request to ADFS as '*wauth=usernamepassworduri*' (asks ADFS to do U/P Auth) and '*wfresh=0*' (asks ADFS to ignore SSO state and do a fresh authentication). If you want to enable certificate-based authentication for these apps, you need to modify the default Azure AD behavior. Just set the '*PromptLoginBehavior*' in your federated domain settings to '*Disabled*'.
 You can use the [MSOLDomainFederationSettings](/powershell/module/msonline/set-msoldomainfederationsettings?view=azureadps-1.0) cmdlet to perform this task:
 
 `Set-MSOLDomainFederationSettings -domainname <domain> -PromptLoginBehavior Disabled`

articles/active-directory/authentication/active-directory-passwords-faq.md

@@ -5,7 +5,7 @@ description: Frequently asked questions about Azure AD self-service password res
 services: active-directory
 ms.service: active-directory
 ms.subservice: authentication
-ms.topic: conceptual
+ms.topic: how-to
 ms.date: 07/11/2018
 
 ms.author: iainfou
@@ -68,7 +68,7 @@ This FAQ is split into the following sections:
   >
 * **Q:  How does the registration portal determine which options to show my users?**
 
-  > **A:** The password reset registration portal shows only the options that you have enabled for your users. These options are found under the **User Password Reset Policy** section of your directory’s **Configure** tab. For example, if you don't enable security questions, then users are not able to register for that option.
+  > **A:** The password reset registration portal shows only the options that you have enabled for your users. These options are found under the **User Password Reset Policy** section of your directory's **Configure** tab. For example, if you don't enable security questions, then users are not able to register for that option.
   >
   >
 * **Q:  When is a user considered registered?**
@@ -104,9 +104,9 @@ This FAQ is split into the following sections:
   > **A:** The password reset UI, SMS messages, and voice calls are localized in the same languages that are supported in Office 365.
   >
   >
-* **Q:  What parts of the password reset experience get branded when I set the organizational branding items in my directory’s configure tab?**
+* **Q:  What parts of the password reset experience get branded when I set the organizational branding items in my directory's configure tab?**
 
-  > **A:** The password reset portal shows your organization's logo and allows you to configure the "Contact your administrator" link to point to a custom email or URL. Any email that's sent by password reset includes your organization’s logo, colors, and name in the body of the email, and is customized from the settings for that particular name.
+  > **A:** The password reset portal shows your organization's logo and allows you to configure the "Contact your administrator" link to point to a custom email or URL. Any email that's sent by password reset includes your organization's logo, colors, and name in the body of the email, and is customized from the settings for that particular name.
   >
   >
 * **Q:  How can I educate my users about where to go to reset their passwords?**
@@ -121,10 +121,10 @@ This FAQ is split into the following sections:
   >
 * **Q:  Do you support unlocking local Active Directory accounts when users reset their passwords?**
 
-  > **A:** Yes. When a user resets their password, if password writeback has been deployed through Azure AD Connect, that user’s account is automatically unlocked when they reset their password.
+  > **A:** Yes. When a user resets their password, if password writeback has been deployed through Azure AD Connect, that user's account is automatically unlocked when they reset their password.
   >
   >
-* **Q:  How can I integrate password reset directly into my user’s desktop sign-in experience?**
+* **Q:  How can I integrate password reset directly into my user's desktop sign-in experience?**
 
   > **A:** If you're an Azure AD Premium customer, you can install Microsoft Identity Manager at no additional cost and deploy the on-premises password reset solution.
   >
@@ -263,12 +263,12 @@ This FAQ is split into the following sections:
   > **A:** Password writeback works for user accounts that are synchronized from on-premises Active Directory to Azure AD, including federated, password hash synchronized, and Pass-Through Autentication Users.
   >
   >
-* **Q:  Does password writeback enforce my domain’s password policies?**
+* **Q:  Does password writeback enforce my domain's password policies?**
 
   > **A:** Yes. Password writeback enforces password age, history, complexity, filters, and any other restriction you might put in place on passwords in your local domain.
   >
   >
-* **Q:  Is password writeback secure?  How can I be sure I won’t get hacked?**
+* **Q:  Is password writeback secure?  How can I be sure I won't get hacked?**
 
   > **A:** Yes, password writeback is secure. To read more about the multiple layers of security implemented by the password writeback service, check out the [Password writeback security](concept-sspr-writeback.md#password-writeback-security) section in the [Password writeback overview](howto-sspr-writeback.md) article.
   >

articles/active-directory/authentication/howto-authentication-methods-usage-insights.md

@@ -5,7 +5,7 @@ description: Reporting on Azure AD self-service password reset and Multi-Factor
 services: active-directory
 ms.service: active-directory
 ms.subservice: authentication
-ms.topic: conceptual
+ms.topic: how-to
 ms.date: 11/21/2019
 
 ms.author: iainfou
@@ -87,7 +87,7 @@ Using the controls at the top of the list, you can search for a user and filter
 
 ## Limitations
 
-The data shown in these reports will be delayed by up to 60 minutes. A “Last refreshed" field exists in the Azure portal to identify how recent your data is.
+The data shown in these reports will be delayed by up to 60 minutes. A "Last refreshed" field exists in the Azure portal to identify how recent your data is.
 
 Usage and insights data is not a replacement for the Azure Multi-Factor Authentication activity reports or information contained in the Azure AD sign-ins report.
 

articles/active-directory/authentication/howto-authentication-passwordless-phone.md

@@ -5,7 +5,7 @@ description: Enable passwordless sign-in to Azure AD using the Microsoft Authent
 services: active-directory
 ms.service: active-directory
 ms.subservice: authentication
-ms.topic: conceptual
+ms.topic: how-to
 ms.date: 11/21/2019
 
 ms.author: iainfou
@@ -79,13 +79,13 @@ The admin can choose to enable the user to use passwordless phone sign-in, or th
 
 ### AD FS integration
 
-When a user has enabled the Microsoft Authenticator passwordless credential, authentication for that user will always default to sending a notification for approval. This logic prevents users in a hybrid tenant from being directed to ADFS for sign-in verification without the user taking an additional step to click “Use your password instead.” This process will also bypass any on-premises Conditional Access policies, and Pass-through authentication flows. 
+When a user has enabled the Microsoft Authenticator passwordless credential, authentication for that user will always default to sending a notification for approval. This logic prevents users in a hybrid tenant from being directed to ADFS for sign-in verification without the user taking an additional step to click "Use your password instead." This process will also bypass any on-premises Conditional Access policies, and Pass-through authentication flows. 
 
 If a user has an unanswered passwordless phone sign-in verification pending and attempts to sign in again, the user may be taken to ADFS to enter a password instead.  
 
 ### Azure MFA server
 
-End users who are enabled for MFA through an organization’s on-premises Azure MFA server can still create and use a single passwordless phone sign in credential. If the user attempts to upgrade multiple installations (5+) of the Microsoft Authenticator with the credential, this change may result in an error.  
+End users who are enabled for MFA through an organization's on-premises Azure MFA server can still create and use a single passwordless phone sign in credential. If the user attempts to upgrade multiple installations (5+) of the Microsoft Authenticator with the credential, this change may result in an error.  
 
 ### Device registration
 

articles/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises.md

@@ -5,7 +5,7 @@ description: Learn how to enable passwordless security key sign-in to on-premise
 services: active-directory
 ms.service: active-directory
 ms.subservice: authentication
-ms.topic: conceptual
+ms.topic: how-to
 ms.date: 03/09/2020
 
 ms.author: iainfou
@@ -50,7 +50,7 @@ Organizations must also meet the following software requirements.
   - For more information on the available Azure AD hybrid authentication options, see [Choose the right authentication method for your Azure Active Directory hybrid identity solution](../../security/fundamentals/choose-ad-authn.md) and [Select which installation type to use for Azure AD Connect](../hybrid/how-to-connect-install-select-installation.md).
 - Your Windows Server domain controllers must have the following patches installed:
     - For Windows Server 2016 - https://support.microsoft.com/help/4534307/windows-10-update-kb4534307
-	- For Windows Server 2019 - https://support.microsoft.com/help/4534321/windows-10-update-kb4534321
+    - For Windows Server 2019 - https://support.microsoft.com/help/4534321/windows-10-update-kb4534321
 
 ### Supported scenarios
 
@@ -110,7 +110,7 @@ This command outputs the properties of the Azure AD Kerberos Server. You can rev
 
 | Property | Description |
 | --- | --- |
-| ID | The unique ID of the AD DS DC object. This ID is sometimes referred to as it’s "slot" or it’s "branch ID". |
+| ID | The unique ID of the AD DS DC object. This ID is sometimes referred to as it's "slot" or it's "branch ID". |
 | DomainDnsName | The DNS domain name of the Active Directory Domain. |
 | ComputerAccount | The computer account object of the Azure AD Kerberos Server object (the DC). |
 | UserAccount | The disabled user account object that holds the Azure AD Kerberos Server TGT encryption key. The DN of this account is `CN=krbtgt_AzureAD,CN=Users,<Domain-DN>` |
@@ -124,7 +124,7 @@ This command outputs the properties of the Azure AD Kerberos Server. You can rev
 
 ### Rotating the Azure AD Kerberos Server key
 
-The Azure AD Kerberos Server encryption krbtgt keys should be rotated on a regular basis. It’s recommended that you follow the same schedule you use to rotate all other Active Directory Domain Controller krbtgt keys.
+The Azure AD Kerberos Server encryption krbtgt keys should be rotated on a regular basis. It's recommended that you follow the same schedule you use to rotate all other Active Directory Domain Controller krbtgt keys.
 
 > [!WARNING]
 > There are other tools that could rotate the krbtgt keys, however, you must use the tools mentioned in this document to rotate the krbtgt keys of your Azure AD Kerberos Server. This ensures the keys are updated in both on-premises AD and Azure AD.

articles/active-directory/authentication/howto-authentication-passwordless-security-key-windows.md

@@ -5,7 +5,7 @@ description: Learn how to enable passwordless security key sign-in to Azure Acti
 services: active-directory
 ms.service: active-directory
 ms.subservice: authentication
-ms.topic: conceptual
+ms.topic: how-to
 ms.date: 01/30/2020
 
 ms.author: iainfou

articles/active-directory/authentication/howto-authentication-passwordless-security-key.md

@@ -5,7 +5,7 @@ description: Enable passwordless security key sign-in to Azure AD using FIDO2 se
 services: active-directory
 ms.service: active-directory
 ms.subservice: authentication
-ms.topic: conceptual
+ms.topic: how-to
 ms.date: 02/12/2020
 
 ms.author: iainfou
@@ -62,7 +62,7 @@ Registration features for passwordless authentication methods rely on the combin
 1. Sign in if not already.
 1. Click **Security Info**.
    1. If the user already has at least one Azure Multi-Factor Authentication method registered, they can immediately register a FIDO2 security key.
-   1. If they don’t have at least one Azure Multi-Factor Authentication method registered, they must add one.
+   1. If they don't have at least one Azure Multi-Factor Authentication method registered, they must add one.
 1. Add a FIDO2 Security key by clicking **Add method** and choosing **Security key**.
 1. Choose **USB device** or **NFC device**.
 1. Have your key ready and choose **Next**.
@@ -94,7 +94,7 @@ Administrator provisioning and de-provisioning of security keys is not available
 
 ### UPN changes
 
-We are working on supporting a feature that allows UPN change on hybrid Azure AD joined and Azure AD joined devices. If a user’s UPN changes, you can no longer modify FIDO2 security keys to account for the change. The resolution is to reset the device and the user has to re-register.
+We are working on supporting a feature that allows UPN change on hybrid Azure AD joined and Azure AD joined devices. If a user's UPN changes, you can no longer modify FIDO2 security keys to account for the change. The resolution is to reset the device and the user has to re-register.
 
 ## Next steps
 

articles/active-directory/authentication/howto-mfa-adfs.md

@@ -5,7 +5,7 @@ description: This is the Azure Multi-Factor authentication page that describes h
 services: multi-factor-authentication
 ms.service: active-directory
 ms.subservice: authentication
-ms.topic: conceptual
+ms.topic: how-to
 ms.date: 07/11/2018
 
 ms.author: iainfou
@@ -91,4 +91,4 @@ Now that the claims are in place, we can configure trusted IPs.
 4. On the Service Settings page, under **trusted IPs**, select **Skip multi-factor-authentication for requests from federated users on my intranet**.  
 5. Click **save**.
 
-That’s it! At this point, federated Office 365 users should only have to use MFA when a claim originates from outside the corporate intranet.
+That's it! At this point, federated Office 365 users should only have to use MFA when a claim originates from outside the corporate intranet.