FortiGate VPN이 잘못된 그룹에 들어갑니다: RADIUS 매칭

로그인은 성공하고 터널은 올라오지만 사용자는 잘못된 정책 또는 아무 정책에도 들어가지 않습니다. FortiGate 로그에는 그룹이 없었다는 사실이 전혀 나오지 않습니다. FortiGate 쪽에서는 인증이 통과했고 그룹 매칭이 그저 발동하지 않았기 때문입니다. 점검해야 할 사슬에는 서로 다른 세 이름이 있고, 보통 그것들은 같은 문자열이 아닙니다.

세 가지 역할을 가진 세 이름

설정을 건드리기 전에 셋 다 적어 두세요. 그중 둘은 서로 다른 시스템에 있기 때문입니다.

디렉터리 그룹은 RADIUS 정책이 평가하는 대상입니다. 반환되는 속성은 Access-Accept 응답 안의 값입니다. FortiGate 로컬 그룹은 정책이 이름으로 참조하는 컨테이너입니다. 이 중 둘만 혼동해도 로그인은 되지만 권한 부여는 되지 않습니다.

매칭은 실제로 어디에서 이루어지는가

Fortinet의RADIUS 그룹 매칭 설명은Fortinet-Group-Name를 기본 그룹 속성으로 제시합니다. FortiGate는 설정된 원격 서버와 그룹 이름 값을 응답이 담고 있는 내용과 비교합니다. 즉 비교 대상은 반환된 문자열이며 로컬 그룹의 표시 레이블이 아닙니다.

그래서VPN-Engineering이라는 로컬 그룹이vpn-engineering로 반환된 값 옆에 있어도 전혀 일치하지 않을 수 있습니다. 이 비교에서 대소문자와 철자는 장식이 아닙니다. 문자열 하나를 골라 응답에 사용하고, 게이트웨이의 매칭 규칙에서도 같은 문자열을 참조하세요.

FortiAuthenticator에서는 그룹을 속성에 연결하고 해당 RADIUS 서비스 정책에 포함해야 하며, 적용되는 경우 그룹 속성 반환 제어를 활성화해야 합니다.

속성이 없어도 응답은 성공할 수 있다

NPS 또는 다른 RADIUS 서버의 경우 정책에서 디렉터리 그룹 조건을 강제한 다음 지원되는 응답 속성을 설정하세요. 암호 확인이 성공하면 그 자체로 Access-Accept가 생성되며,그룹 문자열이 없는 Access-Accept도 완전히 유효한 응답이며 FortiGate 쪽에서는 아무것도 승인하지 않습니다. 이것이 이 문제의 가장 흔한 형태입니다.

그룹을 정의하는 것과 보내는 것은 다릅니다. 서로 다른 화면에서의 두 설정 단계이며 보통 둘 중 하나만 수행됩니다.

Any와 매칭하는 것이 함정인 이유

Any 원격 그룹 매칭은 RADIUS 서버가 이미 원하는 모집단만 허용할 때 정당한 설계입니다. 그 위임을 의도적으로 선택하세요. 빠진 속성을 없애려고 매칭을 넓히면 RADIUS 서버가 우연히 받아들이는 모든 계정이 통과되며, VPN 접근을 염두에 두지 않았던 계정까지 포함됩니다. 증상은 사라지고 접근 제어는 조용히 존재하지 않게 됩니다.

RADIUS 서버가 누구를 허용해야 하는지 이름 붙일 수 없다면 Any 매칭을 할 준비가 되지 않은 것입니다.

지원을 위해 네 가지 기록을 남기세요

여전히 작동하지 않으면 네 가지를 모으세요. 선택된 RADIUS 정책, 실제로 반환된 그룹 속성, 비교에 사용된 FortiGate 서버와 그 값, 그리고 그 결과로 생긴 로컬 그룹입니다. 이 네 기록은 암호를 노출하거나 그룹 구성원을 바꾸지 않고도 끊어진 지점을 찾아냅니다.

실제 규칙 아래에서 승인된 계정 하나와 범위 밖 계정 하나를 시험하고, 인증 결과뿐 아니라 그 결과의 정책과 리소스 접근도 확인하세요. 이 쌍만이 매칭이 의도대로 작동하는지 알려줍니다.