VPN 인증서는 LDAP 구간을 보호하지 않는다

디렉터리에 대해 자격 증명을 확인하는 VPN 로그인에는 두 개의 별도 네트워크 연결이 관련됩니다. 사용자와 게이트웨이의 연결은 VPN 자체의 인증서와 프로토콜 구성으로 보호됩니다. 게이트웨이와 디렉터리의 연결은 자체 TLS 설정, 자체 신뢰 저장소, 자체 실패 방식을 가진 다른 세션입니다. 첫 번째에 관한 어떤 것도 두 번째에 관해 아무것도 보장하지 않습니다.

이 비대칭성이 바로 암호화된 것처럼 보이면서도 bind 암호를 평문으로 보내는 로그인의 메커니즘입니다.

두 연결, 두 신뢰 결정

바깥 세션은 사용자가 보는 것으로, VPN 호스트 이름에 묶인 인증서가 클라이언트에 의해 검증되며 인증 교환을 운반합니다. 안쪽 세션은 게이트웨이 내부의 디렉터리 클라이언트에 속하며, 자체 연결을 열고 TLS를 협상하거나 하지 않습니다. 각 측은 다른 구성 파일의 자료를 사용해 자신이 대화하는 상대를 검증합니다. 잘못 구성된 안쪽 구간은 바깥 구간이 의도한 대로 정확히 동작하기 때문에 사용자 쪽에서 보이지 않습니다.

그래서 이 실패는 요란하지 않고 조용합니다. 디렉터리 인증서를 절대 확인하지 않는 게이트웨이도 사용자를 올바르게 인증하지만, 검증하지 않은 채널로 인증할 뿐입니다.

의도적으로 선택하는 StartTLS와 LDAPS

StartTLS는 일반 LDAP로 열리고 그 자리에서 업그레이드되며, 관례적으로 포트 389를 사용합니다. LDAPS는 연결과 함께 TLS를 시작하며 관례적으로 636을 씁니다. 둘 다 정당하며 어댑터는 디렉터리가 제공하는 것과 일치해야 합니다. StartTLS를 요구하는 것은 시도해 보고 업그레이드가 실패할 때 계속하는 것과 다르며, 바로 그 차이에서 bind 암호가 새어 나갈 수 있습니다. 엄격 모드를 구성하고 암호 bind에 대해 보호되지 않은 대체 경로를 허용하지 마십시오.

ldapsearch -H ldap://dc1.corp.example -ZZ -x -D "CN=VPN Bind,OU=Service Accounts,DC=corp,DC=example" -W -b "DC=corp,DC=example" "(sAMAccountName=example-user)" dn

-ZZ 옵션이 핵심으로, 업그레이드 없이 조용히 진행되는 대신 쿼리가 실패합니다. 그 줄의 이름과 계정은 예시입니다. OpenLDAP TLS 문서가 그 배경의 신뢰 설정을 다룹니다.

LDAP 클라이언트는 어느 신뢰 저장소를 읽는가?

OpenLDAP 클라이언트 라이브러리는 시스템 파일이든 플러그인별 설정이든 자체 신뢰 구성을 읽습니다. VPN의 CA 지시문은 VPN 피어에 적용되며 LDAP 라이브러리가 같은 파일을 읽는다는 증거가 아닙니다. 인증서가 실제로 포함하는 디렉터리 호스트 이름과 라이브러리가 신뢰하는 발급 체인을 사용하십시오. Active Directory에서는 표시 이름에서 추론하는 대신 올바른 서버 인증 용도의 디렉터리 서비스 인증서를 배포하십시오.

모든 장애 조치 대상은 동일한 ID 정책을 충족해야 합니다. 기본이 검증되고 보조가 검증되지 않는 환경은 약한 경로가 장애 중에만 발견되기 때문에 장애 조치가 없는 환경보다 나쁩니다.

bind 계정은 별도의 문제로 남는다

전송을 보호한다고 해서 bind 계정이 할 수 있는 일이 줄어들지 않습니다. 디렉터리 검색 범위, 그룹 권한 부여, 서비스 계정의 권한은 별개의 결정이며, 넓은 bind 계정은 TLS를 활성화한 뒤에도 넓습니다. 통합에 필요한 가장 좁은 서비스 계정과 검색 기준을 사용하고, 엔드포인트, TLS 모드, 신뢰 소유자, 갱신 절차를 VPN 구성과 함께 기록하십시오.

인증서 불일치가 나타나면 올바른 인증서나 체인을 배포하십시오. 검증을 비활성화하면 보이는 불일치가 보이지 않게 되고 두 번째 신뢰 관계는 검증되지 않은 채 남습니다.

두 연결, 두 소유자, 두 갱신 날짜. 이를 문서에서 분리해 두는 것이 로그인을 정직하게 유지합니다.