セキュリティ : Cisco クラウド Web セキュリティ

ScanSafe/Cloud Web セキュリティ 設定例への Web リダイレクションのための ISR IP 許可および LDAP

2015 年 11 月 26 日 - 機械翻訳について
その他のバージョン: PDFpdf | 英語版 (2015 年 8 月 22 日) | フィードバック

概要

この資料に Cisco G2 シリーズ 統合サービス ルータ(ISR)を設定する方法を記述されています。 IP 許可および Lightweight Directory Access Protocol (LDAP) 設定が ISR の認証プロキシのために単に使用することができる間、Cisco クラウド Web セキュリティ(CWS)リダイレクション機能と共に一般的に使用されます。 そのように、この資料は参照であるように ISR の CWS リダイレクション 設定およびトラブルシューティング ドキュメントを補うために意図されています。

ケビン Klous によって貢献される、Cisco TAC エンジニア。

前提条件

要件

Cisco はコンフィギュレーションを試みる前にシステム大会この資料に説明があるこれらの必要条件ことを推奨します:

  • ISR はコードバージョン 15.2(1)T1 またはそれ以降を実行する必要があります。

  • システムは Cisco IOS ® (ユニバーサル)で利用可能であるセキュリティ機能によって設定 される(SEC)ライセンスのイメージがなければなりません。

  • Active Directory (AD) ドメインのクライアントワークステーションは Webブラウザによってアクティブな認証を行う機能がなければなりません。

  • CWS サブスクリプションを持たなければなりません。

使用するコンポーネント

このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づくものです。

  • Internet Explorer、Google クロム、Mozilla Firefox (透過的な NT LAN Manager (NTLM) 認証のために追加設定を必要とします)

  • Cisco G2 800、1900、2900、および 3900 シリーズ ISR。 

  • Microsoft Windows AD ドメインコントローラ(ADDC)

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。 このドキュメントで使用するすべてのデバイスは、クリアな(デフォルト)設定で作業を開始しています。 ネットワークが稼働中の場合は、コマンドが及ぼす潜在的な影響を十分に理解しておく必要があります。

: Cisco G1 1800、2800、および 3800 シリーズ ルータはサポートされません。

背景説明

ネットワークの Cisco 適応性があるセキュリティ アプライアンス モデル(ASA)がない Cisco G2 シリーズ ISR をインストールする多くの管理者は Web フィルタリングのための CWS ソリューションを利用するために ISR CWS (以前の ScanSafe)リダイレクション 機能性を使用することを選択します。 そのソリューションの一部として、ほとんどの管理者はまた CWS ポータルの Web フィルタリング ポリシーのためのユーザまたはグループ ベース ポリシー施行の為に CWS タワーにユーザ ID情報を送信 するために電流 AD インフラストラクチャを利用したいと思います。

全面的な概念は少数の違いを用いる ASA とコンテキスト ディレクトリエージェント(CDA)間の統合に類似した、です。 最も著しい違いは ISR が実際に受動ユーザに IP マッピング データベースを維持しない、ということで、つまりユーザはパススルーある種の認証 ISR を通過し、ユーザを送信 するか、または CWS ポータルに情報をグループ化するために必要があります。

ヒント: 利用可能であるさまざまな認証方式間の違いに関する詳細についてはこの資料の認証方式 セクションを参照して下さい。

この資料に説明がある設定の CWS リダイレクション部分が比較的簡単な間、何人かの管理者は認証部分を設定する試みの問題に出会うかもしれません。 この部分は IP 許可 コマンドをまた設定する必要がある LDAPサーバおよび認証、許可、アカウンティング(AAA) 認証記述を参照すること使用します。 この資料の目的は Cisco G2 シリーズ ISR のこの設定の IP 許可および LDAP 部分を設定するか、またはトラブルシューティングするために広範囲の参照資料をネットワーク オペレータに与えることです。

設定

情報を使用して下さい Cisco ISR を設定するためにこのセクションに説明がある。

: このセクションで使用されているコマンドの詳細を調べるには、Command Lookup Tool登録ユーザ専用)を使用してください。

ネットワーク図

LDAP を設定して下さい

