9.4. 적절한 인증 방법 선택

익명 액세스를 통해 디렉터리에 대한 가장 쉬운 형태의 액세스 권한을 제공합니다. 인증된지 여부에 관계없이 디렉터리의 모든 사용자가 데이터를 사용할 수 있습니다.

그러나 익명 액세스에서는 관리자가 누가 검색을 수행하는 경우에만 어떤 종류의 검색을 수행하는지 추적할 수 없습니다. 익명 액세스를 사용하면 디렉터리에 연결하는 모든 사용자가 데이터에 액세스할 수 있습니다.

따라서 관리자는 특정 사용자 또는 사용자 그룹이 어떤 종류의 디렉토리 데이터에 액세스하지 못하도록 차단할 수 있지만, 익명 액세스가 해당 데이터에 허용되는 경우, 해당 사용자는 디렉토리에 대해 간단하게 디렉토리에 바인딩하여 데이터에 액세스할 수 있습니다.

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

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

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

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

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

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

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

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

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

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

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

TLS 또는 Start TLS 작업을 사용하여 Directory Server와 클라이언트 애플리케이션 간에 보안 연결이 설정된 경우 클라이언트는 일반 텍스트로 암호를 전송하지 않고 추가 수준의 보호로 간단한 바인딩을 수행합니다. nsslapd-require-secure-binds 구성 속성에는 보안 연결을 통해 간단한 암호 인증이 필요합니다(TLS 또는 Start TLS). 이 설정을 사용하면 SASL 인증 또는 인증서 기반 인증과 같은 대체 보안 연결도 사용할 수 있습니다.

보안 연결에 대한 자세한 내용은 9.9절. “서버 연결 보안” 을 참조하십시오.

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

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

인증서 및 TLS에 대한 자세한 내용은 관리 가이드를 참조하십시오.

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

프록시 DN은 사용자가 요청한 작업을 수행할 수 있는 적절한 권한이 있는 엔티티입니다. 사용자 또는 애플리케이션에 프록시 권한이 부여되면 디렉터리 관리자 DN을 제외하고 DN을 프록시 DN으로 지정할 수 있는 권한이 부여됩니다.

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

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

ldapmodify -D "cn=Directory Manager" -W -x -D "cn=directory manager" -W -p 389 -h server.example.com -x -Y "cn=joe,dc=example,dc=com" -f mods.ldif

이 ldapmodify 명령은 mods.ldif 파일에 수정 사항을 적용하기 위해 manager 항목(cn=Directory Manager)에게 이름이cn=joe)에게 권한을 부여합니다. 이 변경을 위해 관리자가 암호를 제공할 필요가 없습니다.

패스스루 인증은 인증 요청이 한 서버에서 다른 서비스로 전달되는 경우입니다.

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

많은 시스템에는 이미 Unix 및 Linux 사용자를 위한 인증 메커니즘이 있습니다. 가장 일반적인 인증 프레임워크 중 하나는 PAM( Pluggable Authentication Modules )입니다. 이미 많은 네트워크에 기존 인증 서비스를 사용할 수 있으므로 관리자는 해당 서비스를 계속 사용할 수 있습니다. PAM 모듈은 Directory Server에서 LDAP 클라이언트의 기존 인증 저장소를 사용하도록 지시하도록 구성할 수 있습니다.

Red Hat Directory Server의 PAM 통과 인증은 PAM Pass-through 인증 플러그인을 사용하여 Directory Server가 PAM 서비스와 통신하여 LDAP 클라이언트를 인증할 수 있습니다.

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

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

인증 시도는 먼저 사용자 계정에 인증 기능이 있는지 여부를 평가합니다. 계정은 활성 상태여야 하며, 잠길 수 없으며, 해당 암호 정책에 따라 유효한 암호가 있어야 합니다(이는 만료되거나 재설정해야 함).

사용자가 인증할 수 있는지에 대한 평가를 수행할 필요가 있지만 사용자가 Directory Server에 바인딩해서는 안 되는 경우가 있을 수 있습니다. 예를 들어 시스템은 PAM을 사용하여 시스템 계정을 관리할 수 있으며 PAM은 LDAP 디렉터리를 ID 저장소로 사용하도록 구성됩니다. 그러나 시스템은 SSH 키 또는 RSA 토큰과 같이 암호가 없는 자격 증명을 사용하고 있으며 해당 인증 정보를 전달하여 Directory Server에 인증할 수 없습니다.

Red Hat Directory Server는 ldapsearch에 대한 계정 지원 연장 제어 기능을 지원합니다. 이 제어는 계정 상태 및 적용되는 암호 정책에 대한 정보를 반환합니다(예: 재설정, 암호 만료 후 남은 유예 로그인 수 또는 암호 만료 후 남아 있는 유예 로그인 수) - 바인딩 시도에서 반환되는 모든 정보는 해당 사용자로 Directory Server에 인증 및 바인딩하지 않습니다. 이를 통해 클라이언트는 사용자가 Directory Server 설정 및 정보를 기반으로 인증할 수 있는지 확인할 수 있지만 실제 인증 프로세스는 Directory Server 외부에서 수행됩니다.

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