Modifier

Partager via


Questions fréquentes sur EAPHost Supplicant

Cette rubrique fournit des réponses aux questions fréquemment posées sur l’API EAPHost Supplicant.

Pourquoi dois-je appeler « EapHostPeerInitialize » et « EapHostPeerUninitialize » ?

EapHostPeerInitialize et EapHostPeerUninitialize initialisent et non initialisent l’environnement COM utilisé pour la communication interprocess (IPC) entre un demandeur et EAPHost.

Quelles fonctions doivent être appelées sur les threads qui ont initialisé COM pour STA (Single Threaded Apartment) ?

EapHostPeerInvokeConfigUI, EapHostPeerInvokeInteractiveUI et EapHostAuthenticatorInvokeConfigUI doivent être appelés sur les threads qui ont été initialisés par COM pour STA. Pour ce faire, appelez l’API COM CoInitialize ; lorsque le demandeur a terminé avec le thread STA , CoUninitialize doit être appelé avant de quitter.

Comment EAPHost exporte-t-il le matériel de keying ?

Les méthodes EAP EAP exportent des clés de session maîtres (MSK) sous la forme de clés MPPE (Microsoft Point à Point Encryption) vers les demandeurs. Des éléments de keying supplémentaires, tels que des clés principales pairwise (PMK) peuvent être générés par le demandeur à l’aide de la MSK. Pour que les méthodes génèrent d’autres clés pendant l’authentification, les méthodes peuvent fournir ces clés en tant qu’attributs propres au fournisseur aux demandeurs.

Qu’est-ce qu’une clé de session maître étendue (EMSK) ?

EMSK est un matériau de clé supplémentaire exporté par la méthode EAP. EMSK a une longueur d’au moins 64 octets. EMSK est partagé entre le client EAP et le serveur, mais n’est pas partagé avec l’authentificateur ou tout autre tiers. Actuellement, EMSK est réservé pour une utilisation ultérieure. Pour plus d’informations, consultez Configuration requise des méthodes eap du protocole d’authentification extensible pour les réseaux locaux sans fil.

Quand une méthode consomme-t-elle ou génère-t-elle un attribut ?

Si une méthode EAP génère des attributs ou EMSK, le demandeur consommera des attributs. En règle générale, les attributs consommés par les demandeurs sont des clés. Les attributs consommés sont eatPeerId, eatServerId, eatMethodId, eatEMSK et eatCredentialsChanged. Pour plus d’informations, consultez EAP_ATTRIBUTE_TYPE. Une méthode EAP peut exporter des matériaux EMSK supplémentaires spécifiques à l’application, par exemple :

  • ID de la session
  • [Protection de l’accès réseau] (/windows/desktop/NAP/network-access-protection-start-page) (NAP)

Quels attributs 802.1X consomme-t-il ?

Le demandeur sans fil natif 802.1X consomme les attributs d’authentification EAPHost suivants :

  • Notification de changement de mot de passe
  • Clés d’envoi/réception MPPE (Microsoft Point à Point Encryption). VendorId/VendorType = 331/16 et 311/1

Les clés MPPE sont des clés générées à la fin de l’authentification réussie, à la fois par l’homologue et l’authentificateur. Ces clés sont utilisées par 802.1X et le serveur d’accès réseau (NAS) pour chiffrer et déchiffrer les paquets envoyés et reçus.

Quel est l’objectif de l’indicateur EAP_PEER_FLAG_GUEST_ACCESS dans EAPHost ?

Lorsque cet indicateur est défini dans EAPHostPeerBeginSession, EAPHost l’interprète comme une demande d’autorisation d’invité et retourne une réponse d’identité NULL qui est ensuite passée au demandeur et retournée au serveur EAP.

Comment le demandeur demande-t-il l’authentification de la machine ?

L’authentification de l’ordinateur est demandée en définissant l’indicateur EAP_FLAG_MACHINE_AUTH .

Comment le demandeur demande-t-il l’authentification utilisateur ?

L’authentification utilisateur est demandée en ne définissant pas l’indicateur EAP_FLAG_MACHINE_AUTH .

Quand utiliser « EapHostPeerFreeErrorMemory » au lieu de la fonction « EapHostFreeEapError » ?