AAA サーバの LDAP プロパティを設定するためにこれらのステップを完了して下さい:

  1. AD の sAMAccountName プロパティを一致するためにユーザによって入力されるユーザ名を強制するために LDAP アトリビュート マップを設定して下さい:
    C-881(config)#ldap attribute-map ldap-username-map map type sAMAccountName
     username
    C-881(config-attr-map)#map type sAMAccountName username

    sAMAccountName アトリビュートがデフォルトで一致するために他では使用される AD の固有の値、Common Name (CN) アトリビュートとは違ってであるのでこの設定が必要となります。 たとえば、AD のジョン・スミスの多数の例がある場合もありますがまたユーザアカウント ログオンである jsmithsAMAccountName を持つ 1 人のユーザがあるただ場合もあります。 ジョン・スミス他のアカウントに jsmith1 または jsmith2 のような sAMAccountNames があります。


    show ldap 属性コマンドも LDAP 属性および関連する AAA 属性のリストを表示するために使用することができます。

  2. LDAPサーバ グループを設定して下さい:
    C-881(config)#aaa group server ldap LDAP_GROUP
    C-881(config-ldap-sg)#server DC01
  3. LDAPサーバを設定して下さい:
    C-881(config)#ldap server DC01
    C-881(config-ldap-server)# ipv4 10.10.10.150
    C-881(config-ldap-server)#attribute map ldap-username-map
    C-881(config-ldap-server)# bind authenticate root-dn CN=Csco_Service,CN=Users,
    DC=lab,DC=cisco,DC=com password Cisco12345!


    C-881(config-ldap-server)#base-dn DC=lab,DC=cisco,DC=com
    C-881(config-ldap-server)#search-filter user-object-type top
    C-881(config-ldap-server)#authentication bind-first

この設定は一般にカスタム検索フィルタを実装する必要がなければ、修正を必要としません。 きちんとこの情報を入力する方法を LDAP でよく精通 して、知っている管理者だけカスタム検索フィルタを利用する必要があります。 使用する必要がある検索フィルタについて不確か記述されているフィルタを単に使用して下さい; それは標準 AD 環境でユーザを見つけます。

また細心の注意が詳述するように要求する LDAP設定のもう一つの部分はバインド認証するルート dn およびベース dn コマンドに必要となる識別名(DN)です。 これらは LDAPサーバに現われるか、または LDAP クエリが失敗すると同時に丁度入力する必要があります。 さらに、ベース dn コマンドが認証された常駐するであるユーザ全員 LDAP ツリーの低い一部である必要がある。

以前のコンフィギュレーションのベース dn コマンドがこれのような修正されるシナリオを考慮して下さい:

base-dn OU=TestCompany,DC=lab,DC=cisco,DC=com

この場合、CN=Users、DC=lab 含まれているユーザ向けのクエリは、DC=cisco、DC=com LDAPサーバがその中の TestCompany Organizational Unit (OU)および子オブジェクトだけを検索するので、結果を返しません。 その結果、認証はそれらのユーザ向けにそれらが TestCompany OU かサブツリーに移動されるまで、またはクエリにそれを含めるためにベース dn コマンドが変われば常に失敗します。 

ヒント判別を AD の DN オブジェクト- ADSI 編集しますベースおよびルート コマンドのための適切な DN を判別する方法についての詳細についてはこの資料のセクションを参照して下さい。

AAA を設定して下さい

LDAPサーバが設定されるので、IP 許可 プロセスに使用する該当の AAA 文でそれらを参照して下さい:

C-881(config)#aaa authentication login SCANSAFE_AUTH group LDAP_GROUP
C-881(config)#aaa authorization network SCANSAFE_AUTH group LDAP_GROUP

: これらのコマンドが利用できない場合、この AAA の 機能性を有効に するためにデフォルトで有効に ならないので aaa new-model コマンドは入力される必要があるかもしれません。

IP 許可を設定して下さい

認証のためのユーザをプロンプト表示する IP 許可部分プロセスを(または透過的な認証を行います)引き起こし、次にユーザーの資格情報に基づいて LDAP クエリをおよび設定で定義される AAA サーバは行います。 ユーザの認証に成功される場合、ユーザ ID情報はコンテンツ スキャン プロセスによってそして引っ張られ、CWS タワーにリダイレクトされたフローと共に、送信されます。 IP 許可 プロセスは IP 許可 name コマンドがルータの入力 インターフェイスで入力されるまでアクティブになりません。 従って、設定のこの部分はトラフィック影響なしで設定されます。

