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.

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.

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 à un fournisseur d'identifiants Okta sur un poste de travail ou un serveur Windows pris en charge.

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.

Les sessions RDP se déconnectent après l'affichage de l'écran de connexion

Symptôme :

Après l'installation ou la mise à niveau vers la version 1.4.6 de l'agent, les sessions RDP se déconnectent dès l'apparition de l'écran de connexion. L'installation s'est terminée sans erreur.

Cause :

La version du composant redistribuable Microsoft Visual C++ 2015-2022 x64 installée sur le serveur est antérieure à la version 14.44 ; par conséquent, le fournisseur d'identifiants ne parvient pas à se charger lors de la connexion.

Solution :

Installez le composant redistributable Microsoft Visual C++ 2015-2022 x64, version 14.44 ou ultérieure.

System.Net.WebException s'est affiché

Symptôme :

Une exception, similaire à celle ci-dessous, s'affiche ; il s'agit probablement d'une ancienne version du protocole Transport Layer Security (TLS). 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'identifiants à l'aide de l'éditeur du registre

Symptôme :

Les utilisateurs finaux ne peuvent plus utiliser la MFA pour le fournisseur d'identifiants Windows et le protocole Remote Desktop Protocol (RDP) 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'identifiants Windows.

  1. Connectez-vous à un autre ordinateur capable d'accéder au serveur hôte en tant qu'administrateur.

  2. Ouvrez l'éditeur de registre.

  3. Sélectionnez Connecter au Registre réseau.

  4. Saisissez le nom d'hôte du serveur distant où est installée la MFA Credential Provider pour Windows.

  5. Sélectionnez Vérifier les noms. Au bout de quelques instants, le nom d'hôte est validé.

  6. Cliquez sur OK.

  7. Accédez à HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Provider Filters.

  8. Notez le CLSID (ou nom du dossier) du fournisseur d'identifiants Okta.

  9. Dans HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Providers, localisez le CLSID de l'étape précédente.

  10. Faites un clic droit et créez un DWORD avec le nom Disabled et la valeur 1.

  11. Redémarrez le serveur. Au redémarrage, le fournisseur d'identifiants doit être inactif.

Utilisateurs verrouillés - désactiver le fournisseur d'identifiants à l'aide de PSExec

Symptôme :

Les utilisateurs finaux ne peuvent plus utiliser la MFA pour le fournisseur d'identifiants Windows et le protocole RDP 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 du Registre Windows, ne peuvent pas être utilisées.

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.

  1. Ouvrez une invite de commande en tant qu'administrateur. À l'aide de psexec et de la commande reg query de Windows, répertoriez les valeurs présentes dans HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Provider Filters. Par exemple :
    psexec \\ipaddress -u username -p password reg query "hklm\software\microsoft\windows\currentversion\authentication\Credential Provider Filters"
    Où :
    • \\ipaddress correspond à l'adresse IP du serveur sur lequel s'exécute la MFA pour le fournisseur d'identifiants Windows. Par exemple : \\192.168.1.199
    • -u username est un utilisateur valide sur le serveur distant représenté par \\ipaddress. Par exemple : -u validuser
    • - p password est le mot de passe de l'utilisateur spécifié par le paramètre -u. Par exemple : -p pwdforValiduser
    Ce qui donne un résultat similaire à :
    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}.
    
  2. Pour chaque résultat renvoyé, interrogez le registre pour déterminer qui est le fournisseur d'identifiants Okta (OktaCredentialProvider) :
    psexec \\ipaddress -u username -p password reg query "hklm\software\microsoft\windows\currentversion\authentication\Credential Provider Filters\{6D269AEA-...-02AA9C14F310}"
    Ce qui devrait donner des résultats semblables à :
    HKEY_LOCAL_MACHINE\software\microsoft\windows\currentversion\authentication\Credential Provider Filters\{6D269AEA-...-02AA9C14F310}
    (Default)    REG_SZ    OktaCredentialProvider
  3. À l'aide de psexec et de la commande reg add et l'ID de classe du fournisseur d'identifiants Okta, créez une valeur DWord portant le nom Disabled et la valeur 1.
    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
    Où :
    • /f - Forcer l'écrasement
    • /v {name of new entry} - Le nom de la nouvelle entrée ajoutée. Désactivé
    • /t {type} - Le type de la nouvelle entrée ajouté, REG_DWORD.
    • /d {value} - La valeur de la nouvelle entrée, 1.
    Ce qui devrait donner un résultat similaire à :
    The operation completed successfully.
  4. Relancez la requête précédente, qui devrait désormais renvoyer des résultats incluant l'élément nouvellement ajouté et similaires à ceci :
    HKEY_LOCAL_MACHINE\software\microsoft\windows\currentversion\authentication\Credential Provider Filters\{6D269AEA-...-02AA9C14F310}
    (Default)    REG_SZ    OktaCredentialProvider
                 REG_DWORD Disabled 1
  5. Redémarrez l'ordinateur distant à l'aide de PsExec et de la commande d'arrêt :
    psexec \\ipaddress -u username -p password shutdown -f -r -t 0
    Où : -f forçant la fermeture des programmes en cours d'exécution sans avertissement.-r - Arrêt complet et redémarrage.-t 0 - Définit le délai avant arrêt à zéro seconde.

Au redémarrage, le fournisseur d'identifiants 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'identifiants ne parvient pas à se connecter à Okta

Symptôme : le fournisseur d'identifiants ne parvient pas à se connecter à Okta. Cela peut arriver avec ou sans proxy. Une exception, similaire à celle 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 :

Le scénario le plus probable est que le protocole TLS ne soit pas correctement activé. Okta requiert la version TLS 1.2 ou ultérieure.

Pour corriger le problème :

  1. Si le proxy est utilisé et que la connexion TLS prend fin au niveau du proxy, désactivez SslPinningEnabled. Consultez Modifier des propriétés supplémentaires dans Installer Okta Credential Provider pour Windows.
  2. 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."
    }