ISEセッション管理とポスチャのトラブルシューティング

Updated: 2023 年 5 月 31 日

Document ID:215419

偏向のない言語

この製品のドキュメントセットは、偏向のない言語を使用するように配慮されています。このドキュメントセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージの取り組みの詳細は、こちらをご覧ください。

翻訳について

シスコは世界中のユーザにそれぞれの言語でサポートコンテンツを提供するために、機械と人による翻訳を組み合わせて、本ドキュメントを翻訳しています。ただし、最高度の機械翻訳であっても、専門家による翻訳のような正確性は確保されません。シスコは、これら翻訳の正確性について法的責任を負いません。原典である英語版（リンクからアクセス可能）もあわせて参照することを推奨します。

内容

はじめに

背景説明

問題

エンドユーザエクスペリエンス

ISE管理エクスペリエンス

一般的な問題のあるシナリオ

古い/ファントムセッションの問題

ISEセッション管理ロジック

MNTおよびセッション管理

PSNおよびセッション管理

はじめに

このドキュメントでは、一般的なIdentity Service Engine(ISE)ポスチャサービスの問題「AnyConnect ISEポスチャモジュールが準拠を示す…」について説明します。

背景説明

このドキュメントでは、一般的なIdentity Service Engine(ISE)ポスチャサービスの問題について説明します。ISEのセッションステータスが保留中の間、AnyConnect ISEポスチャモジュールは準拠を示します。

症状は常に同じですが、この問題には複数の根本原因があります。

多くの場合、このような問題のトラブルシューティングは非常に時間がかかるため、重大な影響が生じます。

このドキュメントでは、次の項目を説明しています。

エンドユーザおよびISE管理者の観点からの問題の表示。
一般的な問題のあるシナリオ
ISE、AnyConnect、およびネットワーク動作の背後にある理論が問題のトリガーとなります。
迅速な問題特定のアルゴリズム。
一般的な問題のあるシナリオに対する古典的な解決策。
Radiusセッションディレクトリを介したポスチャステータスの共有

後述の概念の詳細な説明については、次のドキュメントを参照してください。

ISE ポスチャスタイルの 2.2 前後の比較

虫眼鏡の下のISE。ISEのトラブルシューティング方法 – BRKSEC-3229

問題

エンドユーザエクスペリエンス

通常、この問題は、ブラウザでISEクライアントプロビジョンポータルへのネットワークアクセスや継続的なリダイレクトがないときに発生し、同時に、AnyConnect ISEポスチャモジュールはポスチャステータスを準拠として示します。

一般的なエンドユーザエクスペリエンス：

クライアントプロビジョニングポータル

ISE管理エクスペリエンス

通常、この問題の初期トリアージでは、ISE管理者がRadiusライブログ調査を実行して、ISEをヒットする実際の認証があることを確認します。

この段階で検出される最初の症状は、ライブログのようにエンドポイントとISE間のポスチャステータスの不一致を示しているか、エンドポイントのRadius認証レポートの最終認証がPendingポスチャステータスを示していることを示しています。

一般的なISE管理エクスペリエンス：

クライアントプロビジョニングポータル

最後に成功したIDの認証：alice
セッションのポスチャステータスはPendingです。
アイデンティティの最後のセッションイベント：alice。
セッションイベントでは、ポスチャステータスがCompliantと表示されます。

注:c.およびd.は、上記の問題が発生した場合に、ライブログに必ずしも表示されるわけではありません。ポスチャステータスがCompliantのセッションイベントは、古い（バージョンが古い）セッションやファントムセッション（このドキュメントで後述）が原因で発生するシナリオでより一般的に発生します。

一般的な問題のあるシナリオ

通常、この問題は2つの問題のあるシナリオで発生し、それぞれのシナリオには複数の根本原因があります。シナリオ：

ポスチャプロセス中にポリシーサービスノード(PSN)からAnyConnect ISEポスチャモジュールに誤った通知が送信されたため、誤ったポスチャステータスが表示されました。

この場合、通常はPSNセッションキャッシュ内の古いセッションまたはファントムセッションを処理します。

現在の認証ではディスカバリプロセスがトリガーされなかったため、AnyConnect ISEは前のディスカバリサイクルのポスチャステータスを表示します。

AnyConnectのISEポスチャモジュールには、検出プロセスをトリガーするイベントの数が制限されています。認証または再認証中に、これらのイベントがまったく検出されなかった可能性があります。

古い/ファントムセッションの問題

問題をより詳しく理解するには、必要なISEセッション管理ロジックとAnyConnectディスカバリプロセスを調査します。

ISEセッション管理ロジック

ISEの導入では、セッション管理プロセスを担当する2人の担当者(PSNとモニタリングノード(MNT))が存在します。

この問題を適切にトラブルシューティングして特定するには、両方のペルソナのセッション管理理論を理解することが重要です。

MNTおよびセッション管理

次の図で説明するように、MNTノードは、PSNから送信される渡された認証Syslogメッセージに基づいてシーズンを作成します。

セッションステータスは、アカウンティングのためにSyslogによって後で更新できます。

MNTでのセッションの削除は、次の3つのシナリオで行われます。

1.アカウンティングを使用しないセッションは、作成から約60分後に削除されます。セッションの状態とクリーンを確認するために、5分ごとにcronジョブが実行されます。

2. 終了したセッションは、同じcronジョブによってアカウンティング停止が処理されてから約15分後に削除されました。

3. 各実行の同じcronは、5日（120時間）を超えて「Started」状態になっているセッションも削除します。開始状態とは、MNTノードが認証とアカウンティングの両方を処理して、セッションのSyslogを開始したことを意味します。

PSNからのSyslogメッセージの例：

これらのメッセージは、runtime-aaaコンポーネントがDEBUGに対して有効になるとprrt-server.logに記録されます。太字の部分は、検索正規表現の作成に使用できます。

成功した認証：

