VPN 그룹에 사용자를 추가한다고 접근 권한이 생기지는 않는다
그룹 소속은 하나의 조건일 뿐 권한이 아닙니다. 게이트웨이가 실제로 무엇을 대조했는지 보고, 허용 또는 거부 기록을 읽고, 두 결과를 모두 시험하세요.
계정을 올바른 그룹에 넣고 로그인도 성공했는데 연결이 거부되거나, 연결은 되지만 아무것도 닿지 않는다. 흔한 반응은 뭔가 통과할 때까지 그룹을 더 넣는 것이고, 그래서 조직은 티켓이 요구한 것보다 훨씬 많은 권한을 준다. 그룹 소속은 인가 결정의 입력 하나일 뿐 결정 자체가 아니다. 게이트웨이는 세션의 사실 몇 개를 모아 순서가 정해진 정책과 대조한 뒤에야 무엇을 만질 수 있는지 정한다. 다른 조건이 실패했다면 그룹을 바꿔도 노출만 달라진다.
그룹 소속은 조건이지 권한이 아니다
RADIUS에서 그룹은 인가 속성으로 오고, 속성은 세션을 설명할 뿐 허용하지 않는다. 서버는 Access-Accept 또는 Access-Reject로 답하고, 수락 시 Filter-Id, Class, RFC 2868의 터널 속성을 붙일 수 있으며 반대편 네트워크 장비는 벤더 판단대로 해석한다. 프로토콜 어디에도 그룹을 전체 접근으로 매핑하는 규칙은 없고, 그 매핑은 게이트웨이나 네트워크 접근 서버에서 정책을 설정한 사람이 쓴다.
그래서 같은 그룹 이름이 두 시스템에서 다르게 동작한다. Microsoft NPS는 조건, 제약, 설정으로 네트워크 정책을 구성하고 정해진 순서로 평가한다. OpenVPN Access Server는 자체 그룹과 접근 규칙 모델을 가지며, 커뮤니티 OpenVPN 서버는 질문 전체를 client-connect 스크립트나 client-config-dir 파일에 맡기는 일이 많다.
결정하는 것은 일치한 규칙이지 기대한 그룹이 아니다
대부분의 엔진은 처음 일치하는 정책이나 가장 구체적인 정책에서 멈춘다. 정책 3이 거부하고 정책 7이 허용하면, 통과시킬 규칙에 이르지 못한 채 세션이 실패할 수 있다. 순서는 NPS와 대부분의 네트워크 접근 제어 제품에서 실제 설정이며 세월에 따라 밀린다.
그룹에 딸린 조건이 나머지 절반이다. 장치 상태, 인증 방식, MFA 완료, 출발 네트워크, 인증서 주체, 시간대 창이 같은 정책에 있을 수 있다. 하나라도 충족되지 않으면 정책이 일치하지 않고 엔진은 다음으로 넘어가며 기본 거부가 적용된다. 사용자 쪽에서는 그룹이 무시된 듯 보이고, 엔진 쪽에서는 그룹을 묻지도 않았다.
디렉터리 세부 정보도 같은 착각을 만든다. Windows 그룹 소속으로 대조하는 정책은 토큰의 SID를 읽고, 거기에는 보안 그룹만 열거되어 배포 그룹은 결코 나타나지 않는다. 기본 그룹은 별도 필드에 있어 목록에 없으므로 거기에 고정된 정책은 조용히 실패할 수 있다.
그룹을 건드리기 전에 허용 또는 거부 기록을 읽어라
먼저 한 가지를 물어라. 요청이 인가 단계까지 도달했는가? NPS라면 이벤트 로그에 답이 있고, 6272는 허용, 6273은 거부, 6274는 정책 평가 전에 서버가 버린 요청을 기록한다. 이 세 숫자는 문제를 세 가지 조사로 나누고, 그룹과 관련된 것은 하나뿐이다.
| What the record shows | What it means | Where to look next |
|---|---|---|
| 6272, access granted | Authentication and authorization both succeeded | Routes, split tunnel, DNS, per-resource rules |
| 6273, access denied | A policy matched and denied, or nothing matched and the default denied | The conditions of the policy that fired, in order |
| 6274, request discarded | The request never reached authorization | Shared secret, NAS client entry, proxy chain, malformed attributes |
로그에 닿을 수 없으면 서버에 직접 물어 응답을 읽어라. Filter-Id도 터널 속성도 없는 응답은 서버가 세션을 평범하게 보고 게이트웨이가 자체 규칙을 적용한다는 뜻이다. 적용 지점이 구현하지 않는 속성이 담긴 응답은 다른 고장이다. 인가는 통과했고 장치가 결과를 무시했다.
radtest alice 'password' 10.0.0.5 0 testing123돌려받은 속성을 그룹 이름이 암시하는 것이 아니라 게이트웨이가 문서화한 속성과 비교하라. 그 비교가 보통 정책 문제와 적용 문제를 갈라 준다.
그룹 변경은 소급되지 않는다
인가 속성은 세션 인증 때 한 번만 돌아온다. 게이트웨이는 그것을 세션에 보관하고 패킷마다 디렉터리를 다시 읽지 않는다. 그래서 누군가를 그룹에서 빼도 이미 맺어진 세션은 계속 동작하고, 새 세션은 실패할 수 있다.
변경을 적용하려면 새 인가 결정이 필요하고 새 키만으로는 부족하다. 서버가 RFC 5176 동적 인가를 지원하면 UDP 3799로 보내는 Disconnect-Request나 CoA-Request가 재평가를 강제한다. 아니면 클라이언트를 끊고 다시 연결하게 하라. 재협상은 터널 키만 새로 하고 인가 결과는 대개 그대로 둔다.
고칠 것은 조건이지 그룹이 아니다
어떤 정책이 발동했는지 알면 수리는 대개 작다. 의도한 허용을 가리는 거부의 순서를 바꾸고, 겨냥한 정책에 빠진 장치나 MFA 조건을 넣고, 사용자를 다른 열 개를 지닌 그룹으로 올리는 대신 그 자원 하나에 좁은 규칙을 쓴다.
짧은 고리가 변경을 정직하게 유지한다.
- 원래 계정으로 거부를 재현하고 무엇이든 바꾸기 전에 이벤트 ID를 적어라.
- 객체 하나만 바꿔라. 정책 순서, 조건 하나, 그룹 하나 중 무엇을 바꿨는지 기록하라.
- 새 세션을 열고 허용이 로그에 나타나는지, 자원이 실제로 열리는지 확인하라.
- 여전히 거부되어야 할 사용자를 시험해 수리가 정책을 실수로 넓히지 않았는지 보라.
허용이 맞는데 자원이 열리지 않으면 인가가 통과한 순간 문제는 라우팅이나 이름 해석으로 옮겨간 것이다. 두 고장을 분리해 두면 다음 티켓은 반나절이 아니라 몇 분이 걸린다.