La fonction EapHostPeerFreeErrorMemory est utilisée uniquement pour libérer EAP_ERROR structures retournées par les API de configuration EAPHost. Les API de configuration EAPHost sont définies dans EapHostPeerConfigApis.h. En revanche, la fonction EapHostPeerFreeEapError est utilisée pour libérer EAP_ERROR structures retournées par les API d’exécution EAPHost. Les API d’exécution EAPHost sont définies dans EapPApis.h. N’utilisez jamais la version d’exécution de l’API avec la version de configuration des API ; cela pourrait produire des résultats inattendus.

J’ai implémenté mon interface utilisateur dans le même thread que celui que j’utilise pour traiter une session d’authentification EAP sur le demandeur. Une fois que j’ai déclenché une boîte de dialogue d’interface utilisateur interactive pour obtenir des informations d’identification ou d’autres données d’entrée utilisateur, l’appel suivant par EAPHost à une méthode d’homologue EAP échoue avec « ERROR_OBJECT_DISCONNECTED ». Pourquoi cela s’est-il produit et comment y remédier ?

Bien que les API côté client EAPHost soient toutes des API de style C, ces API C ne sont que des wrappers des API COM correspondantes. Les API de style C s’exécutent dans un environnement COM multithread. Le code de l’interface utilisateur s’exécute généralement dans le modèle de thread d’appartement. Étant donné que les deux modèles de thread sont en conflit l’un avec l’autre, n’exécutez pas le code d’interface utilisateur dans le même thread qui traite les authentifications EAP.

Pourquoi l’API « EapHostPeerBeginSession » prend-elle un pointeur de fonction de rappel « NotificationHandler » en tant que paramètre ?

NotificationHandler est le mécanisme par lequel un demandeur est averti qu’il doit s’authentifier à nouveau. Il existe différents scénarios dans lesquels le demandeur doit s’authentifier à nouveau, notamment l’authentification avec la protection d’accès réseau (NAP).

Quel est l’objectif du paramètre « pConnectionId » dans l’API « EapHostPeerBeginSession » ?

pConnectionId est un pointeur vers une valeur GUID définie par le demandeur utilisé pour identifier une connexion réseau qui appartient au demandeur. Lorsque la fonction de rappel NotificationHandler est appelée, ce GUID est passé pour identifier la connexion réseau que le demandeur utilisera pour les demandes de réauthentification.

Comment faire savoir s’il y a un changement d’état de quarantaine ?

L’utilisateur recevra une notification visuelle d’un changement d’état de mise en quarantaine uniquement s’il existe au moins une interface du client d’application de mise en quarantaine (QEC) de protection d’accès réseau (NAP) inscrite dans le système. Si c’est le cas, quand une nouvelle authentification est tentée, l’utilisateur est averti d’un changement d’état de quarantaine via une fenêtre contextuelle.

Comment faire savoir s’il existe une interface inscrite au QEC NAP dans le système ?

Ouvrez une fenêtre avec élévation de privilèges et exécutez la commande netsh suivante : « netsh nap client show state ». Pour plus d’informations, consultez Commandes Netsh.

Si le demandeur s’authentifie à nouveau, quel ID de connexion le QEC doit-il utiliser lors de la réauthentification ?

Le QEC doit utiliser le même ID de connexion que celui utilisé pour la session précédente.

Il n’existe qu’une seule méthode de demande EAPHost disponible pour afficher les boîtes de dialogue d’interface utilisateur, mais les méthodes EAP ont plusieurs types d’appels spécifiques à l’interface utilisateur. Quelle méthode le demandeur doit-il appeler lorsqu’il obtient le code d’action « EapHostPeerResponseInvokeUI », indiquant que le demandeur doit afficher une boîte de dialogue d’interface utilisateur ?

Aucune action n’est requise par l’utilisateur, car EAPHost sait à quelle fonction de méthode appeler. Par instance, lorsque le code d’action EapHostPeerResponseInvokeUI est retourné, le demandeur appelle ces trois fonctions dans l’ordre suivant : EapHostPeerGetUIContext, EapHostPeerInvokeInteractiveUI et EapHostPeerSetUIContext.

Quelle est la différence entre un objet BLOB d’informations d’identification et un objet BLOB de configuration ?

L’objet BLOB des informations d’identification contient uniquement des données utilisateur telles que le nom d’utilisateur, le mot de passe et le code confidentiel. L’objet BLOB de configuration contient les paramètres qui contrôlent le comportement de la méthode.

Puis-je activer le suivi côté client EAPHost ?

Oui. Pour plus d’informations, consultez Activation du suivi.