> ## Documentation Index
> Fetch the complete documentation index at: https://docs.iru.com/llms.txt
> Use this file to discover all available pages before exploring further.
# EAP(Extensible Authentication Protocol)タイプを構成する
> Iru Endpoint を使用して、Windows コンピュータで 802.1X 用の EAP 認証タイプを構成します。Wi-Fi ネットワークプロファイル用に TLS、TTLS、PEAP、EAP-FAST をセットアップします。
このガイドは Windows コンピュータに適用されます
Wi-Fi ネットワークへの認証には、特にインフラストラクチャが複数の認証方式をサポートしている場合、多数のオプションが用意されています。各方式には、構成が必要な固有の設定があります。この記事では、Windows 向けの [Wi-Fi Library Item の構成](/ja/endpoint/library/library-items-profiles/configure-the-wi-fi-library-item)で利用できる最も一般的な EAP 構成オプションについて説明します。
ネットワークインフラストラクチャは、選択した EAP タイプをサポートし、認証を許可するように正しく構成されている必要があります。ネットワークの構成がわからない場合は、ネットワーク管理者と協力して、ネットワーククライアントの認証方法を確認してください。
Iru Endpoint で Enterprise Wi-Fi を選択すると、選択した EAP タイプに関係なく、Identity certificate と Certificate trust の設定が常に UI に表示されます。これらのフィールドは必須ではなく、EAP タイプによっては適用されません。EAP タイプで証明書を使用しない場合は、これらのフィールドを空白のままにできます。
## EAP-TLS を構成する
EAP-TLS は、Transport Layer Security と **ID 証明書**を使用してデバイスをネットワークに認証します。
EAP-TLS を使用するには、ID 証明書を提供する必要があります。
**Accepted EAP Types** で **TLS** を選択します。
**Credential source** で、クライアントが ID 証明書を見つける方法を選択します。
* ほとんどの展開では **Certificate Store** を使用します。
**Simple certificate selection** を有効にすると、Windows が認証時に正しい証明書を自動的に選択します。
無効にすると、ユーザーは利用可能な証明書から選択するよう求められる場合があります。
RADIUS/証明書インフラストラクチャの展開方法に基づいて、検証オプションを構成します。
* **Perform server validation**(本番環境で推奨)
* **サーバー検証のユーザープロンプトを無効にする**
* **サーバー名を受け入れる**
環境で EKU フィルタリングを使用している場合は、次を構成します。
* **クライアント認証 EKU**
* **任意の目的の EKU**
* **すべての目的の EKU**
## EAP-TTLS を構成する
Tunneled Transport Layer Security(TTLS)は、TLS トンネルを使用して別の認証プロトコルを暗号化します。**通常は ID 証明書を必要とせず**、ほとんどの展開ではユーザー名とパスワード(またはインフラストラクチャに応じてデバイスの資格情報)を使用して認証します。
**Accepted EAP Types** で **TTLS** を選択します。
インフラストラクチャが ID プライバシーをサポートしている場合は、**Enable identity privacy** を有効にします。
有効にすると、クライアントは最初のやり取りで匿名の外部 ID を送信し、暗号化されたトンネル内でのみ実際の ID を明らかにします。
次を構成します。
* **サーバー検証を実行する**
* **サーバー検証のユーザープロンプトを無効にする**
* **サーバー名を受け入れる**
**Inner authentication** で、TLS トンネル内で使用する認証プロトコルを選択します(RADIUS 構成の要件に従います)。
ID 証明書の設定が UI に表示される場合がありますが、インフラストラクチャで明示的に証明書が必要な場合を除き、通常 TTLS では使用されません。
## EAP-PEAP を構成する
Protected Extensible Authentication Protocol(PEAP)は、TLS トンネルを使用して、内部認証方式でやり取りされる資格情報を保護します。TTLS と同様に、PEAP は**通常 ID 証明書を必要とせず**、トンネル内でユーザー名/パスワード認証を使用するのが最も一般的です。
**Accepted EAP Types** で **PEAP** を選択します。
環境に応じて、次を構成します。
* **Enable fast reconnect**(ローミングのパフォーマンスを向上させます)
* **Require cryptobinding**(サポートされている場合に推奨。一部のトンネリング攻撃からの保護に役立ちます)
* **Enable NAP quarantine checks**(レガシー。最新の展開では通常無効にします)
**Allow user to accept untrusted server certificates** を構成します。
* 有効にすると、サーバー CA が信頼されていない場合にユーザーにプロンプトが表示される場合があります。
* 無効にすると、サーバーを検証できない場合は接続が自動的に失敗します。
次を構成します。
* **サーバー検証を実行する**
* **サーバー検証のユーザープロンプトを無効にする**
* **サーバー名を受け入れる**
展開で匿名の外部 ID がサポートされている場合は、**Enable identity privacy** を有効にします。
RADIUS の要件に基づいて **Inner authentication** 方式を選択します。
ID 証明書のフィールドが表示される場合でも、PEAP では通常 ID 証明書を使用しません。
## EAP-TEAP を構成する
Tunneled EAP(TEAP)は、**複数の内部認証メカニズム**をサポートし、PEAP/TTLS よりも高い拡張性を備えた最新のトンネル型 EAP 方式です。多くの TEAP 展開では、ユーザー名/パスワード、証明書、またはそれらの組み合わせを使用して認証します。
**Accepted EAP Types** で **TEAP** を選択します。
**Auto-trust servers accepted by the user** を構成します。
有効にすると、ユーザーがサーバー証明書を手動で承認して接続が成功した場合に、サーバーからプッシュされた追加のルートを信頼された CA リストに追加できます。
次を構成します。
* **サーバー検証を実行する**
* **サーバー検証のユーザープロンプトを無効にする**
* **サーバー名を受け入れる**
インフラストラクチャでサポートされている場合は、**Enable identity privacy** を有効にします。
TEAP では複数の内部方式を使用できます。次を構成します。
* **プライマリ内部認証**
* **Secondary inner authentication**(オプション)
認証戦略によっては、一部の TEAP 展開で ID 証明書を使用する場合があります。TEAP 展開で証明書を使用しない場合は、証明書のフィールドを空白のままにできます。
## EAP-SIM を構成する
EAP-SIM は、認証に **SIM カード**を使用します。アクセス制御に SIM ベースの ID を使用するキャリアまたはエンタープライズ環境で一般的に使用されます。
**Accepted EAP Types** で **SIM** を選択します。
**Require strong cipher keys** を構成すると、より強力な暗号鍵(3 つの RAND)が必須になります。
これを構成しない場合、サーバーの動作に応じて 2 つまたは 3 つの RAND が許可される場合があります。
**Hide permanent subscriber identity (IMSI)** を構成すると、以前の認証による仮名 ID が存在する場合に IMSI が公開されないようにします。
* **Provider name**(このプロバイダに一致する SIM に認証を限定します)
* **Realm configuration**(サーバーに ID を送信する際に使用するレルムを制御します)
## EAP-AKA を構成する
EAP-AKA は **USIM ベースの認証**を使用し、モバイルキャリアや SIM 対応のエンタープライズ展開で一般的に使用されます。
**Accepted EAP Types** で **AKA** を選択します。
仮名が存在する場合に IMSI を保護するかどうかに基づいて、**Hide permanent subscriber identity (IMSI)** を構成します。
* **プロバイダー名**
* **レルムの構成**
## EAP-AKA' を構成する
EAP-AKA' は、ID バインディングと鍵導出が改善された EAP-AKA の拡張バージョンです。一部の最新の SIM ベースの展開で使用されています。
**Accepted EAP Types** で **AKA'** を選択します。
**Validate network name from server** を構成して、クライアントが想定するネットワーク名をサーバーがアドバタイズする名前と照合するかどうかを制御します。
**Enable fast reauthentication** を構成すると、可能な場合に短く高速な AKA' のやり取りが許可されます。
無効または未構成の場合、すべての接続で完全な認証が使用されます。
環境で必要な場合は、IMSI 保護の設定を構成します。
* **プロバイダー名**
* **レルムの構成**
## 推奨事項とベストプラクティス
* **可能な限りサーバー検証を使用してください**。検証を無効にしたり、信頼されていないサーバー証明書を許可したりすると、資格情報の傍受や中間者攻撃のリスクが高まります。
* 利用可能な場合は、特に TTLS/PEAP/TEAP 環境で **ID プライバシーを有効にしてください**。
* **EAP-SIM / AKA / AKA' は**、組織が SIM/USIM ベースの ID 認証をサポートしている場合に**のみ使用してください**。これらは標準的なエンタープライズ Wi-Fi 展開ではあまり一般的ではありません。
* どの EAP タイプを使用すべきかわからない場合は、Wi-Fi/RADIUS チームに相談して、インフラストラクチャで有効になっている方式を確認してください。