ISEセッション管理とポスチャ
目次
はじめに
このドキュメントでは、一般的なIdentity Service Engine(ISE)ポスチャサービスの問題について説明します。ISEのセッションステータスが保留中の間、AnyConnect ISEポスチャモジュールが準拠を示します。この問題は頻繁に発生し、症状は常に同じですが、この問題の実際の根本原因が複数ある可能性があります。このような問題のトラブルシューティングには非常に時間がかかり、重大な影響を及ぼす可能性があります。
背景説明
このドキュメントでは、次の項目を説明しています。
- エンドユーザおよびISE管理者の観点から見た問題の症状。
- 一般的な問題のシナリオ
- 問題を引き起こす可能性があるISE、AnyConnect、およびネットワーク動作の背後にある理論。
- 迅速な問題特定のアルゴリズム。
- 一般的な問題のシナリオに対する古典的なソリューション
- Radiusセッションディレクトリを介したポスチャステータスの共有。
後で説明する概念をより深く理解するには、次の手順を実行することをお勧めします。
問題
エンドユーザエクスペリエンス
この問題は通常、ブラウザでISEクライアントプロビジョニングポータルにネットワークアクセスや継続的なリダイレクトがないときに発生し、同時にAnyConnect ISEポスチャモジュールはポスチャのステータスが[準拠(Compliant)]と表示されます。
一般的なエンドユーザエクスペリエンス：
ISE管理エクスペリエンス
通常、この問題の最初のトリアージ中に、ISE管理者はISEにヒットする実際の認証があることを確認するためにRadius Liveログ調査を実行します。この段階で最初に検出された症状は、エンドポイントとISE間のポスチャステータスの不一致を示します。これは、ライブログやRADIUS認証でエンドポイントの最後の正常な認証がPendingポスチャスステータスと表示されます。
一般的なISE管理エクスペリエンス：
- Aliceの最後の認証が成功しました。
- セッションのポスチャステータスは[保留中]です。
- アリスの最後のセッションイベント。
- セッションイベントでは、ポスチャのステータスが[準拠]と表示されます。
一般的な問題のシナリオ
通常、この問題は2つの問題のあるシナリオで発生し、それぞれのシナリオには複数の根本原因がある可能性があります。シナリオ：
- ポスチャプロセス中にAnyConnect ISEポスチャモジュールがポリシーサービスノード(PSN)によって誤って通知されたため、誤ったポスチャステータスが表示されます。この場合、通常、PSNセッションキャッシュ内の古いセッションまたはファントムセッションを処理します。
- AnyConnect ISEは、現在の認証によって検出プロセスがトリガーされないため、前の検出サイクルからポスチャステータスに表示されます。AnyConnectのISEポスチャモジュールには、検出プロセスをトリガーするイベントの数が限られており、認証中または再認証中に検出されなかった場合があります。
古い/ファントムセッションの問題
この問題をより理解するには、ISEセッション管理ロジックとAnyConnect検出プロセスを詳細に説明する必要があります。
ISEセッション管理ロジック
ISEの導入では、セッション管理プロセスを担当する担当者が2人います。PSNおよびモニタリングノード(MNT)。 この問題を適切にトラブルシューティングして特定するには、両方のペルソナのセッション管理の理論を理解することが重要です。
MNTおよびセッション管理
図で説明されているように、MNTノードは、PSNから送信される渡された認証Syslogメッセージに基づいてシーズンを作成します。以降のセッションステータスは、アカウンティング用にSyslogで更新できます。
MNTでのセッションの削除は3つのシナリオで発生します。
- アカウンティングを使用しないセッションは、作成されてから約60分後に削除されます。セッションのステータスを確認し、クリーニングを実行するために、5分ごとにcronジョブが実行されます。
- 終了したセッションは、同じcronジョブによってアカウンティング停止が処理されてから約15分後に削除されました。
- それぞれの実行で同じcronが削除され、5日間（120時間）以上経過した「Started」状態のセッションも削除されます。開始状態とは、MNTノードが認証とアカウンティングの両方を処理して、セッションのSyslogを開始することを意味します。
PSNからのSyslogメッセージの例。これらのメッセージは、runtime-aaaコンポーネントがDEBUGに有効になっている場合にprrt-server.logに記録されます。太字の部分を使用して、検索正規表現を作成できます。
Passed authentication :
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には、あるノードから別のノードに対してFULLセッション状態のレプリケーションを実行できるメカニズムはありません。
PSNは、アクティブなセッションIDごとに、内部/外部ユーザグループ、ネットワークアクセスデバイス(NAD)属性、証明書属性など、認証/認可フェーズで収集されたすべての属性を保存します。これらの属性は、認証、認可、クライアントプロビジョニング、ポスチャなどのさまざまなポリシータイプを選択するためにPSNによって使用されます。
ノードまたはノード自体のサービスが再起動すると、セッションキャッシュが完全に削除されます。
現在のセッション処理ロジックでは、2つのシナリオでセッションキャッシュに新しいエントリが作成されます。NADからのアカウンティングメッセージから既存のセッションの詳細を後で更新できます。
- セッションはPSNで正常に認証されました。
- PSNは、セッションキャッシュに存在しないセッションのアカウンティング中間更新を取得しました。
セッションの削除については、PSNは次のロジックを実装しています。
- セッションキャッシュエントリは、アカウンティング停止メッセージの処理直後に削除されます。
- PSNは、ノードがアクティブなセッションの制限に達すると、最も最近使用されていないセッションの削除を開始します。
PSNの古いセッション
ISE導入では、既存のセッションのアカウンティング停止が、実際の認証を実行しなかったPSNによって処理されました。
古いセッションの例：
1.セッションABCのPSNで認証が成功します。
2. PSNはセッションキャッシュにエントリを作成します。
3.ポスチャ評価が発生します。
4. Compliantとしてマークされたセッション。
5.ポスチャステータスの変更によってトリガーされる認可変更(COA)により、エンドポイントの再認証が行われ、次のアクセスレベルが適用されます。
6.セッションABCのアカウンティング停止はPSN2に到達します。
ステップ6セッションの後、ABCはPSN1で古い状態のままになります。これは、このPSNで処理されて削除されるアカウンティング停止メッセージがないためです。展開で大量の認証試行が発生しない場合、セッションを長時間削除することはできません。
次のシナリオでは、古いセッションがPSNセッションキャッシュに表示されることがあります。
- ロードバランサでスティッキネスタイマーの期限切れにより、アカウンティング停止が誤ったPSNに達しました。
- NADの誤った設定が、認証とアカウンティング用に設定されたPSNと同じではありません。
- 次のPSNへのNADフェールオーバーを引き起こす、ネットワークパスの一時的な接続の問題。
ロードバランサ(LB)環境の古いセッションの例：
1. PSN 1によって実行されるセッションABCの初期認証。
2.この認証は、ロードバランサでスティッキネスタイマーを開始します。
3. PSN 1は、ローカルキャッシュにセッションABCのエントリを作成します。
4. MNTノードに転送される渡された認証のsyslogメッセージ。
5.セッションABCのエントリは、Authenticated状態でMNTセッションディレクトリに作成されました。
6.セッションABCのアカウンティング開始メッセージはPSN 1に到達します。
7.セッションABCのセッションキャッシュエントリがAccounting-Startからの情報で更新されました。
8. Accounting-StartがMNTノードに転送されるsyslogメッセージ。
9.セッションの状態が開始に更新されました。
10.ロードバランサでスティッキネスタイマーが期限切れになります。
11.ロードバランサによってPSN 2に転送されたセッションABCのアカウンティング停止。
12. PSN 2によってMNTに転送されるAccounting-Stopのsyslogメッセージ。
13. MNTで終了としてマークされたセッションABC。
PSNのファントムセッション
このファントムセッションは、アカウンティング中間更新がこの特定のセッションの認証を実行しなかったPSNに到達したときのシナリオです。このシナリオでは、PSNセッションキャッシュに新しいエントリが作成され、PSNがこのセッションのアカウンティング停止メッセージを取得しない場合、PSNがアクティブセッションの制限に達しない限り、エントリは削除されません。
ファントムセッションの例：
1.古いセッションの例で説明したのと同じ手順が、セッションABCのPSN1で実行されます。
2.セッションABCは、PSN1セッションキャッシュでステータスCompliantです。
3.セッションABCのアカウンティング中間更新がPSN2にヒットします。
4. PSN2で作成されたセッションABCのセッション・エントリ。セッション・エントリは会計メッセージから作成されるため、属性の数が制限されます。たとえば、セッションABCではポスチャステータスを使用できません。ユーザグループやその他の認可固有属性も欠落しています。
ファントムセッションは、次のシナリオでPSNセッションキャッシュに表示されることがあります。
- ネットワーク通過時の短期的な停止。
- ネットワークアクセスデバイスの誤動作。
- ロードバランサーの誤動作または誤った構成。
PSN1へのネットワークパスに一時的な問題があるシナリオのファントムセッションの例：
1. PSNによって実行されるセッションABCの初期認証。
2. PSN1は、ローカルキャッシュにセッションABCのエントリを作成します。
3. MNTノードに転送される渡された認証のsyslogメッセージ。
4.セッションABCのエントリは、Authenticated状態でTimesTen DBに作成されました。
5.セッションABCのアカウンティング開始メッセージはPSN 1に到達します。
6.セッションABCのセッションキャッシュエントリがAccounting-Startからの情報で更新されました。
7. Accounting-StartがMNTノードに転送されるsyslogメッセージ。
8.セッションの状態が開始に更新されました。
9.セッションABCがPSN2に転送された暫定アカウンティング更新。
10. PSN2は、ローカルキャッシュにセッションABCのエントリを作成します。
11. ABCがPSN1に転送したセッションのアカウンティング停止。
12.セッションABCのエントリがPSN1のセッションキャッシュから削除されました。
13. PSN 1によってMNTに転送されるAccounting-Stopのsyslogメッセージ。
14. MNTで終了としてマークされたセッションABC。
長時間にわたるVPN接続のために作成されるファントムセッションのシナリオ：
1. PSN1の初期認証
2.セッションキャッシュに作成されたセッションABC。
3.アカウンティングは、PSNによって処理されたメッセージを開始します。
4.バーチャルプライベートネットワーク(VPN)アダプタに割り当てられた新しいIPアドレス。
5. IPアドレス情報を含む暫定アカウンティング更新はPSNに到達します。
6.セッションキャッシュに追加されたIPアドレス情報。
7.ポスチャ評価はPSN1で行われます。
8.セッションでポスチャステータスを更新。
9. ISEによって実行されるCOAプッシュにより、新しいアクセスレベルが割り当てられます。
10. PSN1にアクセスできないネットワークパスの停止。
11.暫定アップデート間隔の満了後、ASA/FTDはPSN1にアクセスできないことを検出します。
12.暫定アカウンティング更新がPSN2に送信されます。
13. PSN2セッションキャッシュに作成されたファントムセッション。
それ以降のPSN1がアクセス可能(14)になった場合、後続のすべてのアカウンティングメッセージはそこで転送され(15,16)、PSN2セッションキャッシュにセッションABCが不定の時間だけ残ります。
古いセッションとファントムセッションによってポスチャプロセスが中断される可能性がある理由
古いセッションとファントムセッションがポスチャを解除する方法を理解するには、AnyConnect ISEポスチャモジュール検出プロセスを確認します。
ステージ1ディスカバリ：
この段階で、ISEポスチャモジュールは4つの同時に問題を実行し、エンドポイントの認証を行ったPSNを見つけます。
最初に、図の3つのプローブがリダイレクトベース（デフォルトのGW 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が古いセッションまたはファントムセッションを保持する場合のポスチャの動作を示しています。
1. ISEポスチャモジュールによって発行されたセッションプローブを検索します。
2. PSNはセッションキャッシュでセッションルックアップを実行します。セッションが見つかった場合、古いセッションまたはファントムセッションの問題が発生します。
3. PSNはクライアントプロビジョニングポリシーの選択を実行します。認証/許可属性が不足し、カスタマーが設定したすべてのポリシーが非常に固有である（たとえば、特定のActive Directoryグループに対してポリシーが作成される）場合、PSNは正しいクライアントプロビジョニングポリシーを割り当てることができません。これは、「Bypassing AnyConnect scan your network is configured to use Cisco NAC Agent」というエラーメッセージに現れる可能性があります。
- クライアントプロビジョニングポリシーが汎用の場合（ファントムセッションで使用可能な属性は、AnyConnect設定とポリシーを一致させるのに十分です）、PSNは評価プロセスの続行に必要な詳細を含む応答を返します。
- このステップでは、古いセッションを処理できる場合も、ポスチャステータスがCompliantでPSNが応答し、次のステップはすべて実行されません。PSNは、セッションがすでに準拠していると認識しているため、COAを送信しません。Radius Liveログでは、Compliantステータスのセッションイベントは表示されません。
4.ファントムセッションシナリオでは、ISEポスチャモジュールは初期ポスチャ要求を続行します。この要求には、エンドポイントで検出されたすべてのセキュリティおよびパッチ管理製品に関する情報が含まれます。
5. PSNは、要求およびセッション属性からの情報を使用して、適切なポスチャポリシーを照合します。この時点ではファントムセッションには属性がないため、一致するポリシーがない可能性があります。このような場合、ポスチャポリシーが一致しない場合のデフォルトのISE動作であるため、PSNは準拠しているエンドポイントに応答します。
6. PSNは、選択したポスチャポリシーをエージェントに返します。
7.エージェントは、合格または失敗した各ポリシー/要件のステータスを返します。
8. ISEでレポート評価が行われ、セッションステータスが[Compliant]に変更されます。
検出プロセスが新しい認証試行で開始されない
ISEポスチャモジュールは、検出プロセスをトリガーするためにエンドポイント上の限られた量のイベントを監視するように設計されています。検出をトリガーするイベントのリスト：
- ISEポスチャモジュールの初期インストール。
- ユーザログイン。
- 電源イベント。
- インターフェイスのステータスの変更。
- スリープ後にOSが再開します。
- デフォルトゲートウェイ(DG)の変更
- ポスチャ再評価(PRA)の失敗。Cisco Bug ID CSCvo69557
新しいdot1x認証、PCロック解除、IPアドレスの変更は、ISEポスチャモジュールによって検出されません。
ISEポスチャモジュールは、次のシナリオで新しい認証または再認証の試みを検出できません（ISEポスチャモジュールはISEに対してISEを設定します）。
- 再認証が異なるPSNにヒットする（LBの決定または元のPSNの問題により）。
- NADは再認証時に新しいセッションIDを生成します。
異なるPSNでの再認証
元のPSNの停止が原因で異なるPSNで再認証を行った例。ロードバランサのシナリオは非常によく似ています。LBの場合は、スティッキネスのタイマーの期限切れの結果として、再認証が異なるPSNに送信されます。
1. PSN1の初期認証
2. PSN1セッションキャッシュに作成されたセッションABC。
3. PSN1で実行されるポスチャアセスメント。
4.セッションABSポスチャステータスが準拠に移動します。
5.ポスチャステータスの変更によってトリガーされるCOAは、エンドポイントの再認証を行い、次のアクセスレベルを適用します。
6. PSN1が使用不可になります。
7.セッションABCの再認証がPSN2にヒットします。
8.これはセッションのPSN2ポスチャステータスの新しいセッションであるため、Pendingになります。
PSNによってセッションに割り当てられる初期ポスチャステータス：
NADが再認証時に新しいセッションIDを生成
これは、最も一般的な2つのシナリオで発生する可能性があります。
- 再認証がISE側で不適切に設定されている。この問題の解決策については、このドキュメントの後半で説明します。
- NAD側からの誤動作：通常、NADは再認証の試行中に同じセッションIDを保持する必要があります。再認証時にNADがセッションIDを変更することが判明した場合、これはNAD自体で調査する必要があるバグの可能性がある動作です。
新しいセッションIDは、その他のコーナーケースのシナリオで生成できます。たとえば、ワイヤレスローミングが原因である場合があります。ここで主な点は、ポスチャリースが設定されていない限り、ISE PSNは常に新しいセッションをポスチャス保留状態にすることです。ポスチャリースについては、このドキュメントで後述します。
古い/ファントムセッションによって問題が発生した場合の迅速な識別方法
リダイレクト状態である間にAnyConnectがコンプライアンスを示しているかどうかを確認するには、問題のある状態のエンドポイントにアクセスする必要があります。
- システムスキャンの詳細を調査します。
1. AnyConnect UIの歯車アイコンを押します
2.新規ウィンドウで、「システム・スキャン」タブおよびサブタブ「統計」にナビゲートします
次の2つの要素に注意してください。
- [Latest Scan Start Time]：このタイムスタンプは、問題が検出された時刻に近い必要があります。
- [ポリシーサーバ(Policy Server)]：このフィールドは、エンドポイントのポスチャ評価を行ったポリシーサーバの名前を示しました。ここで使用するFQDNは、リダイレクトURLからのFQDN（リダイレクトベースポスチャ用）または最後の認証試行から取得したPSN名（リダイレクトレスポスチャ用）と比較する必要があります。
- システムスキャン統計情報のポリシーサーバFQDNと、エンドポイントの認証を行ったノード名を比較します。
次の例では、名前が一致していません。名前がciscolive-ise2のPSNがこのエンドポイントの古いセッションまたはファントムセッションを保持していることが示されています。
このデモでは、問題の特定に必要な手順を記録しています。
古い/ファントムセッションの高度なトラブルシューティング
前の例では、古いセッションまたはファントムセッションの問題と、開始されなかった検出プロセスの問題を区別します。同時に、問題を引き起こした実際のセッションを特定して、そのセッションが古いセッションまたはファントムセッションの問題になる正確な状態を理解する必要があります。
一部のシナリオでは、古いセッションとファントムセッションを回避できません。一部のベストプラクティスが実装されていないため、環境内に古い/ファントムセッションが作成されていないことを確認する必要があります。
DARTバンドルコレクション
問題を再現しているエンドポイントから取得したDARTバンドルを分析します。
- DARTの重要なログのみを保持します。問題を再現する前に、ログをクリアすることをお勧めします。
そのためには、DARTバンドルユーティリティを管理者として起動し、ログのクリーンアップを実行する必要があります。
- Windowsで、[Start]に移動してDARTの入力を開始し、右クリックして[Run as administrator]を選択します
- 最初のウィザード画面で[次へ]を押します
- 次のウィザード画面で、[Clear All Logs]を押します
- 問題を再現したら、ウィザードに従って[Next]を押します。
DARTバンドル分析
DARTバンドルが収集されたら、アーカイブを解除し、Cisco AnyConnect ISE Posture ModuleフォルダにあるファイルAnyConnect_ISEPosture.txtに焦点を当てる必要があります。このファイルには、すべてのディスカバリ関連イベントが含まれています。
1.ディスカバリの再起動のすべての瞬間を特定して、トラブルシューティングを開始します。検索するキーワードはRestarting DiscoveryまたはHTTP Discoveryです。ここで、問題の瞬間に発生した検出の再起動の行に移動します。
2.ディスカバリの再起動後に数行の行に「Proving no MNT stage targets」という行が表示されます。これは、ステージ1のディスカバリ開始を示しています。
以前ConnectionData.xml(Auth-Statusターゲット)から取得した接続されたPSNは、通常のPSN FQDNが非常に類似しており、その違いを見つけにくいため、すべてのリダイレクトベースのプローブを同じ色で強調表示することをお推奨します。
3.ログファイルに従って、すべてのプローブの結果を確認してください。古い/ファントムセッションが原因で問題が発生した場合は、すでに述べたように、すべてのリダイレクトベースのプローブは失敗する必要があります。次に、失敗したプローブの例を示します。
4.ステージ1またはステージ2のディスカバリ再起動後にファイルのどこかに、1つ以上のPSNからの正常な応答が表示されます。
5.後の行にMSG_NS_SWISS_NEW_SESSIONというキーワードが付いている行が必要です。この行には、セッション検索の結果としてPSNによって選択された実際のセッションIDが含まれています。このセッションが古い/ファントムになる方法を特定するには、次のセッションIDを使用してISEの詳細を調査します。
ISEログの調査
clientwebappコンポーネントがDEBUGに対して有効になっているguest.logには、古い/ファントムセッションで応答する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を検索する方法を確認できます。
cpm.client.provisioning.utils.ProvisioningUtil -::- the input ipAddress from the list currently being 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 Accountingレポートを調べて、このセッションが古い/ファントムセッションになった原因をより詳しく把握できます。
- [Operations] > [Reports] > [Endpoints and Users] > [Radius Accounting]レポートに移動し、このレポートを7日間実行します。フィルタキーとしてエンドポイントIDをユーザに割り当てます。
ciscolive-ise2で古いセッションが残っている様子を示すレポートの例：
- セッションのアカウンティングがPSN ciscolive-ise2に開始されました
- セッションの中間更新が同じPSNで処理されました。
- 問題のあるセッションIDのアカウンティング停止メッセージが異なるPSN(ciscolive-ise1)に送られました。
ディスカバリの再起動がないことが原因で問題が発生した場合の迅速な識別方法
ここでは、前の問題と同じロジックが適用されます。唯一の違いは、最新のスキャン開始時間に集中する必要があることです。このタイプの問題では、最後のスキャンのタイムスタンプは過去のどこかになります。
通常、エンドユーザが問題を検出すると、前に発生したスキャンが表示されます。ISE Radius Liveログに、問題のあるエンドポイントからの最近の認証試行が記録されます。
次のデモは、問題の特定に必要な手順の記録を示しています。
高度なトラブルシューティング：ディスカバリの再起動がない
このアプローチは、「Advanced Troubleshoot Stale/Phantom Session」セクションとよく似ています。主なトラブルシューティング要素は、DARTバンドルの調査です。DARTバンドル内では、以前の問題に関して示したように検出の再開を検索し、問題が報告された時点で検出の再開がなかったことを確認できます。
ISE側で、RADIUSライブログ/RADIUS認証レポートに注目し、PSN間のフェールオーバーが発生したか、NADによって新しいセッションIDが生成されたことを確認します。
解決策
従来のアプローチ：問題の回避
従来、このドキュメントで説明されている問題を解決できるISEの機能はありませんでした。そのため、ネットワークおよびISE側に実装されているベストプラクティスのセットにリスクを最小限に抑える方法だけが唯一でした。
ISE導入における古いセッションまたはファントムセッションの量を最小限に抑えるベストプラクティス
可能であれば常にリダイレクトベースのポスチャを実装する
バックグラウンドのAnyConnect ISEポスチャモジュールが評価プロセスを実行している間に、OSまたはブラウザでポップアップが表示されてリダイレクトが示されるため、この推奨事項に対する一般的な反論はユーザエクスペリエンスの低下です。
この解決策として、ISEポスチャモジュール検出プローブのみをリダイレクトし、他のすべてのトラフィックを選択的に許可できます。
例は、HTTP要求のみをディスカバリホスト(この例では1.1.1.1)およびenroll.cisco.com(72.163.1.80)にリダイレクトするように設計されたリダイレクトACLを示しています。
ip access-list extended REDIRECT-DH-ENROLL
permit tcp any host 1.1.1.1 eq www
permit tcp any host 72.163.1.80
deny ip any any
許容レベルのセキュリティを維持するために、リダイレクトACLをISEから割り当てられたDACLと組み合わせることができます。
[Pending State Allows Connections Only to PSN where Endpoint was Authenticated]
このアプローチは、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.先ほど割り当てられたACLによってNADによってブロックされたPSN2へのプローブ。
5. NADに割り当てられたACLによって許可されるPSN1へのプローブ。
ロードバランサのベストプラクティス
- Calling-Station-IDをスティッキネスキーとして使用して、認証およびアカウンティングのためにLBでスティッキ性を有効にするISEのLBベストプラクティスの詳細については、こちらをご覧ください。
- PCがスリープ状態になる瞬間をカバーするために、平均営業日よりもスティッキネスタイマーを長く使用します（たとえば、8時間ではなく10時間）。
- 再認証が実装されている場合は、再認証タイマーをスティッキネスタイマーよりもわずかに低く使用します（スティッキ性が10時間設定されている場合は8時間など）。 これにより、再認証によってスティッキネス間隔が長くなります。
Posture Over 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つの値を使用します。これらの値は次のとおりです。
- [Administration] > [System] > [Posture] > [General Settings]に移動して、ISE設定のポスチャリースに定義された日数：
- PostureExpiry属性の値：これは、エポックのタイムスタンプを含む実際のエンドポイント属性です。PostureExpiry値は、ISE管理者がポスチャリースを有効にした後、最初にエンドポイントのポスチャ試行が成功すると最初に入力されます。後でこの値は、リースの期限切れ後に発生する、次に成功したポスチャ試行で更新されます。
PostureExpiryは、[Context Visibility] > [Endpoints]でポスチャのエンドポイントの1つを開くと表示されます。
この値は、例えば人間が読み取れるタイムスタンプに変換できます – https://www.epochconverter.com/
- 新しい認証が行われた時点のPSNシステム時間
ポスチャリースを持つエンドポイントの認証がPSNにヒットすると、PostureExpiryとシステム日付を使用して、最後に成功したポスチャチェックから経過した日数を取得します。結果の値が設定で定義されたポスチャリース間隔内の場合、セッションは準拠ステータスを取得します。結果の値がリース値より大きい場合、セッションは不明なステータスを取得します。これにより、ポスチャが再度実行され、新しいPostureExpiry値を保存できます。
図は、フェールオーバーが発生するプロセスを示しています。
1.初期認証はPSN1で行われます。
2.セッションキャッシュに作成されたセッションABC。
3.ポスチャ評価が発生します。
4.セッションステータスが準拠に変更
5.ポスチャステータスの変更によってトリガーされるCOAは、エンドポイントの再認証を行い、次のアクセスレベルを適用します。
6.エンドポイントに保存されたPostureExpiry値。
7.導入全体で複製されたエンドポイントデータ。
8.次の認証がPSN2にヒットします。
9. PSN2は、エンドポイントが有効なポスチャリース内にあるかどうかをチェックします。
11.セッションキャッシュにCompliantとしてセッションが追加されました。
12.有効なリースのため、ポスチャステータスがCompliantのセッションが作成されました。
再認証の実装
「再認証時に接続を維持」で選択したRADIUS-Requestを使用してISEから常に再認証タイマーをプッシュします。この設定により、再認証時にNADが同じセッションIDを保持します。
.
ロードバランサを使用する環境
古い/ファントムセッションのセクションで説明したのと同じベストプラクティスのセットを実装できます。
保留状態と準拠状態に異なるサブネットを使用できる
ネットワーク設計で異なるサブネットPendingとCompliantの状態を使用する機会が得られると、このアプローチでは、ポスチャステータスの変更がデフォルトゲートウェイに反映されることを保証します。
再認証タイマーと同じ間隔で使用されるポスチャアセスメント
ポスチャアセスメントは、再認証タイマーと同じ間隔で有効にできます。このような場合、元のPSNが使用できなくなると、PRA障害によって検出プロセスが再開されます。
現代のアプローチ – ポスチャ状態の共有
ISE 2.6用のCSCvi35647パッチ6で説明されている機能拡張の実装の一環として、ISE導入のすべてのノードでセッションポスチャステータスの共有を実装する新機能が追加されました。この機能拡張は、将来のリリースにも統合されます。ISE 2.7パッチ2およびISE 3.0
この新機能は、ISE 2.6で導入されたLight Session Directory(LSD)メカニズムに基づいています。新しいバージョンでは、この機能の名前がLight Data Distribution(LDD)Radius Session Directoryに変更されています。 Light Data Distributionはデフォルトで有効になっており、ISEノード間で制限されたセッションコンテキストを共有できます。PSN間での完全なセッションコンテキストレプリケーションは存在せず、各セッションで共有される属性の量は限られます。
Light Session Directoryの主な考え方は、展開内のノードの1つが現在のセッション所有者を特定する必要がある場合に、MNTにリソース高価なAPIコールを実行する必要をなくすことです。COAフローの開始時には、主に所有者ルックアップが必要です。LDDを使用すると、各PSNはローカルRADIUSセッションディレクトリキャッシュからセッションの実際の所有者を見つけることができます。
Light Data Distribution Architecture
この機能には、次の要素が含まれます。
- Radius Session Directory(RSD)キャッシュ：このキャッシュはすべてのISEノードに存在し、ISE展開で提示されたすべてのアクティブセッションを保存します。各セッションには、キャッシュ内の属性の数に制限があります。各セッションのRADIUSセッション・ディレクトリに格納される属性の例を次に示します。
- セッションID.
- エンドポイントMAC。
- CallingStationID。
- エンドポイントIP。
- PSN IP：認証が発生したPSN。
- PSN FQDN：上記と同じです。
- NAS-IP-Address。
- NAS-IPv6-Address。
- 状態：認証済み、開始、停止。
- RabbitMQ交換：ISE導入の各ノードで、パブリッシャ、対応するキュー、およびコンシューマが表示される交換が形成されます。これにより、すべてのISEノード間で完全メッシュトポロジが形成されます。
- パブリッシャ：RADIUSセッションディレクトリは、パブリッシャを表します。PSNによって処理された新しい正常な認証が、PSNセッションキャッシュに新しいセッションが作成されます。このセッションでは、RADIUSセッションディレクトリに限定された属性セットが配置されます。
- コンシューマ：他のすべてのノードのRADIUSセッションディレクトリはコンシューマを表します。
注：一般的なRabbitMQの用語とアーキテクチャは、このドキュメントの範囲外です。
図は、RSDキャッシュでのCOAフローの動作を説明します。
1.初期認証はPSN1で行われます。
2.セッションキャッシュに作成されたセッションABC。
3.必要な属性がRSDに保存されます。
4. RabbitMQ上で他のすべてのISEノードと共有されるセッション。
5.セッションはすべてのISEノードのRSDキャッシュに作成されます。
6.新しいプロファイルデータがPSN2に到着します。
7.エンドポイントが報告され、COA実行PSN2が必要な変更の場合は、次のステップに進みます。
8. COAを実行するためにRSDキャッシュに送信された内部APIコール。
9.プロキシCOAメッセージ（あるISEノードから別のISEノードに送信されるCOA、NADにCAO要求を発行するために使用できるすべての詳細を含む）を準備するために使用されるRSDキャッシュからのデータ。
10. PSN2はPSN1にCOAメッセージを送信します。
11. PSN1はNADにCOAメッセージを送信します。
ISEでLDDを介した通信のトラブルシューティングを行うには、Light Session DirectorコンポーネントをDEBUGに有効にします。
元の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でのポスチャステータス共有
ノード間のポスチャステータス共有は、根本的な原因が古い/ファントムセッションまたは元のセッションIDを使用した別のPSNの再認証である場合に、「AnyConnect ISEポスチャモジュールがISEのセッションステータスが保留中にに準拠する」などの問題をを解決。セッションがCompliantになると、この情報はセッションRSDに送られ、後で配置内のすべてのPSNで使用できるようになります。
この機能では解決できない他のコーナーケースが残っています。たとえば、NADが同じPSNで再認証を実行し、セッションIDが異なるシナリオです。このようなシナリオは、このドキュメントで説明されているベストプラクティスを実装することで対処できます。
図は、ポスチャステータス共有のテストに使用されるトポロジを示しています。
RSDでのポスチャステータス共有 – 古い/ファントムセッション
古いセッション認証を作成するために、最初にskuchere-ise26-1以降で実行され、NADがskuchere-ise26-3にアカウンティングを送信するように再設定されました。1つのアカウンティングメッセージが誤ったPSN NADに転送された後。
図は、skuchere-ise26-3のファントムセッションの存在を証明するアカウンティングレポートを示しています。
1. skuchere-ise26-1によって処理されるアカウンティング開始メッセージ。
2. skuchere-ise26-3によって処理された同じセッションの暫定アカウンティング更新。
3.セッションは後でskuchere-ise26-1で終了します。
しばらくすると、エンドポイントはネットワークに再接続しますが、リダイレクションは機能しなくなります。PSN - skuchere-ise26-3のguest.logには、client-webappコンポーネントが有効になっている次のログメッセージが表示されます。
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が含まれている場合、セッションキャッシュ内のセッションが古いと見なされます。
RSDでのポスチャステータス共有 – PSN間のフェールオーバー
このシナリオを再現するには、コンプライアンス状態のエンドポイントに割り当てられた認可プロファイルで、短い再認証タイマーが有効になっています。その後、別のPSN(skuchere-ise26-3)に認証とアカウンティングを送信するようにNADが再設定されました。 再認証タイマーの有効期限が切れると、同じセッションが異なるPSNで認証されなくなります。
図は、skuchere-ise26-1からskuchere-ise26-3へのsaneセッションのフェールオーバーを示す認証レポートを示しています。
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
元の問題は、ポスチャステータス選択プロセスに追加ロジックを追加することで解決されました。図は、変更された内容（赤で強調表示された変更）を示しています。
フィードバック