AcsLogs,2020-04-07 10:07:29,202,DEBUG,0x7fa0ada91700,cntx=0000629480,sesn=skuchere-ise26-1/375283310/10872,CPMSessionID=0A3E946C00000073559C0123,user=bob@example.com,CallingStationID=00-50-56-B6-0B-C6,FramedIPAddress=192.168.255.205,Log_Message=[2020-04-07 22:53:24.288 +02:00 0000423024 5200 NOTICE Passed-Authentication: Authentication succeeded, ConfigVersionId=87, Device IP Address=10.62.148.108, DestinationIPAddress=192.168.43.26, DestinationPort=1812, UserName=bob@example.com, Protocol=Radius, RequestLatency=45, NetworkDeviceName=3850-1-BB, User-Name=bob@example.com, NAS-IP-Address=10.62.148.108, NAS-Port=50105, Service-Type=Framed, Framed-IP-Address=192.168.255.205, Framed-MTU=1472, State=37CPMSessionID=0A3E946C00000073559C0123\;42SessionID=skuchere-ise26-1/375283310/10872\;, Calling-Station-ID=00-50-56-B6-0B-C6, NAS-Port-Type=Ethernet, NAS-Port-Id=GigabitEthernet1/0/5, EAP-Key-Name=, cisco-av-pair=service-type=Framed, cisco-av-pair=audit-session-id=0A3E946C00000073559C0123, cisco-av-pair=method=dot1x, cisco-av-pair=client-iif-id=526638260, NetworkDeviceProfileName=Cisco, NetworkDeviceProfileId=b0699505-3150-4215-a80e-6753d45bf56c, IsThirdPartyDeviceFlow=false, RadiusFlowType=Wired802_1x, AcsSessionID=skuchere-ise26-1/375283310/10872, AuthenticationIdentityStore=EXAMPLE, AuthenticationMethod=MSCHAPV2, SelectedAccessService=Default Network Access, SelectedAuthorizationProfiles=PermitAccess, IsMachineAuthentication=false, IdentityGroup=Endpoint Identity Groups:Profiled:Workstation, Step=11001, Step=11017, Step=15049, Step=15008, Step=15048, Step=15048, Step=15048, Step=11507, Step=12500, Step=12625, Step=11006, Step=11001, Step=11018, Step=12301, Step=12300, Step=12625, Step=11006, Step=11001, Step=11018, Step=12302, Step=12318, Step=12800, Step=12805, Step=12806, Step=12807, Step=12808, Step=12810, Step=12811, Step=12305, Step=11006, Step=11001, Step=11018, Step=12304, Step=12305, Step=11006, Step=11001, Step=11018, Step=12304, Step=12305, Step=11006, Step=11001, Step=11018, Step=12304, Step=12305, Step=11006, Step=11001, Step=11018, Step=12304, Step=12318, Step=12812, Step=12813, Step=12804, Step=12801, Step=12802, Step=12816, Step=12310, Step=12305, Step=11006, Step=11001, Step=11018, Step=12304, Step=12313, Step=11521, Step=12305, Step=11006, Step=11001, Step=11018, Step=12304, Step=11522, Step=11806, Step=12305, Step=11006, Step=11001, Step=11018, Step=12304, Step=11808, Step=15041, Step=22072, Step=15013, Step=24210, Step=24216, Step=15013, Step=24430, Step=24325, Step=24313, Step=24319, Step=24323, Step=24343, Step=24402, Step=22037, Step=11824, Step=12305, Step=11006, Step=11001, Step=11018, Step=12304, Step=11810, Step=11814, Step=11519, Step=12314, Step=12305, Step=11006, Step=11001, Step=11018, Step=12304, Step=24715, Step=15036, Step=24209, Step=24211, Step=24432, Step=24325, Step=24313, Step=24319, Step=24323, Step=24355, Step=24416, Step=15048, Step=15016, Step=22081, Step=22080, Step=12306, Step=11503, Step=11002, SelectedAuthenticationIdentityStores=Internal Users, SelectedAuthenticationIdentityStores=All_AD_Join_Points, SelectedAuthenticationIdentityStores=Guest Users, AuthenticationStatus=AuthenticationPassed, NetworkDeviceGroups=IPSEC#Is IPSEC Device#No, NetworkDeviceGroups=Location#All Locations, NetworkDeviceGroups=Device Type#All Device Types, IdentityPolicyMatchedRule=Dot1X, AuthorizationPolicyMatchedRule=Compliant-Wired, EapTunnel=PEAP, EapAuthentication=EAP-MSCHAPv2, CPMSessionID=0A3E946C00000073559C0123, EndPointMACAddress=00-50-56-B6-0B-C6, PostureAssessmentStatus=NotApplicable, EndPointMatchedProfile=Microsoft-Workstation, ISEPolicySetName=Default, IdentitySelectionMatchedRule=Dot1X, AD-User-Resolved-Identities=bob@example.com, AD-User-Candidate-Identities=bob@example.com, AD-User-Join-Point=EXAMPLE.COM, StepData=4= Radius.NAS-IP-Address, StepData=5= Cisco-VPN3000.CVPN3000/ASA/PIX7x-Tunnel-Group-Name, StepData=6= DEVICE.Device Type, StepData=77=All_User_ID_Stores, StepData=78=Internal Users, StepData=81=All_AD_Join_Points, StepData=82=All_AD_Join_Points, StepData=83=bob@example.com, StepData=84=example.com, StepData=85=example.com, StepData=87=bob@example.com, StepData=88=All_AD_Join_Points, StepData=109=EXAMPLE, StepData=110=bob@example.com, StepData=111=example.com, StepData=112=example.com, StepData=114=example.com, StepData=115=EXAMPLE, StepData=116= EXAMPLE.ExternalGroups, AD-User-Resolved-DNs=CN=bob\,CN=Users\,DC=example\,DC=com, AD-User-DNS-Domain=example.com, AD-Groups-Names=example.com/Users/Domain Users, AD-User-NetBios-Name=EXAMPLE, IsMachineIdentity=false, UserAccountControl=66048, AD-User-SamAccount-Name=bob, AD-User-Qualified-Name=bob@example.com, allowEasyWiredSession=false, TLSCipher=ECDHE-RSA-AES256-GCM-SHA384, TLSVersion=TLSv1.2, DTLSSupport=Unknown, HostIdentityGroup=Endpoint Identity Groups:Profiled:Workstation, Network Device Profile=Cisco, Location=Location#All Locations, Device Type=Device Type#All Device Types, IPSEC=IPSEC#Is IPSEC Device#No, ExternalGroups=S-1-5-21-875452798-754861120-3039794717-513, IdentityAccessRestricted=false, PostureStatus=Compliant, Response={Class=CACS:0A3E946C00000073559C0123:skuchere-ise26-1/375283310/10872; EAP-Key-Name=19:5e:8c:e9:13:0c:89:23:78:49:ad:2b:d4:31:63:51:27:81:db:e2:61:b1:51:36:6d:11:10:41:ce:3b:aa:cc:c6:66:4e:7c:92:f8:83:c5:06:84:ac:95:4c:5b:f1:b2:37:a2:f5:04:4e:9e:4d:08:79:55:b7:4d:9a:41:f5:b2:0a; MS-MPPE-Send-Key=****; MS-MPPE-Recv-Key=****; LicenseTypes=65541; },],MessageFormatter.cpp:107

アカウンティング開始：

AcsLogs,2020-04-07 10:07:30,202,DEBUG,0x7fa0ad68d700,cntx=0000561096,sesn=skuchere-ise26-1/375283310/10211,CPMSessionID=0A3E946C00000073559C0123,user=bob@example.com,CallingStationID=00-50-56-B6-0B-C6,FramedIPAddress=192.168.255.205,Log_Message=[2020-04-07 10:07:30.857 +02:00 0000382874 3000 NOTICE Radius-Accounting: RADIUS Accounting start request, ConfigVersionId=87, Device IP Address=10.62.148.108, UserName=bob@example.com, RequestLatency=7, NetworkDeviceName=3850-1-BB, User-Name=bob@example.com, NAS-IP-Address=10.62.148.108, NAS-Port=50105, Framed-IP-Address=192.168.255.205, Class=CACS:0A3E946C00000073559C0123:skuchere-ise26-1/375283310/10210, Called-Station-ID=00-E1-6D-D1-4F-05, Calling-Station-ID=00-50-56-B6-0B-C6, Acct-Status-Type=Start, Acct-Delay-Time=0, Acct-Session-Id=00000041, Acct-Authentic=Remote, Event-Timestamp=1586279242, NAS-Port-Type=Ethernet, NAS-Port-Id=GigabitEthernet1/0/5, cisco-av-pair=audit-session-id=0A3E946C00000073559C0123, cisco-av-pair=method=dot1x, AcsSessionID=skuchere-ise26-1/375283310/10211, SelectedAccessService=Default Network Access, Step=11004, Step=11017, Step=15049, Step=15008, Step=15048, Step=22083, Step=11005, NetworkDeviceGroups=IPSEC#Is IPSEC Device#No, NetworkDeviceGroups=Location#All Locations, NetworkDeviceGroups=Device Type#All Device Types, CPMSessionID=0A3E946C00000073559C0123, Network Device Profile=Cisco, Location=Location#All Locations, Device Type=Device Type#All Device Types, IPSEC=IPSEC#Is IPSEC Device#No, ],MessageFormatter.cpp:107

暫定アカウンティングの更新：

AcsLogs,2020-04-07 22:57:48,642,DEBUG,0x7fa0adb92700,cntx=0000629843,sesn=skuchere-ise26-1/375283310/10877,CPMSessionID=0A3E946C00000073559C0123,user=bob@example.com,CallingStationID=00-50-56-B6-0B-C6,FramedIPAddress=192.168.255.205,Log_Message=[2020-04-07 22:57:48.650 +02:00 0000423268 3002 NOTICE Radius-Accounting: RADIUS Accounting watchdog update, ConfigVersionId=87, Device IP Address=10.62.148.108, UserName=bob@example.com, RequestLatency=8, NetworkDeviceName=3850-1-BB, User-Name=bob@example.com, NAS-IP-Address=10.62.148.108, NAS-Port=50105, Framed-IP-Address=192.168.255.205, Class=CACS:0A3E946C00000073559C0123:skuchere-ise26-1/375283310/10872, Called-Station-ID=00-E1-6D-D1-4F-05, Calling-Station-ID=00-50-56-B6-0B-C6, Acct-Status-Type=Interim-Update, Acct-Delay-Time=0, Acct-Input-Octets=2293926, Acct-Output-Octets=0, Acct-Session-Id=00000041, Acct-Authentic=Remote, Acct-Input-Packets=15785, Acct-Output-Packets=0, Event-Timestamp=1586325462, NAS-Port-Type=Ethernet, NAS-Port-Id=GigabitEthernet1/0/5, cisco-av-pair=audit-session-id=0A3E946C00000073559C0123, cisco-av-pair=method=dot1x, AcsSessionID=skuchere-ise26-1/375283310/10877, SelectedAccessService=Default Network Access, Step=11004, Step=11017, Step=15049, Step=15008, Step=22085, Step=11005, NetworkDeviceGroups=IPSEC#Is IPSEC Device#No, NetworkDeviceGroups=Location#All Locations, NetworkDeviceGroups=Device Type#All Device Types, CPMSessionID=0A3E946C00000073559C0123, Network Device Profile=Cisco, Location=Location#All Locations, Device Type=Device Type#All Device Types, IPSEC=IPSEC#Is IPSEC Device#No, ],MessageFormatter.cpp:107

アカウンティング停止：

AcsLogs,2020-04-08 11:43:22,356,DEBUG,0x7fa0ad68d700,cntx=0000696242,sesn=skuchere-ise26-1/375283310/11515,CPMSessionID=0A3E946C00000073559C0123,user=bob@example.com,CallingStationID=00-50-56-B6-0B-C6,FramedIPAddress=192.168.255.205,Log_Message=[2020-04-08 11:43:22.368 +02:00 0000463071 3001 NOTICE Radius-Accounting: RADIUS Accounting stop request, ConfigVersionId=88, Device IP Address=10.62.148.108, UserName=bob@example.com, RequestLatency=12, NetworkDeviceName=3850-1-BB, User-Name=bob@example.com, NAS-IP-Address=10.62.148.108, NAS-Port=50105, Framed-IP-Address=192.168.255.205, Class=CACS:0A3E946C00000073559C0123:skuchere-ise26-1/375283310/11503, Called-Station-ID=00-E1-6D-D1-4F-05, Calling-Station-ID=00-50-56-B6-0B-C6, Acct-Status-Type=Stop, Acct-Delay-Time=0, Acct-Input-Octets=4147916, Acct-Output-Octets=0, Acct-Session-Id=00000041, Acct-Authentic=Remote, Acct-Session-Time=92157, Acct-Input-Packets=29120, Acct-Output-Packets=0, Acct-Terminate-Cause=Lost Carrier, Event-Timestamp=1586371399, NAS-Port-Type=Ethernet, NAS-Port-Id=GigabitEthernet1/0/5, Framed-IPv6-Address=2001:10::100, Framed-IPv6-Address=2001:10::101, cisco-av-pair=audit-session-id=0A3E946C00000073559C0123, cisco-av-pair=method=dot1x, AcsSessionID=skuchere-ise26-1/375283310/11515, SelectedAccessService=Default Network Access, Step=11004, Step=11017, Step=15049, Step=15008, Step=22084, Step=11005, NetworkDeviceGroups=IPSEC#Is IPSEC Device#No, NetworkDeviceGroups=Location#All Locations, NetworkDeviceGroups=Device Type#All Device Types, CPMSessionID=0A3E946C00000073559C0123, Network Device Profile=Cisco, Location=Location#All Locations, Device Type=Device Type#All Device Types, IPSEC=IPSEC#Is IPSEC Device#No, ],MessageFormatter.cpp:107

PSNおよびセッション管理

PSNセッションキャッシュは、特定のPSNのすべてのアクティブセッションを格納するインメモリデータベースです。セッションキャッシュは常にノードに対してローカルです。

ISEには、あるノードから別のノードへの完全なセッション状態のレプリケーションを実行できるメカニズムはありません。

すべてのアクティブセッションIDについて、PSNは認証/認可フェーズで収集されたすべての属性(内部/外部ユーザグループ、ネットワークアクセスデバイス(NAD)属性、証明書属性など)を保存します。これらの属性は、PSNが異なるポリシータイプ（認証、認可、クライアントプロビジョニング、ポスチャなど）を選択するために使用されます。

セッションキャッシュは、ノード（またはノード上のサービス）が再起動すると完全に削除されます。

クライアントプロビジョニングポータル

現在のセッション処理ロジックでは、2つのシナリオでセッションキャッシュに新しいエントリが作成されます。既存のセッションの詳細は、NADから送信されるアカウンティングメッセージから更新できます。

セッションがPSNで正常に認証されました。
PSNは、セッションキャッシュに存在しないセッションのアカウンティング中間更新を取得しました。

セッションの削除に関しては、PSNは次のロジックを実装しています。

セッションキャッシュエントリは、アカウンティング停止メッセージを処理した直後に削除されます。
ノードがアクティブセッションの制限に達すると、PSNは最も使用率の低いセッションの削除を開始します。

PSN上の古いセッション

ISEの導入では、既存のセッションのアカウンティング停止は、実際の認証を実行しなかったPSNによって処理されました。

古いセッションの例：

クライアントプロビジョニングポータル

1. セッションABCのPSNで認証に成功します。

2. PSNはセッションキャッシュにエントリを作成します。

3. ポスチャ評価が行われます。

4. セッションが準拠としてマークされている。

5. 認可変更(COA)（ポスチャステータスの変更によってトリガー）により、エンドポイントの再認証が発生し、次のアクセスレベルが適用されます。

6. セッションABCのアカウンティング停止がPSN2に到着します。

その後、ABCはPSN1上で古い状態のままになります。これは、これを削除するために処理されるアカウンティング停止メッセージがこのPSN上にないためです。

導入で認証の試行が頻繁に行われない場合、セッションは長時間にわたって削除されます。

次のシナリオでは、古いセッションがPSNセッションキャッシュに表示されます。

ロードバランサのスティッキネスタイマーの有効期限が切れたため、アカウンティング停止が誤ったPSNに到達しました。
NADの誤った設定は、認証とアカウンティング用に設定されたPSNと同じではありません。
次のPSNへのNADフェールオーバーを引き起こすネットワークパスの一時的な接続問題。

ロードバランサ(LB)環境での古いセッションの例：

クライアントプロビジョニングポータル

1. セッションABCの初期認証は、PSN 1によって実行されます。

2. この認証により、ロードバランサでスティッキネスタイマーが開始されます。

3. PSN 1は、セッションABCのエントリをローカルキャッシュに作成します。

4. MNTノードに転送された合格した認証のsyslogメッセージ。

5. セッションABCのエントリが、状態AuthenticatedでMNTセッションディレクトリに作成されます。

6. セッションABCがPSN 1に到着した場合の会計開始メッセージ

7. セッションABCのセッションキャッシュエントリが、Accounting-Startからの情報で更新されます。

8. Accounting-StartのsyslogメッセージがMNTノードに転送されます。

9. セッションの状態がStartedに更新されます。

10. ロードバランサでスティッキネスタイマーが期限切れになる。

11. セッションABCのアカウンティング停止は、ロードバランサによってPSN 2に転送されます。

12. Accounting-StopのSyslogメッセージがPSN 2によってMNTに転送されます。

13. セッションABCはMNT上で終了したとマークされます。

PSNでのファントムセッション

ファントムセッションは、この特定のセッションに対して認証を実行しなかったPSNにアカウンティングの中間更新が到達した場合のシナリオです。このシナリオでは、新しいエントリがPSNセッションキャッシュに作成されます。

PSNがこのセッションのアカウンティング停止メッセージを取得しない場合、PSNがアクティブセッションの制限に達しない限り、エントリは削除されません。

ファントムセッションの例：

クライアントプロビジョニングポータル

1. セッションABCのPSN1で、失効したセッションの例に記載されているのと同じ手順が実行されます。

2. セッションABCのPSN1セッションキャッシュには、ステータスCompliantが設定されています。

3. セッションABCの会計中間更新がPSN2にヒットします。

4. PSN2でセッションABCのセッションエントリが作成されます。セッションエントリはアカウンティングメッセージから作成されるため、属性の数は限られています。たとえば、セッションABCではポスチャステータスは使用できません。ユーザグループやその他の認可固有の属性なども同様に存在しません。

ファントムセッションは、次のシナリオではPSNセッションキャッシュに表示されます。

ネットワーク通過時の短時間の停止。
ネットワークアクセスデバイスの誤動作。
ロードバランサの誤動作または設定の誤り。

PSN1へのネットワークパスに一時的な問題があるシナリオのファントムセッションの例を次に示します。

クライアントプロビジョニングポータル

1. セッションABCの初期認証は、PSNによって実行される。

2. PSN1は、セッションABCのエントリをローカルキャッシュに作成します。

3. 認証に成功した場合のsyslogメッセージがMNTノードに転送されます。

4. セッションABCのエントリが、状態AuthenticatedでTimesTen DBに作成されます。

5. セッションABCの会計開始メッセージは、PSN 1に到着する。

6. セッションABCのセッションキャッシュエントリが、Accounting-Startからの情報で更新されます。

7. Accounting-StartのSyslogメッセージがMNTノードに転送されます。

8. セッションの状態がStartedに更新されます。

9. セッションABCの暫定アカウンティングアップデートがPSN2に転送されます。

10. PSN2は、セッションABCのエントリをローカルキャッシュに作成します。

11. セッションABCのアカウンティング停止は、PSN1に転送されます。

12. セッションABCのエントリがPSN1のセッションキャッシュから削除されます。

13. Accounting-StopのsyslogメッセージがPSN 1によってMNTに転送されます。

14. セッションABCは、MNT上で終了したとマーキングされている。

次の図は、長寿命のVPN接続のために作成されたファントムセッションのシナリオを示しています。

クライアントプロビジョニングポータル

1. PSN1での初期認証。

2. セッションABCがセッションキャッシュに作成されます。

3. アカウンティングは、PSNによって処理されるメッセージを開始します。

4. 新しいIPアドレスがバーチャルプライベートネットワーク(VPN)アダプタに割り当てられます。

5. IPアドレス情報を含む暫定アカウンティングアップデートがPSNに到着します。

6. IPアドレス情報がセッションキャッシュに追加されます。

7. ポスチャ評価はPSN1で行われます。

8. セッションでポスチャステータスが更新されます。

9. COAプッシュがISEによって実行され、これにより新しいアクセスレベルが割り当てられます。

10. ネットワークパスで停止が発生し、PSN1にアクセスできなくなります。

11. 中間更新間隔の満了後に、ASA/FTDがPSN1にアクセスできないことを検出します。

12. 暫定アカウンティングアップデートがPSN2に到達します。

13. ファントムセッションがPSN2セッションキャッシュに作成されます。

後でPSN1がアクセス可能になった場合(14)、後続のすべてのアカウンティングメッセージがそこに転送され(15、16)、セッションABCがPSN2セッションキャッシュに不定時間だけ残されます。

古いセッションとファントムセッションによるポスチャプロセスの中断

古いセッションとファントムセッションがどのようにポスチャを壊すかを理解するには、AnyConnect ISEポスチャモジュールの検出プロセスを確認します。

クライアントプロビジョニングポータル

ステージ1の検出：

この段階で、ISEポスチャモジュールは4つの問題を同時に実行して、エンドポイントの認証を行ったPSNを特定します。

まず、図の3つのプローブはリダイレクトベース(デフォルトのゲートウェイIP。ディスカバリホストIP（定義されている場合）およびenroll.cisco.com IP)。リダイレクトされたURLはNAD自体から取得されるため、これらのプローブは常にエージェントを正しいPSNにポイントします。

プローブ番号4は、ConnectionData.xmlファイルに記述されているすべてのプライマリサーバに送信されます。このファイルは、最初のポスチャ試行が成功した後に作成されます。クライアントがPSN間で移行する場合に備えて、ファイルの内容を後で更新できます。

Windowsシステムでは、ファイルの場所はC:\ProgramData\Cisco\Cisco AnyConnectセキュアモビリティクライアント\ISEポスチャ\です。

すべてのステージ1プローブは同時に実行されるため、プローブ4の結果は、他の3つのプローブがすべて失敗した場合、またはISEポスチャモジュールが5秒以内にリダイレクトURLで返されたPSNとの適切な通信を確立できなかった場合にのみ使用されます。

プローブ4がPSNに到達すると、エンドポイントで検出されたアクティブなIPアドレスとMACアドレスのリストが含まれます。PSNはこのデータを使用して、ローカルキャッシュ内のこのエンドポイントのセッションを検索します。

PSNにエンドポイントの古いセッションまたはファントムセッションがある場合は、誤ったポスチャステータスがクライアント側に後で表示される可能性があります。

エージェントがプローブ4に対する応答を複数受信した場合(ConnectionData.xmlに複数のプライマリPSNを含めることができる)、常に最速の応答が使用されます。

第2段階の検出：

すべてのステージ2検出プローブはリダイレクトレスです。つまり、すべてのプローブが宛先PSNでセッションルックアップをトリガーします。

PSNがローカルセッションキャッシュ内でセッションを見つけられない場合は、MNTルックアップを実行して（MACアドレスベースのみ）、セッションオーナーを見つけてオーナー名をエージェントに返す必要があります。

すべてのプローブによってセッションルックアップがトリガーされるため、第2段階のディスカバリは、古いセッションや幻のセッションによる問題の影響をさらに受ける可能性があります。

PSNがステージ2に到達すると、セッションキャッシュに存在する検出プローブによって、同じエンドポイントの古いエントリまたはファントムエントリが作成されます。その結果、誤ったポスチャステータスがエンドユーザに返されます。

次の例は、PSNが古いセッションまたはファントムセッションを保持している場合に、ポスチャがどのように発生するかを示しています。

クライアントプロビジョニングポータル

注：この問題が発生するのは、すべてのリダイレクトベースの検出プローブが失敗した場合、またはリダイレクト以外のポスチャが実装されている場合だけです。

1. ISEポスチャモジュールによって発行されたFind my sessionプローブ。

2. PSNは、セッションキャッシュでセッションルックアップを実行します。セッションが見つかると、古いセッションまたは幻のセッションの問題が発生します。

3. PSNはクライアントプロビジョニングポリシー選択を実行します。認証/認可属性がなく、顧客によって設定されたすべてのポリシーが非常に固有であるファントムセッション（たとえば、特定のActive Directoryグループ用にポリシーが作成される）の場合、PSNは適切なクライアントプロビジョニングポリシーを割り当てることができません。これは、「Bypassing AnyConnect scan your network is configured to use Cisco NAC Agent」というエラーメッセージで明らかになります。

クライアントプロビジョニングポリシーが汎用の場合（ポリシーとAnyConnect設定を一致させるには、ファントムセッションで使用可能な属性で十分）、PSNは評価プロセスを続行するために必要な詳細で応答します。
このステップでは、古いセッションを処理できるようになると、PSNはすぐにCompliantのポスチャステータスで応答し、後続のステップはすべて実行されません。PSNは、セッションがすでに準拠していると認識しているため、COAを送信しません。RADIUSライブログに、Compliantステータスを持つセッションイベントが表示されていません。

4. ファントムセッションシナリオでは、ISEポスチャモジュールは初期ポスチャ要求で続行します。この要求には、エンドポイントで検出されたすべてのセキュリティおよびパッチ管理製品に関する情報が含まれます。

5. PSNは、要求およびセッション属性からの情報を使用して、適切なポスチャポリシーに一致させます。ファントムセッションには、この時点で属性がないため、一致させるポリシーがありません。この場合、PSNは準拠していることをエンドポイントに応答します。これは、ポスチャポリシーが一致しない場合のデフォルトのISE動作です。

注：ファントムセッション属性から選択可能な汎用ポリシーがある場合は、ステップ6に進みます。

6. PSNは選択されたポスチャポリシーをエージェントに返します。

注：ポリシーを選択できない場合、PSNは準拠ステータスを返します。

7. エージェントは、各ポリシー/要件のステータスを「合格」または「不合格」として返します。

8. レポートの評価はISEで行われ、セッションステータスは準拠に変更されます。

注：ファントムセッションによって引き起こされるポスチャの問題の場合、ISE管理者はポスチャCOAの失敗に気づく可能性があります。このような場合、COA要求は誤ったPSNおよび誤ったセッションIDから実行されます。

新しい認証の試行時に検出プロセスが開始されない

ISEポスチャモジュールは、検出プロセスをトリガーするためにエンドポイントで監視するイベントの量を制限するように設計されています。

検出をトリガーするイベント：

ISEポスチャモジュールの初期インストール。
ユーザログイン。
電源イベント
インターフェイスステータスの変更。
スリープ後にOSが再開します。
デフォルトゲートウェイ(DG)の変更。
ポスチャ再評価(PRA)の失敗。Cisco Bug ID CSCvo69557を参照してください。

新しいdot1x認証、PCロック解除、およびIPアドレスの変更がISEポスチャモジュールで検出されない。

ISEポスチャモジュールは、次のシナリオでは新しい認証または再認証の試行を検出できません（ポスチャモジュールが新しい認証または再認証の試行を受信する前に確認してください）。

再認証が異なるPSNにヒットする（LBの決定または元のPSNの問題のいずれか）。
NADは再認証時に新しいセッションIDを生成します。

異なるPSNでの再認証

次の図は、元のPSNの停止が原因で発生した、別のPSNでの再認証の例を示しています。ロードバランサを使用するシナリオも非常に似ています。

ロードバランサの場合は、スティッキネスタイマーが期限切れになるため、再認証が別のPSNに送信されます。

クライアントプロビジョニングポータル

1. PSN1での初期認証

2. セッションABCがPSN1セッションキャッシュに作成されます。

3. ポスチャ評価はPSN1で実行されます。

4. セッションABSポスチャステータスがCompliantに移行します。

5. COAはポスチャステータスの変更によってトリガーされ、エンドポイントの再認証によって次のアクセスレベルが適用されます。

6. PSN1が使用できなくなります。

7. セッションABCの再認証がPSN2にヒットします。

8. PSN2の新しいセッションであるため、セッションのポスチャステータスはPendingになります。

初期ポスチャステータスは、PSNによってセッションに割り当てられます。

クライアントプロビジョニングポータル

注：ステートマシンとは、ポスチャステータスの初期選択のみを記述したものです。最初に「不明」とマークされた各セッションは、後でISEポスチャモジュールから受信したレポート評価に基づいて準拠または非準拠になる可能性があります。

NADが再認証時に新しいセッションIDを生成する

これは、次の2つの最も一般的なシナリオで発生する可能性があります。

再認証がISE側で不適切に設定されています。この問題のソリューションは、このドキュメントの後半で説明します。
NAD側の誤動作。通常、NADは再認証試行中に同じセッションIDを保持します。これは、NAD自体で調査する必要がある潜在的にバグのある動作です。

新しいセッションIDは、他のコーナーケースのシナリオで生成される場合があります。たとえば、場合によっては、ワイヤレスローミングがその原因になる可能性があります。

ここで重要なことは、ISE PSNは、ポスチャリースが設定されていない限り、常に新しいセッションをポスチャ保留中状態にすることです。ポスチャリースについては、このドキュメントの後半で説明します。

古いセッションまたはファントムセッションが原因で問題が発生した時間を簡単に特定する方法

AnyConnectがリダイレクト状態にある間に、古い（ファントム）セッションが原因でコンプライアンスが示されるかどうかを確認します。問題のある状態にあるエンドポイントにアクセスする必要があります。

システムスキャンの詳細の調査：

1. AnyConnect UIで歯車アイコンをクリックします。

2. 新しいウィンドウで、「システム・スキャン」>「統計」に移動します。

ここでは、次の2つの要素に注意してください。
- Latest Scan Start Time（最新のスキャン開始時間）：このタイムスタンプは、問題が検出された時刻に近い必要があります。
- ポリシーサーバ：このフィールドは、エンドポイントのポスチャ評価を実行したポリシーサーバの名前を示しています。ここからのFQDNは、リダイレクトURLからのFQDN（リダイレクトベースポスチャの場合）、または最後の認証試行から取得されたPSN名（リダイレクトレスポスチャの場合）と比較する必要があります。
システムスキャン統計のポリシーサーバーFQDNを、エンドポイントの認証を行ったノード名と比較します。

クライアントプロビジョニングポータル

このデモでは、問題の特定に必要な手順の記録を示します。

古い/ファントムセッションの事前トラブルシューティング

前の例は、古いセッションまたはファントムセッションの問題と、開始されなかった検出プロセスの問題を区別するために役立ちます。

同時に、問題を引き起こした実際のセッションを特定し、古いセッションまたは幻のセッションの問題になる正確な状況を把握する必要があります。

一部のシナリオでは、古いセッションやファントムセッションを回避できない場合がありますが、環境で古いセッションやファントムセッションが作成されないように、ベストプラクティスを確実に実装する必要があります。

DARTバンドルの収集

問題が発生しているエンドポイントから取得したDARTバンドルを分析します。

DARTには重要なログのみを保存します。問題が再発する前に、ログをクリアすることを推奨します。

これを実現するには、DARTバンドル・ユーティリティを管理者として起動し、ログのクリーンアップを実行する必要があります。

Windowsの場合は、Startに移動し、DARTと入力して右クリックし、Run as administratorを選択します。
ウィザードの最初の画面で、[次へ]をクリックします。
次のウィザード画面でClear All Logsをクリックします。
問題が再現されたら、ここからDARTを収集できます。Nextをクリックします。

DARTバンドルの分析

DARTバンドルが収集されたら、アーカイブを解除して、Cisco AnyConnect ISE Posture ModuleフォルダにあるAnyConnect_ISEPosture.txtファイルに注目します。このファイルには、ディスカバリ関連のイベントがすべて含まれています。

クライアントプロビジョニングポータル

1. トラブルシューティングを開始し、検出の再開の瞬間をすべて特定します。検索のキーワードは「ディスカバリの再起動」または「HTTPディスカバリ」です。ここで、問題が発生した時点で検出が再開された行に移動します。

CLI出力

2. 検出の再起動後に数行が表示され、「Probling no MNT stage targets」という行が含まれています。これは、ステージ1のディスカバリ開始のインジケータです。

CLI出力

リダイレクトベースのプローブは、すべて同じ色で、以前に接続したPSNはConnectionData.xml（Auth-Statusターゲット）から取得し、異なる色で強調表示することをお勧めします。

通常、PSN FQDNは非常に似ており、その違いを見つけるのは困難です。

3. ログファイルを読み取り、プローブごとの結果を確認します。失敗したプローブの表示例を次に示します。

CLI出力

4. ステージ1またはステージ2の検出の再起動後にファイル内のどこかに、1つ以上のPSNからの正常な応答が表示されます。

CLI出力

5. 数行後に、キーワードMSG_NS_SWISS_NEW_SESSIONを含む行があります。

この行には、セッションルックアップの結果としてPSNによって選択された実際のセッションIDが含まれています。

このセッションIDを使用してISEの詳細な調査を行い、このセッションがどのように古くなった（ファントムになった）かを判断します。

CLI出力

ISEログの調査

clientwebappコンポーネントがDEBUGに対して有効になっているguest.logでは、Stale/Phantomセッションで応答するPSNを確認できます。

PSNは、ISEポスチャエージェントから要求を取得します。これは、User-Agent値が原因のAnyConnectからの要求です。

cisco.cpm.client.posture.PostureStatusServlet -::- Got http request from 192.168.255.228 user agent is: Mozilla/4.0 (compatible; WINDOWS; 1.2.1.6.1.48; AnyConnect Posture Agent v.4.6.03049)

cisco.cpm.client.posture.PostureStatusServlet -::- mac_list from http request ==> C0:4A:00:1F:6B:39

cisco.cpm.client.posture.PostureStatusServlet -::- iplist from http request ==> 192.168.255.228

cisco.cpm.client.posture.PostureStatusServlet -::- Session id from http request - req.getParameter(sessionId) ==> null

要求には、IPアドレスとMACアドレスの配列が含まれます。この特定の例では、各配列は1つの値だけを保持します。

ログには、要求のセッションIDがnullであることが示されています。これは、このIDが非リダイレクトベースのプローブからの要求であることを示しています。

配列の値を使用してセッションIDを特定する方法については、後で説明します。

cpm.client.provisioning.utils.ProvisioningUtil -::- the input ipAddress from the list currently processed in the for loop ==> 192.168.255.228

cpm.client.provisioning.utils.ProvisioningUtil -::- the ipAddress that matched the http request remote address ==> 192.168.255.228

cpm.client.provisioning.utils.ProvisioningUtil -::- the clientMac from the macarray list for the for loop index matching the ipAddress list index ==> C0-4A-00-1F-6B-39

cisco.cpm.client.posture.PostureStatusServlet -::- Found Client IP matching the remote IP 192.168.255.228, corresponding mac address C0-4A-00-1F-6B-39

cpm.client.provisioning.utils.ProvisioningUtil -::- Session = 0a3e949c000000495c216240

キーワードSent http responseの行の後に、実際の応答の内容が表示されます。

cisco.cpm.client.posture.PostureStatusServlet -::- Sent an http response to  192.168.255.228 with X-ISE-PDP=clemea19-ise1.demo.local.

cpm.client.provisioning.utils.ProvisioningUtil -::- header X-ISE-PDP value is clemea19-ise1.demo.local

cpm.client.provisioning.utils.ProvisioningUtil -::- header X-ISE-POSTURE value is /auth/perfigo_validate.jsp

cpm.client.provisioning.utils.ProvisioningUtil -::- header X-ISE-POSTURE_PORT value is 8443

cpm.client.provisioning.utils.ProvisioningUtil -::- header X-ISE-AC_PKG_PORT value is 8443

cpm.client.provisioning.utils.ProvisioningUtil -::- header X-ISE-GUESTFLOW value is false

cpm.client.provisioning.utils.ProvisioningUtil -::- header X-ISE-AC_CONFIG_URL value is https://clemea19-ise1.demo.local:8443/auth/anyconnect?uuid=f62337c2-7f2e-4b7f-a89a-3508d761173c

cpm.client.provisioning.utils.ProvisioningUtil -::- header X-ISE-AC_CONFIG_URI value is /auth/anyconnect?uuid=f62337c2-7f2e-4b7f-a89a-3508d761173c

cpm.client.provisioning.utils.ProvisioningUtil -::- header X-ISE-AC_PKG_URL value is https://clemea19-ise1.demo.local:8443/auth/provisioning/download/066ac0d6-2df9-4a2c-a129-fabf1ace36aa

cpm.client.provisioning.utils.ProvisioningUtil -::- header X-ISE-AC_PKG_URI value is /auth/provisioning/download/066ac0d6-2df9-4a2c-a129-fabf1ace36aa

cpm.client.provisioning.utils.ProvisioningUtil -::- header X-ISE-AC_PKG_VER value is 4.6.3049.0

cpm.client.provisioning.utils.ProvisioningUtil -::- header X-ISE-STATUS_PATH value is /auth/status

cpm.client.provisioning.utils.ProvisioningUtil -::- header X-ISE-BACKUP_SERVERS value is clemea19-ise2.demo.local

cpm.client.provisioning.utils.ProvisioningUtil -::- header X-ISE-SessionId value is 0a3e949c000000495c216240

cpm.client.provisioning.utils.ProvisioningUtil -::- header X-ISE-PostureDomain value is posture_domain

cpm.client.provisioning.utils.ProvisioningUtil -::- header X-ISE-POSTURE_STATUS value is Unknown

ISEレポートの調査

古い/ファントムセッションのIDがわかったら、RADIUSアカウンティングレポートを調査して、このセッションが古い/ファントムになった原因について理解を深めることができます。

Operations > Reports > Endpoints and Users > Radius Accounting reportの順に移動し、このレポートを7日間実行します。フィルタキーとしてエンドポイントIDを使用します。

古いセッションがciscolive-ise2でどのように残ったかを示すレポートの例を次に示します。

CLI出力

セッションのアカウンティングの開始がPSN ciscolive-ise2に到達しました。
セッションの中間更新が同じPSNで処理されました。
問題のあるセッションIDのアカウンティング停止メッセージが、別のPSN(ciscolive-ise1)に送信されました。

問題の原因が検出の再開がなかったことをすぐに特定できる

ここでは、前の問題と同じロジックが適用されます。唯一の違いは、最新のスキャン開始時間に集中する必要があることです。このタイプの問題では、最後のスキャンのタイムスタンプは過去のものです。

通常、エンドユーザが問題を検出すると、一定時間前に発生したスキャンが表示されます。ISE Radiusライブログでは、問題のあるエンドポイントからの最近の認証試行が確認されます。

このデモでは、問題の特定に必要な手順の記録を示します。

ディスカバリが再起動しない場合の高度なトラブルシューティング

ここでのアプローチは、「古い/ファントムセッションの高度なトラブルシューティング」セクションとよく似ています。主なトラブルシューティング要素は、DARTバンドルの調査です。

DARTバンドル内で、検出の再開を検索し（前の問題と同様）、問題が報告された時点で検出の再開がなかったことを確認できます。

ISE側でRadius Live Logs/ Radius認証レポートに注目し、PSN間でフェールオーバーが発生したか、NADによって新しいセッションIDが生成されたことを確認します。

解決方法

従来からのアプローチ：問題の回避

従来、このドキュメントで説明されている問題を解決できる機能はISEにありませんでした。そのため、唯一の方法は、ネットワークに実装されている一連のベストプラクティスに依存することであり、ISE側ではリスクを最小限に抑えることでした。

ISE導入での古いセッションやファントムセッションの量を最小限に抑えることができるベストプラクティス

可能な場合は常にリダイレクトベースのポスチャを実装する

この推奨事項に対する一般的な反論は、ユーザエクスペリエンスの低下です。OSまたはブラウザのポップアップが表示されます。これは、バックグラウンドのAnyConnect ISEポスチャモジュールが評価プロセスを実行している間のリダイレクトを示します。

この解決策として、ISEポスチャモジュールの検出プローブだけをリダイレクトし、他のすべてのトラフィックを選択的に許可することができます。

次の例は、HTTP要求だけを検出ホスト（この例では10.1.1.1）とenroll.cisco.com(172.16.1.80)にリダイレクトするように設計されたリダイレクトACLを示しています。

ip access-list extended REDIRECT-DH-ENROLL

 permit tcp any host 10.1.1.1 eq www

 permit tcp any host 172.16.1.80

 deny   ip any any

許容レベルのセキュリティを維持するために、このようなリダイレクトACLをISEから割り当てられたDACLと組み合わせることができます。

保留中の状態は、エンドポイントが認証されたPSNへの接続のみを許可します

このアプローチは、urlリダイレクションがサポートされていない環境（サードパーティのNADを使用した実装など）で役立ちます。

解決策として、複数のPosturePending認可ポリシー（PSNごとに1つ）を実装します。各ポリシーには、認証が行われたPSNの名前を条件の1つとして含める必要があります。

各ポリシーに割り当てられた認可プロファイルでは、認証が行われたノードを除くすべてのPSNへのアクセスをブロックする必要があります。

2ノード導入用の認証ポリシーを作成します。

認証ポリシー

1. PSN1のポスチャ保留中ポリシー

2. ポリシーで条件として使用されるPSN1名。

3. PSN1以外のすべてのPSNへのアクセスをブロックするACLを持つ認可プロファイル。

4. PSN2のポスチャ保留中ポリシー。

5. ポリシーで条件として使用されるPSN2名。

6. PSN2以外のすべてのPSNへのアクセスをブロックするACLを持つ認可プロファイル。

7. ポスチャ「準拠」認証ポリシー。

図は、このアプローチの仕組みを説明しています。

クライアントプロビジョニングポータル

1. 認証がPSN1にヒットします。

2. 構成された承認ポリシーの結果、PSN1は、PSN1以外のすべてのノードへのアクセスをブロックする承認プロファイルを割り当てます。

3. AnyConnect ISEポスチャモジュールがディスカバリプロセスを再起動します。

4. PSN2へのプローブが、先に割り当てられたACLのようにNADによってブロックされている。

5. PSN1へのプローブは、NADで割り当てられたACLによって許可されます。

ロードバランサのベストプラクティス

スティッキネスキーとしてCalling-Station-IDを使用して、認証およびアカウンティングのためにロードバランサのスティッキネスを有効にします。ISEのLBベストプラクティスの詳細については、ここを参照してください。
PCがスリープ状態になる瞬間（8時間ではなく10時間など）をカバーするために、平均労働時間よりも長いスティッキネスタイマーを使用します。
再認証が実装されている場合は、再認証タイマーをスティッキネスタイマーよりも少し低く設定します（たとえば、スティッキネスが10時間設定されている場合は8時間）。これにより、再認証によってスティッキ性間隔が確実に延長されます。

VPN上のポスチャの使用例

accounting-interim update intervalがvpn-session-timeout以上であることを確認します。これにより、長いVPNセッション中のPSN間のアカウンティングフラッピングが最小限に抑えられます。

この例では、20時間に設定された暫定アカウンティング更新間隔を示します。これにより、エンドポイントに割り当てられたIPアドレスを伝送する最初の暫定アップデートが阻止されることはありません。

aaa-server ISE protocol radius

 interim-accounting-update periodic 20

group-policy SSL-VPN attributes

 vpn-idle-timeout 1200

 vpn-session-timeout 1200

ベストプラクティスを実装して、ISEポスチャモジュール検出の再起動が行われないことによる影響を最小限に抑えることができます

ポスチャリースの有効化

これは、エンドポイントを定義された期間（1 ～ 365日）準拠としてマークするISEの機能です。ポスチャリース値はエンドポイント属性で、ISE DBに保存されることを意味します。

ポスチャリースを含むすべてのエンドポイント属性は、ISE導入環境のすべてのノードで複製されます。

PSNがエンドポイントポスチャの新しいセッションを取得すると、リースを使用して、セッションをすぐに準拠としてマークできます。

この決定を行うために、PSNは3つの値を使用します。これらの値は次のとおりです。

1. ISE設定でポスチャリースに対して定義された日数：Administration > System > Posture > General Settingsに移動します。

クライアントプロビジョニングポータル

2. PostureExpiry属性の値は、エポックタイムスタンプを含む実際のエンドポイント属性です。 PostureExpiryの値は、ISE管理者がポスチャリースを有効にした後にエンドポイントに対して最初に成功したポスチャ試行の際に最初に入力されます。

この値は、リースの期限切れ後に発生する次回のポスチャ試行の成功時に後で更新されます。

姿勢のエンドポイントのいずれかを開いている間に、Context Visibility > EndpointsでPostureExpiryを確認できます。

クライアントプロビジョニングポータル

この値は、人間が判読可能なタイムスタンプに変換できます。たとえば、https://www.epochconverter.com/のようになります。

クライアントプロビジョニングポータル

3. 新しい認証が行われるときのPSNシステム時間

ポスチャリースがあるエンドポイントの認証がPSNに到達すると、PostureExpiryとシステム日付を使用して、最後に正常にポスチャチェックが行われた日から経過した日数が取得されます。

結果値がsettingsで定義されたポスチャリース間隔内である場合、セッションはCompliantステータスを取得します。

結果値がリース値より大きい場合、セッションはUnknownステータスを取得します。

これにより、ポスチャが再度実行され、新しいPostureExpiry値を保存できるようになります。

次の図は、フェールオーバーが発生するプロセスを示しています。

クライアントプロビジョニングポータル

1. 初期認証はPSN1で行われます。

2. セッションABCがセッションキャッシュに作成されます。

3. ポスチャ評価が行われます。

4. セッション・ステータスがCompliantに変更される

5. COAはポスチャステータスの変更によってトリガーされ、エンドポイントの再認証によって次のアクセスレベルが適用されます。

6. PostureExpiry値がエンドポイントに保存されます。

7. エンドポイントデータは導入環境全体で複製されます。

8. 次の認証はPSN2にヒットします。

9. PSN2は、エンドポイントが有効なポスチャリース内にあるかどうかを確認します。

11. セッションが準拠としてセッションキャッシュに追加されます。

12. 有効なリースがあるため、セッションはポスチャステータスCompliantで作成されます。

再認証の実装

再認証時に接続を維持で選択したRADIUS-Requestを使用して、常に再認証タイマーをISEからプッシュします。この設定により、再認証時にNADが同じセッションIDを維持するようになります。

クライアントプロビジョニングポータル

ロードバランサを使用する環境

同じ一連のベストプラクティス（「古い/ファントムセッション」セクションで説明）を実装できます。

異なるサブネットを保留状態と準拠状態に使用できる

ネットワーク設計で異なるサブネットのPending状態とCompliant状態を使用する機会が提供される場合、このアプローチでは、ポスチャステータスのすべての変更によってデフォルトゲートウェイが変更されることが保証されます。

再認証タイマーと同じ間隔で使用されるポスチャアセスメント

ポスチャアセスメントは、再認証タイマーと同じ間隔で有効にできます。この場合、元のPSNが使用できなくなると、PRA障害によって検出プロセスが再開されます。

最新のアプローチ：ポスチャステートの共有

ISE 2.6用のパッチ6(Cisco Bug ID CSCvi35647を参照)に実装された機能拡張の一部として、ISE導入環境のすべてのノード間でセッションポスチャステータスを共有するように実装する新機能が追加されました。

この機能拡張は、ISE 2.7パッチ2およびISE 3.0の将来のリリースに統合されます。

この新機能は、ISE 2.6で導入されたライトセッションディレクトリ(LSD)メカニズムに基づいています。新しいバージョンでは、この機能の名前がLight Data Distribution(LDD)Radius Session Directoryに変更されました。 Light Data Distribution(LDD)はデフォルトで有効になっており、ISEノード間で制限されたセッションコンテキストを共有できます。 PSN間での完全なセッションコンテキストレプリケーションは存在せず、各セッションで共有される属性の量は限られています。

Light Session Directoryを使用すると、展開内のノードの1つが現在のセッションオーナーを決定する必要がある場合に、MNTに対してリソースを消費するAPI呼び出しを実行する必要がなくなります。

ほとんどの場合、COAフローの開始時に所有者のルックアップが必要になります。LDDを使用すると、すべてのPSNはローカルRADIUSセッションディレクトリキャッシュからセッションの実際の所有者を見つけることができます。

光データ分散アーキテクチャ

この機能には、次の要素が含まれています。

RADIUSセッションディレクトリ(RSD)キャッシュ

このキャッシュはすべてのISEノードに存在し、ISEの導入で提示されたすべてのアクティブセッションを保存します。各セッションのキャッシュ内の属性の量は限られています。

各セッションのRADIUSセッションディレクトリに保存される属性の例を次に示します。

セッションID
エンドポイントMAC
通話ステーションID
エンドポイントIP
PSN IP：認証が行われたPSN
PSNのFQDN
nas-ip-address
NAS-IPv6アドレス
状態 – 認証済み、開始済み、停止中

RabbitMQ交換

ISE導入環境のすべてのノードで、パブリッシャ、関連するキュー、およびコンシューマが表示される交換が形成されます。これにより、すべてのISEノード間で完全メッシュトポロジが形成されます。

発行者

RADIUSセッションディレクトリは、ここでパブリッシャを表します。新しい正常な認証がPSNによって処理されると、新しいセッションがPSNセッションキャッシュに作成されます。

このセッションでは、限られた属性セットがRadiusセッションディレクトリに配置されます。

コンシューマ：他のすべてのノード上。Radiusセッションディレクトリはコンシューマを表します。

注:RabbitMQの一般的な用語とアーキテクチャについては、このドキュメントでは扱いません。

図は、COAフローがRSDキャッシュでどのように動作するかを示しています。

クライアントプロビジョニングポータル

1. 初期認証はPSN1で行われます。

2. セッションABCがセッションキャッシュに作成されます。

3. 必要な属性がRSDに保存されます。

4. セッションは、他のすべてのISEノードとRabbitMQで共有されます。

5. すべてのISEノードのRSDキャッシュにセッションが作成されます。

6. 新しいプロファイルデータがPSN2に到着します。

7. エンドポイントがプロファイリングされ、（COA実行PSN2を必要とする変更の場合）次のステップに進みます。

8. 内部APIコールがRSDキャッシュに送信され、COAが実行されます。

9. RSDキャッシュからのデータは、プロキシCOAメッセージを準備するために使用されます。ISEノード間で送信され、宛先ノードがNADにCAO要求を返すために使用できるすべての詳細が含まれます。COAメッセージは、最初に内部でPRRTランタイム（ISE内の実際のAAAサーバ）に転送されます。

10. PSN2がCOAメッセージをPSN1に送信します。

11. PSN1がCOAメッセージをNADに送信します。

ISE上のLDDを介した通信のトラブルシューティングを行うには、デバッグでLight Session Directorコンポーネントを有効にします。

クライアントプロビジョニングポータル

元のPSNでのセッションの作成と公開に使用するlsd.logファイルからのデバッグメッセージの例を次に示します。

DEBUG  [pool-45-thread-6][] cisco.cpm.lsd.service.LSDRedisClient -::::- Mapping Session ID 0a3e9498000008e05e071990 to session {"sessionID":"0a3e9498000008e05e071990","endpointMAC":"C0-4A-00-1F-6B-39","callingStationId":"c0-4a-00-1f-6b-39","ipv6AdressLst":[],"psnIP":"192.168.43.26","deviceIP":"192.168.255.102","destinationIP":"192.168.43.26","nasIP":"192.168.255.102","auditSessionID":"0a3e9498000008e05e071990","acctSessionID":"5e07197b/c0:4a:00:1f:6b:39/2299","timeStamp":1577523495,"status":"Started","id":"614f6c44-6c78-4289-b9fd-b352ff012ca4"}

DEBUG  [PrRTEvents-Executor-2][] cisco.cpm.lsd.service.LSDNetAccessEventListener -::::- Publishing session update for session 0a3e9498000008e05e071990

DEBUG  [PrRTEvents-Executor-2][] cisco.cpm.lsd.service.SessionPublisher -::::- Forwarding session 07a26b4b-ea13-438b-99b5-0bbadc9d8bac to batch manager

他のすべてのISEノードで、セッションがどのように消費されたかを確認します。

[pool-35-thread-38][] cisco.cpm.lsd.service.SessionConsumer -::::- Consumer is processing : sessionID:[0a3e9498000008e05e071990] status:[Started] id:[614f6c44-6c78-4289-b9fd-b352ff012ca4] auditSessionID:[0a3e9498000008e05e071990] accountingSessionID:[5e07197b/c0:4a:00:1f:6b:39/2299] endpointMAC:[C0-4A-00-1F-6B-39] callingStationId: [c0-4a-00-1f-6b-39] endpointIP:[null], IPv6 : [[]], psnIP:[192.168.43.26] deviceIP:[192.168.255.102] destinationIP:[192.168.43.26] nasIP:[192.168.255.102] nasIPv6:[null] timeStamp:[1577523495]

RSDでのポスチャステータスの共有

ポスチャステータスの共有は、根本原因が古い/ファントムセッションまたは異なるPSNでの再認証で、ディスカバリの再起動がトリガーされなかった場合の問題を解決します。

セッションが準拠になると、この情報はセッションRSDに配置され、後で導入環境内のすべてのPSNで使用できるようになります。

説明したフィーチャでは解決できないコーナーのケースが他にもあります。たとえば、NADが同じPSNで異なるセッションIDを使用して再認証を実行する場合です。

このようなシナリオは、このドキュメントで説明するベストプラクティスを使用して処理できます。

次の図は、ポスチャステータス共有のテストに使用されるトポロジを示しています。

Network

RSDを介したポスチャステータスの共有：古い/ファントムセッション

古いセッションを作成するには、まずskuchere-ise26-1で認証を実行する必要があります。次に、skuchere-ise26-3にアカウンティングを送信するようにNADを再設定する必要があります。

1つのアカウンティングメッセージが誤ったPSNに転送された後、アカウンティングをskuchere-ise26-1に返信するためにNADを（再度）再設定する必要があります。

図は、skuchere-ise26-3のファントムセッションの存在を証明するアカウンティングレポートを示しています。

Phantom_session_accounting_report（ファントムセッションアカウンティングレポート）

1. skuchere-ise26-1で処理されるaccounting-startメッセージ。

2. skuchere-ise26-3で処理された同じセッションの中間アカウンティング更新。

3. skuchere-ise26-1でセッションが終了します。

しばらくすると、エンドポイントは再びネットワークに接続しますが、リダイレクションが機能しなくなります。PSN - skuchere-ise26-3のguest.logでは、client-webappコンポーネントが有効になっている次のログメッセージがDEBUGで表示されます。

2020-04-08 13:30:48,217 DEBUG [https-jsse-nio-192.168.43.226-8443-exec-4][] cisco.cpm.client.posture.Util -::- Local session 0A3E946C0000007D5B679296 is stale. Newer session for 00-50-56-B6-0B-C6 is 0A3E946C000000805B7C43A3. Owned by skuchere-ise26-1.example.com

エンドポイントの古い/ファントムセッションを保持していることをPSNが検出すると、ISEポスチャモジュールに応答しないため、最新の認証が発生したPSNから正しい応答を取得できます。

セッションルックアップ時の期限切れ/ファントムセッション問題の解決策として、PSNはRSD内のエンドポイントに対する新しいセッションの存在を確認します。

RSDにローカルセッションキャッシュ内のPSNのセッションIDと異なるセッションIDが含まれている場合は、（セッションキャッシュ内に存在する）セッションが古いと見なされます。

RSDでのポスチャステータスの共有 – PSN間のフェールオーバー

このシナリオを再現するには、準拠する状態のエンドポイントに割り当てられた認可プロファイルで短い再認証タイマーが有効になります。

その後、NADが再設定され、認証とアカウンティングが別のPSN(skuchere-ise26-3)に送信されます。

再認証タイマーが期限切れになると、同じセッションが異なるPSNで認証されなくなります。

図は、skuchere-ise26-1からskuchere-ise26-3への同じセッションのフェールオーバーを示す認証レポートを示しています。

PSN間のフェールオーバー

1. skuchere-ise26-1で認証が行われ、リダイレクションを伴う認可プロファイルが割り当てられます。

2. ポスチャ評価が成功した後のCOA。

3. 準拠状態の認証プロファイルが割り当てられたときの次の認証。

4. 認証は異なるPSNにヒットしますが、準拠する状態の認可プロファイルを取得します。

epm-pipおよびnsf-sessionコンポーネントがDEBUGで有効にされたise-psc.logでフェールオーバーした後、セッションの新しいPSNでのステータスは準拠しています。

2020-04-09 11:06:42,176 DEBUG [Thread-7979][] cpm.nsf.session.impl.SessionCache -::::- Looking up session 0A3E946C000000896011D045 for attribute Session Session.PostureStatus
2020-04-09 11:06:42,176 DEBUG [Thread-7979][] cpm.nsf.session.api.ExecutionContext -::::- Execution context has session id 0A3E946C000000896011D045
2020-04-09 11:06:42,176 DEBUG [Thread-7979][] cpm.nsf.session.impl.PIPManager -::::- Returning a PIP com.cisco.cpm.nsf.session.impl.SessionPIP for type SESSION and flow null
2020-04-09 11:06:42,176 DEBUG [Thread-7979][] cpm.nsf.session.api.ExecutionContext -::::- Execution context has session id 0A3E946C000000896011D045
2020-04-09 11:06:42,176 DEBUG [Thread-7979][] cpm.nsf.session.impl.SessionCache -::::- Looking up session 0A3E946C000000896011D045
2020-04-09 11:06:42,176 DEBUG [SessionLifecycleNotifier][] cpm.nsf.session.internal.LRUAgingAlogrithm -::::- Accessed session 0A3E946C000000896011D045
2020-04-09 11:06:42,176 DEBUG [Thread-7979][] cpm.nsf.session.impl.SessionCache -::::- Returning for session 0A3E946C000000896011D045 data Attrs: {SavedUserNames=[bob@example.com], Acs.LastStepTime=1586423202174, Acs.AD-User-Qualified-Name=bob@example.com, Acs.AD-User-Resolved-DNs=CN=bob,CN=Users,DC=example,DC=com, Acs.StepData=[110=EXAMPLE, 111=bob@example.com, 112=example.com, 113=example.com, 115=example.com, 116=EXAMPLE], Acs.AD-Log-Id=[1585911138/4778, 1585911138/4779], __IntIdGrps__=[Ljava.lang.String;@6d3c29b5, IdentityGroup.Description=[Ljava.lang.String;@3fca88fb, EXAMPLE.ExternalGroups=S-1-5-21-875452798-754861120-3039794717-513, Acs.AD-Groups-Names=example.com/Users/Domain Users, Acs.AuthenCPMSessionID=0A3E946C000000896011D045, Acs.IsMachineAuthentication=false, InternalEndpoint.IdentityGroup=[Ljava.lang.String;@6daf4c5, IDStoreUserQueryCache=[EXAMPLE#bob@example.com], Acs.CurrentIDStoreName=EXAMPLE, Acs.AD-User-Join-Point=EXAMPLE.COM, Acs.Step=[24432, 24325, 24313, 24319, 24323, 24355, 24416], Acs.CustomerMessageDuplicator=, Network Access.WasMachineAuthenticated=false, IdentityGroup.Name=[Ljava.lang.String;@570ab37a, Acs.StepDataStart=110, Acs.AD-User-DNS-Domain=example.com, Network Access.AuthenticationMethod=4, Acs.AD-User-Resolved-Identities=bob@example.com, InternalUser.IdentityGroup=[Ljava.lang.String;@51a6caed, Acs.AuthenticationMethod=4, Acs.AD-User-NetBios-Name=EXAMPLE, Normalised Radius.RadiusFlowType=0, Network Access.AuthenticationIdentityStore=EXAMPLE, EXAMPLE.IdentityAccessRestricted=false, Acs.AD-User-SamAccount-Name=bob}
IndexValues: {}

2020-04-09 11:06:42,177 DEBUG [Thread-7979][] cisco.cpm.posture.pip.PostureStatusPIP -::::- set postureStatus based on posture LSD dictionary: Compliant
2020-04-09 11:06:42,177 DEBUG [Thread-7979][] cisco.cpm.posture.pip.PostureStatusPIP -::::- PostureStatusPIP for mac 00-50-56-B6-0B-C6 - Attribute Session.PostureStatus value is Compliant

元の問題は、ポスチャステータス選択プロセスに追加のロジックを追加することで解決されます。

次の図は、変更内容（赤で強調表示された変更）を示しています。

プロセス

更新履歴

改定	発行日	コメント
2.0	31-May-2023	再認定
1.0	22-Apr-2020	初版

シスコエンジニア提供

セルヒイ・クチェレンコ

ISEセッション管理とポスチャのトラブルシューティング

偏向のない言語

翻訳について

内容

はじめに

背景説明

問題

エンドユーザエクスペリエンス

ISE管理エクスペリエンス

一般的な問題のあるシナリオ

古い/ファントムセッションの問題

ISEセッション管理ロジック

MNTおよびセッション管理

PSNおよびセッション管理

PSN上の古いセッション

PSNでのファントムセッション

古いセッションとファントムセッションによるポスチャプロセスの中断

新しい認証の試行時に検出プロセスが開始されない

異なるPSNでの再認証

NADが再認証時に新しいセッションIDを生成する

古いセッションまたはファントムセッションが原因で問題が発生した時間を簡単に特定する方法

古い/ファントムセッションの事前トラブルシューティング

DARTバンドルの収集

DARTバンドルの分析

ISEログの調査

ISEレポートの調査

問題の原因が検出の再開がなかったことをすぐに特定できる

ディスカバリが再起動しない場合の高度なトラブルシューティング

解決方法

従来からのアプローチ：問題の回避

ISE導入での古いセッションやファントムセッションの量を最小限に抑えることができるベストプラクティス

ベストプラクティスを実装して、ISEポスチャモジュール検出の再起動が行われないことによる影響を最小限に抑えることができます

最新のアプローチ：ポスチャステートの共有

光データ分散アーキテクチャ

RSDでのポスチャステータスの共有

RSDを介したポスチャステータスの共有：古い/ファントムセッション

RSDでのポスチャステータスの共有 – PSN間のフェールオーバー

更新履歴

シスコ エンジニア提供

このドキュメントは役に立ちましたか?

シスコに問い合わせ

このドキュメントは次の製品に対応しています

シスコエンジニア提供