7.4. 적절한 인증 방법 선택

익명 액세스를 통해 디렉터리에 대한 가장 쉬운 형태의 액세스 권한을 제공합니다. 익명 액세스를 사용하면 디렉터리에 연결하는 모든 사용자가 데이터에 액세스할 수 있습니다.

익명 액세스를 구성하면 사용자가 검색을 수행하는 경우에만 어떤 종류의 검색을 수행하는지 추적할 수 없습니다. 특정 사용자 또는 사용자 그룹이 일부 종류의 디렉토리 데이터에 액세스하지 못하도록 차단할 수 있지만, 익명 액세스가 해당 데이터에 대해 허용되는 경우 해당 사용자는 디렉터리에 직접 바인딩하여 해당 데이터에 계속 액세스할 수 있습니다.

익명 액세스를 제한할 수 있습니다. 일반적으로 디렉터리 관리자는 쓰기, 추가, 삭제 또는 자체 쓰기 권한이 아닌 읽기, 검색 및 비교 권한에 대한 익명 액세스만 허용합니다. 관리자는 이름, 전화 번호 및 이메일 주소와 같은 일반 정보가 포함된 속성 하위 집합에 대한 액세스를 제한하는 경우가 많습니다. 정부 식별 번호와 같은 보다 민감한 데이터에 대한 익명 액세스를 허용해서는 안 됩니다 (예: 미국 사회 보안 번호, 가정 전화 번호 및 주소, 급여 정보).

디렉터리 데이터에 액세스하는 사용자에 대한 규칙을 강화해야 하는 경우 익명 액세스를 완전히 비활성화할 수 있습니다.

인증되지 않은 바인딩 은 사용자가 사용자 이름으로 바인딩하려고 하지만 사용자 암호 속성이 없는 경우입니다. 예를 들면 다음과 같습니다.

ldapsearch -x -D "cn=jsmith,ou=people,dc=example,dc=com" -b "dc=example,dc=com" "(cn=joe)"

사용자가 암호를 제공하지 않는 경우 Directory Server는 익명 액세스 권한을 부여합니다. 인증되지 않은 바인딩에서는 바인딩 DN이 기존 항목일 필요가 없습니다.

익명 바인딩과 마찬가지로 인증되지 않은 바인딩을 비활성화하여 데이터베이스에 대한 액세스를 제한하여 보안을 강화할 수 있습니다. 또한 인증되지 않은 바인딩을 비활성화하여 클라이언트에 대한 자동 바인딩 실패를 방지할 수 있습니다. 일부 애플리케이션은 실제로 암호가 전달되지 않고 인증되지 않은 바인딩과 연결할 때 바인딩 성공 메시지를 수신했기 때문에 디렉터리에 성공적으로 인증되었다고 생각할 수 있습니다.

익명 액세스가 허용되지 않는 경우 사용자는 디렉터리 콘텐츠에 액세스하기 전에 디렉터리에 대한 인증을 받아야 합니다. 간단한 암호 인증을 사용하여 클라이언트는 재사용 가능한 암호를 전송하여 서버에 인증합니다.

예를 들어 클라이언트는 고유 이름과 인증 정보 집합을 제공하는 bind 작업을 사용하여 디렉터리에 인증합니다. 서버는 디렉터리에서 클라이언트 DN에 해당하는 항목을 찾고 클라이언트에서 제공한 암호가 해당 항목과 저장된 값과 일치하는지 확인합니다. 이 경우 서버는 클라이언트를 인증합니다. 그렇지 않으면 인증 작업이 실패하고 클라이언트에 오류 메시지가 표시됩니다.

바인딩 DN은 종종 사람의 입력에 해당합니다. 그러나 일부 디렉터리 관리자는 사람이 아닌 조직 항목으로 바인딩하는 것을 선호합니다. 디렉터리에는 userPassword 특성을 허용하는 오브젝트 클래스를 바인딩하는 데 사용하는 항목이 필요합니다. 이렇게 하면 디렉터리가 바인딩 DN 및 암호를 인식합니다.

대부분의 LDAP 클라이언트는 사용자가 이해하기 어려운 DN 문자의 긴 문자열을 찾을 수 있기 때문에 사용자의 바인딩 DN을 숨깁니다. 클라이언트에서 사용자의 바인딩 DN을 숨기려고 하면 다음 바인딩 알고리즘을 사용합니다.

간단한 암호 인증은 사용자를 인증하는 쉬운 방법을 제공하지만 추가 보안 방법이 필요합니다. 조직 인트라넷에 대한 사용을 제한하는 것이 좋습니다. 엑스트라넷을 통해 비즈니스 파트너 간 연결 또는 인터넷 상의 고객과의 전송을 위해서는 안전한(암호화) 연결이 필요한 것이 가장 좋습니다.

nsslapd-require-secure-binds 구성 속성을 사용하여 TLS 또는 Start TLS를 사용하여 보안 연결을 설정합니다. SASL 인증 또는 인증서 기반 인증도 가능합니다. Directory Server 및 클라이언트 애플리케이션이 서로 보안 연결을 설정하는 경우 클라이언트는 일반 텍스트로 암호를 전송하지 않고 추가 수준의 보호로 간단한 바인딩을 수행합니다.

다른 형식의 디렉터리 인증에는 디지털 인증서를 사용하여 디렉터리에 바인딩해야 합니다. 디렉터리에 처음 액세스할 때 사용자에게 암호를 입력하라는 메시지가 표시됩니다. 그러나 디렉터리에 저장된 암호와 일치하지 않고 암호는 사용자 인증서 데이터베이스를 엽니다.

