Résoudre les problèmes liés à la MFA pour la MFA Credential Provider pour Windows
Cette rubrique décrit les scénarios et les solutions de dépannage pour le MFA Credential Provider pour Windows.
Le Sign-In Widget (troisième génération) ne prend pas en charge authentification multifacteur pour les agents tiers.
La boîte de dialogue Contournement de la MFA apparaît lors de la connexion
Symptôme :
La boîte de dialogue Contournement de la MFA apparaît lors de la connexion.
Solution :
Vérifiez dans Okta que l'utilisateur est inclus dans une politique de MFA.
Une politique de connexion aux applications est la seule stratégie pertinente pour l'application Microsoft RDP.
La boîte de dialogue Échec de l'affichage apparaît lors de la connexion
Symptôme :
La boîte de dialogue Échec de l'affichage apparaît lors de la connexion.
Vérifiez :
- L'identifiant client, la clé secrète client et l'URL Okta sont correctement configurés ;
- Le nom d'utilisateur saisi pour la connexion Windows correspond au nom d'utilisateur Okta.
Impossible d'utiliser un RDP pour se connecter à un serveur
Symptôme :
L'utilisateur final ne peut pas utiliser un client RDP pour se connecter à une station de travail ou un serveur pris en charge par Okta Credential Provider pour Windows.
Solution :
Vérifiez que les options Autoriser les connexions à distance à cet ordinateur et Autoriser les connexions uniquement pour les ordinateurs exécutant les services Bureau à distance avec authentification au niveau du réseau sont activées dans la boîte de dialogue Propriétés système.
System.Net.WebException s'est affiché
Symptôme :
Une exception, similaire à celle illustrée ci-dessous, apparaît ; la raison probable est une version de TLS trop ancienne. Okta requiert la version TLS 1.2 ou ultérieure.
System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a send.
. . .
System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.
. . .
System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host.
Solution :
Ouvrez un terminal PowerShell en tant qu'administrateur et exécutez le script suivant :
$is64bit = [IntPtr]::Size * 8 -eq 64
Write-Host "Is 64-bit script: $is64bit"
#helper function to check for if 0x800 bit is set
function checkTls12Bit([Int] $regValue) {
return ($regValue -band 0x800) -ne 0x800
}
function setRegKeyToBitValue([string] $regBranch, [string] $regKey) {
$current = Get-ItemProperty -Path $regBranch -ErrorAction SilentlyContinue
if ($current -eq $null) {
Write-Host "$regBranch\$regKey does not exist. No change."
return $false
}
$regValue = $current.$regKey
if ($regValue -eq $null -or (checkTls12Bit $regValue) ) {
if ($regValue -eq $null) {
$regValue = 0x800
} else {
$regValue = $regValue -bor 0x800
}
$p = New-ItemProperty $regBranch -Name $regKey -PropertyType DWord -Value $regValue -ErrorAction Stop -Force
Write-Host "Updated $regBranch\$regKey value to $regValue"
return $true
}
Write-Host "$regBranch\$regKey value is $regValue. No change."
return $false
}
function setRegKeyToValueOfOne([string] $regBranch, [string] $regKey) {
$current = Get-ItemProperty -Path $regBranch -ErrorAction SilentlyContinue
if ($current -eq $null) {
Write-Host "$regBranch\$regKey does not exist. No change."
return $false
}
if ($current.$regKey -ne 1) {
$p = New-ItemProperty $regBranch -Name $regKey -PropertyType DWord -Value 1 -ErrorAction Stop -Force
Write-Host "Updated $regBranch\$regKey value to 1"
return $true
}
Write-Host "$regBranch\$regKey value is 1. No change."
return $false
}
#setup .net tls settings
function setupTls4NET([boolean]$is64bit, [string]$regBranch, [string]$reg32bitBranch) {
# https://docs.microsoft.com/fr-fr/dotnet/framework/network-programming/tls
$updated = setRegKeyToValueOfOne $regBranch "SchUseStrongCrypto"
$updated = (setRegKeyToValueOfOne $regBranch "SystemDefaultTlsVersions") -or $updated
if ($is64bit) {
$updated = (setRegKeyToValueOfOne $reg32bitBranch "SchUseStrongCrypto") -or $updated
$updated = (setRegKeyToValueOfOne $reg32bitBranch "SystemDefaultTlsVersions") -or $updated
}
return $updated
}
# https://docs.microsoft.com/fr-fr/dotnet/framework/migration-guide/how-to-determine-which-versions-are-installed
$version = Get-ItemProperty -Path "HKLM:\Software\Microsoft\NET Framework Setup\NDP\v4\Full" -Name Release
# 394254 - .NET Framework 4.6.1, which is the current target of the installer
if ($version.Release -ge 394254) {
$ev = [environment]::Version
$v = "v" + $ev.Major + "." + $ev.Minor + "." + $ev.Build
$updated = setupTls4NET $is64bit "HKLM:\SOFTWARE\Microsoft\.NETFramework\$v" "HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\$v"
# https://support.microsoft.com/en-ca/help/3140245/update-to-enable-tls-1-1-and-tls-1-2-as-a-default-secure-protocols-in
$updated = (setRegKeyToBitValue "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp" "DefaultSecureProtocols") -or $updated
$updated = (setRegKeyToBitValue "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings" "SecureProtocols") -or $updated
# updated the 32-bit branches if we are on 64-bit machine
if ($is64bit) {
$updated = (setRegKeyToBitValue "HKLM:\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp" "DefaultSecureProtocols") -or $updated
$updated = (setRegKeyToBitValue "HKLM:\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings" "SecureProtocols") -or $updated
}
# current user settings
$updated = (setRegKeyToBitValue "HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings" "SecureProtocols") -or $updated
# local system account
$userSid = ".DEFAULT"
$updated = (setRegKeyToBitValue "Registry::HKEY_USERS\$userSid\Software\Microsoft\Windows\CurrentVersion\Internet Settings" "SecureProtocols") -or $updated
if ($updated) {
Write-Host "Done. Updated required settings."
}
else
{
Write-Host "Done. No updates are required."
}
}
else
{
Write-Host "No changes were made. Your version of .NET Framework is earlier version than 4.6.1, please upgrade."
}
Utilisateurs verrouillés - désactiver le fournisseur d'informations d'identification à l'aide de l'éditeur du registre
Symptôme :
Les utilisateurs finaux ne peuvent plus utiliser la MFA Credential Provider pour Windows et le protocole RDP (Remote Desktop Protocal) pour accéder à un hôte Windows. Dans les faits, les utilisateurs finaux sont verrouillés.
Solution :
Utilisez l'éditeur Windows Registry pour parcourir le registre de serveurs distants et désactiver la MFA pour le fournisseur d'informations d'identification Windows.
Cette solution désactive la MFA pour le fournisseur d'informations d'identification Windows pour tous les utilisateurs et requiert qu'un administrateur dispose d'un accès à distance au registre du serveur verrouillé. Toute modification apportée au registre Windows doit être réalisée avec la plus grande prudence.
-
Connectez-vous à un autre ordinateur capable de se connecter au serveur hôte en tant qu'administrateur.
-
Ouvrez l'éditeur de registre.
-
Sélectionnez Connecter au Registre réseau.
-
Saisissez le nom d'hôte du serveur distant où est installée la MFA Credential Provider pour Windows.
-
Cliquez sur Vérifier les noms. Après un instant, le nom d'hôte est validé.
-
Cliquez sur OK. Le registre distant s'ouvre.
-
Accédez à :
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Provider Filters. -
Notez le CLSID (ou nom du dossier) du fournisseur d'informations d'identité Okta.
-
Dans
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Providers, localisez le CLSID de l'étape précédente. -
Faites un clic droit et créez un nouveau DWORD avec le nom
Disabledet une valeur de1. -
Redémarrez le serveur. Au redémarrage, le fournisseur d'informations d'identité doit être inactif.
Utilisateurs verrouillés - désactiver le fournisseur d'informations d'identification à l'aide de PSExec
Symptôme :
Les utilisateurs finaux ne peuvent plus utiliser la MFA Credential Provider pour Windows et le protocole RDP (Remote Desktop Protocal) pour accéder à un hôte Windows. Dans les faits, les utilisateurs finaux sont verrouillés.
D'autres solutions, telles que l'utilisation à distance de l'éditeur de registre Windows, sont également indisponibles.
Solution :
Utilisez PsExec pour interroger et modifier le registre du serveur qui exécute MFA Credential Provider pour Windows afin de désactiver le fournisseur.
Cette solution requiert l'utilisation de l'application System Internals PsExec. Disponible en téléchargement depuis https://docs.microsoft.com/fr-fr/sysinternals/downloads/psexec.
Enter-PSSession peut être utilisée comme une alternative à PsExec. Consultez Enter-PSSession.
- Ouvrez une invite de commande en tant qu'administrateur. À l'aide de PsExec et de la commande reg query de Windows, listez les valeurs rencontrées dans
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Provider Filters. Par exemple :
Où :psexec \\ipaddress -u username -p password reg query "hklm\software\microsoft\windows\currentversion\authentication\Credential Provider Filters"\\ipaddress- correspond à l'adresse IP du serveur exécutant la MFA pour le fournisseur d'informations d'identification Windows. Par exemple : \\192.168.1.199-u username- correspond à un utilisateur valide sur le serveur distant représenté par \\ipaddress. Par exemple : -u validuser- p password- correspond au mot de passe pour l'utilisateur spécifié par le paramètre-u. Par exemple : -p pwdforValiduserWhich doit renvoyer un résultat similaire à ce qui suit :HKEY_LOCAL_MACHINE\software\microsoft\windows\currentversion\authentication\Credential Provider Filters\{6D269AEA-...-02AA9C14F310} HKEY_LOCAL_MACHINE\software\microsoft\windows\currentversion\authentication\Credential Provider Filters\{DDC0EED2-...-EDE16A79A0DE}. - Pour chaque résultat renvoyé, interrogez le registre pour déterminer qui est le fournisseur d'informations d'identification Okta (OktaCredentialProvider) :
Vous devriez obtenir un résultat tel que : HKEY_LOCAL_MACHINE\software\microsoft\windows\currentversion\authentication\Credenpsexec \\ipaddress -u username -p password reg query "hklm\software\microsoft\windows\currentversion\authentication\Credential Provider Filters\{6D269AEA-...-02AA9C14F310}"HKEY_LOCAL_MACHINE\software\microsoft\windows\currentversion\authentication\Credential Provider Filters\{6D269AEA-...-02AA9C14F310} (Default) REG_SZ OktaCredentialProvider - À l'aide de PsExec, de la commande reg add et de l'identifiant de classe pour Okta Credential Provider, créez une nouvelle valeur DWord : donnez-lui le nom
Disabledet la valeur1.
Où :psexec \\ipaddress -u username -p password reg add "hklm\software\microsoft\windows\currentversion\authentication\Credential Provider Filters\{value from prior step}" /f /v Disabled /t REG_DWORD /d 1/f- force overwrite/v {name of new entry}étant le nom de la nouvelle entrée ajoutée, Disabled./t {type}- Type de nouvelle entrée ajouté, REG_DWORD./d {value}- Valeur de la nouvelle entrée, 1. qui devrait renvoyer un résultat similaire à ce qui suit :The operation completed successfully. - Exécutez à nouveau la requête précédente, qui devrait à présent renvoyer des résultats avec le nouvel élément ajouté, similaires au suivant :
HKEY_LOCAL_MACHINE\software\microsoft\windows\currentversion\authentication\Credential Provider Filters\{6D269AEA-...-02AA9C14F310} (Default) REG_SZ OktaCredentialProvider REG_DWORD Disabled 1 - Redémarrez l'ordinateur distant à l'aide de PsExec et de la commande d'arrêt :
Où :psexec \\ipaddress -u username -p password shutdown -f -r -t 0-fforçant la fermeture des programmes en cours d'exécution sans avertissement.-r- Arrêt complet et redémarrage.-t0 - Définit le délai avant arrêt à zéro seconde.
Au redémarrage, le fournisseur d'informations d'identité doit être inactif.
Une fois la cause racine déterminée, la valeur Disabled (Désactivée) peut être supprimée à l'aide d'une commande telle que :
psexec \\ipaddress -u username -p password reg delete "hklm\software\microsoft\windows\currentversion\authentication\Credential Provider Filters\{class id from prior step}" /f /v Disabled
Le fournisseur d'informations d'identification ne peut pas se connecter à Okta
Symptôme : le fournisseur d'informations d'identification ne peut pas se connecter à Okta. Cela peut arriver avec ou sans proxy. Une exception, similaire à celle illustrée ci-dessous, est levée.System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a send.
Exception complète
exception thrown is - System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a send. --->
System.IO.IOException: Authentication failed because the remote party has closed the transport stream.
at System.Net.Security.SslState.StartReadFrame (Byte[] buffer, Int32 readBytes, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.ForceAuthentication (Boolean receiveFirst, Byte[] buffer, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult)
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Net.TlsStream.ProcessAuthentication(LazyAsyncResult result)
at System.Net.TlsStream.Write(Byte[] buffer, Int32 offset, Int32 size)
at System.Net.PooledStream.Write(Byte[] buffer, Int32 offset, Int32 size)
at System.Net.ConnectStream.WritHeaders (Boolean async)
--- End of inner exception stack trace ---
at System.Net.HttpWebRequest.GetResponse()
at OktaWidget.JwtService.GetStateTokenUsingJwt(String username)
at OktaWidget.OktaWidgetForm..ctor(String username, Int64 parent, Int64 widgetFlow)
at OktaWidget.OktaWidgetClass.displayWidget(Int64 parent, String username, Int64 flow)
Solution :
La raison probable est que TLS n'est pas correctement activé. Okta requiert la version TLS 1.2 ou ultérieure.
Pour corriger le problème :
- Si un proxy est en cours d'utilisation et que TLS est terminé au niveau du proxy, désactivez SslPinningEnabled. Consultez Modifier des propriétés supplémentaires dansInstaller Okta Credential Provider pour Windows.
- Activez TLS 1.2 dans le registre. Ouvrez un terminal PowerShell en tant qu'administrateur et exécutez le script suivant :
$is64bit = [IntPtr]::Size * 8 -eq 64 Write-Host "Is 64-bit script: $is64bit" #helper function to check for if 0x800 bit is set function checkTls12Bit([Int] $regValue) { return ($regValue -band 0x800) -ne 0x800 } function setRegKeyToBitValue([string] $regBranch, [string] $regKey) { $current = Get-ItemProperty -Path $regBranch -ErrorAction SilentlyContinue if ($current -eq $null) { Write-Host "$regBranch\$regKey does not exist. No change." return $false } $regValue = $current.$regKey if ($regValue -eq $null -or (checkTls12Bit $regValue) ) { if ($regValue -eq $null) { $regValue = 0x800 } else { $regValue = $regValue -bor 0x800 } $p = New-ItemProperty $regBranch -Name $regKey -PropertyType DWord -Value $regValue -ErrorAction Stop -Force Write-Host "Updated $regBranch\$regKey value to $regValue" return $true } Write-Host "$regBranch\$regKey value is $regValue. No change." return $false } function setRegKeyToValueOfOne([string] $regBranch, [string] $regKey) { $current = Get-ItemProperty -Path $regBranch -ErrorAction SilentlyContinue if ($current -eq $null) { Write-Host "$regBranch\$regKey does not exist. No change." return $false } if ($current.$regKey -ne 1) { $p = New-ItemProperty $regBranch -Name $regKey -PropertyType DWord -Value 1 -ErrorAction Stop -Force Write-Host "Updated $regBranch\$regKey value to 1" return $true } Write-Host "$regBranch\$regKey value is 1. No change." return $false } #setup .net tls settings function setupTls4NET([boolean]$is64bit, [string]$regBranch, [string]$reg32bitBranch) { # https://docs.microsoft.com/fr-fr/dotnet/framework/network-programming/tls $updated = setRegKeyToValueOfOne $regBranch "SchUseStrongCrypto" $updated = (setRegKeyToValueOfOne $regBranch "SystemDefaultTlsVersions") -or $updated if ($is64bit) { $updated = (setRegKeyToValueOfOne $reg32bitBranch "SchUseStrongCrypto") -or $updated $updated = (setRegKeyToValueOfOne $reg32bitBranch "SystemDefaultTlsVersions") -or $updated } return $updated } # https://docs.microsoft.com/fr-fr/dotnet/framework/migration-guide/how-to-determine-which-versions-are-installed $version = Get-ItemProperty -Path "HKLM:\Software\Microsoft\NET Framework Setup\NDP\v4\Full" -Name Release # 394254 - .NET Framework 4.6.1, which is the current target of the installer if ($version.Release -ge 394254) { $ev = [environment]::Version $v = "v" + $ev.Major + "." + $ev.Minor + "." + $ev.Build $updated = setupTls4NET $is64bit "HKLM:\SOFTWARE\Microsoft\.NETFramework\$v" "HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\$v" # https://support.microsoft.com/en-ca/help/3140245/update-to-enable-tls-1-1-and-tls-1-2-as-a-default-secure-protocols-in $updated = (setRegKeyToBitValue "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp" "DefaultSecureProtocols") -or $updated $updated = (setRegKeyToBitValue "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings" "SecureProtocols") -or $updated # updated the 32-bit branches if we are on 64-bit machine if ($is64bit) { $updated = (setRegKeyToBitValue "HKLM:\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp" "DefaultSecureProtocols") -or $updated $updated = (setRegKeyToBitValue "HKLM:\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings" "SecureProtocols") -or $updated } # current user settings $updated = (setRegKeyToBitValue "HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings" "SecureProtocols") -or $updated # local system account $userSid = ".DEFAULT" $updated = (setRegKeyToBitValue "Registry::HKEY_USERS\$userSid\Software\Microsoft\Windows\CurrentVersion\Internet Settings" "SecureProtocols") -or $updated if ($updated) { Write-Host "Done. Updated required settings." } else { Write-Host "Done. No updates are required." } } else { Write-Host "No changes were made. Your version of .NET Framework is earlier version than 4.6.1, please upgrade." }