소개
이 문서에서는 Cisco ASA(Adaptive Security Appliance) 및 Cisco ACS(Secure Access Control Server)와 통합할 수 있는 RSA Authentication Manager의 문제 해결 절차에 대해 설명합니다.
RSA Authentication Manager는 인증을 위해 OTP(One Time Password)를 제공하는 솔루션입니다. 이 비밀번호는 60초마다 변경되며 한 번만 사용할 수 있습니다. 하드웨어 및 소프트웨어 토큰을 모두 지원합니다.
사전 요구 사항
요구 사항
Cisco에서는 다음 항목에 대한 기본 지식을 갖춘 것을 권장합니다.
- Cisco ASA CLI 컨피그레이션
- Cisco ACS 컨피그레이션
사용되는 구성 요소
이 문서의 정보는 다음 소프트웨어 버전을 기반으로 합니다.
- Cisco ASA 소프트웨어, 버전 8.4 이상
- Cisco Secure ACS, 버전 5.3 이상
이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 현재 네트워크가 작동 중인 경우 모든 명령의 잠재적인 영향을 미리 숙지하시기 바랍니다.
이론
RSA 서버는 RADIUS 또는 전용 RSA 프로토콜을 통해 액세스할 수 있습니다. SDI. ASA와 ACS 모두 RSA에 액세스하기 위해 두 프로토콜(RADIUS, SDI)을 사용할 수 있습니다.
소프트웨어 토큰을 사용할 경우 RSA를 Cisco AnyConnect Secure Mobility Client와 통합할 수 있습니다. 이 문서에서는 ASA와 ACS 통합에만 중점을 둡니다. AnyConnect에 대한 자세한 내용은 Cisco AnyConnect Secure Mobility Client Administrator Guide, Release 3.1의 Using SDI Authentication(SDI 인증 사용) 섹션을 참조하십시오.
RADIUS를 통한 RSA
RADIUS는 SDI보다 한 가지 큰 이점을 가지고 있습니다. RSA에서는 사용자에게 특정 프로필(ACS의 그룹이라고 함)을 할당할 수 있습니다. 이러한 프로파일에는 특정 RADIUS 특성이 정의되어 있습니다. 인증에 성공하면 RSA에서 반환된 RADIUS-Accept 메시지에 이러한 특성이 포함됩니다. 이러한 특성을 기반으로 ACS는 추가 결정을 내립니다. 가장 일반적인 시나리오는 RSA의 프로파일과 관련된 특정 RADIUS 특성을 ACS의 특정 그룹에 매핑하기 위해 ACS 그룹 매핑을 사용하기로 결정하는 것입니다. 이 논리를 사용하면 전체 권한 부여 프로세스를 RSA에서 ACS로 이동하고 RSA에서처럼 세분화된 논리를 유지할 수 있습니다.
SDI를 통한 RSA
SDI는 RADIUS에 비해 두 가지 주요 장점을 가지고 있다. 첫 번째는 전체 세션이 암호화된다는 것입니다. 두 번째는 SDI 에이전트가 제공하는 흥미로운 옵션입니다. 인증 또는 권한 부여에 실패했거나 사용자를 찾을 수 없어 실패가 발생했는지 확인할 수 있습니다.
이 정보는 ACS에서 ID에 대해 작동하는 데 사용됩니다. 예를 들어, "user not found"에 대해서는 계속되지만 "authentication failed"에 대해서는 거부될 수 있습니다.
RADIUS와 SDI는 한 가지 차이점이 더 있습니다. ASA와 같은 네트워크 액세스 디바이스가 SDI를 사용하는 경우 ACS는 인증만 수행합니다. RADIUS를 사용하는 경우 ACS는 AAA(Authentication, Authorization, Accounting)를 수행합니다. 그러나, 이것은 큰 차이가 아니다. 인증을 위한 SDI와 동일한 세션을 어카운팅하기 위한 RADIUS를 구성할 수 있습니다.
SDI 프로토콜
기본적으로 SDI는 UDP(User Datagram Protocol) 5500을 사용합니다. SDI는 세션을 암호화하기 위해 RADIUS 키와 유사한 대칭 암호화 키를 사용합니다. 이 키는 노드 비밀 파일에 저장되며 모든 SDI 클라이언트에 대해 다릅니다. 해당 파일은 수동 또는 자동으로 구축됩니다.
참고: ACS/ASA는 수동 구축을 지원하지 않습니다.
자동 구축 노드의 경우, 비밀 파일은 첫 번째 성공 적 인 인증 후 자동으로 다운로드 됩니다. 노드 암호는 사용자의 암호 및 기타 정보에서 파생된 키로 암호화됩니다. 이렇게 하면 몇 가지 보안 문제가 발생할 수 있습니다. 공격자가 해당 파일을 가로채서 해독할 수 없도록 하기 위해 첫 번째 인증을 로컬에서 수행하고 암호화된 프로토콜(텔넷이 아닌 SSH[Secure Shell])을 사용해야 합니다.
설정
참고:
이 섹션에 사용된 명령에 대한 자세한 내용을 가져오려면 명령 조회 툴(등록 고객 전용)을 사용하십시오.
아웃풋 인터프리터 툴(등록 고객 전용)은 특정 show 명령을 지원합니다. show 명령 출력의 분석을 보려면 아웃풋 인터프리터 툴을 사용합니다.
debug 명령을 사용하기 전에 debug 명령에 대한 중요한 정보를 참조하십시오.
ACS의 SDI
이는 Users and Identity Stores(사용자 및 ID 저장소) > External Identity Store(외부 ID 저장소) > RSA Secure ID Token Servers(RSA Secure ID 토큰 서버)에서 구성됩니다.
RSA에는 ACS용 보조 서버와 같은 여러 복제본 서버가 있습니다. RSA 관리자가 제공한 sdconf.rec 파일만 포함하여 모든 주소를 여기에 둘 필요가 없습니다. 이 파일에는 기본 RSA 서버의 IP 주소가 포함되어 있습니다. 첫 번째 성공 적 인 인증 노드, 비밀 파일은 모든 RSA 복제본의 IP 주소와 함께 다운로드 됩니다.

