Identity Service EngineとActive Directoryについて
はじめに
このドキュメントでは、Identity Service Engine(ISE)とActive Directory(AD)の通信方法、使用されるプロトコル、ADフィルタ、およびフローについて説明します。
前提条件
要件
次の項目に関する基本知識が推奨されます。
- ISEでの外部ID認証
- ISE 2.xとActive Directoryの統合
使用するコンポーネント
- ISE 2.x
- Windowsサーバ(Active Directory)
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
ADプロトコル
Kerberosプロトコル
Kerberosの3つのヘッドは、鍵発行局(KDC)、クライアントユーザ、およびアクセスするサーバで構成されます。KDCはドメインコントローラ(DC)の一部としてインストールされ、認証サービス(AS)とチケット認可サービス(TGS)という2つのサービス機能を実行します。
クライアントが最初にサーバリソースにアクセスするときには、次の3つの交換が関係します。
- AS交換
- TGS交換
- クライアント/サーバ(CS)Exchange
- ドメインコントローラ= KDC(AS + TGS)
- パスワードを使用してAS（SSOポータル）に認証する
- チケット認可チケット(TGT)（セッションクッキー）の取得
- サービス(SRV01)へのログインを要求する
- SRV01がKDCにリダイレクトする
- Show TGT to KDC:（認証済み）
- KDCはSRV01のTGSを提供
- SRV01にリダイレクトします。
- SRV01へのサービスチケットを表示します
- SRV01がサービスチケットを確認/信頼する
- サービスチケットにすべての情報が含まれている
- SRV01にログインする
最初にネットワークにログオンしたユーザーは、アクセスをネゴシエートし、ドメイン内のKDCのAS部分で確認するログイン名とパスワードを指定する必要があります。KDCはActive Directoryユーザーアカウント情報にアクセスできます。認証されると、ローカルドメインで有効なTicket Granting Ticket(TGT)がユーザに付与されます。TGTのデフォルトのライフタイムは10時間で、ユーザがパスワードを再入力しなくても、ユーザのログオンセッションを通じて更新されます。TGTは、揮発性メモリ領域内のローカルマシンにキャッシュされ、ネットワーク全体でサービスとのセッションを要求するために使用されます。
ユーザーは、サーバー・サービスへのアクセスが必要な場合に、KDCのTGS部分にTGTを提示します。KDC上のTGSはユーザTGTを認証し、クライアントとリモートサーバの両方に対してチケットとセッション鍵を作成します。この情報（サービスチケット）は、クライアントマシン上にローカルにキャッシュされます。TGSはクライアントTGTを受信し、自身のキーで読み取ります。TGSがクライアント要求を承認すると、クライアントとターゲットサーバの両方に対してサービスチケットが生成されます。クライアントは、AS応答から先に取得されたTGSセッションキーを使用して自身の部分を読み取ります。クライアントは、次のクライアント/サーバ交換でTGS応答のサーバ部分をターゲットサーバに提示します。
例：
認証されたユーザのISEからのパケットキャプチャ：
AS-REQにはユーザ名が含まれています。パスワードが正しければ、ASサービスはユーザのパスワードで暗号化されたTGTを提供します。次に、TGTはセッションチケットを受信するためにTGTサービスを提供します。セッションチケットを受信すると、認証は成功します。
クライアントから提供されたパスワードが正しくない場合の例を次に示します。
パスワードが正しくない場合、AS要求は失敗し、TGTは受信されません。
次の例では、パスワードが正しくない場合のad_agent.logファイルのログを示します。
2020-01-14 13:36:05,442 DEBUG,140574072981248,krb5: Sent request (276 bytes) to RALMAAIT.COM,LwKrb5TraceCallback(),lwadvapi/threaded/lwkrb5.c:1325
2020-01-14 13:36:05,444 DEBUG,140574072981248,krb5: Received error from KDC: -1765328360/Preauthentication failed,LwKrb5TraceCallback(),lwadvapi/threaded/lwkrb5.c:1325
2020-01-14 13:36:05,444 DEBUG ,140574072981248,krb5: Preauth tryagain入力タイプ： 16, 14, 19, 2,LwKrb5TraceCallback(),lwadvapi/threaded/lwkrb5.c:1325
2020-01-14 13:36:05,444 WARNING,140574072981248,[LwKrb5GetTgtImpl ../../lwadvapi/threaded/krbtgt.c:329] KRB5エラーコード： -1765328360 （メッセージ：事前認証に失敗）,LwTranslateKrb5Error(),lwadvapi/threaded/lwkrb5.c:892
2020-01-14 13:36:05,444 DEBUG ,140574072981248,[LwKrb5InitializeUserLoginCredentials()]エラーコード： 40022 （シンボル： LW_ERROR_PASSWORD_MISMATCH）,LwKrb5InitializeUserLoginCredentials(),lwadvapi/threaded/lwkrb5.c:1453
MS-RPCプロトコル
ISEはSMB経由のMS-RPCを使用し、SMBは認証を提供するため、特定のRPCサービスが配置されている場所を見つけるために個別のセッションを必要としません。クライアントとサーバ間の通信には、「名前付きパイプ」と呼ばれるメカニズムが使用されます。
- SMBセッション接続の作成
- RPCメッセージをトランスポートとしてSMB/CIFS.TCPポート445経由で転送
- SMBセッションは、特定のRPCサービスが実行し、ユーザー認証を処理するポートを識別します
- プロセス間通信のための隠れた共有IPC$への接続
- 目的のRPCリソース/関数の適切な名前付きパイプを開きます
- SMB経由のRPC交換の処理
negotiate protocol request/response行でSMBのダイアレクトがネゴシエートされ、session setup request/responseで認証が実行されます。ツリー接続要求と応答は、要求されたリソースに接続します。特別な共有IPC$に接続されています。このプロセス間通信シェアは、ホスト間の通信手段を提供し、MSRPC機能のトランスポートとしても使用できます。
パケット77はCreate Request Fileであり、ファイル名は接続されたサービス（この例ではnetlogonサービス）の名前です。
パケット83および86はNetrlogonSamLogonEX要求です。この要求で、フィールドNetwork_INFOで、ISE上のクライアント認証用のユーザ名をADに送信します。NetrlogonSamLogonEX応答パケットが結果で応答します。
NetrlogonSamLogonEX応答のフラグ値の一部：
0xc000006aはSTATUS_WRONG_PASSWORDです
0x00000000はSTATUS_SUCCESS
0x00000103はSTATUS_PENDING
ISEとActive Directory(AD)の統合
ISEは、参加/脱退および認証プロセス中にLDAP、KRB、およびMSRBCを使用してADと通信します。次のセクションでは、ADで特定のDCに接続し、そのDCに対してユーザ認証を行うために使用されるプロトコル、検索形式、およびメカニズムについて説明します。何らかの理由でDCがオフラインになった場合、ISEは次に使用可能なDCにフェールオーバーし、認証プロセスは影響を受けません。
グローバルカタログサーバー(GC)は、フォレスト内のすべてのActive Directoryオブジェクトのコピーを格納するドメインコントローラーです。 ドメインのディレクトリにあるすべてのオブジェクトの完全なコピーと、他のすべてのフォレストドメインにあるすべてのオブジェクトの部分的なコピーが保存されます。 グローバルカタログを使用すると、ユーザおよびアプリケーションは、GCに含まれる属性を検索して、現在のフォレストの任意のドメイン内のオブジェクトを検索できます。 グローバルカタログには、各ドメインの各フォレストオブジェクトの基本的な（不完全な）属性セット（部分属性セット、PAT）が含まれています。
GCは、フォレスト内のすべてのドメインディレクトリパーティションからデータを受信し、標準のADレプリケーションサービスでコピーされます。
AD への ISE の結合
Active DirectoryとISE統合の前提条件
- ISEでスーパー管理者またはシステム管理者の権限があることを確認します。
- ネットワークタイムプロトコル(NTP)サーバ設定を使用して、CiscoサーバとActive Directory間で時刻を同期します。ISEとADの最大許容時間差は5分です。
- ISEで設定されたDNSは、追加のサイト情報の有無にかかわらず、DC、GC、およびKDCに対するSRVクエリに応答する必要があります。
- すべてのDNSサーバが、可能なActive Directory DNSドメインの順方向および逆方向のDNSクエリに応答できることを確認します。
- ADには、シスコが運用し、シスコがアクセス可能なグローバルカタログサーバが少なくとも1つ必要です。これは、シスコとの参加を予定しているドメインに対して行います。
ADドメインへの参加
ISEは、ドメイン検出を適用して、参加ドメインに関する情報を3段階で取得します。
- 参加しているドメインのクエリー：フォレストからドメインを検出し、参加しているドメインに対して外部的に信頼されているドメインを検出します。
- フォレスト内のルートドメインを照会する：フォレストとの信頼を確立します。
- 信頼できるフォレスト内のルートドメインのクエリー：信頼できるフォレストからドメインを検出します。
さらに、Cisco ISEはDNSドメイン名（UPNサフィックス）、代替UPNサフィックス、およびNTLMドメイン名を検出します。
ISEはDCディスカバリを適用して、使用可能なDCおよびGCに関するすべての情報を取得します。
- 参加プロセスは、ドメイン自体に存在するAD上のスーパー管理者の入力クレデンシャルから始まります。別のドメインまたはサブドメインに存在する場合、ユーザ名はUPN表記(username@domain)で表記する必要があります。
- ISEは、すべてのDC、GC、およびKDCレコードに対するDNSクエリを送信します。DNS応答が応答を受信しない場合、統合は失敗し、DNS関連のエラーが表示されます。
- ISEはCLDAP pingを使用して、SRVレコードの優先度に対応するDCに送信されたCLDAP要求によってすべてのDCとGCを検出します。最初のDC応答が使用され、ISEはそのDCに接続されます。
DCの優先度の計算に使用される1つの要素は、CLDAP pingへの応答にDCが要する時間です。応答が速いほど、優先度は高くなります。
注：CLDAPは、ISEがDCとの接続を確立および維持するために使用するメカニズムです。最初のDC応答までの応答時間を測定するDCからの応答が表示されない場合は失敗します。応答時間が2.5秒より長い場合に警告します。CLDAPがオンサイトのすべてのDCに対してpingを実行します（サイトがない場合は、ドメイン内のすべてのDCに対して実行します）。 CLDAP応答には、DCサイトとクライアントサイト（ISEマシンが割り当てられているサイト）が含まれます。
- ISEは、「join user」クレデンシャルを含むTGTを受信します。
- MSRPC（SAMおよびSPN）を使用してISEマシンアカウント名を生成します。
- ISEのマシンアカウントがすでに存在する場合は、SPNによってADを検索します。ISEマシンが存在しない場合は、新しいマシンが作成されます。
- マシンアカウントを開き、ISEマシンアカウントパスワードを設定し、ISEマシンアカウントにアクセスできることを確認します。
- ISEのマシンアカウント属性（SPN、dnsHostnameなど）を設定します。
- KRB5でISEマシンのクレデンシャルを含むTGTを受信し、すべての信頼できるドメインを検出します。
- 参加が完了すると、ISEノードはそのADグループおよび関連するSIDを更新し、SID更新プロセスを自動的に開始します。このプロセスがAD側で完了できることを確認します。
ADドメインから脱退する
ISEが脱退する際、ADは次のことを考慮する必要があります。
- 脱退プロセスを実行するには、完全なAD管理ユーザを使用します。これにより、ISEのマシンアカウントがActive Directoryデータベースから削除されていることが確認されます。
- ADにクレデンシャルがない場合、ISEアカウントはADから削除されないため、手動で削除する必要があります。
- CLIからISE設定をリセットするとき、またはバックアップやアップグレードの後で設定を復元するときは、脱退操作が実行され、Active DirectoryドメインからISEノードが切断されます。ただし、参加している場合、ISEノードアカウントはActive Directoryドメインから削除されません。
- Active Directoryドメインからノードアカウントも削除されるため、Active Directoryクレデンシャルを使用して管理ポータルから脱退操作を実行することをお勧めします。ISEホスト名を変更する場合にも、この方法を使用することをお勧めします。
DCフェールオーバー
何らかの理由でISEに接続されているDCがオフラインまたは到達不能になると、DCフェールオーバーがISEで自動的にトリガーされます。DCフェールオーバーは、次の条件によってトリガーされる可能性があります。
- ADコネクタは、CLDAP、LDAP、RPC、またはKerberos通信の試行中に、現在選択されているDCが使用できなくなったことを検出します。このような場合、ADコネクタはDC選択を開始し、新しく選択したDCにフェールオーバーします。
- DCは起動し、CLDAP pingに応答しますが、ADコネクタが何らかの理由でDCと通信できません（たとえば、RPCポートがブロックされている、DCが「複製が中断されている」状態である、DCは適切に使用停止されていない）。
このような場合、ADコネクタはブロックされたリストを使用してDC選択を開始し（ブロックされたリストに「不良」DCが配置されている）、選択されたDCとの通信を試みます。ブロックされたリストで選択されたDCはキャッシュされません。
ADコネクタは、妥当な時間内にフェールオーバーを完了する（または不可能な場合は失敗する）必要があります。 このため、ADコネクタはフェールオーバー中に限られた数のDCを試行します。ISEは、回復できないネットワークエラーまたはサーバエラーが発生した場合にADドメインコントローラをブロックし、ISEが不正なDCを使用することを防止します。CLDAPのpingに応答しないDCは、ブロックされたリストに追加されません。ISEは、応答しない場合にのみDCの優先度を下げます。
LDAPを介したISE-AD通信
ISEは、次のいずれかの検索形式でAD内のマシンまたはユーザを検索します。マシンを検索した場合、ISEはマシン名の末尾に「$」を追加します。ADでユーザを識別するために使用されるIDタイプのリストを次に示します。
- SAM Name：ドメインマークアップのないユーザ名またはマシン名。これはADのユーザログオン名です。例： sajedaまたはsajeda$
- CN：これはADのユーザ表示名です。SAMと同じにすることはできません。例： sajeda Ahmed
- ユーザプリンシパル名(UPN):SAM名とドメイン名(SAM_NAME@domian)の組み合わせです。 例：sajeda@cisco.comまたはsajeda$@cisco.com
- 代替UPN：これは、ドメイン名以外のADで設定される追加または代替のUPNサフィックスです。この設定はADでグローバルに追加され（ユーザごとに設定されません）、実際のドメイン名のサフィックスである必要はありません。
- 各ADには、複数のUPNサフィックス（@alt1.com、@alt2.comなど）を指定できます。 たとえば、メインUPN(sajeda@cisco.com)、代替UPN :sajeda@domain1、sajeda@domain2などです。
- NetBIOS Prefixed Name：これはマシン名のドメイン名/ユーザ名です。 例：CISCO\sajedaまたはCISCO\machine$
- Host/Prefix with an Unqualified Machine：マシン名だけが使用され、それがホスト/マシン名だけの場合に、マシン認証に使用されます。たとえば、host/machineなどです。
- 完全修飾マシンを含むホスト/プレフィックス：これは、マシンFQDNが使用される場合（通常は証明書認証の場合）にマシン認証に使用されます。これは、マシンのホスト/FQDNです。たとえば、host/machine.cisco.comなどです。
- SPN名：クライアントがサービスのインスタンスを一意に識別する名前です（例： HTTP、LDAP、SSH）。マシンのみに使用されます。
ADフローに対するユーザ認証：
- IDを解決し、SAM、UPN、SPNのIDタイプを決定します。 ISEは、ユーザ名のみとしてIDを受信すると、AD内の関連するSAMアカウントを検索します。ISEがusername@domainとしてIDを受信すると、一致するUPNまたはAD内のメールを検索します。どちらのシナリオでも、ISEはマシンまたはユーザ名に追加のフィルタを使用します。
- ドメインまたはフォレストを検索します（IDタイプによって異なります）。
- 関連付けられたすべてのアカウント（JP、DN、UPN、ドメイン）の情報を保持します。
- 関連付けられたアカウントが見つからない場合、ADはユーザに対して不明な応答を返します。
- 関連付けられた各アカウントに対してMS-RPC （またはKerberos）認証を実行します。
- 入力IDとパスワードに一致するアカウントが1つだけの場合、認証は成功します。
- 複数のアカウントが着信IDに一致する場合、ISEはパスワードを使用してあいまいさを解決し、パスワードが関連付けられているアカウントは認証されますが、他のアカウントは不正なパスワードカウンタを1増やします。
- 着信IDとパスワードに一致するアカウントがない場合、ADは誤ったパスワードで応答します。
ISE検索フィルタ
フィルタは、ADと通信するエンティティを識別するために使用されます。ISEは常にusers and machinesグループのエンティティを検索します。検索フィルタの例：
- SAM検索：ISEがIDをドメインマークアップのないユーザ名としてのみ受信した場合、ISEはユーザ名をSAMとして扱い、そのIDをSAM名として持つすべてのマシンユーザまたはマシンをADで検索します。
- SAM名が一意でない場合、ISEはパスワードを使用してユーザを区別し、ISEはEAP-TLSなどのパスワードレスプロトコルを使用するように設定されます。
- 正しいユーザを見つけるための基準は他にないため、ISEは「あいまいなID」エラーで認証に失敗します。ただし、ユーザ証明書がActive Directoryに存在する場合、Cisco ISEはバイナリ比較を使用してIDを解決します。
- UPNまたはメール検索:ISEがusername@domainとしてIDを受信すると、ISEはフォレストグローバルカタログを検索して、UPN IDまたはメールID「identity=matched UPN or email」と一致するものを探します。一意の一致がある場合、Cisco ISEはAAAフローを続行します。同じUPNとパスワード、または同じUPNとメールを持つ複数の参加ポイントがある場合、Cisco ISEは「あいまいなID」エラーで認証に失敗します。
- NetBIOS検索:ISEがNetBIOSドメインプレフィクスを持つID（CISCO\sajedahなど）を受信すると、ISEはNetBIOSドメインのフォレストを検索します。見つかると、指定されたSAM名（sajedaなど）を検索します。
- マシンベース検索:ISEがホスト/プレフィクスIDを持つマシン認証を受信すると、ISEは一致するservicePrincipalName属性をフォレスト内で検索します。完全修飾ドメインサフィックスがIDで指定された場合（host/machine.domain.comなど）。Cisco ISEは、ドメインが存在するフォレストを検索します。IDがホスト/マシンの形式である場合、Cisco ISEはすべてのフォレストでサービスプリンシパル名を検索します。一致する項目が複数ある場合、Cisco ISEは「あいまいなID」エラーで認証に失敗します。
更新履歴
| 改定 | 発行日 | コメント |
|---|---|---|
3.0 |
04-Aug-2026
|
「概要」、「タイトル」、「スペル」、「文法」、「セクション/読みやすさを区別するための水平線の挿入」、「代替テキストの更新」を更新。 |
2.0 |
03-Aug-2022
|
文法、構造、機械翻訳、スタイル、形式 |
1.0 |
06-Feb-2020
|
初版 |
フィードバック