Domande frequenti su EAPHost Supplicant

Questo argomento fornisce risposte alle domande frequenti sull'API Supplicant EAPHost.

Perché è necessario chiamare "EapHostPeerInitialize" e "EapHostPeerUninitialize"?

EapHostPeerInitialize e EapHostPeerUninitialize initialize e uninitialize the COM environment used for interprocess communication (IPC) between a supplicant and EAPHost.

Quali funzioni devono essere richiamate sui thread con COM inizializzato per Single Threaded Apartment (STA)?

EapHostPeerInvokeConfigUI, EapHostPeerInvokeInteractiveUI e EapHostAuthenticatorInvokeConfigUI devono essere chiamati nei thread con COM inizializzato per STA. A tale scopo, è possibile chiamare COInitialize dell'API COM; al termine della supplicante con il thread STA CoUninitialize deve essere chiamato prima di uscire.

In che modo EAPHost esporta il materiale di keying?

I metodi EAPHost EAP esportano le chiavi della sessione master (MSK) sotto forma di chiavi MPPE (Point-to-Point Encryption) di Microsoft ai supplici. Il materiale aggiuntivo per la chiave, ad esempio chiavi master pairwise (PMK) può essere generato dal supplicante tramite MSK. Affinché i metodi generino qualsiasi altra chiave durante l'autenticazione, i metodi possono fornire tali chiavi come attributi specifici del fornitore ai supplici.

Che cos'è una chiave di sessione master estesa (EMSK)?

EMSK è un materiale di keying aggiuntivo esportato dal metodo EAP. EMSK ha una lunghezza di almeno 64 ottetti. EMSK viene condiviso tra il client EAP e il server, ma non è condiviso con l'autenticatore o con altre terze parti. Attualmente EMSK è riservato per uso futuro. Per altre informazioni, vedere Extensible Authentication Protocol EAP) Method Requirements for Wireless LAN.For more information, see Extensible Authentication Protocol EAP) Method Requirements for Wireless LAN.

Quando un metodo utilizza o genera un attributo?

Se un metodo EAP genera attributi o EMSK, il supplicante utilizzerà gli attributi. In genere, gli attributi utilizzati dai supplici sono chiavi. Gli attributi utilizzati sono eatPeerId, eatServerId, eatMethodId, eatEMSK e eatCredentialsChanged. Per altre informazioni, vedere EAP_ATTRIBUTE_TYPE. Un metodo EAP può esportare materiale EMSK aggiuntivo specifico dell'applicazione, ad esempio:

  • ID sessione
  • [Protezione accesso alla rete] (/windows/desktop/NAP/network-access-protection-start-page) (PROTEZIONE accesso alla rete)

Quali attributi utilizzano 802.1X?

La supplicante wireless nativa 802.1X utilizzerà i seguenti attributi di autenticazione EAPHost:

  • Notifica di modifica della password
  • Chiavi di invio/ricezione di Microsoft Point-to-Point Encryption (MPPE). VendorId/VendorType = 331/16 e 311/1

Le chiavi MPPE sono chiavi generate alla fine dell'autenticazione riuscita, sia dal peer che dall'autenticatore. Queste chiavi vengono usate da 802.1X e dal server di accesso alla rete (NAS) per crittografare e decrittografare i pacchetti inviati e ricevuti.

Qual è lo scopo del flag EAP_PEER_FLAG_GUEST_ACCESS in EAPHost?

Quando questo flag viene impostato in EAPHostPeerBeginSession, EAPHost lo interpreta come richiesta di autorizzazione guest e restituisce una risposta di identità NULL che viene quindi passata al supplicante e restituita al server EAP.

In che modo la supplicante richiede l'autenticazione del computer?

L'autenticazione del computer viene richiesta impostando il flag di EAP_FLAG_MACHINE_AUTH .

In che modo il supplicante richiede l'autenticazione utente?

L'autenticazione utente viene richiesta non impostando il flag di EAP_FLAG_MACHINE_AUTH .

Quando si usa "EapHostPeerFreeErrorMemory" anziché la funzione "EapHostFreeEapError"?