사용자가 올바른 암호를 제공하는 경우 디렉터리 클라이언트 애플리케이션은 인증서 데이터베이스에서 인증 정보를 가져옵니다. 그런 다음 클라이언트 애플리케이션 및 디렉터리는 이 정보를 사용하여 사용자 인증서를 디렉터리 DN에 매핑하여 사용자를 식별합니다. 디렉터리는 이 인증 프로세스 중에 식별된 디렉터리 DN을 기반으로 액세스를 허용하거나 거부합니다.

디렉터리에 대한 액세스를 요청하는 사용자가 자체 DN과 바인딩되지 않지만 프록시 DN과 바인딩되므로 프록시 인증은 특별한 형식의 인증입니다.

프록시 DN은 사용자가 요청하는 작업을 수행할 수 있는 적절한 권한이 있는 엔티티입니다. 사용자 또는 애플리케이션에서 프록시 권한을 수신하는 경우 Directory Manager DN을 제외하고 모든 DN을 프록시 DN으로 지정할 수 있습니다.

프록시 권한의 주요 이점 중 하나는 LDAP 애플리케이션에서 디렉터리 서버에 대한 요청을 수행하는 여러 사용자를 서비스하는 단일 스레드를 사용할 수 있다는 것입니다. 각 사용자에 대해 바인딩하고 인증하는 대신 클라이언트 애플리케이션은 프록시 DN을 사용하여 Directory Server에 바인딩합니다.

프록시 DN은 클라이언트 애플리케이션이 제출하는 LDAP 작업에 지정됩니다. 예를 들면 다음과 같습니다.

ldapmodify -D "cn=Directory Manager" -W -H ldap://server.example.com -X "dn:cn=joe,dc=example,dc=com" -f mods.ldif

이 명령을 사용하면 관리자 항목 cn=Directory Manager 에서 cn=joe 사용자 권한을 수신하여 mods.ldif 파일에 수정 사항을 적용합니다. 관리자는 이러한 변경을 위해 사용자 암호를 제공할 필요가 없습니다.

PTA(Pass-through Authentication) 는 Directory Server가 한 서버에서 다른 서버로 인증 요청을 전달하는 경우입니다.

예를 들어 Directory Server가 다른 디렉터리 인스턴스에 대한 모든 구성 정보를 저장할 때 Directory Server는 사용자 디렉터리 서버에 대한 패스스루 인증을 사용하여 구성 디렉터리 서버에 연결합니다. PTA 플러그인은 Directory Server-to-Directory Server pass-through 인증을 처리합니다.

많은 시스템에는 이미 PAM(Pluggable Authentication Modules)과 같은 Unix 및 Linux 사용자를 위한 인증 메커니즘이 있습니다. LDAP 클라이언트에 기존 인증 저장소를 사용하도록 Directory Server에 지시하도록 PAM 모듈을 구성할 수 있습니다. 디렉터리 서버는 PAM 서비스와 상호 작용하여 PAM 통과 인증 플러그인을 사용하여 LDAP 클라이언트를 인증합니다.

PAM 통과 인증을 사용하여 사용자가 Directory Server에 바인딩하려고 하면 디렉터리 서버는 자격 증명을 PAM 서비스에 전달합니다. 인증 정보가 PAM 서비스의 정보와 일치하는 경우 사용자는 모든 Directory Server 액세스 제어 제한 및 계정 설정을 사용하여 디렉터리 서버에 성공적으로 바인딩할 수 있습니다.

SSSD(System Security Services Daemon)를 사용하여 PAM 서비스를 구성할 수 있습니다. PAM 패스스루 인증 플러그인은 기본적으로 /etc/pam.d/system-auth 와 같이 SSSD에서 사용하는 PAM 파일을 가리키기만 하면 됩니다. SSSD는 Active Directory, Red Hat Directory Server 또는 OpenLDAP와 같은 기타 디렉토리 또는 로컬 시스템 설정을 포함하여 다양한 ID 공급자를 사용할 수 있습니다.

인증 시도는 먼저 사용자 계정을 인증할 수 있는지 평가합니다. 계정은 다음 기준에 속해야 합니다.

경우에 따라 사용자가 Active Directory Server에 바인딩하거나 바인딩할 수 없을 때 사용자 계정 인증을 수행해야 하는 경우가 있습니다. 예를 들어 시스템은 PAM을 사용하여 시스템 계정을 관리하고, LDAP 디렉터리를 ID 저장소로 사용하도록 PAM을 구성할 수 있습니다. 그러나 시스템은 SSH 키 또는 RSA 토큰과 같은 암호 없는 자격 증명을 사용하며 해당 인증 정보를 전달하여 Directory Server에 인증할 수 없습니다.

Red Hat Directory Server는 LDAP 검색에 대한 계정 지원 확장 제어 확장을 지원합니다. 이 확장은 계정 상태를 제공하는 반환된 각 항목에 대한 추가 행과 해당 계정의 암호 정책에 대한 몇 가지 정보를 반환합니다. 그러면 클라이언트 또는 애플리케이션에서 해당 사용자 계정에 대한 디렉터리 서버 외부의 인증 시도를 평가하는 데 해당 상태를 사용할 수 있습니다. 기본적으로 이 제어는 인증 작업을 수행할 필요 없이 사용자가 인증할 수 있는지 여부를 나타냅니다.

또한 PAM과 같은 시스템 수준 서비스와 함께 이 확장을 사용하여 Directory Server를 사용하여 ID를 저장하고 계정 상태를 제어하는 암호 없는 로그인을 허용할 수 있습니다.