ISE 세션 관리 및 상태 문제 해결
소개
이 문서에서는 일반적인 ISE(Identity Service Engine) 상태 서비스 문제에 대해 설명합니다. "AnyConnect ISE Posture 모듈은 규정 준수를 보여줍니다."
배경 정보
이 문서에서는 일반적인 ISE(Identity Service Engine) 상태 서비스 문제에 대해 설명합니다. AnyConnect ISE 상태 모듈은 ISE의 세션 상태가 보류 중인 동안 규정 준수를 보여줍니다.
증상은 항상 동일하지만, 이 문제의 여러 가지 근본 원인이 있습니다.
이러한 문제의 트러블슈팅은 시간이 많이 걸리는 경우가 많아 심각한 영향을 미칩니다.
이 문서에서는 다음 내용을 설명합니다.
- 최종 사용자 및 ISE 관리자 관점에서 문제 발생
- 일반적인 문제 시나리오
- ISE, AnyConnect 및 네트워크 운영에 대한 이론으로 인해 문제가 발생합니다.
- 신속한 문제 식별 알고리즘.
- 일반적인 문제적 시나리오에 대한 고전적인 해결책.
- Radius 세션 디렉토리를 통한 상태 공유.
나중에 설명하는 개념에 대한 자세한 설명은 다음을 참조하십시오.
문제
최종 사용자 환경
이 문제는 일반적으로 브라우저에서 ISE 클라이언트 프로비저닝 포털에 대한 네트워크 액세스 또는 지속적인 리디렉션이 없을 때 나타나며, 동시에 AnyConnect ISE Posture 모듈은 포스처 상태를 Compliant로 표시합니다.
일반적인 최종 사용자 환경:
ISE 관리 환경
일반적으로 이 문제의 초기 분류에서 ISE 관리자는 Radius Live 로그 조사를 수행하여 ISE에 도달하는 실제 인증이 있는지 확인합니다.
이 단계에서 발견 된 첫 번째 증상은 엔드 포인트에 대한 마지막 성공 적 인 인증 보고서 라이브 로그에서처럼 엔드 포인트와 ISE 사이의 상태 불일치를 나타냅니다 Pending 상태 상태 입니다.
일반적인 ISE 관리 환경:
- ID에 대한 마지막 성공 인증: alice.
- 세션의 포스처 상태가 Pending(보류 중)입니다.
- ID에 대한 마지막 세션 이벤트: alice.
- 세션 이벤트는 포스처 상태를 Compliant로 표시합니다.
일반적인 문제 시나리오
이 문제는 일반적으로 두 가지 문제가 있는 시나리오에서 나타나며, 각 시나리오는 여러 가지 근본 원인을 가지고 있습니다. 시나리오는 다음과 같습니다.
- AnyConnect ISE Posture Module이 포스처 프로세스 중에 PSN(Policy Service Node)에 의해 잘못 알려졌으며, 이로 인해 잘못된 포스처 상태가 표시됩니다.
이 경우 일반적으로 PSN 세션 캐시에서 오래된 세션 또는 팬텀 세션을 처리합니다.
- 현재 인증이 검색 프로세스를 트리거하지 않았기 때문에 AnyConnect ISE는 이전 검색 주기의 포스처 상태를 표시합니다.
AnyConnect의 ISE Posture 모듈에는 검색 프로세스를 트리거하는 이벤트 수가 제한됩니다. 인증 또는 재인증 중에 이러한 이벤트가 탐지되지 않았을 수 있습니다.
부실/팬텀 세션 문제
문제를 더 잘 이해하려면 필요한 ISE 세션 관리 로직 및 AnyConnect 검색 프로세스를 조사하십시오.
ISE 세션 관리 로직
ISE 구축에서는 세션 관리 프로세스를 담당하는 페르소나 2개가 있습니다. PSN과 모니터링 노드(MNT)입니다.
이 문제를 제대로 해결하고 파악하려면 두 페르소나의 세션 관리 이론을 이해하는 것이 중요합니다.
MNT 및 세션 관리
이 이미지에 설명된 대로 MNT 노드는 PSN에서 오는 전달 인증 Syslog 메시지를 기반으로 시즌을 생성합니다.
세션 상태는 나중에 Syslog에서 어카운팅용으로 업데이트할 수 있습니다.
MNT에서 세션 제거는 다음 3가지 시나리오에서 수행됩니다.
1. 세션이 생성된 후 약 60분 후에 계정 관리 시작이 제거되지 않은 세션: 세션 상태를 확인하고 정리하기 위해 5분마다 cron 작업이 실행됩니다.
2. 동일한 cron 작업에 의해 계정 정지가 처리된 후 약 15분 후에 제거된 종료된 세션
3. 5일(120시간) 이상 '시작됨' 상태인 세션도 각 실행에 대한 동일한 사유로 제거됩니다. 시작 상태는 MNT 노드가 세션에 대한 Syslog를 시작하기 위해 인증 및 어카운팅을 모두 처리했음을 의미합니다.
PSN의 Syslog 메시지 예:
런타임 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에는 한 노드에서 다른 노드로의 FULL 세션 상태 복제를 수행할 수 있는 메커니즘이 없습니다.
모든 활성 세션 ID에 대해 PSN은 인증/권한 부여 단계 중에 수집된 모든 특성(예: 내부/외부 사용자 그룹, NAD(Network Access Device) 특성, 인증서 특성 등)을 저장합니다. 이러한 특성은 PSN에서 다른 정책 유형(예: Authentication, Authorization, Client Provisioning, Posture)을 선택하는 데 사용됩니다.
노드(또는 노드의 서비스)를 다시 시작하면 세션 캐시가 완전히 제거됩니다.
현재 세션 처리 로직은 두 가지 시나리오에서 세션 캐시에 새 항목을 생성합니다. NADs에서 오는 계정 관리 메시지에서 기존 세션의 나중 세부 정보를 업데이트 할 수 있습니다.
- 세션이 PSN에서 성공적으로 인증되었습니다.
- PSN에서 세션 캐시에 없는 세션에 대한 계정 관리 중간 업데이트를 가져왔습니다.
세션 제거와 관련하여 PSN은 다음 논리를 구현합니다.
- 세션 캐시 항목은 계정 관리 중지 메시지를 처리한 후 즉시 제거됩니다.
- PSN은 노드가 활성 세션의 한계에 도달하면 가장 최근에 사용된 세션을 제거하기 시작합니다.
PSN의 오래된 세션
ISE 구축에서 기존 세션에 대한 어카운팅 중지는 실제 인증을 수행하지 않은 PSN에 의해 처리되었습니다.
부실 세션의 예:
1. 세션 ABC에 대한 PSN에서 인증에 성공했습니다.
2. PSN에서 세션 캐시에 항목을 생성합니다.
3. 실태파악
4. 세션이 호환 세션으로 표시됩니다.
5. COA(Change of Authorization)(상태 변경에 의해 트리거됨)는 다음 액세스 레벨을 적용하기 위한 엔드포인트의 재인증으로 이어집니다.
6. 세션 ABC에 대한 계정 정지가 PSN2에 옵니다.
그런 다음 PSN1에서 계정 관리 중지 메시지를 삭제하기 위해 처리된 계정 관리 중지 메시지가 없으므로 ABC가 PSN1의 부실 상태로 유지됩니다.
구축에서 인증 시도 횟수가 많지 않으면 세션이 오랫동안 제거됩니다.
오래된 세션은 다음 시나리오에서 PSN 세션 캐시에 나타납니다.
- 부하 분산 장치의 고착성 타이머 만료로 인해 계정 관리 중지가 잘못된 PSN으로 이동했습니다.
- NAD의 잘못된 컨피그레이션이 인증 및 어카운팅에 대해 구성된 동일한 PSN이 아닙니다.
- 다음 PSN으로 NAD 장애 조치를 일으키는 네트워크 경로의 일시적인 연결 문제.
LB(로드 밸런서) 환경의 오래된 세션의 예:
1. 세션 ABC에 대한 초기 인증은 PSN 1에서 수행합니다.
2. 이 인증은 로드 밸런서에서 고착성 타이머를 시작합니다.
3. PSN 1은 로컬 캐시에 세션 ABC에 대한 항목을 생성합니다.
4. MNT 노드로 전송된 전달 인증을 위한 Syslog 메시지.
5. 세션 ABC에 대한 항목이 Authenticated(인증됨) 상태로 MNT 세션 디렉토리에 생성됩니다.
6. PSN 1에 있는 세션 ABC에 대한 계정 관리 시작 메시지.
7. 세션 ABC에 대한 세션 캐시 항목이 Accounting-Start의 정보로 업데이트됩니다.
8. Accounting-Start에 대한 Syslog 메시지가 MNT 노드로 전송됩니다.
9. 세션 상태가 시작됨으로 업데이트됩니다.
10. 고착성 타이머가 로드 밸런서에서 만료됩니다.
11. 세션 ABC에 대한 Accounting-Stop은 로드 밸런서에서 PSN 2로 전달됩니다.
12. Accounting-Stop에 대한 Syslog 메시지가 PSN 2에 의해 MNT로 전달됩니다.
13. 세션 ABC가 MNT에서 종료된 것으로 표시됩니다.
PSN의 Phantom 세션
팬텀 세션은 이 특정 세션에 대한 인증을 수행하지 않은 PSN에 대한 계정 관리 중간 업데이트가 오는 시나리오입니다. 이 시나리오에서는 PSN 세션 캐시에 새 항목이 생성됩니다.
PSN이 이 세션에 대한 계정 관리 중지 메시지를 받지 못하면 PSN이 활성 세션 제한에 도달하지 않는 한 항목이 제거되지 않습니다.
팬텀 세션의 예:
1. 부실 세션 예에 설명된 것과 동일한 단계가 세션 ABC에 대한 PSN1에서 발생합니다.
2. 세션 ABC는 PSN1 세션 캐시에 규정 준수 상태가 있습니다.
3. 세션 ABC에 대한 회계 중간 업데이트가 PSN2에 도달합니다.
4. 세션 ABC에 대한 세션 항목이 PSN2에 생성됩니다. 세션 엔트리는 어카운팅 메시지로부터 생성되기 때문에 속성 수가 제한됩니다. 예를 들어, 세션 ABC에서 포스처 상태를 사용할 수 없습니다. 사용자 그룹 및 기타 권한 부여 특정 특성 같은 것도 없습니다.
팬텀 세션은 다음 시나리오에서 PSN 세션 캐시에 나타납니다.
- 네트워크 전송에 대한 단기 중단.
- 네트워크 액세스 디바이스의 잘못된 동작.
- 로드 밸런서에서 잘못된 동작 또는 잘못된 컨피그레이션입니다.
다음은 PSN1에 대한 네트워크 경로에 일시적인 문제가 있는 시나리오에 대한 팬텀 세션의 예입니다.
1. 세션 ABC에 대한 초기 인증은 PSN에서 수행합니다.
2. PSN1은 로컬 캐시에 세션 ABC에 대한 항목을 생성합니다.
3. 전달 된 인증을 위한 syslog 메시지가 MNT 노드로 전송 됩니다.
4. 세션 ABC에 대한 항목이 TimesTen DB에 Authenticated(인증됨) 상태로 생성됩니다.
5. 세션 ABC에 대한 계정 관리 시작 메시지가 PSN 1에 있습니다.
6. 세션 ABC에 대한 세션 캐시 항목이 Accounting-Start의 정보로 갱신됩니다.
7. Accounting-Start에 대한 Syslog 메시지가 MNT 노드로 전송됩니다.
8. 세션 상태가 시작됨으로 업데이트됩니다.
9. 세션 ABC에 대한 중간 회계 업데이트가 PSN2로 전달됩니다.
10. PSN2는 로컬 캐시에 세션 ABC에 대한 항목을 생성합니다.
11. 세션 ABC에 대한 Accounting-Stop이 PSN1에 전달됩니다.
12. 세션 ABC에 대한 항목이 PSN1의 세션 캐시에서 제거됩니다.
13. Accounting-Stop에 대한 syslog 메시지가 PSN 1에 의해 MNT로 전달됩니다.
14. 세션 ABC가 MNT에서 종료된 것으로 표시됩니다.
다음은 장기 지속 VPN 연결을 위해 생성된 팬텀 세션의 시나리오를 보여줍니다.
1. PSN1에 대한 초기 인증
2. 세션 캐시에서 세션 ABC가 생성됩니다.
3. Accounting은 PSN에서 처리하는 메시지를 시작합니다.
4. 새 IP 주소가 VPN(Virtual Private Network) 어댑터에 할당됩니다.
5. PSN에 있는 IP 주소에 대한 중간 회계 업데이트
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 Posture 모듈은 엔드포인트에 대한 인증을 수행한 PSN을 찾기 위해 4개의 동시 문제를 실행합니다.
먼저 그림에서 3개의 프로브는 리디렉션 기반(기본 GW IP)입니다. 검색 호스트 IP(정의된 경우) 및 enroll.cisco.com IP. 이러한 프로브는 NAD 자체에서 리디렉션된 URL을 가져옴에 따라 항상 에이전트를 올바른 PSN으로 가리킵니다.
Probe 번호 4는 ConnectionData.xml 파일에 있는 모든 기본 서버로 전송됩니다. 이 파일은 첫 번째 성공 적 인 상태 시도 후 생성 됩니다. 클라이언트가 PSN 간에 마이그레이션하는 경우 파일 내용을 나중에 업데이트할 수 있습니다.
Windows 시스템에서 파일 위치는 C:\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client\ISE Posture\입니다.
모든 1단계 프로브가 동시에 실행되므로, 프로브 4의 결과는 다른 3개 프로브가 모두 실패하거나 ISE 포스처 모듈이 리디렉션 URL에서 반환된 PSN과의 통신을 5초 이내에 제대로 설정할 수 없는 경우에만 사용됩니다.
프로브 4가 PSN에 착륙하면 엔드포인트에서 검색된 활성 IP 및 MAC 주소 목록이 포함됩니다. PSN은 이 데이터를 사용하여 로컬 캐시에서 이 엔드포인트에 대한 세션을 찾습니다.
PSN에 엔드포인트에 대한 부실 또는 팬텀 세션이 있는 경우, 클라이언트 측에서 나중에 잘못된 상태 상태가 표시될 수 있습니다.
에이전트가 프로브 4에 대해 여러 개의 응답을 받는 경우(ConnectionData.xml에 둘 이상의 기본 PSN이 포함될 수 있음) 항상 가장 빠른 응답이 사용됩니다.
2단계 검색:
모든 2단계 검색 프로브는 리디렉션이 없으므로 모든 프로브가 대상 PSN에서 세션 조회를 트리거합니다.
PSN이 로컬 세션 캐시에서 세션을 찾을 수 없는 경우 MNT 조회(MAC 주소 기반 전용)를 수행하여 세션 소유자를 찾고 소유자 이름을 에이전트에게 반환해야 합니다.
모든 프로브가 세션 조회를 트리거하므로 2단계 검색은 오래된 세션 또는 팬텀 세션의 결과로 인한 문제의 영향을 더 크게 받을 수 있습니다.
PSN이 2단계에 도달하면 세션 캐시에 있는 검색 프로브는 동일한 엔드포인트에 대해 부실 또는 팬텀 엔트리를 생성합니다. 최종 사용자에게 반환된 잘못된 상태 상태가 됩니다.
이 예에서는 PSN이 오래된 세션 또는 팬텀 세션을 유지할 때 상태가 발생하는 방법을 보여 줍니다.
1. ISE Posture 모듈에서 발급한 내 세션 프로브 찾기
2. PSN은 세션 캐시에서 세션 조회를 수행합니다. 세션을 찾으면 부실 또는 팬텀 세션 문제가 발생합니다.
3. PSN에서 클라이언트 프로비저닝 정책 선택을 실행합니다. 인증/권한 부여 특성이 없는 팬텀 세션과 고객이 구성한 모든 정책이 매우 구체적인 경우(예: 특정 Active Directory 그룹에 대해 정책이 생성됨), PSN은 올바른 클라이언트 프로비저닝 정책을 할당할 수 없습니다. 이는 "AnyConnect 스캔 우회를 통해 네트워크가 Cisco NAC Agent를 사용하도록 구성되었습니다."라는 오류 메시지에서 나타날 수 있습니다.
- 클라이언트 프로비저닝 정책이 일반적인 경우(팬텀 세션에서 사용 가능한 특성은 AnyConnect 컨피그레이션과 정책을 일치시키기에 충분함) PSN은 평가 프로세스를 계속하는 데 필요한 세부 정보를 사용하여 회신합니다.
- 이 단계에서는 오래된 세션을 처리할 수 있을 때 PSN이 Compliant(규정 준수) 상태로 바로 회신하며 모든 다음 단계가 수행되지 않습니다. PSN은 세션이 이미 규정을 준수한다고 생각하므로 COA를 보내지 않습니다. Radius Live 로그에는 Compliant 상태로 표시되는 세션 이벤트가 없습니다.
4. 팬텀 세션 시나리오의 경우 ISE Posture 모듈은 Initial Posture 요청을 계속 진행합니다. 이 요청에는 엔드포인트에서 탐지된 모든 보안 및 패치 관리 제품에 대한 정보가 포함됩니다.
5. PSN은 요청 및 세션 특성의 정보를 사용하여 올바른 상태 정책과 일치시킵니다. 이 시점에서 팬텀 세션은 속성이 부족하기 때문에, 우리는 일치시킬 정책이 없습니다. 이러한 경우 PSN은 엔드포인트에 규정을 준수한다고 응답합니다. 이는 일치 하지 않는 상태 정책의 경우 기본 ISE 동작 입니다.
6. PSN은 선택한 포스처 정책을 에이전트에게 다시 반환합니다.
7. 에이전트는 각 정책/요구 사항의 상태를 "통과" 또는 "실패"로 반환합니다.
8. ISE에서 보고서 평가가 수행되고 세션 상태가 Compliant로 변경됩니다.
새 인증 시도에서 검색 프로세스가 시작되지 않습니다.
ISE Posture 모듈은 엔드포인트에서 제한된 양의 이벤트를 모니터링하여 검색 프로세스를 트리거하도록 설계되었습니다.
검색을 트리거하는 이벤트:
- 초기 ISE 상태 모듈 설치.
- 사용자 로그인.
- 전원 이벤트.
- 인터페이스 상태 변경.
- 절전 모드 후 OS가 다시 시작됩니다.
- DG(Default Gateway) 변경.
- PRA(Posture Reassessment) 실패. Cisco 버그 ID CSCvo를 참조하십시오69557
새로운 dot1x 인증, PC 잠금 해제 및 IP 주소 변경은 ISE Posture 모듈에서 탐지되지 않습니다.
ISE Posture 모듈은 다음 시나리오에서 새 인증 또는 재인증 시도를 탐지할 수 없습니다.
- 재인증은 다른 PSN에 도달합니다(LB 결정 또는 원래 PSN의 문제로 인해).
- NAD는 재인증 시 새 session-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에 의해 세션에 할당됩니다.
NAD는 재인증 시 새 세션 ID를 생성합니다.
이는 다음과 같은 두 가지 일반적인 시나리오에서 발생할 수 있습니다.
- 재인증이 ISE 측에서 잘못 구성되었습니다. 이 문제의 해결책은 이 문서의 뒷부분에서 다룹니다.
- NAD 측의 잘못된 동작. 일반적으로 NAD는 재인증 시도 중에 동일한 세션 ID를 유지합니다. 이는 NAD 자체에서 조사되어야 할 잠재적인 버그식 행동입니다.
새 세션 ID는 다른 코너 케이스 시나리오에서 생성할 수 있습니다. 예를 들어, 무선 로밍이 원인인 경우도 있습니다.
여기서 중요한 것은 상태 리스가 구성되지 않는 한 ISE PSN은 항상 새 세션을 상태 Pending 상태로 전환한다는 것입니다. 포스처 리스에 대해서는 이 문서의 뒷부분에서 설명합니다.
문제가 부실/팬텀 세션으로 인해 발생한 경우를 신속하게 식별할 수 있는 방법
AnyConnect가 리디렉션 상태에 있는 동안 규정 준수를 표시하는지 여부를 확인하기 위해 부실/팬텀 세션으로 인해 발생한 것입니다. 문제가 있는 상태에서 엔드포인트에 액세스해야 합니다.
- Investigate System Scan Details(시스템 스캔 세부사항 조사):
1. AnyConnect UI에서 톱니바퀴 모양 아이콘을 클릭합니다
2. 새 창에서 System Scan > Statistics로 이동합니다
여기서 두 가지 요소에 주목하십시오.
- Latest Scan Start Time(최신 스캔 시작 시간) - 여기에서 타임스탬프는 문제가 발견된 시간에 근접해야 합니다.
- Policy Server(정책 서버) - 이 필드는 엔드포인트에 대한 상태 평가를 수행한 정책 서버의 이름을 나타냅니다. 여기서 FQDN은 Redirect-URL의 FQDN(리디렉션 기반 포스처) 또는 마지막 인증 시도(리디렉션 없는 포스처)에서 가져온 PSN 이름과 비교해야 합니다.
- 시스템 검사 통계의 정책 서버 FQDN을 엔드포인트에 대한 인증을 수행한 노드 이름과 비교합니다.
데모에서는 문제 식별에 필요한 단계를 기록합니다.
부실/팬텀 세션의 고급 문제 해결
이전 예는 오래된 세션 또는 팬텀 세션의 문제와 시작되지 않은 검색 프로세스의 문제를 구별하는 역할을 합니다.
동시에 문제를 유발한 실제 세션을 식별해야 부실 또는 팬텀 세션 문제가 되는 정확한 상황을 더 잘 이해할 수 있습니다.
일부 시나리오에서는 부실 및 팬텀 세션을 피할 수 없지만, 환경에서 부실/팬텀 세션이 생성되지 않도록 모범 사례를 구현해야 합니다.
DART 번들 모음
문제를 재현한 엔드포인트에서 가져온 DART 번들을 분석합니다.
- DART에 중요한 로그만 보관합니다. 문제가 재현되기 전에 로그를 지우는 것이 좋습니다.
이를 위해서는 DART 번들 유틸리티가 관리자로 시작하여 로그 정리를 수행해야 합니다.
- Windows에서 시작으로 이동하여 DART를 입력하고 마우스 오른쪽 버튼을 클릭한 다음 - 관리자로 실행을 선택합니다.
- 첫 번째 마법사 화면에서 다음을 클릭합니다.
- 다음 마법사 화면에서 Clear All Logs(모든 로그 지우기)를 클릭합니다.
- 문제가 재현되면 여기에서 DART를 수집할 수 있습니다. Next(다음)를 클릭합니다.
DART 번들 분석
DART 번들이 수집된 후 아카이브를 해제하고 Cisco AnyConnect ISE Posture Module 폴더에 있는 AnyConnect_ISPosture.txt 파일에 초점을 맞춥니다. 이 파일에는 모든 검색 관련 이벤트가 포함되어 있습니다.
1. 문제 해결을 시작하고 검색이 다시 시작되는 모든 순간을 확인합니다. 검색할 키워드는 검색 또는 HTTP 검색을 다시 시작하는 것입니다. 여기서 문제가 되는 순간에 검색 재시작이 발생한 줄로 이동합니다.
2. 검색 재시작 후 여러 행에 MNT 스테이지 대상에서 프로빙을 포함하는 행이 있습니다. 1단계 검색 시작을 나타내는 지표입니다.
ConnectionData.xml(Auth-Status 대상)에서 가져온 이전 연결 PSN과 동일한 색상의 모든 리디렉션 기반 프로브를 다른 색상으로 강조 표시하는 것이 좋습니다.
일반적으로 PSN FQDN은 매우 유사하며 차이점을 찾아내기가 어렵습니다.
3. 로그 파일을 읽고 모든 단일 프로브의 결과를 확인합니다. 다음은 실패한 프로브가 표시되는 예입니다.
4. 1단계 또는 2단계의 검색이 다시 시작된 후 파일 어딘가에 하나 이상의 PSN에서 성공적으로 회신이 온 것을 확인할 수 있습니다.
5. 여러 행 뒤에 MSG_NS_SWISS_NEW_SESSION 키워드가 있는 행이 있습니다.
이 줄에는 세션 조회의 결과로 PSN에서 선택한 실제 세션 ID가 포함되어 있습니다.
이 세션 ID를 사용하여 ISE에 대한 추가 조사를 수행하여 이 세션이 부실/팬텀이 되는 방법을 확인할 수 있습니다.
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 주소의 배열이 포함됩니다. 이 특정 예에서 각 배열은 하나의 값만 보유합니다.
이 로그는 요청의 세션 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
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(RADIUS 어카운팅 보고서)로 이동하여 7일 동안 이 보고서를 실행합니다. 엔드포인트 ID를 필터 키로 사용합니다.
다음은 오래된 세션이 ciscolive-ise2에 남아 있는 방법을 보여 주는 보고서의 예입니다.
- 세션에 대한 어카운팅 시작이 PSN ciscolive-ise2로 전송되었습니다.
- 세션에 대한 중간 업데이트가 동일한 PSN에서 처리되었습니다.
- 문제가 있는 세션 ID에 대한 계정 관리 중지 메시지가 다른 PSN(ciscolive-ise1)으로 전달되었습니다.
디스커버리 재시작 없이 발생한 문제의 원인을 신속하게 파악
여기에서도 앞선 사안과 동일한 논리가 적용될 수 있다. 유일한 차이점은 Latest Scan Start Time(최신 스캔 시작 시간)에 주력해야 한다는 것입니다. 이러한 유형의 문제에서 마지막 스캔의 타임스탬프는 과거 어딘가에 있습니다.
일반적으로 최종 사용자가 문제를 발견하면 몇 시간 전에 수행된 검사가 표시됩니다. ISE Radius Live 로그에 있는 동안 문제가 되는 엔드포인트의 최근 인증 시도가 표시됩니다.
데모에서는 문제 식별에 필요한 단계를 기록합니다.
고급 검색 재시작 부재 트러블슈팅
이 방법은 Advanced Troubleshoot Stale/Phantom Session 섹션과 매우 유사합니다. 주요 문제 해결 요소는 DART 번들 조사입니다.
DART 번들 내에서 검색 재시작을 검색하고(이전 문제와 같이) 문제가 보고된 시점에 검색 재시작이 없음을 확인할 수 있습니다.
ISE 측에서 Radius Live Logs/Radius 인증 보고서를 중점적으로 검토하여 PSN 간에 장애 조치가 발생했거나 NAD에 의해 새 세션 ID가 생성되었음을 확인합니다.
솔루션
고전적 접근 방식 - 이슈 회피
지금까지 ISE에는 이 문서에 설명된 문제를 해결할 수 있는 기능이 없으므로 네트워크 및 ISE에 구현된 모범 사례 집합에 의존하는 것이 유일한 방법이었으며 위험을 최소화했습니다.
ISE 구축에서 오래된 세션 또는 가상 세션의 양을 최소화할 수 있는 모범 사례
가능한 경우 항상 리디렉션 기반 상태 구현
이 권장 사항에 대한 일반적인 반대 의견은 사용자 환경이 좋지 않다는 것입니다. OS 또는 브라우저에서 팝업이 나타납니다. 이는 백그라운드에서 AnyConnect ISE Posture 모듈이 평가 프로세스를 수행하는 동안 리디렉션을 나타냅니다.
이에 대한 해결책으로 ISE Posture 모듈 검색 프로브만 리디렉션하고 다른 모든 트래픽을 선택적으로 허용할 수 있습니다.
다음 예에서는 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과 결합할 수 있습니다.
Pending State(보류 중 상태)는 엔드포인트가 인증된 PSN에 대해서만 연결을 허용합니다.
이 접근 방식은 url-리디렉션이 지원되지 않는 환경(예: 서드파티 NAD를 사용한 구현)에 유용합니다.
해결 방법으로 여러 PosturePending 권한 부여 정책(PSN당 하나)을 구현합니다. 각 정책은 인증 이 발생 한 PSN의 이름을 조건 중 하나로 포함 해야 합니다.
각 정책에 할당된 권한 부여 프로파일에서 모든 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 Posture 모듈이 검색 프로세스를 다시 시작합니다.
4. PSN2에 대한 프로브는 이전에 할당된 ACL과 마찬가지로 NAD에 의해 차단됩니다.
5. PSN1에 대한 프로브는 NAD에 할당된 ACL에 의해 허용됩니다.
로드 밸런서 모범 사례
- Calling-Station-ID를 고정 키로 사용하여 인증 및 어카운팅을 위해 로드 밸런서에서 고정 기능을 활성화합니다. ISE에 대한 LB 모범 사례에 대한 자세한 내용은 여기를 참조하십시오.
- PC가 절전 모드로 전환되는 시간(예: 8시간이 아닌 10시간)을 감당하려면 평균 업무일보다 긴 고착성 타이머를 사용하십시오.
- 재인증이 구현된 경우, 재인증 타이머를 고착성 타이머보다 약간 낮게 사용합니다(예를 들어, 고착성이 10시간으로 구성된 경우 8시간). 이렇게 하면 재인증을 통해 고착성 간격이 연장됩니다.
Posture Over VPN 활용 사례
- accounting-interim 업데이트 간격이 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 Posture 모듈 검색 재시작의 부재로 인한 영향을 최소화할 수 있습니다.
상태 임대 사용
이는 엔드포인트를 정의된 기간(1-365일) 동안 규정 준수로 표시하는 ISE의 기능입니다. 포스처 리스 값은 ISE DB에 저장됨을 의미하는 엔드포인트 특성입니다.
상태 임대를 포함하는 모든 엔드포인트 특성은 ISE 구축의 모든 노드에 복제됩니다.
PSN이 엔드포인트 상태에 대한 새 세션을 가져오면 리스를 활용하여 즉시 세션을 Compliant로 표시할 수 있습니다.
이 결정을 내리기 위해 PSN은 3개의 값을 사용한다. 해당 값은 다음과 같습니다.
1. ISE 설정에서 포스처 임대에 정의된 기간: Administration > System > Posture > General Settings로 이동합니다.
2. PostureExpiry 특성의 값은 Epoch 타임스탬프를 포함하는 실제 엔드포인트 특성입니다. PostureExpiry 값은 ISE 관리자가 포스처 임대를 활성화한 후 엔드포인트에 대한 첫 번째 성공적인 포스처 시도 시 초기에 채워집니다.
나중에 이 값은 임대 만료 후 다음 성공 적 인 상태 시도에 업데이트 됩니다.
포스처 엔드포인트 중 하나가 열린 동안 Context Visibility(상황 가시성) > Endpoints(엔드포인트)에서 PostureExpiry(포스처 만료)를 볼 수 있습니다.
이 값은 사람이 읽을 수 있는 타임스탬프로 변환할 수 있습니다(예: https://www.epochconverter.com/).
3. 새로운 인증이 발생하는 시점의 PSN 시스템 시간
포스처 임대를 사용하는 엔드포인트에 대한 인증이 PSN에 도달하면 PostureExpiry 및 시스템 날짜를 사용하여 마지막으로 성공한 포스처 검사에서 경과된 기간(일)을 가져옵니다.
결과 값이 설정에 정의된 상태 임대 간격 내에 있으면 세션은 Compliant 상태를 가져옵니다.
결과 값이 리스 값보다 크면 세션은 Unknown(알 수 없음) 상태가 됩니다.
이렇게 하면 상태가 다시 실행되고 새 PostureExpiry 값이 저장될 수 있습니다.
이 다이어그램은 장애 조치가 수행되는 프로세스를 보여줍니다.
1. PSN1에서 초기 인증이 수행됩니다.
2. 세션 캐시에서 세션 ABC가 생성됩니다.
3. 실태파악
4. 세션 상태가 Compliant로 변경됩니다
5. COA는 상태 변경에 의해 트리거되며 다음 액세스 레벨을 적용하기 위해 엔드포인트의 재인증으로 이어집니다.
6. PostureExpiry 값이 엔드포인트에 저장됩니다.
7. 엔드포인트 데이터는 구축 전반에 걸쳐 복제됩니다.
8. 다음 인증이 PSN2에 도달합니다.
9. PSN2는 엔드포인트가 유효한 포스처 리스 내에 있는지 확인합니다.
11. 세션이 세션 캐시에 [호환]으로 추가됩니다.
12. 유효한 임대로 인해 세션이 포스처 상태 준수 상태로 생성됩니다.
재인증 구현
Reauthentication During Connectivity(재인증 중 연결 유지)에서 선택한 RADIUS-Request(RADIUS 요청)를 사용하여 ISE에서 재인증 타이머를 항상 푸시합니다. 이 설정은 NAD가 재인증 시 동일한 세션 ID를 유지하도록 합니다.
.
로드 밸런서가 있는 환경
동일한 모범 사례(부실/팬텀 세션 섹션에서 설명)를 구현할 수 있습니다.
서로 다른 서브넷을 Pending(보류 중) 및 Compliant(준수) 상태에 사용할 수 있음
네트워크 설계에서 서로 다른 서브넷 Pending 및 Compliant 상태를 사용할 수 있는 기회를 제공하는 경우, 이 접근 방식은 포스처 상태를 변경할 때마다 Default Gateway(기본 게이트웨이)가 변경되도록 보장합니다.
재인증 타이머와 동일한 간격으로 사용되는 상태 평가
Posture Assessment는 재인증 타이머와 같은 간격으로 활성화할 수 있습니다. 이러한 경우 원래 PSN을 사용할 수 없게 되면 PRA 장애가 검색 프로세스를 다시 시작합니다.
최신 접근 방식 - 상태 공유
(Cisco 버그 ID CSCvi35647에 설명된) 구현된 개선의 일환으로 ISE 2.6용 패치 6에는 ISE 구축의 모든 노드에서 세션 포스처 상태를 공유하는 새로운 기능이 있습니다.
이러한 개선 사항은 향후 릴리스인 ISE 2.7 패치 2 및 ISE 3.0에 통합됩니다.
이 새로운 기능은 ISE 2.6에 도입된 LSD(Light Session Directory) 메커니즘을 기반으로 합니다. 최신 버전에서는 이 기능의 이름이 LDD(Light Data Distribution) Radius 세션 디렉토리로 변경되었습니다. Light Data Distribution은 기본적으로 활성화되어 있으며 ISE 노드 간에 제한된 세션 컨텍스트를 공유할 수 있도록 합니다. PSN 간의 전체 세션 컨텍스트 복제와 같은 기능은 없으며, 각 세션에 대해 공유되는 특성의 양이 제한적입니다.
Light Session Directory를 사용하면 구축의 노드 중 하나에서 현재 세션 소유자를 결정해야 할 때 MNT에 대해 값비싼 리소스 API 호출을 실행할 필요가 없습니다.
대개 COA 흐름이 시작될 때 소유자 조회가 필요합니다. LDD를 사용하면 모든 PSN은 로컬 Radius 세션 디렉터리 캐시에서 세션의 실제 소유자를 찾을 수 있습니다.
라이트 데이터 분배 아키텍처
이 기능에는 다음 요소가 포함됩니다.
- RSD(Radius Session Directory) 캐시
이 캐시는 모든 ISE 노드에 존재하며 ISE 구축에서 제공되는 모든 활성 세션을 저장합니다. 모든 세션은 캐시에 제한된 양의 특성을 가지고 있습니다.
다음은 각 세션에 대한 Radius 세션 디렉토리에 저장된 특성의 예입니다.
- 세션 ID
- 엔드포인트 MAC
- 호출 스테이션 ID
- 엔드포인트 IP
- PSN IP - 인증이 발생한 PSN
- PSN FQDN
- NAS IP 주소
- NAS IPv6 주소
- 상태 - 인증됨, 시작됨, 중지됨
- RabbitMQ 교환
ISE 구축의 모든 노드에 게시자, 관련 대기열 및 소비자가 표시되는 Exchange가 있습니다. 이렇게 하면 모든 ISE 노드 간에 풀 메시 토폴로지가 형성됩니다.
- 게시자
Radius 세션 디렉토리는 여기서 게시자를 나타냅니다. PSN에 의해 새 성공 인증이 처리되면 PSN 세션 캐시에서 새 세션이 생성됩니다.
이 세션의 경우, Radius 세션 디렉토리에 제한된 속성 세트가 배치됩니다.
- Consumer(소비자) - 다른 모든 노드에서, Radius Session Directory(Radius 세션 디렉토리)는 소비자를 나타냅니다.
참고: 일반적인 RabbitMQ 용어 및 아키텍처는 이 문서 범위에 속하지 않습니다.
이 그림에서는 RSD 캐시에서 COA 플로우가 작동하는 방식을 설명합니다.
1. PSN1에서 초기 인증이 수행됩니다.
2. 세션 캐시에서 세션 ABC가 생성됩니다.
3. 필수 속성은 RSD에 저장됩니다.
4. 세션이 다른 모든 ISE 노드와 RabbitMQ를 통해 공유됩니다.
5. 모든 ISE 노드의 RSD 캐시에서 세션이 생성됩니다.
6. 새 프로파일 데이터가 PSN2에 도착합니다.
7. 엔드포인트가 다시 프로파일링되고 (COA 실행 PSN2가 필요한 변경의 경우) 다음 단계를 진행합니다.
8. COA를 실행하기 위해 내부 API 호출이 RSD 캐시에 제출됩니다.
9. RSD 캐시의 데이터를 사용하여 프록시 COA 메시지를 준비합니다. 이는 한 ISE 노드에서 다른 노드로 이동하며 목적지 노드가 NAD로 다시 CAO 요청을 발행하는 데 사용할 수 있는 모든 세부 정보를 포함합니다. COA 메시지는 먼저 PRRT 런타임(ISE 내부의 실제 AAA 서버)에 내부적으로 전송됩니다.
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를 통한 상태 공유
상태 공유는 근본 원인이 부실/팬텀 세션이거나 검색 재시작을 트리거하지 않은 다른 PSN에서 재인증인 경우 문제를 해결합니다.
세션이 Compliant가 되면 이 정보는 세션 RSD에 저장되며 나중에 구축의 모든 PSN에서 사용될 수 있습니다.
기술된 기능이 해결할 수 없는 몇몇 다른 코너 케이스들이 여전히 존재한다. 예를 들어 NAD가 동일한 PSN에서 재인증을 실행하지만 세션 ID가 다른 시나리오를 예로 들 수 있습니다.
이러한 시나리오는 이 문서에 설명된 모범 사례로 처리할 수 있습니다.
이 그림에서는 상태 공유 테스트에 사용되는 토폴로지를 보여줍니다.
RSD를 통한 상태 공유 - 부실/팬텀 세션
오래된 세션을 생성하려면 skuchere-ise26-1에서 초기에 인증을 수행해야 합니다. 그런 다음 SKUCHERE-ise26-3에 어카운팅을 전송하도록 NAD를 다시 구성해야 합니다.
하나의 어카운팅 메시지가 잘못된 PSN으로 전달된 후, 어카운팅을 skuchere-ise26-1로 다시 보내려면 NAD를 다시 재구성해야 합니다.
이 그림에는 skuchere-ise26-3에 대한 팬텀 세션이 있음을 증명하는 회계 보고서가 나와 있습니다.
1. skuchere-ise26-1에서 처리하는 Accounting-Start 메시지
2. skuchere-ise26-3에서 처리하는 동일 세션에 대한 중간 회계 업데이트
3. 세션이 skuchere-ise26-1에서 나중에 끝납니다.
일정 시간이 지나면 엔드포인트가 다시 네트워크에 연결되지만 리디렉션이 더 이상 작동하지 않습니다. PSN의 guest.log - skuchere-ise26-3에서 DEBUG에 클라이언트-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와 다른 세션 ID가 있는 경우 세션(세션 캐시에 있음)이 오래된 것으로 가정합니다.
RSD를 통한 상태 공유 - PSN 간 장애 조치
이 시나리오를 재현하기 위해, 짧은 재인증 타이머가 호환 상태 엔드포인트에 할당된 권한 부여 프로파일에서 활성화됩니다.
나중에 NAD가 다른 PSN(skuchere-ise26-3)에 인증 및 어카운팅을 전송하도록 재구성됩니다.
재인증 타이머 만료 시 동일한 세션이 다른 PSN에서 인증되지 않습니다.
이 그림에서는 skuchere-ise26-1에서 skuchere-ise26-3으로의 동일한 세션에 대한 장애 조치를 보여 주는 인증 보고서를 보여 줍니다.
1. 인증은 skuchere-ise26-1에서 발생하며 리디렉션이 있는 권한 부여 프로파일이 할당됩니다.
2. 자세평가에 성공한 후 COA
3. 규정 준수 상태에 대한 권한 부여 프로파일이 할당된 경우 다음 인증.
4. 인증은 다른 PSN에 도달하지만 호환 상태에 대한 권한 부여 프로파일을 받습니다.
DEBUG로 활성화된 epm-pip 및 nsf-session 구성 요소를 포함하는 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 |
최초 릴리스 |
피드백