この製品のドキュメントセットは、偏向のない言語を使用するように配慮されています。このドキュメントセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブ ランゲージの取り組みの詳細は、こちらをご覧ください。
シスコは世界中のユーザにそれぞれの言語でサポート コンテンツを提供するために、機械と人による翻訳を組み合わせて、本ドキュメントを翻訳しています。ただし、最高度の機械翻訳であっても、専門家による翻訳のような正確性は確保されません。シスコは、これら翻訳の正確性について法的責任を負いません。原典である英語版(リンクからアクセス可能)もあわせて参照することを推奨します。
このドキュメントの目的は、Firepower Device Management(FDM)によって管理されるCisco Firepower Threat Defense(FTD)に接続するAnyConnectクライアントのActive Directory(AD)認証を設定する方法を詳しく説明します。 AnyConnectユーザを特定のIPアドレスおよびポートに制限するために、アクセスポリシーでユーザIDが使用されます。
次の項目に関する知識があることが推奨されます。
このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づいています。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期(デフォルト)設定の状態から起動しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
Windowsサーバには、ユーザーIDをテストするため、インターネットインフォメーションサービス(IIS)およびリモートデスクトッププロトコル(RDP)があらかじめ設定されています。この設定ガイドでは、3つのユーザアカウントと2つのグループが作成されます。
ユーザアカウント:
グループ:
FTDでAD認証とユーザIDを適切に設定するには、いくつかの値が必要です。FDMで構成を行う前に、これらの詳細をすべてMicrosoft Serverで作成または収集する必要があります。主な値は次のとおりです。
管理者がマーケティング組織ユニット内のユーザにベースDNを認証できるようにしたい場合は、ルート(example.com)に設定できます。ただし、これは、Finance組織ユニットのUser1もログインできます。これは、ユーザ検索がルートで始まり、Finance、Marketing、Researchに移動するためです。
ベースDNをexample.comに設定します。
ログインをマーケティング組織単位以下のユーザだけに制限するには、管理者がBase DNをMarketingに設定します。これで、User2とUser3のみが認証を実行できます。これは、検索がマーケティングで開始されるためです。
[Base DN set to Marketing]:
FTD内でより詳細な制御を行うために、ユーザが接続したり、AD属性に基づいて異なる許可をユーザに割り当てたりできるように、LDAP許可マップを設定する必要があることに注意してください。
この簡素化されたLDAP階層は、この設定ガイドで使用され、ルートexample.comのDNがベースDNに使用されます。
1. ADユーザーとコンピューターを開きます。
2.ルートドメイン(コンテナを開くには)を左クリックし、ルートドメインを右クリックして、[View]に移動し、[Advanced Features]をクリックします。
3.これにより、ADオブジェクトの下に追加のプロパティが表示されます。たとえば、ルートexample.comのDNを検索するには、example.comを右クリックして、Propertiesに移動します。
4. [プロパティ]の下の[属性エディタ]タブをクリックします。属性の下でdistinguishedNameを検索し、[表示]をクリックします。
5.これにより、新しいウィンドウが開き、DNを後でコピーしてFDMに貼り付けることができます。この例では、ルートDNはDC=example、DC=comです。値をコピーします。[OK]をクリックして[String Attribute Editor]ウィンドウを終了し、もう一度[OK]をクリックして[Properties]を終了します。
これは、AD内の複数のオブジェクトに対して実行できます。たとえば、ユーザコンテナのDNを検索するには、次の手順を使用します。
6. [拡張機能]ビューは削除できます。ルートDNを右クリックし、[View]に移動し、[Advanced Features]をもう一度クリックします。
このユーザアカウントを使用すると、FDMとFTDをADにバインドし、ユーザとグループを検索して認証できます。別のFTDアカウントを作成する目的は、バインディングに使用されるクレデンシャルが侵害された場合に、ネットワーク内の他の場所で不正アクセスを防止することです。このアカウントは、ベースDNの範囲内である必要はありません。
1. [Active Directory Users and Computers]で、FTDアカウントを追加するコンテナまたは組織を右クリックします。この構成では、FTDアカウントがユーザ名ftd.admin@example.comの下のUsersコンテナに追加されます。[Users]を右クリックし、[New] > [User]をクリックします。
2. 「新規オブジェクト – ユーザー」ウィザードをナビゲートします。
3. FTDアカウントが作成されたことを確認します。さらに、IT AdminとTest Userという2つの追加アカウントが作成されました。
認証に不要なグループを使用すると、アクセスポリシーを複数のユーザに簡単に適用したり、LDAP認可を適用したりできます。この構成ガイドでは、グループを使用して、後でFDM内のユーザーIDを介してアクセス制御ポリシー設定を適用します。
1. [Active Directory Users and Computers]で、新しいグループが追加されるコンテナ/組織を右クリックします。この例では、グループAnyConnect AdminsがUsersコンテナの下に追加されます。[ユーザー]を右クリックし、[新規作成] > [グループ]をクリックします。
2.図に示すように、New Object - Group Wizardをナビゲートします。
3.グループが作成されたことを確認します。AnyConnect Usersグループも作成されています。
4.ユーザーを追加するグループを右クリックし、「プロパティ」を選択します。この構成では、ユーザーIT AdminがグループAnyConnect Adminsに追加され、ユーザーTest UserがグループAnyConnect Usersに追加されます。
5.図に示すように、[メンバ]タブをクリックし、[追加]をクリックします。
フィールドにユーザを入力し、[Check Names]ボタンをクリックして、ユーザが見つかったことを確認します。確認したら、[OK]をクリックします。
正しいユーザーが追加されていることを確認し、[OK]ボタンをクリックします。同じ手順を使用して、ユーザTest UserをグループAnyConnect Usersに追加します。
1. Win+Rを押し、mmc.exeと入力します。[OK] をクリックします。
2. [ファイル] > [スナップインの追加と削除…]に移動します。 図に示すように
3.使用可能なスナップインの下で、[証明書]をクリックし、[追加]をクリックします。
4.図に示すように、[コンピュータアカウント]を選択し、[次へ]をクリックします。
[Finish] をクリックします。
5. 「OK」をクリックします。
6. [Personal]フォルダを展開し、[Certificates]をクリックします。LDAPSで使用される証明書は、Windowsサーバの完全修飾ドメイン名(FQDN)に発行する必要があります。このサーバには3つの証明書がリストされています。
この設定ガイドでは、FQDNはwin2016.example.comであるため、最初の2つの証明書はLDAPS SSL証明書として使用するには有効ではありません。win2016.example.comに発行されるID証明書は、Windows Server CAサービスによって自動的に発行された証明書です。証明書をダブルクリックして詳細を確認します。
7. LDAPS SSL証明書として使用するには、証明書が次の要件を満たしている必要があります。
証明書の[Details]タブの[Subject] と[Subject Alternative Name] に、FQDN win2016.example.comが表示されます。
[Enhanced Key Usage] の下に[Server Authentication]が表示されています。
8.確認したら、[Certification Path]タブに移動します。ルートCA証明書にする証明書の一番上をクリックし、[View Certificate]ボタンをクリックします。
9.これにより、ルートCA証明書の証明書の詳細が開きます。
10. [詳細]タブを開き、[ファイルにコピー…]をクリックします。 図に示すように
11.ルートCAをPEM形式でエクスポートする証明書エクスポートウィザードをナビゲートします。
12. Base-64 encoded X.509を選択します。
13.ファイルの名前とエクスポート先を選択します。
14. 「完了」をクリックします。
15.ここで、場所に移動し、メモ帳などのテキストエディタで証明書を開きます。PEM形式の証明書が表示されます。後で保存します。
-----BEGIN CERTIFICATE----- MIIDCDCCAfCgAwIBAgIQE4ZG5Z1wT6lONTjooEQyMTANBgkqhkiG9w0BAQsFADAd MRswGQYDVQQDExJleGFtcGxlLVdJTjIwMTYtQ0EwIBcNMjAwNDI3MTQ1MDU5WhgP MjA2MDA0MTkxNDUwNTlaMB0xGzAZBgNVBAMTEmV4YW1wbGUtV0lOMjAxNi1DQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAI8ghT719NzSQpoQPh0YT67b Ya+PngsxMyvkewP33QLTAWw1HW1Tb9Mk5BDWOItTaVsgHwPBfd++M+bLn3AiZnHV OO+k6dVVY/E5qVkEKSGoY+v940S2316lzdwReMOFhgbc2qMertIoficrRhihonuU Cjyeub3CO+meJUuKom2R47C0D35TUvo/FEHGgXJFaJS1se2UrpNO7KEMkfA1LPuM aob4XE/OzxYQpPa18djsNnskfcFqD/HOTFQN4+SrOhHWlRnUIQBUaLdQaabhipD/ sVs5PneYJX8YKma821uYI6j90YuytmsHBtCieyC062a8BKqOL7N86HFPFkMA3u8C AwEAAaNCMEAwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0O BBYEFD2fJjf7ER9EM/HCxCVFN5QzqEdvMA0GCSqGSIb3DQEBCwUAA4IBAQB31ZJo vzwVD3c5Q1nrNP+6Mq62OFpYH91k4Ch9S5g/CEOemhcwg8MDIoxW2dTsjenAEt7r phFIHZoCoSyjBjMgK3xybmoSeg8vBjCXseYNGEmOc9KW1oFmTOvdNVIb7Xpl1IVa 6tALTt3ANRNgREtxPA6yQbthKGavW0Anfsojk9IcDr2vp0MTjlBCxsTscbubRl+D dLEFKQqmMeYvkVf+a7a64mqPZsG3Uxo0rd6cZxAPkq/ylcdwNSJFfQV3DgZg+R96 9WLCR3Obig6xyo9Zu+lixcWpdrbADO6zMhbEYEhkhOOjBrUEBBI6Cy83iTZ9ejsk KgwBJXEu33PplW6E -----END CERTIFICATE-----
FDMでAnyConnectを設定するには、FTDをスマートライセンスサーバに登録し、有効なPlus、Apex、またはVPN Onlyライセンスをデバイスに適用する必要があります。
1.図に示すように、[Device] > [Smart License]に移動します。
2. FTDがスマートライセンスサーバに登録され、AnyConnect Plux、Apex、またはVPN Onlyライセンスが有効になっていることを確認します。
1. [Objects] > [Identity Sources]に移動し、+記号をクリックし、図に示すように[AD]を選択します。
2. Active Directoryサーバの適切な設定に、以前に収集した情報を入力します。IPアドレスの代わりにMicrosoftサーバにホスト名(FQDN)を使用する場合は、[Objects] > [DNS Group]で適切なDNSグループを必ず作成してください。次に、[Device] > [System Settings] > [DNS Server]に移動し、[Management Interface]および[Data Interface]でDNSグループを適用し、DNSクエリに適切な出力インターフェイスを指定して、そのDNSグループをFTDにに適用します。Testボタンをクリックして、FTDの管理インターフェイスから正常な設定と到達可能性を確認します。これらのテストはFTDの管理インターフェイスから開始され、FTDに設定されているルーティング可能インターフェイス(内部、外部、dmzなど)からは開始されないため、正常な(または失敗した)接続ではAnyConnect認証の結果は保証されません。FTDからのLDAP接続のテストの詳細については、「トラブルシューティング」領域の「AAAのテスト」および「パケットキャプチャ」の項を参照してください。
LDAPSまたはSTARTTLSを使用する場合は、適切な暗号化を選択し、信頼できるCA証明書を選択します。ルートCAがまだ追加されていない場合は、[Create New Trusted CA Certificate]をクリックします。ルートCA証明書の[Name]を指定し、先ほど収集したPEM形式のルートCA証明書を貼り付けます。
この設定では、次の値が使用されています。
3.図に示すように、右上の[Pending Changes]ボタンをクリックします。
4. [今すぐ展開]ボタンをクリックします。
設定されたAD IDソースを使用するには、AnyConnect設定に適用する必要があります。
1.図に示すように、[Device] > [Remote Access VPN]に移動します。
2.図に示すように、+記号または[接続プロファイルの作成]ボタンをクリックします。
3. [Connection and Client Configuration]セクションで、以前に作成したAD IDソースを選択します。[接続プロファイル名(Connection Profile Name)]や[クライアントアドレスプールの割り当て(Client Address Pool Assignment)]など、他のセクションに適切な値を設定します。完了したら[Submit Query]をクリックします。
4. [Remote User Experience]セクションで、適切なグループポリシーを選択します。デフォルトでは、DfltGrpPolicyが使用されます。ただし、別のものを作成できます。
5. [Global Settings]セクションで、少なくとも[SSL Certificate]、[Outside Interface]、および[AnyConnect]パッケージを指定します。証明書が以前に作成されていない場合は、デフォルトの自己署名証明書(DefaultInternalCertificate)を選択できますが、信頼できないサーバ証明書メッセージが表示されます。ユーザIDアクセスポリシーのルールが後で有効になるように、復号化されたトラフィック(sysopt permit-vpn)のBypass Access Control policyをオフにする必要があります。NAT免除は、ここでも設定できます。この設定では、AnyConnectクライアントのIPアドレスに向かう内部インターフェイスからのipv4トラフィックはすべて、NAT以外のものです。外部から外部へのヘアピニングなどのより複雑な設定では、NATポリシーの下に追加のNATルールを作成する必要があります。AnyConnectパッケージは、シスコのサポートサイトにあります。 https://software.cisco.com/download/homeAnyConnectパッケージをダウンロードするには、有効なPlusライセンスまたはApexライセンスが必要です。
6. [Summary]セクションで、AnyConnectが適切に設定されていることを確認し、[Submit Query]をクリックします。
7.図に示すように、右上の[Pending Changes]ボタンをクリックします。
8. [今すぐ展開]をクリックします。
この時点で、AnyConnectユーザは正常に接続できますが、特定のリソースにアクセスできない可能性があります。この手順では、ユーザIDを有効にして、AnyConnect Admins内のユーザだけがRDPを使用して内部リソースに接続でき、AnyConnect Usersグループ内のユーザだけがHTTPを使用して内部リソースに接続できるようにします。
1. [Policies] > [Identity]に移動し、[Enable Identity Policy]をクリックします。
この設定では、これ以上の設定は必要なく、デフォルトアクションで十分です。
2. [Policies] > [NAT] に移動し、NATが適切に設定されていることを確認します。AnyConnect設定で設定されたNAT例外で十分な場合、ここでは追加の設定は必要ありません。
3.[Policies] > [Access Control] に移動します。このセクションでは、[Default Action]が[Block]に設定されており、アクセスルールは作成されていないため、AnyConnectユーザが接続すると、何にもアクセスできなくなります。+記号または[アクセス規則の作成]をクリックして、新しい規則を追加します。
4.フィールドに適切な値を入力します。この設定では、AnyConnect Adminsグループ内のユーザは、内部ネットワーク内のWindows ServerにRDPアクセスできる必要があります。送信元の場合、ゾーンはoutside_zoneとして設定されます。これはAnyConnectユーザが接続する外部インターフェイスであり、ネットワークはAnyConnectクライアントにIPアドレスを割り当てるために以前に設定されたAnyConnect-Poolオブジェクトです。FDMのユーザーIDの場合、ソースはユーザーが接続を開始するゾーンとネットワークである必要があります。宛先に対して、ゾーンはWindows Serverの内部インターフェイスであるinside_zone、ネットワークはWindows Serverのサブネットを定義するオブジェクトであるInside_Netオブジェクト、ポート/プロトコルは2つのカスタムポートオブジェクトに設定され、TCP 3389とUDP 3389で9への8への8RDP8アクセス8を8を8を8可能8可能8に89
[Users]セクションで、グループAnyConnect Adminsが追加され、このグループ以外のユーザはWindows ServerへのRDPアクセスが許可されます。+記号をクリックし、[グループ]タブをクリックし、該当するグループをクリックして、[OK]をクリックします。個々のユーザとアイデンティティソースも選択できます。
適切なオプションを選択したら、[OK]をクリックします。
5.必要に応じて、さらにアクセスルールを作成します。この設定では、AnyConnect Usersグループ内のユーザがWindows ServerにHTTPアクセスできるように、別のアクセスルールが作成されます。
6.アクセスルールの設定を確認し、図に示すように、右上の[Pending Changes]ボタンをクリックします。
7.変更を確認し、[今すぐ展開]をクリックします。
ここでは、設定が正常に機能しているかどうかを確認します。
AAA 設定
show running-configuration aaa-server
aaa-server LAB-AD protocol ldap realm-id 7 aaa-server LAB-AD host win2016.example.com server-port 389 ldap-base-dn DC=example,DC=com ldap-scope subtree ldap-login-password ***** ldap-login-dn ftd.admin@example.com server-type auto-detect
AnyConnectの設定
> show running-config webvpn webvpn enable outside http-headers hsts-server enable max-age 31536000 include-sub-domains no preload hsts-client enable x-content-type-options x-xss-protection content-security-policy anyconnect image disk0:/anyconnpkgs/anyconnect-linux64-4.7.03052-webdeploy-k9.pkg 1 anyconnect image disk0:/anyconnpkgs/anyconnect-win-4.7.03052-webdeploy-k9.pkg 2 anyconnect enable tunnel-group-list enable cache disable error-recovery disable > show running-config tunnel-group tunnel-group General type remote-access tunnel-group General general-attributes address-pool AnyConnect-Pool authentication-server-group LAB-AD tunnel-group General webvpn-attributes group-alias General enable > show running-config group-policy group-policy DfltGrpPolicy attributes vpn-tunnel-protocol ssl-client split-tunnel-policy tunnelspecified split-tunnel-network-list value DfltGrpPolicy|splitAcl webvpn anyconnect ssl dtls none > show running-config ssl ssl trust-point FTD-3-Manual outside
ユーザIT Adminは、Windows ServerにRDPアクセスできるグループAnyConnect Adminsに属していますが、HTTPにアクセスできません。このサーバーに対してRDPおよびFirefoxセッションを開くと、このユーザーはRDP経由でのみサーバーにアクセスできます。
HTTPアクセスを持ち、RDPアクセスを持たないグループAnyConnect Usersに属するテストユーザでログインした場合、アクセスコントロールポリシールールが有効であることを確認できます。
ここでは、設定が正常に機能しているかどうかを確認します。
このデバッグは、LDAP認証に関連する問題をトラブルシューティングするために、診断CLIで実行できます。debug ldap 255を使用します。
ユーザIDのアクセスコントロールポリシーの問題をトラブルシューティングするために、system support firewall-engine-debugをclishで実行し、トラフィックが予期せず許可またはブロックされる理由を判別できます。
[53] Session Start [53] New request Session, context 0x00002b1d13f4bbf0, reqType = Authentication [53] Fiber started [53] Creating LDAP context with uri=ldap://192.168.1.1:389 [53] Connect to LDAP server: ldap://192.168.1.1:389, status = Successful [53] supportedLDAPVersion: value = 3 [53] supportedLDAPVersion: value = 2 [53] LDAP server 192.168.1.1 is Active directory [53] Binding as ftd.admin@example.com [53] Performing Simple authentication for ftd.admin@example.com to 192.168.1.1 [53] LDAP Search: Base DN = [DC=example,DC=com] Filter = [sAMAccountName=it.admin] Scope = [SUBTREE] [53] User DN = [CN=IT Admin,CN=Users,DC=example,DC=com] [53] Talking to Active Directory server 192.168.1.1 [53] Reading password policy for it.admin, dn:CN=IT Admin,CN=Users,DC=example,DC=com [53] Read bad password count 6 [53] Binding as it.admin [53] Performing Simple authentication for it.admin to 192.168.1.1 [53] Processing LDAP response for user it.admin [53] Message (it.admin): [53] Authentication successful for it.admin to 192.168.1.1 [53] Retrieved User Attributes: [53] objectClass: value = top [53] objectClass: value = person [53] objectClass: value = organizationalPerson [53] objectClass: value = user [53] cn: value = IT Admin [53] sn: value = Admin [53] givenName: value = IT [53] distinguishedName: value = CN=IT Admin,CN=Users,DC=example,DC=com [53] instanceType: value = 4 [53] whenCreated: value = 20200421025811.0Z [53] whenChanged: value = 20200421204622.0Z [53] displayName: value = IT Admin [53] uSNCreated: value = 25896 [53] memberOf: value = CN=AnyConnect Admins,CN=Users,DC=example,DC=com [53] uSNChanged: value = 26119 [53] name: value = IT Admin [53] objectGUID: value = &...J..O..2w...c [53] userAccountControl: value = 512 [53] badPwdCount: value = 6 [53] codePage: value = 0 [53] countryCode: value = 0 [53] badPasswordTime: value = 132320354378176394 [53] lastLogoff: value = 0 [53] lastLogon: value = 0 [53] pwdLastSet: value = 132319114917186142 [53] primaryGroupID: value = 513 [53] objectSid: value = .............{I...;.....j... [53] accountExpires: value = 9223372036854775807 [53] logonCount: value = 0 [53] sAMAccountName: value = it.admin [53] sAMAccountType: value = 805306368 [53] userPrincipalName: value = it.admin@example.com [53] objectCategory: value = CN=Person,CN=Schema,CN=Configuration,DC=example,DC=com [53] dSCorePropagationData: value = 16010101000000.0Z [53] lastLogonTimestamp: value = 132319755825875876 [53] Fiber exit Tx=515 bytes Rx=2659 bytes, status=1 [53] Session End
[-2147483611] Session Start [-2147483611] New request Session, context 0x00007f9e65ccdc40, reqType = Authentication [-2147483611] Fiber started [-2147483611] Creating LDAP context with uri=ldap://171.16.1.1:389 [-2147483611] Connect to LDAP server: ldap://172.16.1.1:389, status = Failed [-2147483611] Unable to read rootDSE. Can't contact LDAP server. [-2147483611] Fiber exit Tx=0 bytes Rx=0 bytes, status=-2 [-2147483611] Session End
潜在的なソリューション:
[-2147483615] Session Start [-2147483615] New request Session, context 0x00007f9e65ccdc40, reqType = Authentication [-2147483615] Fiber started [-2147483615] Creating LDAP context with uri=ldap://192.168.1.1:389 [-2147483615] Connect to LDAP server: ldap://192.168.1.1:389, status = Successful [-2147483615] defaultNamingContext: value = DC=example,DC=com [-2147483615] supportedLDAPVersion: value = 3 [-2147483615] supportedLDAPVersion: value = 2 [-2147483615] LDAP server 192.168.1.1 is Active directory [-2147483615] supportedSASLMechanisms: value = GSSAPI [-2147483615] supportedSASLMechanisms: value = GSS-SPNEGO [-2147483615] supportedSASLMechanisms: value = EXTERNAL [-2147483615] supportedSASLMechanisms: value = DIGEST-MD5 [-2147483615] Binding as ftd.admin@example.com [-2147483615] Performing Simple authentication for ftd.admin@example.com to 192.168.1.1 [-2147483615] Simple authentication for ftd.admin@example.com returned code (49) Invalid credentials [-2147483615] Failed to bind as administrator returned code (-1) Can't contact LDAP server [-2147483615] Fiber exit Tx=186 bytes Rx=744 bytes, status=-2 [-2147483615] Session End
考えられる解決策:ログインDNとログインパスワードが適切に設定されていることを確認します。これは、ADサーバでldp.exeを使用して確認できます。アカウントがldpを使用して正常にバインドできることを確認するには、次の手順を実行します。
1. ADサーバーでWin+Rを押し、ldp.exeを検索します。
2. [接続] > [接続]をクリックします。 図に示すように
3.サーバーにlocalhostと適切なポートを指定し、「OK」をクリックします。
4. [Right]列には、接続が成功したことを示すテキストが表示されます。「接続」>「バインド」をクリックします。 図に示すように
5. 「簡易バインド」を選択し、ディレクトリ・アカウントのユーザー名とパスワードを指定します。[OK] をクリックします。
バインドが成功すると、ldpはDOMAIN\usernameとしてAuthenticatedと表示されます。
無効なユーザ名またはパスワードを使用してバインドしようとすると、次のようなエラーが発生します。
[-2147483612] Session Start [-2147483612] New request Session, context 0x00007f9e65ccdc40, reqType = Authentication [-2147483612] Fiber started [-2147483612] Creating LDAP context with uri=ldap://192.168.1.1:389 [-2147483612] Connect to LDAP server: ldap://192.168.1.1:389, status = Successful [-2147483612] supportedLDAPVersion: value = 3 [-2147483612] supportedLDAPVersion: value = 2 [-2147483612] LDAP server 192.168.1.1 is Active directory [-2147483612] Binding as ftd.admin@example.com [-2147483612] Performing Simple authentication for ftd.admin@example.com to 192.168.1.1 [-2147483612] LDAP Search: Base DN = [dc=example,dc=com] Filter = [samaccountname=it.admi] Scope = [SUBTREE] [-2147483612] Search result parsing returned failure status [-2147483612] Talking to Active Directory server 192.168.1.1 [-2147483612] Reading password policy for it.admi, dn: [-2147483612] Binding as ftd.admin@example.com [-2147483612] Performing Simple authentication for ftd.admin@example.com to 192.168.1.1 [-2147483612] Fiber exit Tx=456 bytes Rx=1082 bytes, status=-1 [-2147483612] Session End
考えられる解決策:ADがFTDによる検索でユーザを検索できることを確認します。これは、ldp.exeでも実行できます。
1.バインドが正常に完了したら、図に示すように[View] > [Tree]に移動します。
2. FTDに設定されているベースDNを指定し、[OK]をクリックします。
3. [Base DN]を右クリックし、図に示すように[Search]をクリックします。
4.デバッグに示されているのと同じベースDB、フィルタ、スコープの値を指定します。この例では、次の項目を示します。
ldpは、samaccountname=it.admiのユーザアカウントがベースDN dc=example,dc=comに存在しないため、0エントリを見つけます。
正しいsamaccountname=it.adminを使用して再試行すると、結果が異なります。ldpは、ベースDN dc=example,dc=comの下に1つのエントリを見つけ、そのユーザのDNを出力します。
[-2147483613] Session Start [-2147483613] New request Session, context 0x00007f9e65ccdc40, reqType = Authentication [-2147483613] Fiber started [-2147483613] Creating LDAP context with uri=ldap://192.168.1.1:389 [-2147483613] Connect to LDAP server: ldap://192.168.1.1:389, status = Successful [-2147483613] supportedLDAPVersion: value = 3 [-2147483613] supportedLDAPVersion: value = 2 [-2147483613] LDAP server 192.168.1.1 is Active directory [-2147483613] Binding as ftd.admin@example.com [-2147483613] Performing Simple authentication for ftd.admin@example.com to 192.168.1.1 [-2147483613] LDAP Search: Base DN = [dc=example,dc=com] Filter = [samaccountname=it.admin] Scope = [SUBTREE] [-2147483613] User DN = [CN=IT Admin,CN=Users,DC=example,DC=com] [-2147483613] Talking to Active Directory server 192.168.1.1 [-2147483613] Reading password policy for it.admin, dn:CN=IT Admin,CN=Users,DC=example,DC=com [-2147483613] Read bad password count 0 [-2147483613] Binding as it.admin [-2147483613] Performing Simple authentication for it.admin to 192.168.1.1 [-2147483613] Simple authentication for it.admin returned code (49) Invalid credentials [-2147483613] Message (it.admin): 80090308: LdapErr: DSID-0C09042A, comment: AcceptSecurityContext error, data 52e, v3839 [-2147483613] Invalid password for it.admin [-2147483613] Fiber exit Tx=514 bytes Rx=2764 bytes, status=-1 [-2147483613] Session End
考えられる解決策:ユーザのパスワードが適切に設定され、期限が切れていないことを確認します。Login DNと同様に、FTDはユーザのクレデンシャルを使用してADに対してバインドを実行します。このバインドは、ADが同じユーザ名とパスワードのクレデンシャルを認識できることを確認するために、ldpでも実行できます。ldpの手順は、「ログインDNのバインド」セクションと「パスワードが正しくない」セクションのいずれかまたは両方で示されています。さらに、Microsoftサーバのイベントビューアのログを確認して、潜在的な理由を調べることができます。
test aaa-serverコマンドを使用すると、FTDから特定のユーザ名とパスワードを使用した認証の試みをシミュレートできます。これは、接続または認証の失敗をテストするために使用できます。コマンドはtest aaa-server authentication [AAA-server] host [AD IP/hostname]です。
> show running-configuration aaa-server aaa-server LAB-AD protocol ldap realm-id 7 aaa-server LAB-AD host win2016.example.com server-port 389 ldap-base-dn DC=example,DC=com ldap-scope subtree ldap-login-password ***** ldap-login-dn ftd.admin@example.com server-type auto-detect > test aaa-server authentication LAB-AD host win2016.example.com Username: it.admin Password: ******** INFO: Attempting Authentication test to IP address (192.168.1.1) (timeout: 12 seconds) INFO: Authentication Successful
パケットキャプチャは、ADサーバへの到達可能性を確認するために使用できます。LDAPパケットがFTDから送信されても応答がない場合は、ルーティングの問題を示している可能性があります。
双方向LDAPトラフィックを示すキャプチャを次に示します。
> show route 192.168.1.1 Routing entry for 192.168.1.0 255.255.255.0 Known via "connected", distance 0, metric 0 (connected, via interface) Routing Descriptor Blocks: * directly connected, via inside Route metric is 0, traffic share count is 1 > capture AD interface inside match tcp any host 192.168.1.1 eq 389 > show capture capture AD type raw-data interface inside [Capturing - 0 bytes] match tcp any host 192.168.1.1 eq ldap > test aaa-server authentication LAB-AD host win2016.example.com username it.admin password ****** INFO: Attempting Authentication test to IP address (192.168.1.1) (timeout: 12 seconds) INFO: Authentication Successful > show capture capture AD type raw-data interface inside [Capturing - 10905 bytes] match tcp any host 192.168.1.1 eq ldap > show capture AD 54 packets captured 1: 23:02:16.770712 192.168.1.17.61960 > 192.168.1.1.389: S 3681912834:3681912834(0) win 32768 <mss 1460,nop,nop,timestamp 1061373057 0> 2: 23:02:16.772009 192.168.1.1.389 > 192.168.1.17.61960: S 491521506:491521506(0) ack 3681912835 win 8192 <mss 1460,nop,nop,timestamp 762393884 1061373057> 3: 23:02:16.772039 192.168.1.17.61960 > 192.168.1.1.389: . ack 491521507 win 32768 <nop,nop,timestamp 1061373058 762393884> 4: 23:02:16.772482 192.168.1.17.61960 > 192.168.1.1.389: P 3681912835:3681912980(145) ack 491521507 win 32768 <nop,nop,timestamp 1061373059 0> 5: 23:02:16.772924 192.168.1.1.389 > 192.168.1.17.61960: P 491521507:491522141(634) ack 3681912980 win 65160 <nop,nop,timestamp 762393885 1061373059> 6: 23:02:16.772955 192.168.1.17.61960 > 192.168.1.1.389: . ack 491522141 win 32768 <nop,nop,timestamp 1061373059 762393885> 7: 23:02:16.773428 192.168.1.17.61960 > 192.168.1.1.389: P 3681912980:3681913024(44) ack 491522141 win 32768 <nop,nop,timestamp 1061373060 0> 8: 23:02:16.775030 192.168.1.1.389 > 192.168.1.17.61960: P 491522141:491522163(22) ack 3681913024 win 65116 <nop,nop,timestamp 762393887 1061373060> 9: 23:02:16.775075 192.168.1.17.61960 > 192.168.1.1.389: . ack 491522163 win 32768 <nop,nop,timestamp 1061373061 762393887> [...] 54 packets shown
ADサーバのバンに関するイベントビューアのログには、障害が発生した理由に関する詳細情報が記載されています。
1.イベントビューアを検索して開きます。
2. [Windows Logs]を展開し、[Security]をクリックします。図に示すように、ユーザーのアカウント名で[Audit Failure]を検索し、[Failure Information]を確認します。
An account failed to log on. Subject: Security ID: SYSTEM Account Name: WIN2016$ Account Domain: EXAMPLE Logon ID: 0x3E7 Logon Type: 3 Account For Which Logon Failed: Security ID: NULL SID Account Name: it.admin Account Domain: EXAMPLE Failure Information: Failure Reason: The specified user account has expired. Status: 0xC0000193 Sub Status: 0x0 Process Information: Caller Process ID: 0x25c Caller Process Name: C:\Windows\System32\lsass.exe Network Information: Workstation Name: WIN2016 Source Network Address: 192.168.1.17 Source Port: 56321