RADIUS 거부와 무응답: 로컬 로그인이 실행되는 조건

긴급용 로컬 계정을 유지한다고 해서 그것이 거부된 모든 로그인에 두 번째 기회가 되는 것은 아닙니다. Cisco IOS와 IOS XE의 AAA 모델에서 그 데이터베이스는 이전 메서드가 특정한 방식으로 실패할 때만 조회되며, 거부로 응답하는 RADIUS 서버는 그런 방식으로 실패한 것이 아닙니다. 로컬 계정은 도달할 수 없는 메서드를 처리하며, 거부된 메서드를 처리하지 않습니다. 반대로 믿으면 정책 결정이 존재하지 않는 서버 결함을 찾는 일로 바뀝니다.

메서드 목록이 사다리처럼 보이는 이유

다음과 같은 줄 aaa authentication login default group radius local 은 왼쪽에서 오른쪽으로 읽히며, 대부분의 사람은 RADIUS를 시도한 뒤 로컬 데이터베이스를 시도한다고 읽습니다. 목록은 순서이므로 구문이 그런 읽기를 유도합니다. 의미는 더 좁아서, 목록은 인증 메서드의 이름을 나열하고, 한 메서드에서 다음으로 넘어가는 규칙은 이전 메서드의 결과에 달려 있으며 사용자에게 다시 시도하게 하는 것이 아닙니다.

오류를 반환하는 메서드와 실패를 반환하는 메서드는 여기서 서로 다른 결과로 이어집니다. 거부는 응답이며, 서버가 자격 증명을 처리하고 아니라고 말했기 때문에 목록은 거기서 멈춥니다. 도달할 수 없는 서버, 만료된 요청 또는 검증할 수 없는 응답이 다음 메서드를 실행하게 하는 경우이며, 플랫폼의 오류 처리가 그렇게 구성된 곳에서만 그렇습니다. 그래서 local을 추가하라는 고전적인 조언은 장애 시에는 효과가 있고 잘못된 비밀번호에는 아무것도 하지 않습니다. 대신 목록을 두 가지 질문, 즉 어느 메서드가 응답하는가와 플랫폼은 무엇을 응답으로 보는가로 읽으십시오.

메서드 목록과 서버 그룹을 분리하십시오

메서드 목록은 한 계층이고 서버 그룹은 다른 계층입니다. group radius 키워드는 내부 순서, 재시도, 시간 제한, 죽은 서버 탐지가 그룹에 속하는 그룹을 가리키며, 로컬 메서드는 그 위의 계층입니다. 따라서 그룹 내부에서 무엇을 조정하더라도 거부를 폴백으로 바꿀 수 없습니다. 두 계층 중 하나를 변경하기 전에 서비스가 실제로 어느 목록을 참조하는지 확인하십시오.

AAA 구성을 출력하고, 자신이 작성했다고 기억하는 기본값이 아니라 서비스가 가리키는 목록을 읽으십시오. 실제로 서비스가 종료되는 장비에서 수행하십시오.

show running-config | section aaa
show radius server-group RAD-GRP
show aaa servers

서버 표는 각 항목의 상태와 카운터를 보고하며, 이는 시도 중에 게이트웨이가 서버에 도달했는지 알려 줍니다. 요청 카운터가 증가하는 가동 중인 서버는 응답해 왔으므로, 실패한 로그인은 판단이며 연결 문제가 아닙니다.

로그보다 먼저 응답을 읽으십시오

응답 코드는 결과를 명명하고 그 자체의 다음 단계를 함축합니다. Access-Reject는 백엔드가 결정을 내렸다는 뜻이므로 유용한 증거는 일치한 정책과 그 뒤의 계정 상태입니다. Access-Challenge 는 교환이 두 번째 요소 같은 다른 지원 단계를 원한다는 뜻이며, 로컬 폴백은 정책이 요구하는 무언가를 조용히 건너뛰었을 것입니다.

지정된 테스트 계정으로 한 번의 시도를 재현하여 응답과 백엔드 기록을 같은 타임스탬프에서 비교할 수 있게 하십시오. 실패시켜도 되는 자격 증명을 사용하십시오.

test aaa group RAD-GRP svc-ops 'LabPass!24' legacy
debug radius authentication

RADIUS 클라이언트 항목이 없거나 인식되지 않는 것은 서버가 요청을 받고 일치하는 클라이언트 정의를 찾지 못해 응답 없이 버리기 때문에 조용한 시간 초과의 흔한 원인입니다. 공유 비밀의 불일치도 응답이 검증을 통과하지 못해 버려지기 때문에 보통 시간 초과처럼 보입니다. 어느 것도 Access-Reject처럼 보이지 않으며, 어느 것도 로컬 계정을 추가해서 고쳐지지 않습니다. 메서드 목록을 건드리기 전에 양쪽에서 클라이언트 정의와 비밀을 확인하십시오.

로컬 계정이 아무것도 증명하지 못한 이유

목록에서 그룹 뒤에 있는 계정은 누군가 장애를 계획했다는 것만 증명합니다. 계획이 작동하는지는, 그것을 시험하는 경우가 아무도 연습하지 않는 경우, 즉 서버가 응답을 멈춘 때이기 때문에 말해 주지 않습니다. 정상 운영에서 결코 도달하지 않는 로컬 로그인은 만료된 비밀번호나 잠긴 상태를 몇 달씩 안고 있을 수 있으며 아무도 알아채지 못합니다.

긴급 액세스는 설계 결정이며 구성의 부작용이 아닙니다. 고유한 제한 계정, 고유한 책임자, 문서화된 복구 절차를 부여하고 공유 비밀 순환을 그 절차에 포함하십시오. 모든 중앙 사용자에게 같은 이름의 로컬 비밀번호를 유지하는 것은 제거했다고 생각한 액세스를 조용히 되살리는 패턴입니다.

중요한 테스트는 의도적으로 수행하며, 실행되는 동안 로그인을 중단시킵니다. 바로 그래서 롤백 단계를 먼저 작성한 계획된 창에 속합니다.

유지보수 창에서 폴백 경로를 확인하십시오

마지막 진입 경로를 절대 제거하지 않도록 테스트를 배열하십시오. 먼저 독립적인 관리 경로를 확인하고, 다음으로 정상적인 허용 액세스, 다음으로 의도적인 거부, 마지막으로 승인된 장애 동작을 확인하십시오. 이 네 가지 경우는 예상 결과가 다르며, 그것들을 하나의 테스트로 합치는 것은 아직 필요한 장비에서 사람이 스스로를 잠그는 방식입니다.

모든 점검을 콘솔 세션 또는 대역 외 경로에서 실행하여 실수가 작업 중인 세션을 닫지 못하게 하십시오. 콘솔은 테스트 대상 구성 요소에 의존하지 않는 유일한 경로입니다.

show aaa servers
show running-config | include aaa authentication
test aaa group RAD-GRP svc-ops 'LabPass!24' legacy

그런 다음 이전 구성을 복원하고 다음 실제 로그인에서 카운터가 다시 움직이는지 확인하십시오. 의도적인 거부가 거부 대신 로컬 로그인을 만들어 낸다면 목록이나 오류 처리가 믿었던 것과 다르며, 그 발견은 처음 시작한 장애보다 중요합니다. 결과를 계정 이름과 테스트 날짜 옆의 변경 기록에 작성하십시오.