C-881(config)#ip admission virtual-ip 1.1.1.1 virtual-host ISR_PROXY
C-881(config)#ip admission name SCANSAFE_ADMISSION ntlm
C-881(config)#ip admission name SCANSAFE_ADMISSION method-list authentication
 SCANSAFE_AUTH authorization SCANSAFE_AUTH

イネーブル IP 許可

設定はここにあります IP 許可を有効に するために使用される:

: 認証が失敗した場合トラフィックフロー 割り込みを引き起こすこれはユーザを認証させます。

C-881(config)#int vlan301 (internal LAN-facing interface)
C-881(config-if)#ip admission SCANSAFE_ADMISSION

認証からの免除されている内部ホスト

何人かの管理者は認証プロセスからのいくつかの内部ホストをさまざまな理由で免除することを望むかもしれません。 たとえば、それは IP 許可 プロセスが影響を受ける NTLM か基本的な認証が可能ではないデバイスか内部サーバのために望ましくないかもしれません。 これらの例では、Access Control List (ACL)は IP 許可 設定に特定のホスト IP かサブネットが IP 許可を引き起こすことを防ぐために適用することができます。

この例では、認証がまだ他のすべてのホストに必要となるが、内部ホスト 10.10.10.150 は認証の要件から免除されています:

C-881(config)#ip access-list extended NO_ADMISSION
C-881(config-ext-nacl)#deny ip host 10.10.10.150 any
C-881(config-ext-nacl)#permit ip any any
C-881(config)#ip admission name SCANSAFE_ADMISSION ntlm list NO_ADMISSION

ISR の HTTPサーバを有効に して下さい

HTTP セッションを代行受信し、認証プロセスを開始することを HTTPサーバが可能にすることが必要となります:

Ip http server
Ip http secure-server

Ip http secure-server は認証のための HTTPS へのリダイレクションが必要となる場合その時だけ必要です。

CWS リダイレクションを設定して下さい

CWS リダイレクションのための基本サマリ設定はここにあります:

parameter-map type content-scan global
 server scansafe primary name proxy139.scansafe.net port http 8080 https 8080
 server scansafe secondary name proxy187.scansafe.net port http 8080 https 8080
 license 0 DE749585HASDH83HGA94EA8C369
 source interface Vlan302
user-group DEFAULT_GROUP username DEFAULT_USER
 server scansafe on-failure allow-all

interface Vlan302 (egress interface towards Internet)
 content-scan out

完全な設定例

このセクションは前のセクションにコード例全体コンフィギュレーションを提供します。

LDAP

aaa group server ldap LDAP_GROUP
 server DC01
ldap attribute-map ldap-username-map
 map type sAMAccountName username
ldap server DC01
 ipv4 10.10.10.150
 attribute map ldap-username-map
 bind authenticate root-dn CN=Csco_Service,CN=Users,DC=lab,DC=cisco,DC=com
  password Cisco12345!
 base-dn dc=lab,dc=cisco,dc=com
 search-filter user-object-type top
 authentication bind-first

[AAA]

aaa new-model
aaa authentication login SCANSAFE_AUTH group LDAP_GROUP
aaa authorization network SCANSAFE_AUTH group LDAP_GROUP

IP 許可

ip admission virtual-ip 1.1.1.1 virtual-host ISR_PROXY
ip admission name SCANSAFE_ADMISSION ntlm
ip admission name SCANSAFE_ADMISSION method-list authentication
 SCANSAFE_AUTH authorization SCANSAFE_AUTH

interface Vlan301
 ip admission SCANSAFE_ADMISSION

HTTP Server

ip http server

コンテンツ スキャンおよび CWS

parameter-map type content-scan global
 server scansafe primary name proxy139.scansafe.net port http 8080 https 8080
 server scansafe secondary name proxy187.scansafe.net port http 8080 https 8080
 license 0 DE13621993BD87B306B5A5607EA8C369
 source interface Vlan302
 user-group DEFAULT_GROUP username DEFAULT_USER
 server scansafe on-failure allow-all

interface Vlan302
 content-scan out

AD の DN オブジェクトを- ADSI 編集します判別して下さい

