AnyConnectクライアント用のAD認証の設定

はじめに

このドキュメントでは、Firepower Threat Defense(FTD)に接続するAnyConnectクライアントのActive Directory(AD)認証を設定する方法について説明します。

前提条件

要件

次の項目に関する知識があることが推奨されます。

• Firepower Manage Center(FMC)でのRAバーチャルプライベートネットワーク(VPN)の設定
• FMCでのLightweight Directory Access Protocol(LDAP)サーバの設定
• Active Directory（AD）
• 完全修飾ドメイン名(FQDN)
• Intersightインフラストラクチャサービス(IIS)
• リモートデスクトッププロトコル(RDP)

使用するコンポーネント

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

• Microsoft 2016サーバー
• 6.5.0が稼働するFMCv
• 6.5.0を実行するFTDv

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

背景説明

このドキュメントでは、Firepower Threat Defense(FTD)に接続し、Firepower Management Center(FMC)で管理するAnyConnectクライアントのActive Directory(AD)認証を設定する方法について説明します。

ユーザIDは、AnyConnectユーザを特定のIPアドレスとポートに制限するためにアクセスポリシーで使用されます。

設定

ネットワークダイアグラムとシナリオ

Windowsサーバでは、ユーザIDをテストするためにIISとRDPが事前設定されています。この設定ガイドでは、3つのユーザアカウントと2つのグループが作成されます。

ユーザアカウント:

• FTD Admin:FTDをActive Directoryサーバにバインドするためのディレクトリアカウントとして使用されます。
• IT管理者：ユーザーIDを示すために使用されるテスト管理者アカウント。
• テストユーザ：ユーザIDを示すために使用されるテストユーザアカウント。

グループ:

• AnyConnect管理者：ユーザIDを示すためにIT管理者が追加するテストグループ。このグループは、Windows Serverに対するRDPアクセスのみを持ちます。
• AnyConnectユーザ：ユーザIDを示すためにテストユーザが追加されるテストグループ。このグループには、Windows ServerへのHTTPアクセス権しかありません。

Active Directoryの設定

FTDでAD認証とユーザIDを適切に設定するには、いくつかの値が必要です。

これらの詳細はすべて、FMCで設定を行う前にMicrosoftサーバで作成または収集する必要があります。主な値は次のとおりです。

• [Domain Name]：

これはサーバのドメイン名です。このコンフィギュレーションガイドでは、example.comがドメイン名です。

• サーバIP/FQDNアドレス:

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を使用します。

• ルートCA :

LDAPSまたはSTARTTLSを使用する場合、LDAPSで使用するSSL証明書の署名に使用するルートCAが必要です。

• ディレクトリユーザ名とパスワード:

これは、LDAPサーバにバインドし、ユーザを認証し、ユーザとグループを検索するためにFMCとFTDによって使用されるアカウントです。

この目的のために、FTD Adminという名前のアカウントが作成されます。

• ベースとグループの識別名(DN):

ベース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の両方に使用されます。

LDAPベース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]をもう一度クリックして削除できます。

FTDアカウントの作成

このユーザアカウントを使用すると、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つのアカウントが作成されます。

ADグループの作成とADグループへのユーザの追加（オプション）

認証には不要ですが、グループを使用すると、複数のユーザへのアクセスポリシーの適用や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グループに追加します。

LDAPS SSL証明書ルートのコピー（LDAPSまたはSTARTTLSの場合のみ必要）

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つの証明書がリストされています。

• example-WIN2016-CAによって発行されたCA証明書。
• example-WIN2016-CAによってWIN2016に発行されたID証明書。
• example-WIN2016-CAによってwin2016.example.comに発行されたID証明書。

この設定ガイドでは、FQDNはwin2016.example.comであるため、最初の2つの証明書はLDAPS SSL証明書として使用できません。win2016.example.comに発行されたID証明書は、Windows Server CAサービスによって自動的に発行された証明書です。証明書をダブルクリックして詳細を確認します。

7. LDAPS SSL証明書として使用するには、証明書が次の要件を満たしている必要があります。

• 共通名またはDNS Subject Alternate Nameが、WindowsサーバのFQDNと一致している。
• 証明書は、Enhanced Key Usageフィールドの下にServer Authenticationがあります。

証明書の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を抽出できます。

FMCの設定

ライセンスの確認

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証明書を認証する必要はありません。したがって、このメッセージは無視できます。

AD認証用のAnyConnectの設定

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をクリックします。

アイデンティティポリシーの有効化とユーザIDのセキュリティポリシーの設定

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] をクリックします。

NAT免除の設定

インターネット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をクリックします。

確認

Final Configuration

AAA 設定

> 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

AnyConnectの設定

> 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

AnyConnectを使用した接続とアクセスコントロールポリシールールの確認

ユーザIT管理者は、Windows ServerへのRDPアクセス権を持つAnyConnect Adminsグループに属しています。ただし、HTTPにはアクセスできません。

このサーバへのRDPおよびFirefoxセッションを開くと、このユーザはRDP経由でのみサーバにアクセスできることを確認します。

AnyConnect Usersグループに属するTest Userユーザで、HTTPアクセスとしてログインしているが、RDPアクセスとしてログインしていない場合は、アクセスコントロールポリシールールが有効であることを確認できます。

FMC接続イベントを使用した確認

アクセスコントロールポリシールールでロギングが有効にされているため、これらのルールに一致するトラフィックの接続イベントをチェックできます。

Analysis > Connections > Eventsの順に移動します。

接続イベントのテーブルビューで、ログはIT管理者の接続イベントのみを表示するようにフィルタリングされます。

ここでは、サーバ（TCPおよびUDP 3389）へのRDPトラフィックは許可されているが、ポート80のトラフィックはブロックされていることを確認できます。

ユーザTest Userでは、サーバへのRDPトラフィックがブロックされ、ポート80のトラフィックが許可されていることを確認できます。

トラブルシュート

デバッグ

このデバッグは、LDAP認証関連の問題をトラブルシューティングするために診断CLI(debug ldap 255)で実行できます。

ユーザIDのアクセスコントロールポリシーの問題をトラブルシューティングするには、system support firewall-engine-debugを簡潔に実行して、トラフィックが予期せず許可またはブロックされる理由を判別します。

LDAPデバッグの動作

[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

LDAPサーバとの接続を確立できない

[-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

考えられる解決策：

• ルーティングをチェックし、FTDがLDAPサーバから応答を受信していることを確認します。
• LDAPSまたはSTARTTLSを使用する場合は、SSLハンドシェイクが正常に完了できるように、正しいルートCA証明書が信頼されていることを確認します。
• 正しいIPアドレスとポートが使用されていることを確認します。ホスト名を使用している場合は、DNSがホスト名を正しいIPアドレスに解決できることを確認します。

バインディングログインDNまたはパスワードが正しくない

[-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つのエラーが発生します。

LDAPサーバがユーザ名を見つけられない

[-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
• スコープ：サブツリー

ベース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ログを確認できます。

AAAのテスト

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

Windows Serverイベントビューアのログ

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