ISEセッション管理およびポスチャのトラブルシューティング
内容
はじめに
このドキュメントでは、「AnyConnect ISEポスチャモジュールは準拠を示す」などの一般的なIdentity Service Engine(ISE)ポスチャサービスの問題について説明します。
バックグラウンド情報
このドキュメントでは、一般的なIdentity Service Engine(ISE)ポスチャサービスの問題「ISEのセッションステータスが保留中の間、AnyConnect ISEポスチャモジュールは準拠を示す」について説明します。
症状は常に同じですが、この問題には複数の根本原因があります。このような問題のトラブルシューティングは非常に時間がかかることが多く、重大な影響を及ぼします。
このドキュメントでは、次の項目を説明しています。
- 一般的な問題のあるシナリオ
- 問題を迅速に特定するアルゴリズム
- 一般的な問題のあるシナリオに対する古典的な解決策。
- RADIUSセッションディレクトリでのポスチャステータスの共有
- エンドユーザおよびISE管理者の観点からの問題表示
- ISE、AnyConnect、およびネットワーク動作の背後にある理論が、問題を引き起こします。
後で説明する概念の詳細な説明については、『2.2前後のISEポスチャスタイルの比較』を参照してください。
問題
エンドユーザエクスペリエンス
通常、この問題は、ブラウザにISEクライアントプロビジョンポータルへのネットワークアクセスや継続的なリダイレクションがない場合に発生しますが、同時に、AnyConnect ISEポスチャモジュールはポスチャステータスをCompliantとして示します。
一般的なエンドユーザエクスペリエンス：
ISE管理エクスペリエンス
この問題を最初に試みると、ISE管理者は認証がISEにヒットすることを確認するためにRADIUSライブログの調査を開始します。この段階で検出される最初の症状は、ライブログでのエンドポイントとISE間のポスチャステータスの不一致を示します。または、エンドポイントのRadius認証レポートに、最後に成功した認証がPendingポスチャステータスとして表示されます。
一般的なISE管理エクスペリエンス：
- 最後に成功したIDの認証：alice。
- セッションのポスチャステータスはPendingです。
- アイデンティティの最後のセッションイベント：alice。
- セッションイベントでは、ポスチャステータスがCompliantと表示されます。
一般的な問題のあるシナリオ
通常、この問題は2つの問題のあるシナリオで発生し、それぞれのシナリオには複数の根本原因があります。シナリオ：
- ポスチャプロセス中にポリシーサービスノード(PSN)からAnyConnect ISEポスチャモジュールに誤った通知が送信されたため、誤ったポスチャステータスが表示されました。この場合、TACは通常、PSNセッションキャッシュ内の古いセッションまたはファントムセッションを使用して動作します。
- 現在の認証ではディスカバリプロセスがトリガーされなかったため、AnyConnect ISEには前のディスカバリサイクルのポスチャステータスが表示されます。
AnyConnectのISEポスチャモジュールには、検出プロセスをトリガーするイベントの数が制限されています。認証または再認証中に、これらのイベントがまったく検出されなかった可能性があります。
古い/ファントムセッションの問題
問題をよりよく理解するために、必要なISEセッション管理ロジックとAnyConnect検出プロセスを調査します。
ISEセッション管理ロジック
ISEの導入では、セッション管理プロセスを担当するPSNとモニタリングノード(MNT)の2人の担当者が存在します。 問題を適切にトラブルシューティングして特定するには、両方のペルソナのセッション管理理論を理解することが重要です。
MNTおよびセッション管理
次の図で説明するように、MNTノードは、PSNから送信される渡された認証Syslogメッセージに基づいてシーズンを作成します。セッションステータスは、アカウンティングのためにSyslogによって後で更新できます。
MNTでのセッションの削除は、次の3つのシナリオで行われます。
1.アカウンティングを使用しないセッションは、作成してから約60分後に削除されます。セッションステータスとクリーンを確認するために、5分ごとに実行されるcronジョブがあります。
2. 終了したセッションは、同じcronジョブによってアカウンティングの停止が処理されてから約15分後に削除されました。
3. 各実行の同じcronが、「Started」状態のセッションを5日間（120時間）以上削除します。「started」状態とは、MNTノードが認証とアカウンティングの両方を処理してSyslogセッションを開始したことを意味します。
注：これらは通常のMnTクリーンアップタイマーであり、ウォールクロックの削除時間は保証されていません。次の場合、削除が遅れる可能性があります。
- SessionPurgeJobが正常に実行されていません。
- MnTはリソースまたはデータベースのプレッシャーにさらされています。
- Accounting-Stopを既存のセッションに関連付けることはできません。
PSNからのsyslogメッセージの例：
runtime-aaaコンポーネントが有効になっている場合、メッセージは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には、あるノードから別のノードに完全なセッション状態のレプリケーションを実行できるメカニズムはありません。
PSNは、アクティブなセッションIDごとに、認証/許可フェーズで収集されたすべての属性(内部/外部ユーザグループ、ネットワークアクセスデバイス(NAD)属性、証明書属性など)を格納します。 これらの属性は、認証、認可、クライアントプロビジョニング、ポスチャなど、さまざまなポリシータイプを選択するためにPSNによって使用されます。
ノード（またはノード上のサービス）が再起動すると、セッションキャッシュは完全に削除されます。
現在のセッション処理ロジックでは、2つのシナリオでセッションキャッシュに新しいエントリが作成されます。既存のセッションの詳細は、NADから送信されるアカウンティングメッセージから更新できます。
- セッションはPSNで正常に認証されました。
- PSNには、セッションキャッシュに存在しないセッションのアカウンティング中間更新があります。セッションを削除すると、PSNは次のロジックを実装します。
- セッションキャッシュエントリは、アカウンティング停止メッセージの処理の直後に削除されます。
- ノードがアクティブセッションの制限に達すると、PSNは最も最近使用されていないセッションの削除を開始します。
PSN上の古いセッション
ISEの導入では、既存のセッションのアカウンティング停止が、実際の認証を実行しなかったPSNによって処理されました。
古いセッションの例：
- セッションABCのPSNで認証に成功します。
- PSNは、セッションキャッシュにエントリを作成します。
- ポスチャ評価が行われます。
- セッションが準拠としてマークされている。
- 認可変更(COA)は、ポスチャステータスの変更によってトリガーされ、エンドポイントの再認証によって次のアクセスレベルが適用されます。
- セッションABCからPSN2へのアカウンティングが停止します。
その後、ABCはPSN1上で古い状態のままになります。このPSN上では、これを削除するためのアカウンティング停止メッセージが処理されていないためです。展開で認証試行の回数が多くない場合、セッションは削除されます。
次のシナリオでは、古いセッションがPSNセッションキャッシュに表示されます。
- ロードバランサーのスティッキネスタイマーの有効期限が切れたため、アカウンティングの停止が正しくないPSNに送信されました。
- NADの誤った設定は、認証とアカウンティング用に設定されたPSNと同じではありません。
- ネットワークパスの一時的な接続の問題により、次のPSNへのNADフェールオーバーが発生しました。
ロードバランサ(LB)環境での古いセッションの例：
- セッションABCの初期認証はPSN1によって実行されます。この認証により、ロードバランサのスティッキネスタイマーが開始されます。
- PSN1は、セッションABCのエントリをローカルキャッシュに作成します。
- 渡された認証のSyslogメッセージがMNTノードに転送されます。
- セッションABCのエントリが、Authenticated 状態のMNTセッションディレクトリに作成されます。
- セッションABCのアカウンティング開始メッセージはPSN1に到着します。
- セッションABCのセッションキャッシュエントリが、Accounting-Startからの情報で更新されます。
- Accounting-StartのSyslogメッセージがMNTノードに転送されます。
- セッションの状態がStartedに更新されます。
- スティッキネスタイマーはロードバランサーで期限切れになります。
- セッションABCのアカウンティング停止は、ロードバランサによってPSN2に転送されます。
- Accounting-StopのSyslogメッセージがPSN2によってMNTに転送されます。
- セッションABCはMNT上で終了したとマークされています。
PSN上のファントムセッション
ファントムセッションは、アカウンティングの暫定アップデートがPSNに到達し、そのセッションの認証を実行しなかったシナリオです。このシナリオでは、新しいエントリがPSNセッションキャッシュに作成されます。PSNがこのセッションのアカウンティング停止メッセージを受信しない場合、PSNがアクティブセッションの制限に達しない限り、エントリは削除されません。
ファントムセッションの例：
- 失効したセッションの例で説明した同じ手順が、ABCセッションのPSN1で発生します。
- セッションABCのPSN1セッションキャッシュでのステータスはCompliantです。
- セッションABCのアカウンティング暫定アップデートがPSN2にヒットします。
- ABCのセッションエントリがPSN2に作成されます。セッションエントリはアカウンティングメッセージから作成されるため、限られた数の属性を持ちます。たとえば、セッションABCではポスチャステータスを使用できず、ユーザグループや他の認可固有の属性も存在しません。
ファントムセッションは、次のシナリオのPSNセッションキャッシュに表示されます。
- ネットワークを通過する際の一時的な停止。
- ネットワークアクセスデバイスの誤動作。
- ロードバランサの誤動作または設定の誤り。
次のスクリーンショットは、PSN1へのネットワークパスで一時的な問題が発生するファントムセッションの例です。
- セッションABCの初期認証はPSNによって実行されます。
- PSN1は、セッションABCのエントリをローカルキャッシュに作成します。
- 成功した認証のsyslogメッセージがMNTノードに転送されます。
- セッションABCのエントリが、状態AuthenticatedでTimesTen DBに作成されます。
- セッションABCの会計開始メッセージはPSN 1に到着します。
- セッションABCのセッションキャッシュエントリが、Accounting-Startからの情報で更新されます。
- Accounting-StartのSyslogメッセージがMNTノードに転送されます。
- セッションの状態がStartedに更新されます。
- セッションABCの暫定アカウンティングアップデートがPSN2に転送されます。
- PSN2は、セッションABCのエントリをローカルキャッシュに作成します。
- セッションABCのアカウンティング停止はPSN1に転送されます。
- セッションABCのエントリがPSN1のセッションキャッシュから削除されます。
- Accounting-StopのSyslogメッセージがPSN1によってMNTに転送されます。
- セッションABCはMNTで終了したとマークされています。
次の図は、長時間のVPN接続のために作成されたファントムセッションのシナリオを示しています。
- PSN1での初期認証。
- セッションABCはセッションキャッシュに作成されます。
- アカウンティングは、PSNによって処理されるメッセージを開始します。
- 新しいIPアドレスがバーチャルプライベートネットワーク(VPN)アダプタに割り当てられます。
- IPアドレス情報を含む暫定アカウンティングアップデートがPSNに到達します。
- IPアドレス情報がセッションキャッシュに追加されます。
- ポスチャ評価はPSN1で実行されます。
- セッションでポスチャステータスが更新されます。
- COAプッシュがISEによって実行され、これにより新しいアクセスレベルが割り当てられます。
- ネットワークパスで停止が発生し、PSN1にアクセスできなくなります。
- 暫定アップデート間隔の満了後、ASA/FTDはPSN1にアクセスできないことを検出します。
- 暫定アカウンティングアップデートがPSN2に到着します。
- ファントムセッションが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 Secure Mobility Client\ISE Posture\です。
すべてのステージ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が古いセッションまたはファントムセッションを保持している場合に、ポスチャがどのように表示されるかを示しています。
- ISEポスチャモジュールによって発行されたFind my sessionプローブのいずれか。
- PSNは、セッションキャッシュでセッションルックアップを実行します。セッションが見つからない場合は、古いセッションまたはファントム・セッションの問題が発生します。
- PSNは、クライアントプロビジョニングポリシーの選択を実行します。ファントムセッションに認証/許可属性がなく、ユーザーによって構成されたすべてのポリシーが固有である場合（たとえば、特定のActive Directoryグループに対してポリシーが作成される場合）、PSNは正しいクライアントプロビジョニングポリシーを割り当てることができません。これは、エラーメッセージ「Bypassing AnyConnect scan your network is not configured to use Cisco NAC Agent」で明らかになります。
- クライアントプロビジョニングポリシーが汎用の場合（ファントムセッションで使用可能な属性が、ポリシーとAnyConnect設定を一致させるのに十分である場合）、PSNは評価プロセスを続行するために必要な詳細で応答します。
- このステップでは、古いセッションを使用して作業している場合、PSNはポスチャステータスCompliantですぐに応答し、次のステップはすべて完了しません。PSNは、セッションがすでに準拠していると見なすため、COAを送信しません。RADIUSライブログに、Compliantステータスを示すセッションイベントが表示されません。
4. ファントムセッションシナリオでは、ISEポスチャモジュールは初期ポスチャ要求を続行します。この要求には、エンドポイントで検出されたすべてのセキュリティおよびパッチ管理製品に関する情報が含まれます。
5. PSNは、要求およびセッション属性からの情報を使用して、適切なポスチャポリシーに一致させます。この時点でファントムセッションには属性がなく、一致するポリシーはありません。この場合、PSNは準拠していることをエンドポイントに応答します。ポスチャポリシーが一致しない場合、これはデフォルトのISE動作です。
6. PSNは、選択されたポスチャポリシーをエージェントに返します。
7. エージェントは、各ポリシー/要件のステータスを「成功」または「失敗」として返します。
8. レポートの評価がISEで行われ、セッションステータスがCompliantに変わります。
新しい認証の試行時に検出プロセスが開始されない
ISEポスチャモジュールは、検出プロセスをトリガーするためにエンドポイントで限られた量のイベントを監視するように設計されています。
検出をトリガーするイベント：
- ISEポスチャモジュールの初期インストール。
- ユーザログイン。
- 電源イベント。
- インターフェイスのステータス変更。
- スリープ後にOSが再開します。
- デフォルトゲートウェイ(DG)の変更
- ポスチャ再評価(PRA)の失敗。Cisco Bug ID CSCvo69557を参照してください。新しいdot1x認証、PCロック解除、およびIPアドレスの変更がISEポスチャモジュールによって検出されません。
ISEポスチャモジュールは、次のシナリオで新しい認証または再認証の試行を検出できません。
- 再認証が異なるPSNにヒットする（LBの決定または元のPSNの問題のいずれか）
- NADは、再認証時に新しいセッションIDを生成します。
異なるPSNでの再認証
次の図は、元のPSNの停止が原因で発生した、別のPSNでの再認証の例を示しています。ロードバランサのシナリオも同様です。ロードバランサの場合、スティッキネスタイマーが期限切れになると、再認証は別のPSNに送信されます。
- PSN1での初期認証。
- セッションABCがPSN1セッションキャッシュに作成されます。
- ポスチャ評価はPSN1で実行されます。
- セッションABCポスチャステータスがCompliantに移行します。
- COAはポスチャステータスの変更によってトリガーされ、エンドポイントの再認証によって次のアクセスレベルが適用されます。
- PSN1が使用できなくなります。
- セッションABCの再認証がPSN2にヒットします。
- PSN2の新しいセッションであるため、セッションのポスチャステータスはPendingに変わります。
初期ポスチャステータスは、PSNによってセッションに割り当てられます。
NADが再認証時に新しいセッションIDを生成する
これは、次の2つの最も一般的なシナリオで発生する可能性があります。
- 再認証がISE側で不適切に設定されています（この問題のソリューションについては、このドキュメントで後述します）。
- NAD側の誤動作。通常、NADは再認証試行中に同じセッションIDを保持します。これはバグが発生する可能性のある動作であり、NADで調査する必要があります。
- 新しいセッションIDは、他のシナリオでも生成できます。たとえば、場合によっては、ワイヤレスローミングが原因である可能性があります。
- ISE PSNは、ポスチャリースが設定されていない限り、常に新しいセッションをポスチャPending状態にします。ポスチャリースについては、このドキュメントの後半で説明します。
古い/ファントムセッションによって問題が発生した時期を特定する簡単な方法
リダイレクト状態にあるときに、古い/ファントムセッションが原因でAnyConnectがコンプライアンスを示しているかどうかを識別します。問題のある状態のエンドポイントにアクセスできる必要があります。
システムスキャンの詳細の調査
1. AnyConnect UIで歯車アイコンをクリックします。
2. 新しいウィンドウで、「システム・スキャン」>「統計」に移動します。
次に、2つの重要な要素に注意してください。
- Latest Scan Start Time（最新のスキャン開始時刻）：ここで表示されるタイムスタンプは、問題が検出された時刻に近い必要があります。
- ポリシーサーバ：このフィールドは、エンドポイントのポスチャ評価を実行するポリシーサーバの名前を示します。FQDNは、リダイレクトURLからのFQDN（リダイレクトベースポスチャの場合）、または最後の認証試行から取得されたPSN名（リダイレクトレスポスチャの場合）と比較する必要があります。
- システムスキャン統計情報のポリシーサーバFQDNを、エンドポイントの認証を行ったノード名と比較します。
このデモでは、問題の特定に必要な手順の記録を示します。
古い/ファントムセッションの事前トラブルシューティング
前の例では、古いセッションまたはファントムセッションの問題と、開始されなかった検出プロセスの問題を区別しています。同時に、問題を引き起こした実際のセッションを特定して、古いセッションまたはファントムなセッションの問題になる仕組みを理解する必要があります。一部のシナリオでは、古いセッションやファントムセッションを回避できない場合がありますが、環境で古いセッションやファントムセッションが作成されないようにするために、ベストプラクティスが実装されていることを確認する必要があります。
DARTバンドルの収集
問題が発生しているエンドポイントから取得したDARTバンドルを分析します。
- DARTには重要なログのみを保存し、問題が再現される前にログを消去することを推奨します。
- これを実現するには、DARTバンドル・ユーティリティを管理者として起動し、ログのクリーンアップを実行する必要があります。
- Windowsの場合は、Startに移動し、DART > right-clickと入力して、- Run as Administratorを選択します。
4. ウィザードの最初の画面で、Nextをクリックします。
5. 次のウィザード画面で、Clear All Logsをクリックします。
6. 問題が再現されたら、ここからDARTを収集できます。Nextをクリックします。
DARTバンドルの分析
DARTバンドルが収集された後、アーカイブを解除して、Cisco AnyConnect ISE Posture ModuleフォルダにあるファイルAnyConnect_ISEPosture.txtに注目します。このファイルには、ディスカバリ関連のイベントがすべて含まれています。
1. トラブルシューティングを開始し、検出の再開の瞬間をすべて特定します。検索のキーワードは、ディスカバリの再起動またはHTTPディスカバリです。問題が発生した瞬間に検出が再起動した行に移動します。
2. ディスカバリが再起動してから数行が経過した後、「Proving no MNT stage targets （MNTステージのターゲットをプローブしていません）（これはステージ1のディスカバリ開始のインジケータです）:
3. リダイレクトベースのプローブでは、ConnectionData.xml（Auth-Statusターゲット）から取得した同じ色と以前に接続したPSNが別の色で強調表示されることを推奨します。通常、PSNのFQDNは似ており、違いを見分けるのが難しい場合があります。
4. ログファイルを読み、各プローブの結果を確認します（失敗したプローブの例を以下に示します）。
5. ステージ1またはステージ2のディスカバリ再起動後にファイルのどこかで、1つ以上のPSNからの正常な応答が表示されます。
5. 数行後、キーワードMSG_NS_SWISS_NEW_SESSIONの行があります。 この行には、セッションルックアップの結果としてPSNによって選択された実際のセッションIDが含まれています。このセッションIDを使用してISEの詳細な調査を行い、セッションが期限切れまたはファントムになった方法を特定します。
ISEログの調査
1. client-webappコンポーネントがイネーブルになっているguest.logでDEBUGに対して、PSNがStale/Phantomセッションで応答します。この応答は確認できます。
2. 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
3. 要求にIPアドレスとMACアドレスの配列が含まれている。この例では、各配列は1つの値だけを保持します。ログには、要求のセッションIDがnullであることが示されます。これは、リダイレクトに基づかないプローブからの要求であることを示します。 後で、配列の値を使用してセッション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
4. キーワードが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をフィルタキーとして使用します。
2. これは、古いセッションがciscolive-ise2でどのように残ったかを示すレポートの例です。
- セッションのアカウンティングの開始は、PSN ciscolive-ise2に到達しました。
- セッションの中間更新が同じPSNで処理されました。
- 問題のあるセッションIDのアカウンティング停止メッセージが別のPSN(ciscolive-ise1)に送信されました。
ディスカバリの再起動がないことが原因で問題が発生したことを特定する方法
前の問題にも同じロジックが適用されますが、唯一の違いは、最新のスキャン開始時間に集中する必要があることです。このタイプの問題では、最後のスキャンのタイムスタンプは過去のものです。
通常、エンドユーザが問題を検出すると、スキャンが実行されます。ISE Radiusライブログでは、問題のあるエンドポイントからの最近の認証試行が確認されます。
このデモでは、問題の特定に必要な手順の記録を示します。
高度なトラブルシューティング：ディスカバリが再起動しない
このアプローチは、「古い/ファントムセッションの高度なトラブルシューティング」セクションと似ています。 主なトラブルシューティング要素は、DARTバンドルの調査です。
DARTバンドル内で、検出の再開を検索し（前の問題と同様）、問題が報告された時点で検出の再開がなかったことを確認できます。
ISE側でRadius Live Logs/Radius認証レポートに注目し、PSN間でフェールオーバーが発生したか、NADによって新しいセッションIDが生成されたことを確認します。
ソリューション
従来からのアプローチ：問題の回避
従来、このドキュメントで説明されている問題を解決する機能はISEにはありませんでした。そのため、リスクを最小限に抑えるために、ネットワークとISE側に実装されている一連のベストプラクティスに依存するしかありません。
ISE導入で古いセッションやファントムセッションの数を最小限に抑えるためのベストプラクティス
可能な場合は常にリダイレクトベースのポスチャを実装する
この推奨事項に対する一般的な反論は、OSに「bad user experience」が表示される、またはブラウザが表示されるというものです。これは、バックグラウンドで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を使用した実装）で役立ちます。
解決策として、複数のポスチャ保留中認証ポリシーを実装します（PSNごとに1つ）。 各ポリシーには、条件の1つとして、認証が行われたPSNの名前が含まれている必要があります。認可プロファイルでは、認証が発生したノードを除くすべてのPSNをブロックする必要があります。
2つのノードの認可ポリシーを作成します。
- PSN1のポスチャ保留中ポリシー。
- PSN1名は、ポリシーの条件として使用されます。
- ACLを使用する認可プロファイルは、PSN1を除くすべてのPSNへのアクセスをブロックします。
- PSN2のポスチャPendingポリシー
- ポリシーの条件としてPSN2名が使用されます。
- ACLを使用する認可プロファイルは、PSN2を除くすべてのPSNへのアクセスをブロックします。
- ポスチャの「準拠」認可ポリシー。
次の図に、このアプローチの仕組みを示します。
- 認証がPSN1にヒットします。
- 設定された承認ポリシーの結果として、PSN1は承認プロファイルを割り当てます。このプロファイルは、PSN1以外のすべてのノードへのアクセスをブロックします。
- AnyConnect ISEポスチャモジュールがディスカバリプロセスを再起動します。
- PSN2へのプローブは、以前に割り当てられたACLと同様にNADによってブロックされます。
- PSN1へのプローブは、NADで割り当てられたACLによって許可されます。
ロードバランサのベストプラクティス
- スティッキネスキーとしてCalling-Station-IDを使用して、認証とアカウンティングのロードバランサでスティッキ性を有効にします。『Cisco & F5 Deployment Guide: ISE Load Balancing Using BIG-IP』に記載されているISEのベストプラクティスを参照してください。
- 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つの値を使用します。これらの値は次のとおりです。
- ISE設定でポスチャリースに対して定義された日数：Administration > System > Posture > General Settingsに移動します。
2. PostureExpiry属性の値は、エポックタイムスタンプを含むエンドポイント属性です。 PostureExpiryの値は、ISE管理者がポスチャリースを有効にした後、エンドポイントに対して最初に成功したポスチャの試行に最初に入力されます。後でこの値は、リースの期限切れ後に発生する次回のポスチャ試行成功時に更新されます。次のように、ポーズ設定されたエンドポイントの1つが開いている間は、Context Visibility > EndpointsでPostureExpiryを確認できます。
3. この値は、人間が読み取り可能なタイムスタンプに変換できます。たとえば、https://www.epochconverter.com/のようになります。
3. ポスチャリースがあるエンドポイントの認証がPSNに到達すると、PostureExpiryとシステム日付を使用して、最後に成功したポスチャチェックから経過した日数が取得されます。結果値が設定で定義されたポスチャリース間隔内にある場合、セッションは準拠ステータスを受け取ります。結果値がリース値より大きい場合、セッションはUnknownステータスを受信します。これにより、ポスチャが再度実行され、新しいPostureExpiry値を保存できるようになります。
次の図は、フェールオーバーが発生するプロセスを示しています。
- 初期認証はPSN1で行われます。
- セッションABCはセッションキャッシュに作成されます。
- ポスチャ評価が行われます。
- セッションステータスがCompliantに変わります。
- COAはポスチャステータスの変更によってトリガーされ、エンドポイントの再認証が次のアクセスレベルに適用されます。
- PostureExpiry値はエンドポイントに保存されます。
- エンドポイントデータは導入環境全体で複製されます。
- 次の認証はPSN2にヒットします。
- PSN2は、エンドポイントが有効なポスチャリース内にあるかどうかを確認します。
- セッションが準拠としてセッションキャッシュに追加されます。
- 有効なリースがあるため、セッションはCompliantのポスチャステータスで作成されます。
再認証の実装
Maintain Connectivity During Reauthenticationで選択したRADIUS-Requestを使用して、常に再認証タイマーをISEからプッシュしてください。 この設定により、NADは再認証時に同じセッションIDを維持します。
ロードバランサを使用する環境
同じ一連のベストプラクティス（「古い/ファントムセッション」セクションで説明）を実装できます。
保留中の状態と準拠状態に異なるサブネットを使用できる
ネットワーク設計において、Pending状態やCompliant状態など、異なるサブネットを使用する機会が提供されている場合、このアプローチでは、ポスチャステータスのすべての変更がデフォルトゲートウェイの変更の結果として保証されます。
再認証タイマーと同じ間隔で使用されるポスチャアセスメント
ポスチャアセスメントは、再認証タイマーと同じ間隔で有効にできます。元のPSNが使用できない場合、PRA障害によって検出プロセスが再起動されます。
最新のアプローチ：ポスチャステートの共有
ISE 2.6用に実装された機能拡張(Cisco Bug ID CSCvi35647)のパッチ6の一部として、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キャッシュでどのように動作するかを説明しています。
- 初期認証はPSN1で行われます。
- セッションABCはセッションキャッシュに作成されます。
- 必要な属性はRSDに保存されます。
- セッションは、他のすべてのISEノードとRabbitMQで共有されます。
- すべてのISEノードのRSDキャッシュにセッションが作成されます。
- 新しいプロファイルデータがPSN2に到着します。
- エンドポイントがプロファイリングされ（COA実行PSN2を必要とする変更の場合）、次のステップに進みます。
- COAを実行するために、内部APIコールがRSDキャッシュに送信されます。
- RSDキャッシュからのデータは、プロキシCOAメッセージを準備するために使用されます。ISEノード間を移動し、宛先ノードがCAO要求をNADに返すために使用できるすべての詳細を含みます。COAメッセージは、最初に内部でPRRTランタイム（ISE内の実際のAAAサーバ）に転送されます。
- PSN2はCOAメッセージをPSN1に送信します。
- PSN1はCOAメッセージをNADに送信します。
ISE上のLDDを介した通信のトラブルシューティングを行うには、DEBUGでLight-Session-Directoryコンポーネントを有効にします。
次に、元の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で再認証を実行する場合です。これらのシナリオは、このドキュメントで説明されているベストプラクティスで処理できます。次の図は、ポスチャステータス共有のテストに使用されるトポロジを示しています。
RSDでのポスチャステータスの共有：期限切れ/ファントムセッション
古いセッションを作成するには、最初にskuchere-ise26-1で認証を実行する必要があります。次に、アカウンティングをskuchere-ise26-3に送信するようにNADを再設定する必要があります。1つのアカウンティングメッセージが誤ったPSNに転送された後、アカウンティングをskuchere-ise26-1に返信するようにNADを（再度）再設定する必要があります。
次の図は、skuchere-ise26-3のファントムセッションの存在を証明するアカウンティングレポートを示しています。
- Accounting-Startメッセージはskuchere-ise26-1で処理されます。
- Skuchere-ise26-3で処理された同じセッションのInterim Accounting-Update。
- セッションは後でskuchere-ise26-1で終了します。
エンドポイントはネットワークに接続されますが、リダイレクトは機能しません。skuchere-ise26-3用PSNの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への同じセッションのフェールオーバーを示す認証レポートを示しています。
- 認証はskuchere-ise26-1で行われ、リダイレクションを伴う認可プロファイルが割り当てられます。
- ポスチャ評価が成功した後のCOA。
- 認可プロファイルの次の認証が準拠状態に割り当てられます。
- 認証は別の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
元の問題は、ポスチャステータス選択プロセスに追加のロジックを追加することで解決されます。次の図は、変更内容を示しています（変更内容は赤で強調表示されています）。
更新履歴
| 改定 | 発行日 | コメント |
|---|---|---|
3.0 |
25-Aug-2026
|
タイトル、スペル、文法、読みやすさを考慮してセクションを区切るための挿入された水平線、固定されたURL、CCWアラート、および代替テキストが更新されました。 |
2.0 |
31-May-2023
|
再認定 |
1.0 |
22-Apr-2020
|
初版 |
フィードバック