もし必要なら、ユーザまたはグループ検索ベースと併用するための DN を調べるために AD 構造を参照することは可能性のあるです。 管理者は編集します AD ドメインコントローラに構築される ADSI と呼ばれるツールを使用できます。 ADSI を開くために編集し、AD ドメインコントローラで Start > Run の順に選択 し、adsiedit.msc を入力して下さい

ADSI Edit 開いていたら、オブジェクトを、OU のような、グループ、かユーザ右クリックし、そのオブジェクトの DN を表示するために『Properties』 を選択 して下さい。 DN ストリングはルータコンフィギュレーションにそれから誤植を防ぐために容易にコピー アンド ペーストすることができます。 このイメージはプロセスを説明します:

 

認証方式

利用可能 な IP 許可を使用する、彼らは頻繁に、透過的な、受動 NTLM 間の特に違い誤解されます認証方式には 4 つの異なる型があり。 次の セクションは認証のこれらの型間の違いを記述します。

アクティブ NTLM

アクティブ NTLM 認証方式は透過的な NTLM 認証が失敗するとき認証のためのユーザをプロンプト表示します。 これは通常クライアント ブラウザが Microsoft Windows 統合された認証をサポートしないというまたはユーザがローカル(非ドメイン)資格情報が付いているワークステーションにログイン したので事実が原因です。 アクティブな NTLM 認証はドメインコントローラに提供された資格情報が正しいことを確認するために LDAP クエリを行います。

: NTLM 認証のすべての型によって、資格情報はクリアテキストによって渡されません。 ただし、NTLM バージョン 1 (NTLMv1)によくとり上げられる脆弱性があります。 ISR はデフォルトで、Microsoft Windows のより古いバージョンが NTLMv1 によってネゴシエートするかもしれませんが、NTLMv2-capable です。 この動作は AD 認証 ポリシーに依存しています。

透過的な NTLM

透過的な NTLM 認証はユーザがドメイン 資格情報が付いているワークステーション ログイン される、それらの資格情報は IOSルータにブラウザを透過的に通じますとき行われ。 IOSルータはそれからユーザーの資格情報を検証するために LDAP クエリを行います。 これは一般にこの機能のための望ましい認証方式です。

基本的な認証(クリアテキストの HTTP によって)

この認証方式は代替機構として一般的に NTLM 認証がマッキントッシュ、Linuxベース デバイス、またはモバイルデバイスのようなクライアントのために可能性のある失敗するか、またはではないとき使用されます。 この方式によって HTTP セキュアサーバが有効に ならなければ、そしてこれらの資格情報はクリアテキストの HTTP によって渡されます(非常に不確かな)。

受動 NTLM

ユーザからの受動 NTLM 認証要求 資格情報はドメインコントローラに対してしかし実際にユーザを認証しません。 これはクエリがドメインコントローラに対して失敗する LDAP 関連の問題を回避できる間、またセキュリティリスク--に環境のユーザをさらします。 透過的な認証が可能性のある失敗したか、またはではない場合、ユーザは資格情報のためにプロンプト表示されます。 ただし、ユーザは CWS タワーに通じる、選択する資格情報を入力することができます。 その結果、ポリシーは適切に適用されないかもしれません。

たとえば、ユーザ A は(追加設定なしではデフォルトで透過的な NTLM を可能にしない) Firefox 使用し、あらゆるパスワードでユーザ B のユーザ名を入力できユーザ B 向けのポリシーはユーザ A.に適用されます。 リスク公開はユーザがすべて透過的な NTLM 認証をサポートするが、ほとんどの場合、受動認証の使用は推奨されませんブラウザを使用させる場合軽減することができます。

アクティブな NTLM 認証のためのメッセージ シーケンス

アクティブ NTLM 認証方式のためのメッセージ全体 シーケンスはここにあります:

Browser -->  ISR : GET / google.com
Browser <--  ISR : 302 Page moved http://1.1.1.1/login.html
Browser -->  ISR : GET /login.html 1.1.1.1
Browser <--  ISR : 401 Unauthorized..Authenticate using NTLM
Browser -->  ISR : GET /login.html + NTLM Type-1 msg
ISR     -->  AD  : LDAP Bind Request + NTLM Type-1 msg

ISR はデータ変更なしで HTTP から LDAP にタイプ 1 メッセージを、バイトごとコピーします。

ISR     <--  AD  : LDAP Bind Response + NTLM Type-2 msg
Browser <--  ISR : 401 Unauthorized + NTLM Type-2 msg