La funzione EapHostPeerFreeErrorMemory viene usata solo per liberare EAP_ERROR strutture restituite dalle API di configurazione EAPHost. Le API di configurazione EAPHost sono definite in EapHostPeerConfigApis.h. Al contrario, la funzione EapHostPeerFreeEapError viene usata per liberare EAP_ERROR strutture restituite dalle API di runtime EAPHost. Le API di runtime EAPHost sono definite in EapPApis.h. Non usare mai la versione di runtime dell'API con la versione di configurazione delle API; a tale scopo potrebbe produrre risultati imprevisti.

L'interfaccia utente è stata implementata nello stesso thread usato per elaborare una sessione di autenticazione EAP sulla supplicante. Dopo aver generato una finestra di dialogo interattiva dell'interfaccia utente per ottenere le credenziali o altri dati di input dell'utente, la chiamata successiva da EAPHost a un metodo peer EAP ha esito negativo con "ERROR_OBJECT_DISCONNECTED". Perché si è verificato questo problema e come è possibile risolverlo?

Anche se le API lato client EAPHost sono tutte API di stile C, queste API C sono solo wrapper delle API COM corrispondenti. Le API di stile C vengono eseguite in un ambiente COM multithreading. Il codice dell'interfaccia utente viene in genere eseguito nel modello di thread apartment. Poiché i due modelli di thread sono in conflitto tra loro, non eseguire il codice dell'interfaccia utente nello stesso thread che elabora le autenticazioni EAP.

Perché l'API "EapHostPeerBeginSession" accetta un puntatore alla funzione di callback "NotificationHandler" come parametro?

NotificationHandler è il meccanismo mediante il quale un supplicante riceve una notifica che deve eseguire di nuovo l'autenticazione. Esistono vari scenari in cui è necessaria la supplicante per ripetere l'autenticazione, inclusa l'autenticazione con Protezione accesso alla rete .

Qual è lo scopo del parametro "pConnectionId" nell'API "EapHostPeerBeginSession"?

pConnectionId è un puntatore a un valore GUID supplicante usato per identificare una connessione di rete appartenente al supplicante. Quando viene chiamata la funzione di callback NotificationHandler , questo GUID viene passato per identificare la connessione di rete che verrà usata dal supplicante per le richieste di nuova autenticazione.

Ricerca per categorie sapere se si verifica una modifica dello stato di quarantena?

L'utente riceverà una notifica visiva di una modifica dello stato di quarantena solo se è presente almeno un'interfaccia registrata del client di imposizione della quarantena protezione accesso alla rete (QEC) nel sistema. In tal caso, quando si tenta di ripetere l'autenticazione, l'utente riceverà una notifica di modifica dello stato di quarantena tramite una finestra popup.

Ricerca per categorie sapere se nel sistema è presente un'interfaccia registrata nap QEC?

Aprire una finestra con privilegi elevati ed eseguire il comando netsh seguente: "netsh nap client show state". Per altre informazioni, vedere Comandi Netsh.

Se la ripetizione dell'autenticazione supplica, quale ID di connessione deve essere usato dal QEC durante la nuova autenticazione?

QEC deve usare lo stesso ID di connessione usato per la sessione precedente.

È disponibile un solo metodo supplicante EAPHost per visualizzare le finestre di dialogo dell'interfaccia utente, ma i metodi EAP hanno diversi tipi di chiamate specifiche dell'interfaccia utente. Quale metodo deve chiamare la supplicante quando ottiene il codice dell'azione "EapHostPeerResponseInvokeUI", che indica che il supplicante deve visualizzare una finestra di dialogo dell'interfaccia utente?

Nessuna azione richiesta dall'utente perché EAPHost conosce la funzione del metodo da chiamare. Ad esempio, quando viene restituito il codice azione EapHostPeerResponseInvokeUI , la supplicant chiama queste tre funzioni nell'ordine seguente: EapHostPeerGetUIContext, EapHostPeerInvokeInteractiveUI e EapHostPeerSetUIContext.

Qual è la differenza tra un BLOB di credenziali e un BLOB di configurazione?

Il BLOB delle credenziali contiene solo i dati utente, ad esempio nome utente, password e PIN. Il BLOB di configurazione contiene le impostazioni che controllano il comportamento del metodo.

È possibile abilitare la traccia sul lato client EAPHost?

Sì. Per altre informazioni, vedere Abilitazione della traccia.