Exporter (0) Imprimer
Développer tout

Le client DirectAccess ne peut pas établir de tunnels au serveur DirectAccess

Publication: novembre 2009

Mis à jour: novembre 2009

S'applique à: Windows Server 2008 R2

Un client DirectAccess qui a déterminé qu'il ne se trouve pas sur l'intranet aura des règles basées sur DirectAccess en vigueur dans sa table de stratégie de résolution des noms (NRPT). Ces règles indiquent au client DirectAccess d'envoyer des requêtes DNS qui mettent en correspondance l'espace de noms intranet à un serveur DNS intranet. Lorsque le client DirectAccess essaie de rechercher un contrôleur de domaine, il doit résoudre des noms pour lesquels le suffixe DNS correspond à l'espace de noms intranet et à une règle correspondante dans la table NRPT en vigueur. Mais avant qu'une requête DNS puisse être envoyée au serveur DNS intranet, le tunnel d'infrastructure doit être établi.

Une fois que le tunnel d'infrastructure été établi avec succès, le client DirectAccess envoie la requête DNS afin de trouver un contrôleur de domaine. Le client DirectAccess se connecte ensuite au contrôleur de domaine, effectue une ouverture de session de domaine basée sur l'ordinateur et se connecte à d'autres serveurs d'infrastructure pour exécuter des fonctions de démarrage à partir de l'ordinateur, telles que l'exécution d'une évaluation d'intégrité et l'obtention d'un certificat d'intégrité avec la protection d'accès réseau (NAP).

Lorsque l'utilisateur ouvre une session sur l'ordinateur et qu'un processus dans le contexte du compte d'utilisateur essaie d'accéder à une ressource intranet par son adresse IPv6, le client DirectAccess établit le tunnel intranet.