タイプ 2 メッセージはまたバイトごと LDAP から HTTP へのコピーされます。 従って、PCAP で、それは 1.1.1.1 から起きるようですが実際のコンテンツは AD からあります。

Browser -->  ISR : GET /login.html + NTLM Type-3 msg
ISR     -->  AD  : LDAP Bind Request + NTLM Type-3 msg
ISR     <--  AD  : LDAP Bind response - Success
Browser <--  ISR : 200OK + redirect to google.com

アクティブ NTLM が設定されるとき、ISR は NTLM 交換の間に干渉しません。 ただし受動 NTLM が設定されれば、そして ISR は自身のタイプ 2 メッセージを生成します。

確認

現在、この設定に使用できる確認手順はありません。

トラブルシューティング

このセクションでは、設定のトラブルシューティングに役立つ情報を提供します。

show コマンド

アウトプット インタープリタ ツール登録ユーザ専用)は、特定の show コマンドをサポートしています。 show コマンド出力の分析を表示するには、アウトプット インタープリタ ツールを使用してください。

設定をトラブルシューティングするためにこれらの show コマンドを使用できます:

  • IP 許可 キャッシュを示して下さい
  • IP 許可ステータスを表示して下さい
  • IP 許可統計情報を表示して下さい
  • show ldap server all

debug コマンド

debug コマンドを使用する前に、『debug コマンドの重要な情報』を参照してください。

設定をトラブルシューティングするために使用できるいくつかの有用な debug コマンドはここにあります:

  • 全デバッグ LDAP はこのコマンド 認証が失敗するという原因を検出するために使用することができます。

  • debug ip 許可 詳細-このコマンドは非常に冗長、CPU 集中型です。 Cisco は IP 許可を引き起こす 単一 テスト クライアントとだけそれを使用することを推奨します。

  • debug ip 許可 ntlm -このコマンドは IP 許可 プロセスが引き起こされるという原因を検出するために使用することができます。

  • debug ip 許可 httpd

  • debug ip http トランザクション

  • debug aaa authentication debug aaa authorization

一般的な問題

このセクションはこの資料に説明がある設定と見つけられるいくつかのよくある 問題を記述します。

IP 許可は HTTP 要求を代行受信しません

この問題は提示 IP 許可 statistics コマンド出力を表示するとき明白になります。 出力はあらゆる HTTP 要求の遮断を示さないものです:

C-881#show ip admission statistics
Webauth HTTPd statistics:

HTTPd process 1
Intercepted HTTP requests: 0

考えられる解決策

この問題へ 2 つの可能 な 解決策があります。 第 1 は ip http server が有効に なることを確認することです。 

ISR のための HTTPサーバが有効に ならない場合、IP 許可は HTTPセッションを引き起こしませんが、決して実際に代行受信します。 従って、それは認証のためにプロンプト表示します。 この場合、提示 IP 許可 cache コマンドのための出力がありませんが、これらのラインの多くの再発は debug ip 許可 detail コマンドの出力で見られます:

*Jan 30 20:49:35.726: ip_admission_det:proceed with process path authentication
*Jan 30 20:49:35.726: AUTH-PROXY auth_proxy_find_conn_info :
find srcaddr - 10.10.10.152, dstaddr - 192.168.1.1
ip-srcaddr 10.20.10.1
pak-srcaddr 10.10.10.152

この問題への第 2 ソリューションはユーザ IP アドレスが IP 許可 設定の ACL から免除されていないことを確認することです。

ユーザは 404 Not Found エラーを受け取ります

この問題はユーザが認証のためにリダイレクトされる、404 Not Found エラーはブラウザで発生しますとき観察され。

考えられる解決策

IP 許可 バーチャルIP 1.1.1.1 バーチャル ホスト ISR_PROXY の名前がクライアント Domain Name System (DNS) サーバと問題なく解決することができるようにして下さい。 この場合、クライアントは lab.cisco.com がワークステーションが加入されるドメインの完全修飾ドメイン名 (FQDN)であるので ISR_PROXY.lab.cisco.com のための DNS クエリを行います。 DNS クエリが失敗した場合、クライアントはローカルサブネットへブロードキャストである NETBIOS クエリに先行しているリンク ローカル マルチキャスト 名前解決(LLMNR)クエリを送信します。 

