Identity Service Engine(ISE)とActive Directory(AD)について

はじめに

このドキュメントでは、IDサービスエンジン(ISE)とActive Directory(AD)の通信方法、使用されるプロトコル、ADフィルタ、およびフローについて説明します。

前提条件

要件

シスコでは、以下に関する基礎知識を推奨しています。

• ISE 2.xとActive Directoryの統合
• ISEでの外部ID認証

使用するコンポーネント

• ISE 2.x（ISEで設定されたIPアドレス）
• Windows Server(Active Directory)。

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。

ADプロトコル

Kerberosプロトコル  

Kerberosの3つのヘッドは、鍵発行局(KDC)、クライアントユーザ、およびアクセスするサーバで構成されます。

KDCはドメインコントローラ(DC)の一部としてインストールされ、認証サービス(AS)とチケット認可サービス(TGS)という2つのサービス機能を実行します。

クライアントが最初にサーバリソースにアクセスするときには、次の3つの交換が関係します。

1. AS Exchangeです。
2. TGS交換。
3. クライアント/サーバ(CS)の交換。

• ドメインコントローラ= 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の統合の前提条件

1. ISEでスーパー管理者またはシステム管理者の権限があることを確認します。
2. ネットワークタイムプロトコル(NTP)サーバ設定を使用して、CiscoサーバとActive Directory間で時刻を同期します。ISEとADの最大許容時間差は5分です
3. ISEで設定されたDNSは、追加のサイト情報の有無にかかわらず、DC、GC、およびKDCに対するSRVクエリに応答できる必要があります。
4. すべてのDNSサーバが、可能なActive Directory DNSドメインに対して順方向および逆方向のDNSクエリに応答できることを確認します。
5. ADには、シスコがアクセス可能なグローバルカタログサーバが少なくとも1つ必要です。このサーバは、シスコに参加するドメイン内に配置する必要があります。

ADドメインへの参加

ISEは、ドメイン検出を適用して、参加ドメインに関する情報を3段階で取得します。

1. 参加しているドメインのクエリー：フォレストからドメインを検出し、参加しているドメインに対して外部的に信頼されているドメインを検出します。
2. フォレスト内のルートドメインを照会する：フォレストとの信頼を確立します。
3. 信頼できるフォレスト内のルートドメインのクエリー：信頼できるフォレストからドメインを検出します。

さらに、Cisco ISEはDNSドメイン名（UPNサフィックス）、代替UPNサフィックス、およびNTLMドメイン名を検出します。

ISEはDCディスカバリを適用して、使用可能なDCとGCに関するすべての情報を取得します。

1. 参加プロセスは、ドメイン自体に存在するAD上のスーパー管理者の入力クレデンシャルから始まります。別のドメインまたはサブドメインに存在する場合、ユーザ名はUPN表記(username@domain)で表記する必要があります。
2. ISEは、すべてのDC、GC、およびKDCレコードに対するDNSクエリを送信します。DNS応答の応答にこれらのいずれかが含まれていない場合、統合は失敗し、DNS関連のエラーが表示されます。
3. ISEはCLDAP pingを使用して、SRVレコードの優先度に対応するDCに送信されたCLDAP要求によってすべてのDCとGCを検出します。最初のDC応答が使用され、ISEはそのDCに接続されます。

DCの優先度の計算に使用される1つの要素は、CLDAP pingへの応答にDCが要する時間です。応答が速いほど、優先度は高くなります。

注：CLDAPは、ISEがDCとの接続を確立および維持するために使用するメカニズムです。  最初のDC応答までの応答時間を測定するDCから応答がない場合は失敗します。応答時間が2.5秒を超えた場合に警告するCLDAP ping all DCs in site（サイトがない場合は、ドメイン内のすべてのDC）。 CLDAP応答には、DCサイトとクライアントサイト（ISEマシンが割り当てられているサイト）が含まれます。

4. その後、ISEは「join user」クレデンシャルを含むTGTを受信します。
5. MSRPC（SAMおよびSPN）を使用してISEのマシンアカウント名を生成します。
6. ISEのマシンアカウントがすでに存在する場合は、SPNによってADを検索します。ISEマシンが存在しない場合、ISEは新しいマシンを作成します。
7. マシンアカウントを開き、ISEマシンアカウントパスワードを設定し、ISEマシンアカウントにアクセスできることを確認します。
8. ISEのマシンアカウント属性（SPN、dnsHostnameなど）を設定します。
9. KRB5でISEマシンのクレデンシャルを使用してTGTを取得し、すべての信頼できるドメインを検出します。
10. 参加が完了すると、ISEノードはそのADグループおよび関連するSIDを更新し、SID更新プロセスを自動的に開始します。このプロセスがAD側で完了できることを確認します。

ADドメインから脱退する

ISEが脱退する際、ADは次のことを考慮する必要があります。

1. 脱退プロセスを実行するには、完全なAD管理ユーザを使用します。これにより、ISEのマシンアカウントがActive Directoryデータベースから削除されていることが確認されます。
2. ADにクレデンシャルが残っていない場合、ISEアカウントはADから削除されないため、手動で削除する必要があります。
3. バックアップまたはアップグレード後にCLIからISE設定をリセットするか、設定を復元すると、脱退操作が実行され、Active DirectoryドメインからISEノードが切断されます。（結合されている場合）。 ただし、ISEノードアカウントはActive Directoryドメインから削除されません。
4. Active Directoryのクレデンシャルを使用して管理ポータルから脱退操作を実行することをお勧めします。これは、Active Directoryドメインからノードアカウントも削除するためです。ISEホスト名を変更する場合にも、この方法を使用することをお勧めします。

