NetExtender 로그인은 되지만 접속은 안 됨: SonicWall 로컬 + LDAP

로그인은 성공하고 터널도 올라오지만 방화벽 뒤에서는 아무것도 응답하지 않는다. SonicWall SSL VPN 에서 이런 양상이 나오면 보통 계정이 인증을 통과한 뒤 두 가지 후속 권한 중 하나에서 멈춘 것이다. SSL VPN 서비스 승인이나 리소스 접근 허용이다. 로컬 계정과 LDAP 계정이 섞여 있으면 더 나빠진다. 두 저장소가 이 권한에 도달하는 경로가 다르기 때문이다. 클라이언트에서 보이는 증상은 같으므로 계층을 의식적으로 분리해야 한다.

증상과 그 뒤의 세 가지 권한

사용자 이름과 접근 가능한 서버 사이에는 독립적인 세 가지 결정이 있다. 인증 방식은 자격 증명이 받아들여지는지, 어느 저장소가 받아들이는지를 결정한다. SSL VPN 서비스 멤버십은 그 신원이 SSL VPN을 쓸 수 있는지를 결정한다. VPN 액세스 목록은 세션이 어떤 사설 대상에 도달할 수 있는지를 결정한다. 하나를 통과했다고 해서 다음 두 가지에 대해 알 수 있는 것은 없다.

인증은 통과했지만 SSL VPN 서비스 그룹에 속하지 않은 사용자는 연결이 맺어졌다가 아무것도 전송하지 않는 것을 보게 되고, 방화벽 로그에는 실패가 아니라 로그인 승인이 남는다. 빨리 알아챌 가치가 있는 사례다. 해결은 그룹 멤버십이지 비밀번호 재설정이 아니다.

승인은 되었지만 리소스가 없는 사용자는 연결은 되지만 쓸모 있는 곳으로 라우팅되지 않는 세션을 보게 된다. 둘 다 헬프데스크에서는 끊긴 터널처럼 보이지만, 둘 다 연결성이 아니라 구성 문제다.

도메인 입력란은 디렉터리가 아니다

NetExtender는 도메인을 묻는데, 그 입력란은 Active Directory의 검색 기준이 아니다. 기본 구성에서는 이 입력란이 방화벽에 설정된 SSL VPN 사용자 도메인과 같아야 하며, 문서화된 기본값은 LocalDomain. 비교는 대소문자를 구분하므로 대소문자가 다른 값은 계정이 맞아도 실패한다.

인증 파티션이 구성되어 있으면 파티션 이름이 외부 인증 컨텍스트를 선택하고, 구성된 기본값은 자체 역할을 유지한다. 두 구성 모두에서 클라이언트 쪽 도메인 레이블은 사용자 이름의 일부로 LDAP나 RADIUS에 전달되지 않으므로 디렉터리 검색을 이끌 수 없다.

세 문자열을 메모에서 따로 관리하라. 회사의 DNS 접미사, LDAP 검색 기준, NetExtender 도메인 레이블이다. 서로 비슷해 보이지만 어느 것도 다른 것을 대신하지 않는다. 다른 펌웨어 버전에 관한 포럼 글의 값이 아니라 이 설치의 운영자가 준 값을 복사하라.

승인과 리소스 접근은 별개의 권한이다

로컬 계정은 서비스가 받아들이기 전에 SSL VPN 서비스 그룹 멤버십이 필요하다. 디렉터리 계정은 지원되는 그룹 매핑 워크플로로 같은 그룹에 도달하므로, LDAP 그룹 관계를 구성한 뒤 디렉터리 쪽에서 가정하지 말고 실제로 유효한 멤버십인지 검증해야 한다.

다음은 리소스 접근이다. 사용자나 그룹의 VPN 액세스에서 설정한다. 역할에 필요한 특정 서브넷과 서비스만 부여하고, 애플리케이션 하나가 필요하다고 LAN 전체를 주는 지름길을 택하지 마라. 세션 경로, 액세스 규칙, 대상 서비스 권한이 모두 그 범위와 일치해야 한다.

클라이언트의 경로는 대상을 선택 가능하게 할 뿐 권한을 부여하지 않는다. SSL VPN 그룹 멤버십도 계정을 방화벽 관리자로 만들지 않으며, 일반적인 권한 부여로 취급해서는 안 된다.

두 신원, 각각 네 가지 확인

로컬 계정 하나와 디렉터리 계정 하나로 테스트하라. 둘 다 권한을 좁게 주고 둘 다 테스트 계정으로 문서화한다. 각각에 대해 로그인을 받아들인 인증 소스, 유효한 그룹, 부여된 리소스 접근, 허용된 애플리케이션 작업 하나를 기록한다. 네 가지 확인, 두 저장소, 조합마다 서면 결과다.

그다음 부정 사례를 시험하라. 계정이 도달해서는 안 되는 리소스와 즉시 거부되어야 하는 계정이다. 긍정 경로만 증명하는 설계는 특히 같은 짧은 사용자 이름이 두 저장소에 존재할 때 두 번째 입구를 열어 두기 쉽다. 디렉터리 계정을 비활성화하고 로컬 계정이 조용히 계속 동작하지 않는지 확인하라.

중복 이름 검토는 사고 후가 아니라 배포의 일부로 하라. 같은 사람이 두 저장소에 있는 것은 지원 편의이자 동시에 감사 문제이며, 방화벽은 구성한 쪽을 기꺼이 인증한다.

복구 경로를 좁게 유지하라

로컬 계정을 예외로 두지 말고 계정 등급마다 MFA 정책을 유지하라. 디렉터리 장애 시 승인된 복구 경로로 로컬 계정을 쓴다면 그 경로를 이름이 지정된 관리자로 제한하고 의도적으로 운영하라. 모든 직원에게 로컬 비상 계정을 두는 것은 감독이 더 약한 두 번째 인증 시스템이다.

클라이언트 도메인, 인증 소스, 유효한 접근을 같은 기록에 적어라. 그러면 다음 관리자는 로그인이 될 때까지 도메인 문자열을 바꿔 보는 대신 동작하는 혼합 계정 설계를 재현할 수 있다.