これらの解決試みすべてが失敗した場合、404 Not FoundInternet Explorer はブラウザで表示する Web ページ エラーを表示することができません。 

ユーザ認証はプロンプト表示されてと失敗します

これはさまざまな原因によって引き起こされる場合がありますが、通常 ISR の LDAP設定、か ISR と LDAPサーバ間の通信と関連しています。 ISR で、現象は一般に一度 IP 許可が引き起こされる ユーザが INIT 状態でスタックしているとき観察されます:

C-881(config)#do show ip admi cac
Authentication Proxy Cache
Client Name N/A, Client IP 10.10.10.152, Port 56674, timeout 60,
  Time Remaining 2, state INIT

よくある原因

これらはこの問題のためのコモン コーズです:

  • 無効 な ユーザ名やパスワードはアクティブな認証のためのユーザによって入力されます。

  • 無効ベース dn は結果を返さない検索という結果に終る LDAP設定で使用されます。

  • 無効 なバインド認証ルート dn は LDAP バインドが失敗しますパスワード設定されます、かユーザ名のために。

  • ISR と LDAPサーバ間の通信は失敗します。 LDAPサーバが LDAP 通信を規定 された TCPポートで聞き取ること、そして 2 割り当て間のすべてのファイアウォール トラフィックことを確認して下さい。

  • 無効 な 検索フィルタにより LDAP 検索用の結果を引き起こしません。

LDAP を解決して下さい

認証が失敗するという理由を判別する最もよい方法は ISR で LDAP debug コマンドを利用することです。 過度な出力がある、によりルータはハードな電源の再投入をハングさせ、必要とします場合があります場合デバッグが ISR で動作してが高く、危ない場合もあることに留意すれば。 これは下端 プラットフォームについて言うことができます。 

解決するために、Cisco は認証にネットワークの単一テスト ワークステーションだけ服従させるために IP 許可ルールに ACL を適用することを推奨します。 こうすればはルータの機能への悪影響の最小リスクと、デバッグ トラフィックを通過させる有効に することができます。

ヒント: ACL のアプリケーションに関する詳細についてはこの資料の Authentication セクションから IP 許可 設定に免除されている内部ホストを参照して下さい。

LDAP 関連の問題を解決するとき、LDAP が ISR からの要求を処理するステップを理解することは有用です。 

LDAP認証のための高レベル ステップ

LDAP認証のための高レベル ステップはここにあります:

  1. 特定のポートの LDAPサーバへの接続を開いて下さい。 デフォルトポートは TCP 389 です。

  2. バインド認証するルート dn ユーザおよびパスワードで LDAPサーバへのバインド。

  3. LDAP設定で定義される検索フィルタおよび認証するように試みるユーザ向けのベース dn の使用と LDAP 検索を、行って下さい。

  4. 認証が正常、または資格情報のための reprompt を作成して下さい LDAPサーバからの LDAP 結果を得、認証失敗の場合にユーザ向けの IP 許可 キャッシュ エントリ。

LDAP デバッグ 出力 分析

これらのプロセスはデバッグ LDAP の出力ですべてのコマンド表示することができます。 このセクションは無効ベース dn が原因で失敗する認証に LDAP デバッグ 出力の例を提供します。  前述ステップが失敗にどこに直面するかもしれませんか示す出力の部分を記述する関連するコメント検討して下さい、およびデバッグ 出力を。

*Jan 30 20:51:50.818: LDAP: LDAP: Queuing AAA request 23 for processing
*Jan 30 20:51:50.818: LDAP: Received queue event, new AAA request
*Jan 30 20:51:50.818: LDAP: LDAP authentication request
*Jan 30 20:51:50.818: LDAP: Username sanity check failed
*Jan 30 20:51:50.818: LDAP: Invalid hash index 512, nothing to remove
*Jan 30 20:51:50.818: LDAP: New LDAP request
*Jan 30 20:51:50.818: LDAP: Attempting first next available LDAP server
*Jan 30 20:51:50.818: LDAP: Got next LDAP server :DC01
*Jan 30 20:51:50.818: LDAP: Free connection not available. Open a new one.
*Jan 30 20:51:50.818: LDAP: Opening ldap connection
( 10.10.10.150, 389 )ldap_open

