この製品のドキュメントセットは、偏向のない言語を使用するように配慮されています。このドキュメントセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブ ランゲージの取り組みの詳細は、こちらをご覧ください。
シスコは世界中のユーザにそれぞれの言語でサポート コンテンツを提供するために、機械と人による翻訳を組み合わせて、本ドキュメントを翻訳しています。ただし、最高度の機械翻訳であっても、専門家による翻訳のような正確性は確保されません。シスコは、これら翻訳の正確性について法的責任を負いません。原典である英語版(リンクからアクセス可能)もあわせて参照することを推奨します。
このドキュメントでは、Firepower Threat Defense(FTD)に接続するAnyConnectクライアントのActive Directory(AD)認証を設定する方法について説明します。
次の項目に関する知識があることが推奨されます。
このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づいています。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな(デフォルト)設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
このドキュメントでは、Firepower Threat Defense(FTD)に接続し、Firepower Management Center(FMC)で管理するAnyConnectクライアントのActive Directory(AD)認証を設定する方法について説明します。
ユーザIDは、AnyConnectユーザを特定のIPアドレスとポートに制限するためにアクセスポリシーで使用されます。
Windowsサーバでは、ユーザIDをテストするためにIISとRDPが事前設定されています。この設定ガイドでは、3つのユーザアカウントと2つのグループが作成されます。
ユーザアカウント:
グループ:
FTDでAD認証とユーザIDを適切に設定するには、いくつかの値が必要です。
これらの詳細はすべて、FMCで設定を行う前にMicrosoftサーバで作成または収集する必要があります。主な値は次のとおりです。
これはサーバのドメイン名です。このコンフィギュレーションガイドでは、example.comがドメイン名です。
Microsoftサーバに到達するために使用されるIPアドレスまたはFQDN。FQDNを使用する場合は、FQDNを解決するためにDNSサーバをFMCおよびFTD内で設定する必要があります。
このコンフィギュレーションガイドでは、この値はwin2016.example.com(192.168.1.1に解決される)です。
LDAPサービスが使用するポート。デフォルトでは、LDAPおよびSTARTTLSはLDAPにTCPポート389を使用し、LDAP over SSL(LDAPS)はTCPポート636を使用します。
LDAPSまたはSTARTTLSを使用する場合、LDAPSで使用するSSL証明書の署名に使用するルートCAが必要です。
これは、LDAPサーバにバインドし、ユーザを認証し、ユーザとグループを検索するためにFMCとFTDによって使用されるアカウントです。
この目的のために、FTD Adminという名前のアカウントが作成されます。
ベースDNはFMCの開始点で、FTDはActive Directoryに対してユーザの検索と認証を開始するように指示します。
同様に、グループDNは、FMCがActive DirectoryにユーザIDのグループ検索を開始する場所を指示する開始点です。
このコンフィギュレーションガイドでは、ルートドメインexample.comがベースDNおよびグループDNとして使用されます。
ただし、実稼働環境の場合は、LDAP階層内のベースDNとグループDNを使用する方が適しています。
たとえば、次のLDAP階層があります。
管理者が、Marketing組織単位(OU)内のユーザがベースDNを認証できるようにする必要がある場合は、ルート(example.com)に設定できます。
ただし、これによってFinance組織単位(OU)の下のUser1もログインできます。これは、ユーザ検索がルートから始まり、Finance、Marketing、およびResearchに移動するためです。
ベースDNをexample.comに設定
ログインをMarketing組織単位(OU)以下の唯一のユーザに制限するために、管理者はベースDNをMarketingに設定できます。
Marketingで検索が開始されるため、ここで認証できるのはUser2とUser3だけです。
ベースDNをMarketingに設定
ユーザが接続を許可される、またはユーザにAD属性に基づいた異なる許可を割り当てる、FTD内でのさらに細かい制御のために、LDAP認可マップを設定する必要があることに注意してください。
詳細については、「Firepower Threat Defense(FTD)でのAnyConnect LDAPマッピングの設定」を参照してください。
この簡素化されたLDAP階層がこの設定ガイドで使用され、ルートexample.comのDNがベースDNとグループDNの両方に使用されます。
1. Active Directory Users and Computersを開きます。
2. ルートドメインをクリックし(コンテナを開く)、次にルートドメインを右クリックして、表示の下で、拡張機能をクリックします。
3. これにより、ADオブジェクトの下に追加のプロパティを表示できます。たとえば、ルートexample.comのDNを検索するには、example.comを右クリックしてPropertiesを選択します。
4. 「プロパティ」で、「属性エディタ」タブを選択します。Attributesの下でdistinguishedNameを探し、Viewをクリックします。
5. 新しいウィンドウが開き、DNをコピーして後でFMCに貼り付けることができます。この例では、ルートDNはDC=example,DC=comです。
値をコピーして、後で使用するために保存します。OKをクリックしてString Attribute Editorウィンドウを終了し、もう一度OKをクリックしてPropertiesを終了します。
これは、Active Directory内の複数のオブジェクトに対して実行できます。たとえば、次の手順を使用してUserコンテナのDNを検索します。
6. [Advanced Features] ビューは、ルートDNを再度右クリックし、[View]の下の[Advanced Features]をもう一度クリックして削除できます。
このユーザアカウントを使用すると、FMCとFTDがActive Directoryとバインドして、ユーザとグループを検索し、ユーザを認証できます。
別のFTDアカウントを作成する目的は、バインディングに使用されるクレデンシャルが侵害された場合に、ネットワーク内の他の場所への不正アクセスを防止することです。
このアカウントは、ベースDNまたはグループDNの範囲内にある必要はありません。
1. Active Directory User and Computersで、FTDアカウントが追加されているコンテナ/組織を右クリックします。
この設定では、ユーザ名ftd.admin@example.comの下のUsersコンテナにFTDアカウントが追加されます。
Usersを右クリックし、New > Userに移動します。
2. 「新規オブジェクト – ユーザー」ウィザードを実行します。
3. FTDアカウントが作成されたことを確認します。さらに、IT管理者とテストユーザの2つのアカウントが作成されます。
認証には不要ですが、グループを使用すると、複数のユーザへのアクセスポリシーの適用やLDAP認可が容易になります。
このコンフィギュレーションガイドでは、グループを使用して、後でFMC内のユーザIDを通じてアクセスコントロールポリシー設定を適用します。
1. Active Directoryユーザーとコンピューターで、新しいグループが追加されるコンテナーまたは組織単位を右クリックします。
この例では、AnyConnect AdminsグループがUsersコンテナの下に追加されています。Usersを右クリックし、New > Groupに移動します。
2. 「新規オブジェクト – グループ」ウィザードを実行します。
3. グループが作成されたことを確認します。AnyConnect Usersグループも作成されます。
4. ユーザのグループを右クリックし、Propertiesを選択します。この設定では、ユーザIT AdminをグループAnyConnect Adminsに追加し、ユーザTest UserをグループAnyConnect Usersに追加します。
5. 「メンバー」タブで、「追加」をクリックします。
フィールドにユーザを入力し、Check Namesをクリックして、そのユーザが見つかったことを確認します。確認したら、OKをクリックします。
正しいユーザが追加されていることを確認し、OKをクリックします。同じ手順で、Test UserユーザをAnyConnect Usersグループに追加します。
1. Win+Rを押して、mmc.exeと入力します。次に [OK] をクリックします。
2. File > Add/Remove Snap-inの順に移動します。
3. Available snap-insでCertificatesを選択し、Addをクリックします。
4. Computer accountを選択し、Nextをクリックします。
[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証明書の証明書の詳細が開きます。
Detailsタブで、Copy to Fileをクリックします。
10.証明書のエクスポートウィザードを実行します。ウィザードは、ルートCAをPEM形式でエクスポートします。
Base-64 encoded X.509を選択します。
ファイルの名前とエクスポート先を選択します。
Finishをクリックします。
11. その場所に移動し、メモ帳などのテキストエディタで証明書を開きます。これは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-----
12. (オプション)LDAPSで使用できるID証明書が複数あり、どれが使用されているかが不明な場合、またはLDAPSサーバへのアクセスがない場合は、WindowsサーバまたはFTDで実行後にパケットキャプチャを実行すると、ルートcaを抽出できます。
AnyConnect設定を導入するには、FTDがスマートライセンスサーバに登録され、有効なPlus、Apex、またはVPN Onlyライセンスがデバイスに適用されている必要があります。
1. [システム] > [ライセンス] > [スマートライセンス] に移動します。
2. デバイスが準拠し、正常に登録されていることを確認します。デバイスがAnyConnect Apex、Plus、またはVPN Onlyライセンスで登録されていることを確認します。
1. 「システム」>「統合」にナビゲートします。
2. [Realms]で、[New realm]をクリックします。
3. Microsoftサーバから収集した情報に基づいて、該当するフィールドに入力します。次に [OK] をクリックします。
4. 新しいウィンドウでDirectoryを選択し(まだ選択していない場合)、Add directoryをクリックします。
ADサーバの詳細を入力します。FQDNが使用される場合、FQDNを解決するようにDNSが設定されていない限り、FMCとFTDは正常にバインドできません。
FMC用にDNSをセットアップするには、System > Configurationの順に移動し、Management Interfacesを選択します。
FTDのDNSを設定するには、Devices > Platform Settingsの順に移動し、新しいポリシーを作成するか、現在のポリシーを編集してからDNSに移動します。
LDAPSまたはSTARTTLSを使用する場合、緑色の+(プラス)記号をクリックして証明書に名前を付け、PEM形式のルートCA証明書をコピーします。次に [Save] をクリックします。
SSL Certificateの横のドロップダウンメニューから新しく追加したルートCAを選択し、STARTTLSまたはLDAPSをクリックします。
Testをクリックし、FMCが前の手順で指定したDirectory UsernameとPasswordに正常にバインドできることを確認します。
これらのテストは、FTDに設定されたルーティング可能なインターフェイス(inside、outside、dmzなど)の1つではなく、FMCから開始されるため、接続の成功(または失敗)はAnyConnect認証の同じ結果を保証しません。これは、AnyConnect LDAP認証要求がFTDのルーティング可能なインターフェイスの1つから開始されるためです。
FTDからのLDAP接続テストの詳細については、「トラブルシューティング」領域の「AAAのテスト」および「パケットキャプチャ」の項を参照してください。
5. 「ユーザーのダウンロード」で、後の手順でユーザーIDに使用するグループをダウンロードします。
Download users and groupsのチェックボックスをオンにし、Available Groupsの列にActive Directory内で設定されたグループが移入されます。
グループは含めるか除外することができますが、デフォルトではグループDNの下にあるすべてのグループが含まれます。
特定のユーザを含めることも、除外することもできます。含まれているグループとユーザは、後でユーザIDとして選択できます。
終了したら、Saveをクリックします。
6. 新しいレルムを有効にします。
7. LDAPSまたはSTARTTLSを使用する場合、ルートCAもFTDによって信頼される必要があります。これを行うには、最初にDevices > Certificatesの順に移動します。
右上のAddをクリックします。
FTDを選択すると、LDAP設定がに追加され、+(プラス)記号をクリックします。
トラストポイントに名前を指定し、Enrollment TypeドロップダウンメニューからManual enrollmentを選択します。PEMルートCA証明書をここに貼り付け、Saveをクリックします。
作成したトラストポイントが選択されていることを確認し、Addをクリックします。
新しいトラストポイントがFTDの下に表示されます。アイデンティティ証明書のインポートが必要であると記載されていますが、FTDがLDAPSサーバによって送信されたSSL証明書を認証する必要はありません。したがって、このメッセージは無視できます。
1. これらの手順では、リモートアクセスVPNポリシーがすでに作成されていないことを前提としています。ポリシーが作成されている場合は、そのポリシーの編集ボタンをクリックしてステップ3に進みます。
Devices > VPN > Remote Accessの順に移動します。
Addをクリックして、新しいリモートアクセスVPNポリシーを作成します
2.リモートアクセスVPNポリシーウィザードを完了します。Policy Assignmentで、ポリシーの名前とポリシーが適用されるデバイスを指定します。
Connection Profileで、Connection Profileの名前を指定します。この名前は、AnyConnectユーザが接続したときに表示されるグループエイリアスとしても使用されます。
以前にAuthentication Serverの下に作成したレルムを指定します。
AnyConnectクライアントにIPアドレスを割り当てる方法を指定します。
この接続プロファイルに使用されるデフォルトのグループポリシーを指定します。
AnyConnectで、使用するAnyConnectパッケージをアップロードして指定します。
Access & Certificateで、AnyConnectユーザがAnyConnect用にアクセスするインターフェイスを指定します。
SSLハンドシェイク中にFTDによって使用される証明書を作成または指定します。
復号化されたトラフィックのBypass Access Control policy(sysopt permit-vpn)のチェックボックスがオフになっていることを確認して、後で作成されたユーザIDがRAVPN接続に対して有効になるようにします。
Summaryの下で設定を確認し、Finishをクリックします。
3.VPN > Remote Accessポリシーで、該当する接続プロファイルの編集アイコン(鉛筆)をクリックします。
認証サーバが、先ほど作成したレルムに設定されていることを確認します。
Advanced SettingsでEnable Password Managementにチェックマークを入れると、ユーザはパスワードの有効期限が切れる前または切れた時点でパスワードを変更できます。
ただし、この設定では、レルムがLDAPSを使用する必要があります。変更が加えられた場合は、Saveをクリックします。
終了したら、Saveをクリックします。
1. Policies > Access Control > Identityの順に移動します。
新しいアイデンティティポリシーを作成します。
新しいアイデンティティポリシーの名前を指定します。
2. Add Ruleをクリックします。
3. 新しいルールの名前を指定します。これが有効で、アクションがパッシブ認証に設定されていることを確認します。
Realm & Settingsタブをクリックし、先ほど作成したレルムを選択します。終了したら、Addをクリックします。
4. Saveをクリックします。
5. Policies > Access Control > Access Controlの順に移動します。
6. FTDが設定されているアクセスコントロールポリシーを編集します。
7. 「アイデンティティポリシー」の横の値をクリックします。
以前に作成したアイデンティティポリシーを選択し、OKをクリックします。
8. Add Ruleをクリックして、新しいACPルールを作成します。これらの手順では、AnyConnect Adminsグループ内のユーザがRDPを使用して内部ネットワーク内のデバイスに接続することを許可するルールを作成します。
ルールの名前を指定します。ルールが有効になっており、適切なアクションが設定されていることを確認します。
Zonesタブで、対象トラフィックに適切なゾーンを指定します。
ユーザによって開始されたRDPトラフィックは、外部ゾーンインターフェイスから発信されたFTDに入り、内部ゾーンから出ます。
Networksで、送信元ネットワークと宛先ネットワークを定義します。
オブジェクトAnyConnect_Poolには、AnyConnectクライアントに割り当てられたIPアドレスが含まれています。
オブジェクトInside_Netには内部ネットワークサブネットが含まれています。
Usersの下で、Available Realmsの下に以前に作成されたレルムをクリックし、Available Usersの下で適切なグループまたはユーザをクリックしてから、Add to Ruleをクリックします。
Available Usersセクションに使用可能なユーザまたはグループがない場合、FMCがレルムのセクションにUsersとGroupsをダウンロードし、適切なGroups/Userが含まれていることを確認します。
ここで指定されたユーザ/グループが、ソース側からチェックされます。
たとえば、このルールですでに定義されているように、FTDは、トラフィックの送信元が外部ゾーンで宛先が内部ゾーン、送信元がAnyConnect_Poolsオブジェクトのネットワーク、宛先がInside_Netオブジェクトのユーザ、トラフィックの送信元がAnyConnect Adminsグループのユーザであると評価します。
Portsの下に、カスタムRDPオブジェクトが作成され、TCPおよびUDPポート3389を許可するように追加されました。RDPは「アプリケーション」セクションに追加できますが、簡略化のためにポートだけがチェックされます。
最後に、後で追加の確認のために、Loggingの下でLog at End of Connectionにチェックマークが入っていることを確認します。入力を終えたら [Add] をクリックします。
9. グループAnyConnect User内のユーザがWindows Server IIS Webサイトにアクセスできるように、HTTPアクセス用の追加ルールが作成されます。[Save] をクリックします。
インターネットPATルールなど、AnyConnectトラフィックに影響を与えるNATルールがある場合は、AnyConnectトラフィックがNATの影響を受けないようにNAT免除ルールを設定することが重要です。
1. Devices > NATの順に移動します。
FTDに適用されているNATポリシーを選択します。
2. このNATポリシーでは、OutsideインターフェイスからOutsideインターフェイスに出力されるすべてのトラフィック(AnyConnectトラフィックを含む)にPATが影響するダイナミックPATが最後に存在します。
AnyConnectトラフィックがNATの影響を受けないようにするには、Add Ruleをクリックします。
3. NAT除外ルールを設定し、ルールがType Staticを使用した手動NATルールであることを確認します。これは、AnyConnectトラフィックに適用される双方向NATルールです。
これらの設定を使用すると、FTDがInside_Netを送信元、AnyConnect IPアドレス(AnyConnect_Poolで定義)を宛先とするトラフィックを検出すると、トラフィックがinside_zoneに入りoutside_zoneから出るときに送信元が同じ値(Inside_Net)に変換され、宛先が同じ値(AnyConnect_Pool)に変換されます。この場合、これらの条件が満たされると、基本的にNATがバイパスされます。
また、FTDは、このトラフィックに対してルートルックアップを実行し、プロキシARPを実行しないように設定されます。完了したら [OK] をクリックします。
4. Saveをクリックします。
1. 設定が終了したら、Deployをクリックします。
2. 設定が適用されるFTDの横にあるチェックボックスをクリックし、Deployをクリックします。
> show running-configuration aaa-server aaa-server LAB-AD protocol ldap max-failed-attempts 4 realm-id 5 aaa-server LAB-AD host win2016.example.com server-port 389 ldap-base-dn DC=example,DC=com ldap-group-base-dn DC=example,DC=com ldap-scope subtree ldap-naming-attribute samaccountname ldap-login-password ***** ldap-login-dn ftd.admin@example.com server-type microsoft
> show running-config webvpn webvpn enable Outside anyconnect image disk0:/csm/anyconnect-linux64-4.7.03052-webdeploy-k9.pkg 1 regex "Linux" anyconnect image disk0:/csm/anyconnect-win-4.7.00136-webdeploy-k9.pkg 2 regex "Windows" anyconnect profiles Lab disk0:/csm/lab.xml anyconnect enable tunnel-group-list enable cache no 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-simultaneous-logins 10 vpn-tunnel-protocol ikev2 ssl-client split-tunnel-policy tunnelspecified split-tunnel-network-list value Lab user-authentication-idle-timeout none webvpn anyconnect keep-installer none anyconnect modules value dart anyconnect ask none default anyconnect http-comp none activex-relay disable file-entry disable file-browsing disable url-entry disable deny-message none anyconnect ssl df-bit-ignore enable > show running-config ssl ssl trust-point FTD-2-SelfSigned outside
ユーザIT管理者は、Windows ServerへのRDPアクセス権を持つAnyConnect Adminsグループに属しています。ただし、HTTPにはアクセスできません。
このサーバへのRDPおよびFirefoxセッションを開くと、このユーザはRDP経由でのみサーバにアクセスできることを確認します。
AnyConnect Usersグループに属するTest Userユーザで、HTTPアクセスとしてログインしているが、RDPアクセスとしてログインしていない場合は、アクセスコントロールポリシールールが有効であることを確認できます。
アクセスコントロールポリシールールでロギングが有効にされているため、これらのルールに一致するトラフィックの接続イベントをチェックできます。
Analysis > Connections > Eventsの順に移動します。
接続イベントのテーブルビューで、ログはIT管理者の接続イベントのみを表示するようにフィルタリングされます。
ここでは、サーバ(TCPおよびUDP 3389)へのRDPトラフィックは許可されているが、ポート80のトラフィックはブロックされていることを確認できます。
ユーザTest Userでは、サーバへのRDPトラフィックがブロックされ、ポート80のトラフィックが許可されていることを確認できます。
このデバッグは、LDAP認証関連の問題をトラブルシューティングするために診断CLI(debug ldap 255)で実行できます。
ユーザIDのアクセスコントロールポリシーの問題をトラブルシューティングするには、system support firewall-engine-debugを簡潔に実行して、トラフィックが予期せず許可またはブロックされる理由を判別します。
[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とログインパスワードが適切に設定されていることを確認します。これは、ldp.exeを使用してADサーバで確認できます。ldpを使用してアカウントを正常にバインドできることを確認するには、次の手順を実行します。
1. ADサーバでWin+Rを押し、ldp.exeを検索します。
2. Connectionの下で、Connectを選択します。
3. サーバーのlocalhostおよび適切なポートを指定し、OKをクリックします。
4. 右側の列には、接続が正常に行われたことを示すテキストが表示されます。Connection > Bindの順に移動します。
5. Simple Bindを選択し、ディレクトリ・アカウント・ユーザーとパスワードを指定します。[OK] をクリックします。
バインドが正常に行われると、ldpにはAuthenticated as: DOMAIN\usernameと表示されます。
無効なユーザ名またはパスワードを使用してバインドしようとすると、次に示す2つのエラーが発生します。
[-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. 前述のように正常にバインドされた後、「表示」>「ツリー」にナビゲートします。
2. FTDで設定されているベースDNを指定し、OKをクリックします。
3. ベースDNを右クリックし、検索をクリックします。
4. デバッグに表示されるのと同じBase DN、Filter、およびScopeの値を指定します。
この例では、次のようになります。
ベースDN dc=example,dc=comの下にsAMAccountname it.admiを持つユーザアカウントがないため、ldpは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
考えられる解決方法:ユーザーパスワードが適切に構成され、有効期限が切れていないことを確認します。ログインDNと同様に、FTDはユーザクレデンシャルを使用してADに対するバインドを実行します。
このバインドは、ADが同じユーザ名とパスワードのクレデンシャルを認識できることを確認するためにldpで実行することもできます。ldpの手順は、「ログインDNまたはパスワードのバインディングが正しくない」のセクションを参照してください。
また、潜在的な障害の原因を確認するために、MicrosoftサーバのEvent Viewerログを確認できます。
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をクリックします。ユーザアカウント名で監査エラーを検索し、エラー情報を確認します。
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
改定 | 発行日 | コメント |
---|---|---|
3.0 |
23-Apr-2024 |
再認定 |
1.0 |
22-Mar-2021 |
初版 |