Pour les deux tunnels, la réussite des associations de sécurité en mode tunnel IPsec dépend des règles de sécurité de connexion configurées sur les clients DirectAccess et le serveur DirectAccess. Ces règles consistent en divers paramètres pour les éléments suivants :

  • Les adresses ou préfixes d'adresses IPv6 source ou de destination pour lesquels le mode tunnel IPsec est requis.

  • Points de terminaison de tunnel (adresses IPv6 du serveur DirectAccess).

  • Les méthodes d'authentification requises pour authentifier avec succès les deux homologues IPsec (serveur et client DirectAccess).

    • Pour le tunnel d'infrastructure, les méthodes d'authentification sont le certificat d'ordinateur et UserNTLM (à l'aide des informations d'identification de compte de l'ordinateur).

    • Pour le tunnel intranet, les méthodes d'authentification sont le certificat d'ordinateur et UserKerb (à l'aide des informations d'identification de compte de l'utilisateur).

  • Méthodes d'intégrité des données et de chiffrement.

L'Assistant Installation DirectAccess configure un jeu compatible de règles de sécurité de connexion pour le serveur DirectAccess et les clients DirectAccess qui doivent aboutir à une négociation réussie des associations de sécurité IPsec pour les deux tunnels, à condition que le serveur et le client DirectAccess comportent des certificats installés dans leur magasin d'ordinateurs pouvant être utilisés pour IPsec et validés par les deux homologues IPsec.

Si le client DirectAccess ne parvient pas à négocier les deux tunnels avec succès, il ne peut pas se connecter aux ressources sur l'intranet.

Pour vérifier si le client DirectAccess peut créer le tunnel d'infrastructure avec succès

  1. Sur le client DirectAccess, démarrez une invite de commandes en tant qu'administrateur.

  2. Sur le client DirectAccess, cliquez sur Démarrer, tapez wf.msc, puis appuyez sur ENTRÉE.

  3. Dans le volet d'arborescence de la console du composant logiciel enfichable Pare-feu Windows avec fonctions avancées de sécurité, cliquez sur Règles de sécurité de connexion.

    Dans le volet d'informations, des règles de sécurité de connexion dont les noms commencent par Stratégie DirectAccess doivent s'afficher. Si ce n'est pas le cas, c'est que ce client DirectAccess n'a pas reçu ses règles de sécurité de connexion de la stratégie de groupe de configuration d'ordinateur. Vérifiez que le client DirectAccess exécute Windows 7 Édition Intégrale, Windows 7 Entreprise ou Windows Server 2008 R2 et qu'il est membre de l'un des groupes de sécurité spécifiés à l'étape 1 de l'Assistant Installation DirectAccess.

  4. Dans le volet d'arborescence de la console du composant logiciel enfichable Pare-feu Windows avec fonctions avancées de sécurité, ouvrez Analyse\Règles de sécurité de connexion.

    Dans le volet d'informations, vous devez voir une liste des règles de sécurité de connexion qui commencent par Stratégie DirectAccess, notamment des règles nommées Stratégie DirectAccess-ClientToDnsDc et Stratégie DirectAccess-ClientCorp.

  5. Si ces règles ne s'affichent pas, depuis la fenêtre d'invite de commandes, exécutez la commande netsh advfirewall monitor show currentprofile.

    Cette commande affiche les réseaux attachés et leurs profils de pare-feu déterminés. Aucun de vos réseaux ne doit figurer dans le profil de domaine. Si le profil de domaine a été attribué à l'un de vos réseaux, déterminez si vous disposez d'une connexion VPN d'accès à distance active ou d'un contrôleur de domaine disponible sur Internet.

  6. À partir de la fenêtre d'invite de commandes, exécutez la commande netsh advfirewall monitor show mmsa.

    Il doit exister une association de sécurité en mode principal avec l'Adresse IP distante définie sur l'adresse IPv6 2002:WWXX:YYZZ::WWXX:YYZZ, dans laquelle WWXX:YYZZ correspond à la représentation hexadécimale utilisant les deux-points comme séparateur de w.x.y.z, la première adresse publique IPv4 attribuée à l'interface Internet du serveur DirectAccess. Par exemple, si la première adresse IPv4 publique est 131.107.0.2, l'adresse IPv6 6to4 correspondante est 2002:836b:2::836b:2 (836b:2 correspond à la représentation hexadécimale utilisant les deux-points comme séparateur pour 131.107.0.2). L'association de sécurité en mode principal doit également indiquer ComputerCert pour Auth1 et UserNTLM pour Auth2.

  7. À partir de la fenêtre d'invite de commandes, exécutez la commande netsh advfirewall monitor show qmsa.

    Il doit exister une association de sécurité en mode rapide avec l'Adresse IP distante définie sur l'adresse IPv6 2002:WWXX:YYZZ::WWXX:YYZZ, ce qui correspond à la première adresse IPv4 publique attribuée à l'interface Internet du serveur DirectAccess.

Si l'ordinateur client DirectAccess ne peut pas établir les associations de sécurité en mode principal et en mode rapide pour le tunnel d'infrastructure à l'aide des règles de sécurité de connexion par défaut créées par l'Assistant Installation DirectAccess, le problème le plus probable est un échec d'authentification de certificats. Pour plus d'informations, consultez les sections traitant du processus de sélection de certificat IKE et du processus d'acceptation de certificat IKE de Certificat de clé publique.

Vous pouvez afficher les certificats dans le magasin d'ordinateurs local sur le serveur et le client DirectAccess avec le composant logiciel enfichable Certificats.

Pour vérifier que le serveur DirectAccess peut accéder à un contrôleur de domaine afin de valider les informations d'identification du client DirectAccess, exécutez la commande nltest /dsgetdc: /force à une invite de commandes avec élévation de privilèges. Si aucun contrôleur de domaine n'est répertorié, dépannez le manque de découverte et de connectivité entre le serveur DirectAccess et Active Directory.

De la même façon, utilisez la commande nltest /dsgetdc: /force sur le client DirectAccess pour vérifier qu'il a accès à un contrôleur de domaine. Si aucun contrôleur de domaine n'est répertorié, vérifiez que les contrôleurs de domaine compatibles IPv6 utilisés par les clients DirectAccess utilisent les enregistrements de localisateur sans site dans le DNS.

Pour exécuter l'analyse de négociation IPsec détaillée, utilisez des événements d'audit IPsec dans le journal des événements Journaux Windows\Sécurité et le suivi réseau pour DirectAccess. Pour plus d'informations, consultez Observateur d'événements et Diagnostic et suivi réseau.

Pour vérifier si le client DirectAccess peut créer le tunnel intranet avec succès

  1. Sur le client DirectAccess, démarrez une invite de commandes en tant qu'administrateur.

  2. À partir de la fenêtre d'invite de commandes, exécutez la commande net view \\IntranetFileServer. Utilisez éventuellement votre navigateur Web Internet pour accéder à une adresse Web intranet (URL) ou à une autre application pour accéder à une ressource intranet.

  3. À partir de la fenêtre d'invite de commandes, exécutez la commande netsh advfirewall monitor show mmsa.

    Il doit exister une association de sécurité en mode principal avec l'Adresse IP distante définie sur l'adresse IPv6 6to4 qui correspond à la deuxième adresse IPv4 publique attribuée à l'interface Internet du serveur DirectAccess. Par exemple, si la première adresse IPv4 publique est 131.107.0.3, l'adresse IPv6 6to4 correspondante est 2002:836b:3::836b:3 (836b:3 est la notation hexadécimale utilisant le signe deux-points comme séparateur pour 131.107.0.3). L'association de sécurité en mode principal doit également indiquer ComputerCert pour Auth1 et UserKerb pour Auth2.

  4. À partir de la fenêtre d'invite de commandes, exécutez la commande netsh advfirewall monitor show qmsa.

    Il doit exister une association de sécurité en mode rapide avec l'Adresse IP distante définie sur l'adresse IPv6 6to4 qui correspond à la deuxième adresse IPv4 publique attribuée à l'interface Internet du serveur DirectAccess.

Si l'ordinateur client DirectAccess ne peut pas établir les associations de sécurité en mode principal et en mode rapide pour le tunnel intranet à l'aide des règles de sécurité de connexion par défaut créées par l'Assistant Installation DirectAccess, le problème le plus probable est un échec de l'authentification de certificats. Pour plus d'informations, consultez les sections traitant du processus de sélection de certificat IKE et du processus d'acceptation de certificat IKE de Certificat de clé publique.

Pour vérifier que le serveur DirectAccess peut accéder à un contrôleur de domaine afin de valider les informations d'identification du client DirectAccess, exécutez la commande nltest /dsgetdc: /force à une invite de commandes avec élévation de privilèges. Si aucun contrôleur de domaine n'est répertorié, dépannez le manque de découverte et de connectivité entre le serveur DirectAccess et Active Directory.

De la même façon, utilisez la commande nltest /dsgetdc: /force sur le client DirectAccess pour vérifier qu'il a accès à un contrôleur de domaine. Si aucun contrôleur de domaine n'est répertorié, vérifiez que les contrôleurs de domaine compatibles IPv6 utilisés par les clients DirectAccess utilisent les enregistrements de localisateur sans site dans le DNS.

Pour exécuter l'analyse de négociation IPsec détaillée, utilisez des événements d'audit IPsec dans le journal des événements Journaux Windows\Sécurité et le suivi réseau pour DirectAccess. Pour plus d'informations, consultez Observateur d'événements et Diagnostic et suivi réseau.

IPsec et vérification de la révocation des certificats

Par défaut, le client DirectAccess ne procède pas à la vérification de la révocation des certificats sur les certificats qu'il reçoit d'homologues IPsec pour l'authentification. Toutefois, le serveur DirectAccess procède par défaut à la vérification de la révocation des certificats qu'il reçoit d'homologues IPsec avec un contrôle de liste de révocation de certificats faible ou renforcé.

Avec un contrôle faible de la révocation des certificats, IPsec vérifiera son cache de liste de révocation de certificats local pour les certificats révoqués. Si le certificat qui est examiné figure dans le cache comme révoqué, l'authentification échouera. S'il n'apparaît pas comme révoqué dans le cache de liste de révocation de certificats local, l'authentification réussira. Vous pouvez consulter la liste de fichiers CRL dans votre cache de liste de révocation de certificats local avec la commande certutil -URLcache CRL. Le contrôle faible de liste de révocation de certificats correspond à la configuration par défaut du serveur DirectAccess.

Avec le contrôle renforcé de liste de révocation de certificats, IPsec vérifie si le certificat a été révoqué dans son cache de liste de révocation de certificats local et les points de distribution de liste de révocation de certificats publiés. Si le certificat qui est examiné figure dans le cache comme révoqué, est répertorié dans la liste de révocation de certificats du point de distribution de liste de révocation de certificats comme révoqué, ou que le point de distribution de liste de révocation de certificats n'est pas accessible, l'authentification échoue. Si le contrôle renforcé de liste de révocation de certificats est activé, obtenez les propriétés du certificat d'ordinateur pour le client DirectAccess, examinez le champ Point de distribution de la liste de révocation de certificats et vérifiez que le serveur DirectAccess peut accéder à la liste de révocation de certificats à partir de l'un des emplacements de point de distribution de liste de révocation de certificats spécifiés. Si le serveur DirectAccess ne peut pas récupérer la liste de révocation de certificats depuis l'un de ces emplacements, toutes les authentifications de certificats IPsec échouent.

Si un contrôle de liste de révocation de certificats renforcé ou faible est configuré sur le client ou le serveur DirectAccess, vous pouvez obtenir des informations supplémentaires via le journal des événements Journaux Windows\Sécurité. Pour consulter les échecs pour IPsec dans le journal des événements Journaux Windows\Sécurité dans l'Observateur d'événements, vous devez activer l'audit sur le serveur ou le client DirectAccess avec la commande auditpol.exe /set /SubCategory:"IPsec Main Mode","IPsec Extended Mode" /success:enable /failure:enable.

Recherchez les événements suivants dans le journal des événements Journaux Windows\Sécurité :

  • ID d'événement 4653 : Mode principal : Échec : Échec d'une négociation en mode principal IPsec

  • ID d'événement 4654 : Mode rapide : Échec : Échec d'une négociation en mode rapide IPsec

  • ID d'événement 4984 : Mode étendu : Échec : Échec d'une négociation en mode étendu IPsec. L'association de sécurité en mode principal correspondante a été supprimée.

    Les échecs en mode étendu sont en principe générés en cas de problèmes avec l'authentification utilisateur pour le mode tunnel et pour les échecs d'autorisation IPsec, comme lorsque vous utilisez des cartes à puce pour une autorisation supplémentaire. L'événement 4984 indique que les informations d'identification fournies ne sont pas autorisées pour établir le tunnel au serveur DirectAccess.

Contrainte de mise en conformité d'intégrité NAP pour le tunnel intranet

Si le mode de mise en conformité complet de la protection d'accès réseau (NAP) est configuré dans les règles de sécurité de connexion pour le tunnel intranet et que le client DirectAccess ne reçoit pas de certificat d'intégrité, le client DirectAccess ne sera pas en mesure d'accéder aux ressources intranet.

Le journal des événements Journaux Windows\Sécurité contiendra un échec d'audit IPsec. L'événement spécifique qui indique un échec de l'intégrité de la protection d'accès réseau (NAP) est le suivant :

  • MessageId=13905

  • SymbolicName=ERROR_IPSEC_IKE_AUTHORIZATION_FAILURE. L'établissement d'associations de sécurité n'est pas autorisé.

Pour effectuer un dépannage supplémentaire d'évaluation de l'intégrité de la protection d'accès réseau (NAP), consultez les sections traitant de la Introduction to Troubleshooting NAP et de la Fixing Health Certificate Problems dans le guide de dépannage NAP.

Autorisation par carte à puce

Si vous utilisez des cartes à puce pour un niveau supplémentaire d'autorisation et que l'authentification IPsec échoue, le journal des événements Journaux Windows\Sécurité contiendra des échecs d'audit IPsec. Pour l'autorisation par carte à puce, les règles d'autorisation sur le serveur DirectAccess requièrent qu'un client DirectAccess spécifie un identificateur de sécurité (SID) qui indique que l'utilisateur est en possession d'un certificat qualifié pour la propriété « Ce certificat d'organisation ».

L'événement spécifique qui indique un échec de présentation d'un certificat à base de cartes à puce pendant la négociation du tunnel intranet est le suivant :

  • MessageId=13906

  • SymbolicName=ERROR_IPSEC_IKE_STRONG_CRED_AUTHORIZATION_FAILURE. L'établissement d'associations de sécurité n'est pas autorisé en raison d'un manque d'informations d'identification PKINIT suffisamment puissantes.

Échecs d'authentification NTLM

Si des erreurs d'authentification NTLM se sont produites pendant l'authentification (notamment des erreurs NTLM sur le client DirectAccess avec NO_AUTHENTICATING_AUTHORITY), il peut se produire un goulot d'étranglement au niveau du serveur DirectAccess. Pour augmenter le nombre d'appels d'authentification simultanés en cours à un instant donné entre le serveur DirectAccess et le contrôleur de domaine, définissez la valeur du Registre HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\MaxConcurrentApi sur 5 sur le serveur DirectAccess, puis redémarrez le service NETLOGON.

Analyse détaillée de la négociation IPsec

En plus des événements du journal des événements de Journaux Windows\Sécurité, vous pouvez utiliser la fonction de suivi du Pare-feu Windows pour capturer les informations d'interaction de composants et de négociation IPsec détaillées. Pour plus d'informations, consultez Diagnostic et suivi réseau.

Cela vous a-t-il été utile ?
(1500 caractères restants)
Merci pour vos suggestions.

Ajouts de la communauté

AJOUTER
Microsoft réalise une enquête en ligne pour recueillir votre opinion sur le site Web de MSDN. Si vous choisissez d’y participer, cette enquête en ligne vous sera présentée lorsque vous quitterez le site Web de MSDN.

Si vous souhaitez y participer,
Afficher:
© 2014 Microsoft