太字で示されている出力の部分は接続がうまく開くのでこれがネットワーク層問題ではないことを示します。

*Jan 30 20:51:50.822: LDAP: Root Bind on CN=Csco_Service,CN=Users,DC=lab,
DC=cisco,DC=com initiated.
*Jan 30 20:51:51.330: LDAP: Ldap Result Msg: SUCCESS, Result code =0
*Jan 30 20:51:51.330: LDAP: Root DN bind Successful on :CN=Csco_Service,
CN=Users,DC=lab,DC=cisco,DC=com

バインド認証する dn はこの出力で正しいです。 設定がこれのために不正確である場合、バインド失敗は見られます。 

*Jan 30 20:51:51.846: LDAP: Received Bind Responseldap_parse_sasl_bind_result
*Jan 30 20:51:51.846: LDAP: Ldap SASL Result Msg: SUCCESS, Result code =14
sasLres_code =14
*Jan 30 20:51:51.846: LDAP: SASL NTLM authentication do not require
further tasks
*Jan 30 20:51:51.846: LDAP: Next Task: All authentication task completed
*Jan 30 20:51:51.846: LDAP: Transaction context removed from list
[ldap reqid=14]
*Jan 30 20:51:51.846: LDAP: * * AUTHENTICATION COMPLETED SUCCESSFULLY * *
*Jan 30 20:51:51.846: LDAP: Notifying AAA: REQUEST CHALLENGED

太字で示されている出力の部分はバインド操作すべてが正常であり、実際のユーザを捜すことを続行することを示します。

*Jan 30 20:51:51.854: LDAP: SASL NTLM authentication done..Execute search
*Jan 30 20:51:51.854: LDAP: Next Task: Send search req
*Jan 30 20:51:51.854: LDAP: Transaction context removed from list[ldap reqid=15]
*Jan 30 20:51:51.854: LDAP: Dynamic map configured
*Jan 30 20:51:51.854: LDAP: Dynamic map found for aaa type=username
*Jan 30 20:51:51.854: LDAP: Ldap Search Req sent
ld 2293572544
base dn dc=lab1,dc=cisco,dc=comscope 2
filter (&(objectclass=top)(sAMAccountName=testuser5))
ldap_req_encode
put_filter "(&(objectclass=top)(sAMAccountName=testuser5))"
put_filter: AND
put_filter_list "(objectclass=top)(sAMAccountName=testuser5)"
put_filter "(objectclass=top)"
put_filter: simple
put_filter "(sAMAccountName=testuser5)"
put_filter: simple
Doing socket write
*Jan 30 20:51:51.854: LDAP: lctx conn index = 2

最初の行は(太字で示されている) LDAP 検索デバッグ 出力が始まることを示します。 またベース dn ドメインコントローラがラボのために設定する必要があることに、ない lab1 注意して下さい。

*Jan 30 20:51:52.374: LDAP: LDAP Messages to be processed: 1
*Jan 30 20:51:52.374: LDAP: LDAP Message type: 101
*Jan 30 20:51:52.374: LDAP: Got ldap transaction context from reqid
16ldap_parse_result
*Jan 30 20:51:52.374: LDAP: resultCode: 10 (Referral)
*Jan 30 20:51:52.374: LDAP: Received Search Response resultldap_parse_result
ldap_err2string
*Jan 30 20:51:52.374: LDAP: Ldap Result Msg: FAILED:Referral, Result code =10
*Jan 30 20:51:52.374: LDAP: LDAP Search operation result : failedldap_msgfree
*Jan 30 20:51:52.374: LDAP: Closing transaction and reporting error to AAA
*Jan 30 20:51:52.374: LDAP: Transaction context removed from list
[ldap reqid=16]
*Jan 30 20:51:52.374: LDAP: Notifying AAA: REQUEST FAILED

太字で示されている出力の部分はこの場合無効ベース dn が原因である検索が結果を返さなかったことを示します。

RFC 4511

RFC 4511 (Lightweight Directory Access Protocol (LDAP): プロトコルは LDAP に) IETF Webサイトによって参照することができる結果コード メッセージについての情報および他の LDAP プロトコル関係の情報を提供します。


関連するシスコ サポート コミュニティ ディスカッション

シスコ サポート コミュニティは、どなたでも投稿や回答ができる情報交換スペースです。


Document ID: 117893