DCフェールオーバー

何らかの理由でISEに接続されているDCがオフラインまたは到達不能になると、DCフェールオーバーがISEで自動的にトリガーされます。DCフェールオーバーは、次の条件によってトリガーされる可能性があります。

1. ADコネクタは、CLDAP、LDAP、RPC、またはKerberos通信の試行中に、現在選択されているDCが使用できなくなったことを検出します。このような場合、ADコネクタはDC選択を開始し、新しく選択したDCにフェールオーバーします。
2. 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名：ドメインマークアップのないユーザ名またはマシン名。これは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,..., etc)を指定できます。 例：メインUPN(sajeda@cisco.com)、代替UPN :sajeda@domain1 , sajeda@domain2

• NetBIOSプレフィクス付きの名前：は、マシン名のドメイン名\ユーザ名です。例：CISCO\sajedaまたはCISCO\machine$

• 非修飾マシンを含むホスト/プレフィックス：マシン名のみを使用する場合にマシン認証に使用され、ホスト/マシン名のみを使用します。例：ホスト/マシン

• 完全修飾マシンを含むホスト/プレフィックス：マシンFQDNが使用される場合にマシン認証に使用されます。通常、証明書認証の場合は、マシンのホスト/FQDNです。  例： host/machine.cisco.com

• SPN名：クライアントがサービスのインスタンスを一意に識別するために使用する名前（例： HTTP、LDAP、SSH）。マシンのみで使用されます。

ADフローに対するユーザ認証：

1. IDを解決し、SAM、UPN、SPNのIDタイプを決定します。 ISEがユーザ名のみとしてIDを受信した場合、ADで関連付けられたSAMアカウントを検索します。ISEがusername@domainとしてIDを受信すると、一致したUPNまたはメールをAD内で検索します。どちらのシナリオでも、ISEはマシンまたはユーザ名に追加のフィルタを使用します。 
2. ドメインまたはフォレストの検索（IDの種類によって異なります）
3. 関連付けられたすべてのアカウント（JP、DN、UPN、ドメイン）の情報を保持
4. 関連付けられたアカウントが見つからない場合、ADはユーザに対して不明な応答を返します。
5. 関連付けられた各アカウントに対してMS-RPC （またはKerberos）認証を実行する
6. 入力IDとパスワードに一致するアカウントが1つだけの場合、認証は成功します
7. 複数のアカウントが着信IDに一致する場合、ISEはパスワードを使用してあいまいさを解決し、パスワードが関連付けられているアカウントが認証され、他のアカウントは不正なパスワードカウンタを1増やします。
8. 着信IDとパスワードに一致するアカウントがない場合、ADは誤ったパスワードで応答します。

ISE 検索フィルタ

フィルタは、ADと通信するエンティティを識別するために使用されます。ISEは常にusersグループとmachinesグループでそのエンティティを検索します。

検索フィルタの例：

1. SAM検索：ISEがドメインマークアップのないユーザ名としてのみIDを受信した場合、ISEはこのユーザ名をSAMとして扱い、そのIDをSAM名として持つすべてのマシンユーザまたはマシンをADで検索します。

SAM名が一意でない場合、ISEはパスワードを使用してユーザを区別し、ISEはEAP-TLSなどのパスワードレスプロトコルを使用するように設定されます。

適切なユーザを見つけるための基準は他にないため、ISEは「あいまいなID」エラーで認証に失敗します。

ただし、ユーザ証明書がActive Directoryに存在する場合、Cisco ISEはバイナリ比較を使用してIDを解決します。

2. UPNまたはメール検索：ISEがusername@domainとしてIDを受信すると、ISEは各フォレストグローバルカタログを検索して、そのUPN IDに一致するものを探すか、メールID「identity=matched UPN or email」を探します。

一意の一致がある場合、Cisco ISEはAAAフローを続行します。

同じUPNとパスワード、または同じUPNとメールを持つ複数の参加ポイントがある場合、Cisco ISEは「あいまいなID」エラーで認証に失敗します。

3. NetBIOS検索：ISEがNetBIOSドメインプレフィックス（例：CISCO\sajedah）を持つIDを受信した場合、ISEはNetBIOSドメインのフォレストを検索します。見つかると、指定されたSAM名（この例ではsajeda）を検索します

4. マシンベース検索：ISEがホスト/プレフィクスIDを含むマシン認証を受信すると、一致するservicePrincipalName属性をフォレスト内で検索します。

完全修飾ドメインサフィックス(host/machine.domain.comなど)がIDに指定されている場合、Cisco ISEはそのドメインが存在するフォレストを検索します。

IDがホスト/マシンの形式である場合、Cisco ISEはすべてのフォレストでサービスプリンシパル名を検索します。

一致する項目が複数ある場合、Cisco ISEは「あいまいなID」エラーで認証に失敗します。

注：同じフィルタがISE ad-agent.logファイルに表示されます

注：ISE 2.2パッチ4以前および2.3パッチ1以前では、属性がSAM、CN、またはその両方のユーザが特定されています。Cisco ISEリリース2.2パッチ5以降および2.3パッチ2以降では、デフォルト属性としてsAMAccountName属性のみを使用します。