그 LDAP 비밀번호 오류는 사용자의 비밀번호가 아닐 수도 있습니다

로그가 bind가 거부되었다고만 말할 때 사용자의 비밀번호를 재설정하는 것은 잘못된 첫 조치입니다. 디렉터리 플러그인에서는 한 번의 로그인에 bind가 여러 개 있고, 거부가 검색을 수행하는 서비스 계정의 것일 수 있습니다. 그 경우 사용자의 자격 증명을 재설정해도 아무것도 바뀌지 않습니다. 문제가 아니었던 사람까지 잠그게 됩니다.

한 번의 로그인, 여러 개의 bind

전용 디렉터리 계정이 있는 구성은 보통 네 단계를 순서대로 수행하며, 그중 어느 것이든 로그인을 끝낼 수 있습니다.

connect to the directory and establish the configured TLS protection
bind as the configured service account
search for the user entry using the search base and filter
open a second connection and bind as that user, then evaluate groups

플러그인은 첫 연결을 처리하는 것과 동일한 도우미를 통해 사용자 인증 연결을 만들기 때문에, 그 도우미는 연결할 때, TLS 협상 중에, 또는 서비스 계정으로 bind할 때 실패할 수 있습니다. 비밀번호에 관한 상위 수준 메시지는 나중에 생성되며 어떤 ID가 관련되었는지 담지 않습니다. 그래서 오류 텍스트만으로는 사용자와 서비스 계정 중 누가 거부되었는지 알 수 없습니다.

메시지 앞의 줄을 읽고 실패가 일어난 시점을 기록하세요. 시작 시점, 아직 어떤 사용자도 오기 전의 거부는 구성된 계정이나 엔드포인트를 가리킵니다. 검색이 성공한 뒤 한 사람에게만 나타나는 거부는 그 사람의 항목이나 계정 상태를 가리킵니다.

오류를 ID와 짝지으세요

실무 원칙은 세 가지를 함께 기록하는 것입니다: 언제 실패했는지, 어떤 작업이 실행 중이었는지, 어떤 ID가 제시되었는지. 이 세 가지가 없으면 마지막 문장만 남기는 로그에서 아주 다른 두 장애가 똑같아 보입니다.

구성된 계정이 실패하면 어떤 사용자 레코드도 건드리기 전에 그 계정과 연결을 살펴보세요. 검색이 성공한 뒤 사용자 bind가 실패하면, 반환될 것이라 가정한 항목이 아니라 검색이 실제로 반환한 항목을 조사하세요. 두 경로는 메시지 하나만 공유할 뿐입니다. 다음 사람이 바로 그것을 물을 것이므로 어느 쪽을 배제했는지 적어 두세요.

고유 이름은 데이터이지 추측이 아닙니다

낯설어 보인다는 이유로 이름 구성 요소를 바꾸는 것은 작동하는 구성을 깨뜨리는 흔한 방법입니다. Active Directory에서 사용자 개체의 기본 위치는 Users라는 컨테이너이며, 컨테이너는 비슷한 이름의 조직 구성 단위와 같은 종류의 개체가 아닙니다.

디렉터리 관리자에게 계정의 실제 고유 이름을 요청하거나 개체 자체에서 읽으세요. 다음 두 가지 모두 각자의 디렉터리에서는 올바를 수 있으므로, 어느 것도 기억에 의존해 입력해서는 안 됩니다.

CN=VPN Bind,CN=Users,DC=corp,DC=example
CN=VPN Bind,OU=Service Accounts,DC=corp,DC=example

이동이나 이름 변경은 계정과 비밀번호가 유효한 상태에서 그 값을 바꾸므로, 지난 분기에 작동하던 구성이 아무도 자격 증명을 건드리지 않아도 이번 분기에 실패할 수 있습니다. 재구성 후에는 구성된 문자열을 디렉터리의 현재 속성과 비교하세요. 조용한 마이그레이션 후에도 하고, 보고된 장애 후에만 하지 마세요.

검색 기준은 서비스 계정이 아닙니다

bind ID와 검색 기준은 서로 다른 질문에 답합니다: 플러그인이 누구로 인증하는지, 그리고 사람을 어디서 찾는지. bind가 성공했는데 일치하는 사용자가 없는 것은 범위, 필터 또는 읽기 권한 문제이며, 계정의 고유 이름을 사용자 기준으로 바꾼다고 해서 그것이 달라지지 않습니다.

서비스가 편집한 구성을 로드했는지, 그리고 그 엔드포인트, TLS 신뢰 및 인증 모드 가 작동하는 관리 테스트와 일치하는지 확인하세요. 다른 계정으로 또는 다른 도메인 컨트롤러를 상대로 한 수동 조회는 동등한 실험이 아닙니다.

저장된 비밀을 확인하고, 비밀번호를 어디에도 출력하지 않은 채 계정이 활성화되었는지, 만료되었는지, 잠겼는지 확인하세요. 만료는 계정이 더 이상 작동하지 않는 날까지 계속 작동하기 때문에 놓치기 쉽습니다. 관련 없는 서비스에서 물려받은 잠금도 마찬가지로 조용합니다. 두 상태 모두 서비스 계정을 지목하는 메시지를 만들지 않습니다.

그룹 규칙은 마지막에 옵니다

권한 부여는 bind가 성공한 뒤에 실행되므로 그룹 검사가 bind 실패의 원인이 될 수 없고, 그룹 요구 사항을 제거해도 고칠 수 없습니다. 로그인이 이제 그룹 단계에 도달한다면 남은 문제는 자격 증명이 아니라 멤버십입니다.

오류를 없애기 위해 서비스 계정에 광범위한 디렉터리 권한을 부여하는 것은 전체 배포의 접근 정책을 바꿉니다. 그것은 아직 ID에 귀속시키지 않은 메시지에 대한 수정이 아니라, 자체 검토가 따르는 보안 결정으로 다루세요.