From b1d18bdd655d866e8374a47a440d74461fb5e0e2 Mon Sep 17 00:00:00 2001 From: Stephen Peters <101433558+StephenBrentPeters@users.noreply.github.com> Date: Fri, 1 Apr 2022 11:49:53 -0700 Subject: [PATCH 1/2] [BrokenLinksH2] fixing broken link **Global effort to fix broken links** @GitPrakhar13 The Content & Learning team is fixing broken links on docs.microsoft.com for the rest of H2. This effort will eliminate potential accessibility, security, and usability issues. This PR includes only link fixes and does not change other content. Please review within five business days and merge, or comment in the PR with any changes you'd like to see. Thanks! --- .../hello-for-business/hello-deployment-issues.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/windows/security/identity-protection/hello-for-business/hello-deployment-issues.md b/windows/security/identity-protection/hello-for-business/hello-deployment-issues.md index 16f8e33766..49c7800974 100644 --- a/windows/security/identity-protection/hello-for-business/hello-deployment-issues.md +++ b/windows/security/identity-protection/hello-for-business/hello-deployment-issues.md @@ -61,7 +61,7 @@ Before the user's Windows Hello for Business key is synced, sign-in's with Windo In environments impacted with this issue, after the first sign-in with Windows Hello for Business after provisioning is completed, the next sign-in attempt will fail. In environments where domain controllers are running a mix of builds, only some may be impacted by this issue and subsequent logon attempts may be sent different domain controllers. This may result in the sign-in failures appearing to be intermittent. -After the initial logon attempt, the user's Windows Hello for Business public key is being deleted from the msDS-KeyCredentialLink attribute. This can be verified by querying a user's msDS-KeyCredentialLink attribute before and after sign-in. The msDS-KeyCredentialLink can be queried in AD using [Get-ADUser](/powershell/module/addsadministration/get-aduser) and specifying *msds-keycredentiallink* for the *-Properties* parameter. +After the initial logon attempt, the user's Windows Hello for Business public key is being deleted from the msDS-KeyCredentialLink attribute. This can be verified by querying a user's msDS-KeyCredentialLink attribute before and after sign-in. The msDS-KeyCredentialLink can be queried in AD using [Get-ADUser](/powershell/module/activedirectory/get-aduser) and specifying *msds-keycredentiallink* for the *-Properties* parameter. ### Resolving User Public Key Deletion Issue From 665661301001c8bb9b330921fab24313b671c630 Mon Sep 17 00:00:00 2001 From: Angela Fleischmann Date: Fri, 1 Apr 2022 15:35:40 -0600 Subject: [PATCH 2/2] Fix typos Line 32 it will shows a (show) Line 60 "user should be able to login" (log in) --- .../hello-for-business/hello-deployment-issues.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/windows/security/identity-protection/hello-for-business/hello-deployment-issues.md b/windows/security/identity-protection/hello-for-business/hello-deployment-issues.md index 49c7800974..b8c2e0c3b8 100644 --- a/windows/security/identity-protection/hello-for-business/hello-deployment-issues.md +++ b/windows/security/identity-protection/hello-for-business/hello-deployment-issues.md @@ -29,7 +29,7 @@ Applies to: - Windows 10, version 1803 and later - Windows 11 -PIN reset on Azure AD joined devices uses a flow called web sign-in to authenticate the user above lock. Web sign in only allows navigation to specific domains. If it attempts to navigate to a domain that is not allowed it will shows a page with the error message "We can't open that page right now". +PIN reset on Azure AD joined devices uses a flow called web sign-in to authenticate the user above lock. Web sign in only allows navigation to specific domains. If it attempts to navigate to a domain that is not allowed it will show a page with the error message "We can't open that page right now". ### Identifying Azure AD joined PIN Reset Allowed Domains Issue @@ -57,7 +57,7 @@ In Hybrid key trust deployments with domain controllers running certain builds o After the user provisions a Windows Hello for Business credential in a hybrid key trust environment, the key must sync from Azure AD to AD during an Azure AD Connect sync cycle. The user's public key will be written to the msDS-KeyCredentialLink attribute of the user object. -Before the user's Windows Hello for Business key is synced, sign-in's with Windows Hello for Business will fail with the error message, *"That option is temporarily unavailable. For now, please use a different method to sign in."* After the sync is successful, the user should be able to login and unlock with their PIN or enrolled biometrics. +Before the user's Windows Hello for Business key is synced, sign-in's with Windows Hello for Business will fail with the error message, *"That option is temporarily unavailable. For now, please use a different method to sign in."* After the sync is successful, the user should be able to log in and unlock with their PIN or enrolled biometrics. In environments impacted with this issue, after the first sign-in with Windows Hello for Business after provisioning is completed, the next sign-in attempt will fail. In environments where domain controllers are running a mix of builds, only some may be impacted by this issue and subsequent logon attempts may be sent different domain controllers. This may result in the sign-in failures appearing to be intermittent.