"사용자를 찾을 수 없음"과 "인증 실패"를 구분하려면 고급 탭에서 설정을 선택합니다.

여러 RSA 서버(기본 및 복제본) 간에 기본 라우팅(로드 밸런싱) 메커니즘을 변경할 수도 있습니다. RSA 관리자가 제공한 sdopts.rec 파일로 변경합니다. ACS에서는 Users and Identity Stores(사용자 및 ID 저장소) > External Identity Store(외부 ID 저장소) > RSA Secure ID Token Servers(RSA Secure ID 토큰 서버) > ACS Instance Settings(ACS 인스턴스 설정)에서 업로드됩니다.
클러스터 구축의 경우 컨피그레이션을 복제해야 합니다. 첫 번째 성공 적 인 인증 후 각 ACS 노드는 1 주 RSA 서버에서 다운로드 된 자신의 노드 암호를 사용 합니다. 클러스터의 모든 ACS 노드에 대해 RSA를 구성해야 합니다.
ASA의 SDI
ASA에서는 sdconf.rec 파일의 업로드를 허용하지 않습니다. 또한 ACS와 마찬가지로 자동 구축만 허용합니다. 기본 RSA 서버를 가리키려면 ASA를 수동으로 구성해야 합니다. 비밀번호는 필요하지 않습니다. 첫 번째 성공 적 인 인증 노드 후 비밀 파일 이 설치 됩니다 ( 플래시의 .sdi 파일) 추가 인증 세션 이 보호 됩니다. 다른 RSA 서버의 IP 주소도 다운로드됩니다.
예를 들면 다음과 같습니다.
aaa-server SDI protocol sdi
aaa-server SDI (backbone) host 1.1.1.1
debug sdi 255
test aaa auth SDI host 1.1.1.1 user test pass 321321321
인증에 성공하면 show aaa-server protocol sdi 또는 show aaa-server <aaa-server-group> 명령은 모든 RSA 서버를 보여주지만(둘 이상의 RSA 서버가 있을 경우), show run 명령은 기본 IP 주소만 보여줍니다.
bsns-asa5510-17# show aaa-server RSA
Server Group: RSA
Server Protocol: sdi
Server Address: 10.0.0.101
Server port: 5500
Server status: ACTIVE (admin initiated), Last transaction at
10:13:55 UTC Sat Jul 27 2013
Number of pending requests 0
Average round trip time 706ms
Number of authentication requests 4
Number of authorization requests 0
Number of accounting requests 0
Number of retransmissions 0
Number of accepts 1
Number of rejects 3
Number of challenges 0
Number of malformed responses 0
Number of bad authenticators 0
Number of timeouts 0
Number of unrecognized responses 0
SDI Server List:
Active Address: 10.0.0.101
Server Address: 10.0.0.101
Server port: 5500
Priority: 0
Proximity: 2
Status: OK
Number of accepts 0
Number of rejects 0
Number of bad next token codes 0
Number of bad new pins sent 0
Number of retries 0
Number of timeouts 0
Active Address: 10.0.0.102
Server Address: 10.0.0.102
Server port: 5500
Priority: 8
Proximity: 2
Status: OK
Number of accepts 1
Number of rejects 0
Number of bad next token codes 0
Number of bad new pins sent 0
Number of retries 0
Number of timeouts 0
문제 해결
이 섹션에서는 설정 문제 해결을 위해 사용할 수 있는 정보를 제공합니다.
RSA에 에이전트 컨피그레이션 없음
새 ASA를 설치하거나 ASA IP 주소를 변경한 후 RSA에서 동일한 변경을 수행하는 것을 잊어버리기 쉬운 경우가 많습니다. RSA에 액세스하는 모든 클라이언트에 대해 RSA의 에이전트 IP 주소를 업데이트해야 합니다. 그런 다음 새 노드 암호가 생성됩니다. ACS에도 마찬가지입니다. 특히 보조 노드에도 마찬가지입니다. ACS는 IP 주소가 다르며 RSA는 이를 신뢰해야 하기 때문입니다.
손상된 비밀 노드
ASA 또는 RSA의 비밀 노드 파일이 손상되는 경우가 있습니다. 그런 다음 RSA에서 에이전트 컨피그레이션을 제거하고 다시 추가하는 것이 가장 좋습니다. ASA/ACS에서도 동일한 프로세스를 수행하여 구성을 제거하고 다시 추가해야 합니다. 또한 플래시에서 .sdi 파일을 삭제하여 다음 인증에서 새 .sdi 파일이 설치되도록 합니다. 이 완료 한 자동 노드 비밀 배포가 발생 해야 합니다.
일시 중단 모드의 노드
노드 중 하나가 일시 중단 모드에 있는 경우가 있는데, 이는 해당 서버의 응답이 없기 때문입니다.
asa# show aaa-server RSA
<.....output ommited"
SDI Server List:
Active Address: 10.0.0.101
Server Address: 10.0.0.101
Server port: 5500
Priority: 0
Proximity: 2
Status: SUSPENDED
일시 중단 모드에서는 ASA가 해당 노드로 패킷을 전송하지 않습니다. 이 경우 OK 상태가 필요합니다. 오류가 발생한 서버는 데드 타이머 이후에 다시 액티브 모드로 전환됩니다. 자세한 내용은 Cisco ASA Series Command Reference, 9.1 가이드의 reactivation-mode 명령 섹션을 참조하십시오.
이러한 시나리오에서는 해당 서버를 다시 액티브 모드로 트리거하려면 해당 그룹에 대한 AAA-server 컨피그레이션을 제거하고 추가하는 것이 가장 좋습니다.
계정 잠김
여러 번 재시도하면 RSA가 계정을 잠글 수 있습니다. 보고서를 통해 RSA에서 쉽게 확인할 수 있습니다. ASA/ACS에서 보고서는 "실패한 인증"만 표시합니다.
MTU(Maximum Transition Unit) 문제 및 조각화
SDI는 MTU 경로 검색이 아니라 UDP를 전송으로 사용합니다. 또한 UDP 트래픽에는 기본적으로 DF(Don't Fragment) 비트가 설정되어 있지 않습니다. 큰 패킷의 경우 단편화 문제가 있을 수 있습니다. RSA에서 트래픽을 스니핑하기 쉽습니다(어플라이언스와 가상 머신[VM] 모두 Windows를 사용하고 Wireshark 사용). ASA/ACS에서 동일한 프로세스를 완료하고 비교합니다. 또한 SDI와 비교하기 위해(문제를 좁히기 위해) RSA에서 RADIUS 또는 WebAuthentication을 테스트합니다.
ACS용 패킷 및 디버그
SDI 페이로드는 암호화되므로 캡처 문제를 해결할 수 있는 유일한 방법은 응답의 크기를 비교하는 것입니다. 200바이트보다 작으면 문제가 생길 수 있습니다. 일반적인 SDI 교환에는 각각 550바이트인 4개의 패킷이 포함되지만, 이는 RSA 서버 버전에 따라 변경될 수 있습니다.

문제가 발생할 경우 일반적으로 4개 이상의 패킷이 교환되고 크기가 더 작습니다.

또한 ACS 로그는 매우 명확합니다. 다음은 ACS의 일반적인 SDI 로그입니다.
EventHandler,11/03/2013,13:47:58:416,DEBUG,3050957712,Stack: 0xa3de560
Calling backRSAIDStore: Method MethodCaller<RSAIDStore, RSAAgentEvent> in
thread:3050957712,EventStack.cpp:242
AuthenSessionState,11/03/2013,13:47:58:416,DEBUG,3050957712,cntx=0000146144,
sesn=acs-01/150591921/1587,user=mickey.mouse,[RSACheckPasscodeState
::onEnterState],RSACheckPasscodeState.cpp:23
EventHandler,11/03/2013,13:47:58:416,DEBUG,3002137488,Stack: 0xa3de560
Calling RSAAgent:Method MethodCaller<RSAAgent, RSAAgentEvent> in thread:
3002137488,EventStack.cpp:204
RSAAgent,11/03/2013,13:47:58:416,DEBUG,3002137488,cntx=0000146144,sesn=
acs-01/150591921/1587,user=mickey.mouse,[RSAAgent::handleCheckPasscode],
RSAAgent.cpp:319
RSASessionHandler,11/03/2013,13:47:58:416,DEBUG,3002137488,[RSASessionHandler::
checkPasscode] call AceCheck,RSASessionHandler.cpp:251
EventHandler,11/03/2013,13:48:00:417,DEBUG,2965347216,Stack: 0xc14bba0
Create newstack, EventStack.cpp:27
EventHandler,11/03/2013,13:48:00:417,DEBUG,3002137488,Stack: 0xc14bba0 Calling
RSAAgent: Method MethodCaller<RSAAgent, RSAServerResponseEvent> in
thread:3002137488,EventStack.cpp:204
RSAAgent,11/03/2013,13:48:00:417,DEBUG,3002137488,cntx=0000146144,sesn=acs-01
/150591921/1587,user=mickey.mouse,[RSAAgent::handleResponse] operation completed
with ACM_OKstatus,RSAAgent.cpp:237
EventHandler,11/03/2013,13:48:00:417,DEBUG,3002137488,Stack: 0xc14bba0
EventStack.cpp:37
EventHandler,11/03/2013,13:48:00:417,DEBUG,3049905040,Stack: 0xa3de560 Calling
back RSAIDStore: Method MethodCaller<RSAIDStore, RSAAgentEvent> in thread:
3049905040,EventStack.cpp:242
AuthenSessionState,11/03/2013,13:48:00:417,DEBUG,3049905040,cntx=0000146144,sesn=
acs-01/150591921/1587,user=mickey.mouse,[RSACheckPasscodeState::onRSAAgentResponse]
Checkpasscode succeeded, Authentication passed,RSACheckPasscodeState.cpp:55
관련 정보