test

Sun Java System Directory Server Enterprise Edition 6.3 관리 설명서

7장 디렉토리 서버 액세스 제어

디렉토리에 대한 액세스 제어는 보안 디렉토리 생성에 있어 필요한 부분입니다. 이 장에서는 디렉토리에 액세스하는 사용자에게 부여되는 권한을 결정하는 액세스 제어 지침(ACI)에 대해 설명합니다.

전체 보안 정책을 제공하는 액세스 제어 전략은 디렉토리 배포의 계획 단계에서 정의합니다. 액세스 제어 전략을 계획하는 방법은 Sun Java System Directory Server Enterprise Edition 6.3 Deployment Planning Guide를 참조하십시오.

ACI 구문 및 바인드 규칙을 포함하여 ACI에 대한 추가 정보는 Sun Java System Directory Server Enterprise Edition 6.3 Reference를 참조하십시오.

이 장은 다음 내용으로 구성되어 있습니다.

ACI 작성, 보기 및 수정

디렉토리 서비스 제어 센터(Directory Service Control Center, DSCC) 또는 명령줄을 사용하여 ACI를 작성할 수 있습니다. 어떤 방법을 선택하든 처음부터 ACI를 새로 작성하는 것보다 기존 ACI 값을 보고 복사하는 것이 보다 간편합니다.

DSCC에서 aci 속성 값을 보고 수정할 수 있습니다. DSCC에서 ACI를 수정하는 방법에 대한 자세한 내용은 DSCC 온라인 도움말을 참조하십시오.

ProcedureACI를 작성, 수정 및 삭제하는 방법

명령줄을 사용하여 ACI를 작성하려면 먼저 LDIF 명령문을 사용하여 ACI를 파일로 작성합니다. 그런 다음 ldapmodify 명령을 사용하여 ACI를 디렉토리 트리에 추가합니다.

DSCC를 사용하여 이 작업을 수행할 수 있습니다. 자세한 내용은 디렉토리 서비스 제어 센터 인터페이스 및 DSCC 온라인 도움말을 참조하십시오.

  1. ACI를 LDIF 파일로 작성합니다. 


    dn: dc=example,dc=com
changetype: modify
add: aci
aci: (target)(version 3.0; acl "name";permission bindrules;)

    이 예에서는 ACI를 추가하는 방법을 보여줍니다. ACI를 수정하거나 삭제하려면 add를 replace 또는 delete로 대체하십시오.

    일반적으로 사용되는 ACI의 예는 액세스 제어 사용 예를 참조하십시오.

  2. LDIF 파일을 사용하여 변경합니다. 


    $ ldapmodify -h host -p port -D cn=admin,cn=Administrators,cn=config -w - -f ldif-file

ProcedureACI 속성 값을 보는 방법

ACI는 하나 이상의 aci 속성 값으로 항목에 저장됩니다. aci 속성은 여러 값을 갖는 작동 가능 속성으로, 디렉토리 사용자가 읽고 수정할 수 있으므로 ACI에서 ACI 속성 자체를 보호해야 합니다. 일반적으로 관리 사용자는 aci 속성에 대한 전체 액세스 권한을 가집니다.

DSCC를 사용하여 이 작업을 수행할 수 있습니다. 자세한 내용은 디렉토리 서비스 제어 센터 인터페이스 및 DSCC 온라인 도움말을 참조하십시오.

  1. 다음 ldapsearch 명령을 실행하여 항목의 ACI 속성 값을 봅니다.


    $ ldapsearch -h host -p port -D cn=admin,cn=Administrators,cn=config -w - \
 -b entryDN -s base "(objectclass=*)" aci

    결과는 LDIF 텍스트로 표시되며, 이 텍스트를 새 LDIF ACI 정의에 복사하여 편집할 수 있습니다. ACI 값이 긴 문자열이기 때문에 ldapsearch 작업의 출력은 여러 줄에 걸쳐 표시되며, 첫 칸의 공백으로 연속된 줄을 나타냅니다. LDIF 출력에 연속된 줄이 포함되지 않게 하려면 -T 옵션을 사용합니다. 출력 형식을 고려해서 LDIF 출력을 복사하여 붙여넣습니다.

    주 –

    aci 값이 부여하거나 거부하는 권한을 보려면 유효 권한 보기를 참조하십시오.

Procedure루트 수준에서 ACI를 보는 방법

접미어를 작성할 때 일부 기본 ACI는 최상위 또는 루트 수준에서 작성됩니다. 이러한 ACI는 기본 관리 사용자 cn=admin,cn=Administrators,cn=config에게 디렉토리 관리자와 동일한 디렉토리 데이터 액세스 권한을 허용합니다.

DSCC를 사용하여 이 작업을 수행할 수 있습니다. 자세한 내용은 디렉토리 서비스 제어 센터 인터페이스 및 DSCC 온라인 도움말을 참조하십시오.

  1. 기본 루트 수준 ACI를 봅니다.


    $ ldapsearch -h host -p port -D cn=admin,cn=Administrators,cn=config -w - \
 -b "" -s base "(objectclass=*)" aci

액세스 제어 사용 예

이 절에서는 가상의 ISP 업체인 Example.com에서 액세스 제어 정책을 구현하는 방법에 대한 예를 보여줍니다.

또한 install_path/ds6/ldif/Example.ldif 설치와 함께 제공된 LDIF 파일 예에서 ACI 예를 찾을 수 있습니다.

모든 예는 LDIF 파일을 사용하여 지정된 작업을 수행하는 방법에 대해 설명합니다. 다음 그림은 example.com 디렉토리 정보 트리를 그래픽 형식으로 보여줍니다.

디렉토리 트리 형태 예최상위 항목과 그 바로 아래에 있는 항목이 표시됩니다.

Example.com은 웹 호스팅 서비스와 인터넷 액세스를 제공하며 웹 호스팅 서비스의 일부로 클라이언트 기업의 디렉토리를 호스팅합니다. Example.com은 실제로 두 개 중소 기업(Company333과 Company999)의 디렉토리를 호스팅하고 있으며 일부 관리 작업도 수행합니다. 또한 다수의 개인 가입자에게 인터넷 액세스를 제공합니다.

Example.com에서 적용하려는 액세스 규칙은 다음과 같습니다.

익명 액세스 권한 부여

대부분의 디렉토리는 읽기, 검색 또는 비교를 위해 하나 이상의 접미어에 익명으로 액세스할 수 있도록 구성됩니다. 전화 번호부 등 직원들이 검색할 수 있는 인사 디렉토리를 실행하는 경우 이러한 권한을 설정할 수 있습니다. Example.com 내부의 경우가 이에 해당하며 ACI "Anonymous Example.com"에서 자세히 설명합니다.

또한 Example.com은 ISP로서 누구든지 이용할 수 있는 공공 전화 번호부를 작성하여 모든 가입자의 연락처 정보를 제공하려고 합니다. 여기에 대해서는 ACI "Anonymous World"에서 설명합니다.

ACI "Anonymous Example.com"

Example.com 직원들에게 전체 Example.com 트리에 대한 읽기, 검색 및 비교 권한을 부여하려면 LDIF로 아래 명령문을 작성합니다. 


aci: (targetattr !="userPassword")(version 3.0; acl "Anonymous
 example"; allow (read, search, compare)
 userdn= "ldap:///anyone") ;)

이 예에서는 dc=example,dc=com entry에 aci를 추가한다고 가정합니다. userPassword 속성은 ACI 범위에서 제외됩니다.

주 –

비밀번호 속성을 보호하기 위한 예에서 동일한 구문을 사용하여 표시해서는 안되는 속성과 기밀 속성을 보호합니다(targetattr !="attribute-name").

ACI "Anonymous World"

모든 사람에게 개인 가입자 하위 트리에 대한 읽기 및 검색 권한을 부여하는 동시에 목록에 표시하지 않을 가입자 정보에 대한 액세스를 거부하려면 LDIF로 아래 명령문을 작성합니다.


aci: (targetfilter= "(!(unlistedSubscriber=yes))")
 (targetattr="homePostalAddress || homePhone || mail")
 (version 3.0; acl "Anonymous World"; allow (read, search)
 userdn="ldap:///anyone";)

이 예에서는 ou=subscribers,dc=example, dc=com 항목에 ACI를 추가한다고 가정합니다. 또한 모든 가입자 항목에 yes 또는 no로 설정된 unlistedSubscriber 속성이 있다고 가정합니다. 대상 정의는 이 속성 값을 기준으로 목록에 없는 가입자를 필터링합니다. 필터 정의에 대한 자세한 내용은 필터링을 사용한 대상 설정을 참조하십시오.

개인 항목에 대한 쓰기 액세스 권한 부여

대부분의 디렉토리 어드민 관리자는 내부 사용자가 자신의 항목에 있는 일부 속성만 변경할 수 있도록 설정합니다. Example.com의 디렉토리 어드민 관리자도 사용자가 자신의 비밀번호, 집 전화 번호 및 집 주소만 변경할 수 있도록 설정하려고 합니다. 자세한 내용은 ACI "Write Example.com"을 참조하십시오.

또한 Example.com에는 가입자가 디렉토리에 대한 SSL 연결을 설정할 경우 Example.com 트리에서 자신의 개인 정보를 업데이트하도록 허용하는 정책이 있습니다. 자세한 내용은 ACI "Write Subscribers"를 참조하십시오.

ACI "Write Example.com"

주 –

이 권한을 설정하면 사용자에게 속성 값을 삭제할 수 있는 권한도 부여하게 됩니다.

Example.com 직원들에게 집 전화 번호 및 집 주소를 업데이트할 수 있는 권한을 부여하려면 LDIF로 아래 명령문을 작성합니다.


aci: (targetattr="homePhone ||
 homePostalAddress")(version 3.0; acl "Write Example.com";
 allow (write) userdn="ldap:///self" ;)

이 예에서는 ou=People,dc=example,dc=com 항목에 ACI를 추가한다고 가정합니다.

ACI "Write Subscribers"

주 –

이 권한을 설정하면 사용자에게 속성 값을 삭제할 수 있는 권한도 부여하게 됩니다.

Example.com 가입자에게 집 전화 번호를 업데이트할 수 있는 권한을 부여하려면 LDIF로 아래 명령문을 작성합니다.


aci: (targetattr="homePhone")
 (version 3.0; acl "Write Subscribers"; allow (write)
 userdn= "ldap://self" and authmethod="ssl";)

이 예에서는 ou=subscribers,dc=example, dc=com 항목에 aci를 추가하고 사용자가 SSL을 사용하여 바인드해야 한다고 가정합니다.

Example.com 가입자는 해당 속성을 삭제할 수 있기 때문에 집 주소에 대한 쓰기 액세스 권한이 없습니다. 집 주소는 Example.com에서 청구하는 데 필요한 업무상 중요한 정보입니다.

특정 수준의 액세스 허용

디렉토리 트리 내에서 다른 수준에 영향을 미치는 ACI 범위를 설정하여 허용할 액세스 수준을 미세 조정할 수 있습니다. 대상 ACI 범위를 다음 중 하나로 설정할 수 있습니다.

base

항목 자체

onelevel

항목 자체와 한 수준 아래의 모든 항목

subtree

항목 자체와 해당 항목 아래의 모든 항목(제한 없음)

ACI "Read Example.com only"

Example.com 가입자에게 회사 연락처 정보의 dc=example,dc=com 항목에 대한 읽기 권한을 부여하고 그 아래 항목에 대한 액세스 권한은 허용하지 않으려면 LDIF로 아래 명령문을 작성합니다.


aci: (targetscope="base") (targetattr="*")(version 3.0;
 acl "Read Example.com only";  allow (read,search,compare)
 userdn="ldap:///cn=*,ou=subscribers,dc=example,dc=com";)

이 예에서는 dc=example, dc=com 항목에 ACI를 추가한다고 가정합니다.

중요 역할에 대한 액세스 제한

디렉토리에서 역할 정의를 사용하여 네트워크 및 디렉토리 관리와 같은 업무상 중요한 기능을 식별할 수 있습니다.

예를 들어 특정 시간과 요일에 전세계 기업 사이트에서 사용할 수 있는 시스템 관리자의 부분 집합을 식별하여 superAdmin 역할을 작성할 수 있습니다. 또는 특정 사이트에서 응급 조치 교육을 이수한 모든 직원 구성원을 포함하는 First Aid 역할을 작성할 수 있습니다. 역할 정의 작성에 대한 자세한 내용은 역할 관리를 참조하십시오.

중요한 기업 또는 비즈니스 기능에 대한 사용자 권한을 부여하는 역할이 있을 경우 이 역할에 대한 액세스를 제한해 보십시오. 예를 들어 Example.com의 직원들은 다음 예에 표시된 것처럼 superAdmin 역할을 제외한 모든 역할을 자신의 항목에 추가할 수 있습니다.

ACI "Roles"

Example.com 직원들에게 superAdmin 역할을 제외한 모든 역할을 자신의 항목에 추가할 수 있는 권한을 부여하려면 LDIF로 아래 명령문을 작성합니다.


aci: (targetattr="*") (targattrfilters="add=nsRoleDN:
 (nsRoleDN !="cn=superAdmin, dc=example, dc=com")")
 (version 3.0; acl "Roles"; allow (write)
 userdn= "ldap:///self" ;)

이 예에서는 ou=People,dc=example,dc=com 항목에 ACI를 추가한다고 가정합니다.

모든 접미어에 대한 전체 액세스 권한 부여

특정 사용자에게 접미어에 대해 디렉토리 관리자와 동일한 권한을 부여하는 것이 좋은 경우도 있습니다. Example.com에서 Kirsten Vaughan은 디렉토리 서버의 관리자로서 superAdmin 역할을 가지고 있습니다. 이 역할의 이점은 다음과 같습니다.

주 –

Kirsten Vaughan을 cn=Administrators,cn=config 그룹에 추가하면 디렉토리 관리자와 동일한 권한이 부여됩니다.

전체 서버에 대해 디렉토리 관리자와 동일한 권한을 부여하려면 루트 액세스 권한이 있는 관리 사용자를 만드는 방법의 절차를 수행합니다.

ACI "Full Access"

관리자 Kirsten Vaughan에게 디렉토리 관리자와 동일한 권한을 부여하려면 LDIF로 아래 명령문을 사용합니다.


aci: (targetattr="*") (version 3.0; acl "Full Access";
 allow (all) groupdn= "ldap:///cn=SuperAdmin,dc=example,dc=com"
 and authmethod="ssl" ;)

이 예에서는 루트 항목""(텍스트 없음)에 ACI를 추가한다고 가정합니다.

그룹에 접미어에 대한 전체 액세스 권한 부여

대부분의 디렉토리에는 기업의 특정 기능을 식별하는 그룹이 있습니다. 이러한 그룹에 디렉토리의 모두 또는 일부에 대한 액세스 권한을 부여할 수 있습니다. 그룹에 액세스 권한을 적용하면 각 구성원에 대해 개별적으로 액세스 권한을 설정할 필요가 없습니다. 대신, 사용자를 그룹에 추가하여 액세스 권한을 부여할 수 있습니다.

예를 들어 디렉토리 서버 인스턴스를 작성하는 경우 디렉토리에 대한 전체 액세스 권한이 있는 관리자 그룹 cn=Administrators,cn=config가 기본적으로 작성됩니다.

Example.com에서 Human Resources 그룹은 디렉토리의 ou=People 분기에 대한 전체 액세스 권한을 갖고 있으므로 ACI "HR"에 표시된 것처럼 직원 디렉토리를 업데이트할 수 있습니다.

ACI "HR"

디렉토리의 employee 분기에 대한 모든 권한을 HR 그룹에 부여하려면 LDIF로 아래 명령문을 작성합니다.


aci: (targetattr="*") (version 3.0; acl "HR"; allow (all)
  groupdn= "ldap:///cn=HRgroup,ou=Groups,dc=example,dc=com";)

이 예에서는 다음 항목에 ACI를 추가한다고 가정합니다.


ou=People,dc=example,dc=com

그룹 항목 추가 및 삭제 권한 부여

일부 조직에서 직원들은 효율성을 높이고 사기를 불어넣는 항목을 트리에 작성할 수 있습니다. 예를 들어 Example.com에는 테니스, 수영, 스키, 롤 플레잉 등 여러 클럽으로 구성된 사교 모임이 있습니다.

ACI "Create Group"에 표시된 것처럼 Example.com의 직원이라면 누구든지 새 클럽을 나타내는 그룹 항목을 작성할 수 있습니다.

사용자가 그룹에 자신을 추가 또는 제거할 수 있도록 허용에 표시된 것처럼 Example.com의 모든 직원은 이러한 그룹 중 하나의 구성원이 될 수 있습니다.

ACI "Delete Group"에 표시된 것처럼 그룹 소유자만 그룹 항목을 수정하거나 삭제할 수 있습니다.

ACI "Create Group"

Example.com 직원들에게 ou=Social Committee 분기에 그룹 항목을 작성할 수 있는 권한을 부여하려면 LDIF로 아래 명령문을 작성합니다.


aci: (targetattr="*") (targattrfilters="add=objectClass: 
(|(objectClass=groupOfNames)(objectClass=top))") 
(version 3.0; acl "Create Group"; allow (read,search,add) 
userdn= "ldap:///uid=*,ou=People,dc=example,dc=com") 
and dns="*.Example.com";)

이 예에서는 ou=Social Committee,dc=example,dc=com 항목에 ACI를 추가한다고 가정합니다.

주 –

ACI "Delete Group"

Example.com 직원들에게 ou=Social Committee 분기에서 그들이 속하는 그룹의 항목을 수정하거나 삭제할 수 있는 권한을 부여하려면 LDIF로 아래 명령문을 작성합니다.


aci: (targetattr = "*") (targattrfilters="del=objectClass:
(objectClass=groupOfNames)")
 (version 3.0; acl "Delete Group"; allow (write,delete)
 userattr="owner#GROUPDN";)

이 예에서는 ou=Social Committee,dc=example,dc=com 항목에 aci를 추가한다고 가정합니다.

DSCC를 사용하여 이 ACI를 작성하려면 수동 편집 모드를 사용하여 대상 필터를 작성하고 그룹 소유권을 확인해야 하기 때문에 그다지 효율적이지 않습니다.

사용자가 그룹에 자신을 추가 또는 제거할 수 있도록 허용

대부분의 디렉토리는 사용자가 메일 목록과 같이 그룹에 자신을 추가하거나 제거할 수 있도록 허용하는 ACI를 설정합니다.

ACI "Group Members"에 표시된 것처럼 Example.com의 직원들은 ou=Social Committee 하위 트리 아래의 모든 그룹 항목에 자신을 추가할 수 있습니다.

ACI "Group Members"

Example.com 직원들에게 그룹에 자신을 추가할 수 있는 권한을 부여하려면 LDIF로 아래 명령문을 작성합니다.


aci: (targettattr="member")(version 3.0; acl "Group Members";
 allow (selfwrite)
 (userdn= "ldap:///uid=*,ou=People,dc=example,dc=com") ;)

이 예에서는 ou=Social Committee,dc=example,dc=com 항목에 ACI를 추가한다고 가정합니다.

그룹이나 역할에 조건부 액세스 권한 부여

일반적으로 그룹이나 역할에 디렉토리에 대한 액세스 권한을 부여하는 경우 권한이 있는 사용자를 사칭하는 침입자들로부터 해당 권한을 보호해야 합니다. 따라서 그룹이나 역할에 중요한 액세스 권한을 부여하는 액세스 제어 규칙에는 많은 조건이 따릅니다.

예를 들어 Example.com은 자사가 호스팅 서비스를 제공하는 두 회사인 Company333과 Company999에 대해 각각 디렉토리 어드민 관리자 역할을 작성했습니다. Example.com은 두 회사가 자사 데이터를 관리하고 액세스 제어 규칙을 구현하는 동시에 침입자로부터 데이터를 보호할 수 있기를 원합니다.

이런 이유로 Company333과 Company999는 다음과 같은 조건에 부합될 경우 디렉토리 트리의 해당 분기에 대한 전체 권한을 갖습니다.

이러한 조건에 대해서는 각 회사별 ACI(ACI "Company333" 및 ACI "Company999")에서 설명합니다. 두 ACI의 내용이 동일하므로 다음 예에서는 "Company333" ACI만 사용합니다.

ACI "Company333"

이전에 명시된 조건을 전제로 Company333에 디렉토리의 분기에 대한 전체 액세스 권한을 부여하려면 LDIF로 아래 명령문을 작성합니다.


aci: (targetattr = "*") (version 3.0; acl "Company333"; allow (all)
 (roledn="ldap:///cn=DirectoryAdmin,ou=Company333,
 ou=corporate clients,dc=example,dc=com") and (authmethod="ssl")
 and (dayofweek="Mon,Tues,Wed,Thu") and (timeofday >= "0800" and
 timeofday <= "1800") and (ip="255.255.123.234"); )

이 예에서는 ou=Company333,ou=corporate clients,dc=example,dc=com 항목에 ACI를 추가한다고 가정합니다.

액세스 거부

접미어 중 많은 부분에 대한 액세스 권한이 이미 있는 경우 기존 ACI 아래에 있는 더 적은 접미어 부분에 대한 액세스를 거부할 수 있습니다.

주 –

액세스 거부는 의외의 복잡한 액세스 제어 동작을 유발할 수 있으므로 가능하면 피해야 합니다. 범위, 속성 목록, 대상 필터 등을 조합하여 액세스를 제한합니다.

또한 거부 액세스 ACI를 삭제하여 권한을 제거하는 대신, 다른 ACI에서 설정한 권한을 확장합니다.

디렉토리 서버에서는 액세스 권한을 평가할 때 deny 권한을 먼저 읽은 다음 allow 권한을 읽습니다.

다음 예에서 Example.com은 모든 가입자가 자신의 항목에서 연결 시간이나 계좌 잔고와 같은 결제 정보를 읽을 수 있도록 허용합니다. 또한 Example.com은 이 정보에 대한 쓰기 액세스를 명시적으로 거부합니다. 읽기 액세스에 대한 자세한 내용은 ACI "Billing Info Read"를 참조하십시오. deny 액세스에 대한 자세한 내용은 ACI "Billing Info Deny"를 참조하십시오.

ACI "Billing Info Read"

가입자에게 자신의 항목에서 결제 정보를 읽을 수 있는 권한을 부여하려면 LDIF로 아래 명령문을 작성합니다.


aci: (targetattr="connectionTime || accountBalance")
 (version 3.0; acl "Billing Info Read"; allow (search,read)
  userdn="ldap:///self";)

이 예에서는 스키마에 해당 속성이 작성되어 있으며 ou=subscribers,dc=example,dc=com 항목에 ACI를 추가한다고 가정합니다.

ACI "Billing Info Deny"

가입자에게 자신의 항목에서 결제 정보를 수정할 수 있는 권한을 부여하려면 LDIF로 아래 명령문을 작성합니다.


aci: (targetattr="connectionTime || accountBalance")
 (version 3.0; acl "Billing Info Deny";
 deny (write) userdn="ldap:///self";)

이 예에서는 스키마에 해당 속성이 작성되어 있으며 ou=subscribers,dc=example,dc=com 항목에 ACI를 추가한다고 가정합니다.

프록시 인증

프록시 인증 방법은 특별한 인증 형식입니다. 자신의 아이디를 사용하여 디렉토리에 바인드하는 사용자에게 프록시 인증을 통해 다른 사용자의 권한을 부여합니다.

프록시 요청을 허용하도록 디렉토리 서버를 구성하려면 다음을 수행해야 합니다.

주 –

디렉토리 관리자를 제외한 모든 디렉토리 사용자에게 프록시 권한을 부여할 수 있습니다. 디렉토리 관리자의 DN을 프록시 DN으로 사용할 수는 없습니다. 프록시 권한을 부여하면 디렉토리 관리자 DN을 제외한 모든 DN을 프록시 DN으로 지정할 수 있는 권한을 부여하는 것이므로 특히 주의해야 합니다. 디렉토리 서버가 동일한 작업에서 프록시 인증 제어를 둘 이상 수신하면 클라이언트 응용 프로그램에 오류가 반환되고 작업 시도는 실패하게 됩니다.

프록시 인증 예

Example.com은 MoneyWizAcctSoftware로 바인드하는 클라이언트 응용 프로그램이 LDAP 데이터에 대해 계정 관리자와 동일한 액세스 권한을 갖도록 허용합니다.

적용되는 매개 변수는 다음과 같습니다.

클라이언트 응용 프로그램이 계정 관리자와 동일한 액세스 권한을 사용하여 계정 하위 트리에 액세스하려면 다음과 같은 조건에 부합해야 합니다.

이 ACI가 디렉토리에 있으면 MoneyWizAcctSoftware 클라이언트 응용 프로그램은 디렉토리에 바인드하여 프록시 DN의 액세스 권한이 필요한 ldapsearch 또는 ldapmodify와 같은 LDAP 명령을 전송할 수 있습니다.

위의 예에서 클라이언트가 ldapsearch 명령을 수행하려면 명령에 다음과 같은 컨트롤이 포함됩니다.


$ ldapsearch -D "uid=MoneyWizAcctSoftware,ou=Applications,dc=example,dc=com" -w - \
 -Y "dn: uid=AcctAdministrator,ou=Administrators,dc=example,dc=com" ...

클라이언트가 ldapmodify 명령을 수행하려면 명령에 다음과 같은 컨트롤이 포함됩니다.


$ ldapmodify -h hostname -p port \
-D "uid=MoneyWizAcctSoftware,ou=Applications,dc=example,dc=com" -w - \
-Y"dn: uid=AcctAdministrator,ou=Administrators,dc=example,dc=com"
dn: uid=AcctAdministrator,ou=Administrators,dc=example,dc=com
changetype: modify
delete: userpassword
-
add: userpassword
userpassword: admin1

클라이언트는 자신으로 바인드하지만 프록시 항목의 권한이 부여되며프록시 항목의 비밀번호를 제공할 필요가 없습니다.

필터링을 사용한 대상 설정

디렉토리에 분산된 여러 항목에 대한 액세스를 허용하는 액세스 제어를 설정하려면 필터를 사용하여 대상을 설정할 수 있습니다.

필터를 사용하여 HR의 모든 사용자에게 직원 항목에 대한 액세스를 허용하려면 LDIF로 아래 명령문을 작성합니다.


aci: (targetattr="*") (targetfilter=(objectClass=employee))
 (version 3.0; acl "HR access to employees";
 allow (all) groupdn= "ldap:///cn=HRgroup,ou=People,dc=example,dc=com";)

이 예에서는 ou=People,dc=example,dc=com 항목에 ACI를 추가한다고 가정합니다.

주 –

검색 필터는 액세스를 관리할 객체를 직접 지정하지 않으므로 잘못된 객체에 대한 액세스를 허용하거나 거부하지 않도록 합니다. 잘못된 객체에 대한 액세스를 실수로 허용하거나 거부할 경우 디렉토리가 더 복잡해질 위험이 있습니다. 또한 필터를 사용할 경우 디렉토리 내의 액세스 제어 문제점을 해결하기 어렵다는 단점이 있습니다.

쉼표가 있는 DN에 대한 권한 정의

쉼표가 있는 DN은 LDIF ACI 명령문에서 특수 처리해야 합니다. ACI 명령문의 대상 및 바인드 규칙 부분에서 백슬래시(\)를 사용하여 쉼표를 이스케이프해야 합니다. 아래 예에서는 이 구문에 대해 설명합니다.


dn: o=Example.com Bolivia\, S.A. 
objectClass: top 
objectClass: organization 
aci: (target="ldap:///o=Example.com Bolivia\,S.A.") (targetattr="*") 
(version 3.0; acl "aci 2"; allow (all) groupdn = 
"ldap:///cn=Directory Administrators, o=Example.com Bolivia\, S.A.";)

유효 권한 보기

디렉토리 항목에 대한 액세스 정책을 유지관리할 때 정의한 ACI의 보안에 미치는 영향을 알고 있어야 합니다. 디렉토리 서버에서는 ACI에서 지정된 항목의 특정 사용자에게 부여하는 유효 권한을 보고 기존 ACI를 평가할 수 있습니다.

디렉토리 서버는 검색 작업에 포함할 수 있는 "유효 권한 보기" 컨트롤에 응답합니다. 항목과 속성에 대한 유효 권한 정보를 검색 결과로 반환합니다. 이 추가 정보에는 각 항목 및 항목에 있는 각 속성에 대한 읽기 및 쓰기 권한이 포함됩니다. 검색에 사용된 바인드 DN이나 임의 DN에 대한 권한을 요청할 수 있으므로 관리자는 디렉토리 사용자의 권한을 테스트할 수 있습니다.

유효 권한 기능은 LDAP 컨트롤을 사용합니다. 원격 서버에 바인드할 때 사용한 프록시 아이디도 유효 권한 속성에 액세스할 수 있어야 합니다.

유효 권한 보기 컨트롤에 대한 액세스 제한

유효 권한 보기 작업은 보호 및 적절한 제한이 필요한 디렉토리 작업입니다.

유효 권한 정보에 대한 액세스를 제한하려면 getEffectiveRights 속성의 기본 ACI를 수정합니다. 그런 다음 getEffectiveRightsInfo 속성의 새 ACI를 작성합니다.

예를 들어 다음 ACI는 디렉토리 어드민 관리자 그룹의 구성원에게만 유효 권한 보기를 허용합니다.


aci: (targetattr != "aci")(version 3.0; acl
 "getEffectiveRights"; allow(all) groupdn =
 "ldap:///cn=Directory Administrators,ou=Groups,dc=example,dc=com";)

유효 권한 정보를 보려면 유효 권한 컨트롤 사용을 위한 액세스 제어 권한 및 aclRights 속성에 대한 읽기 권한이 있어야 합니다. 이러한 이중 액세스 제어 계층은 필요에 따라 세부 조정할 수 있는 기본 보안을 제공합니다. 프록시와 마찬가지로 항목에 aclRights 속성에 대한 읽기 권한이 있는 경우 해당 항목과 속성에 대한 모든 사용자의 권한 정보를 요청할 수 있습니다. 즉, 자원을 관리하는 사용자는 해당 자원에 대한 권한이 있는 사용자를 결정할 수 있지만 이 사용자가 권한이 있는 사용자를 실제로 관리하는 것은 아닙니다.

권한 정보를 요청하는 사용자에게 유효 권한 컨트롤을 사용할 권한이 없는 경우 작업이 실패하고 오류 메시지가 반환됩니다. 그러나 권한 정보를 요청하는 사용자에게 컨트롤 사용 권한이 있지만 aclRights 속성에 대한 읽기 권한이 없는 경우에는 aclRights 속성이 반환된 항목에 표시되지 않습니다. 이 동작은 디렉토리 서버의 일반 검색 동작을 반영합니다.

유효 권한 보기 컨트롤 사용

ldapsearch 명령을 -J "1.3.6.1.4.1.42.2.27.9.5.2" 옵션과 함께 사용하여 "유효 권한 보기" 컨트롤을 지정합니다. 기본적으로 이 컨트롤은 항목과 속성에 대한 바인드 DN 항목의 유효 권한을 검색 결과로 반환합니다.

기본 동작을 변경하려면 다음과 같은 옵션을 사용합니다.

주 –

aclRights 및 aclRightsInfo 속성은 가상의 작동 가능 속성처럼 동작합니다. 이러한 속성은 디렉토리에 저장되지 않고 명시적인 요청이 있는 경우에만 반환되며 디렉토리 서버에서 "유효 권한 보기" 컨트롤에 대한 응답으로 생성됩니다.

따라서 필터 또는 검색 작업에서는 이러한 속성을 사용할 수 없습니다.

유효 권한 기능은 액세스 제어에 영향을 주는 다른 매개 변수를 상속합니다. 이러한 매개 변수에는 시간, 인증 방법, 시스템 주소, 이름 등이 포함됩니다.

아래 예에서는 사용자 Carla Fuente가 디렉토리에서 자신의 권한을 볼 수 있는 방법을 보여줍니다. 결과에서 1은 권한이 부여된 것을 의미하고 0은 권한이 거부된 것을 의미합니다.


$ ldapsearch -J "1.3.6.1.4.1.42.2.27.9.5.2 -h host1.Example.com -p 389 \
 -D "uid=cfuente,ou=People,dc=example,dc=com" -w - -b "dc=example,dc=com" \
 "(objectclass=*)" aclRights
Enter bind password:
dn: dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0
dn: ou=Groups, dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0
dn: ou=People, dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0
dn: cn=Accounting Managers,ou=groups,dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0
dn: cn=HR Managers,ou=groups,dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0
dn: uid=bjensen,ou=People, dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0
dn: uid=cfuente, ou=People, dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:1,proxy:0

이 결과는 Carla Fuente에게 최소한 읽기 권한이 있는 디렉토리 항목을 보여주며 자신의 항목을 수정할 수 있음을 표시합니다. 유효 권한 컨트롤은 일반 액세스 권한을 무시하지 않으므로 사용자는 읽기 권한이 없는 항목을 볼 수 없습니다. 아래 예에서 디렉토리 관리자는 Carla Fuente에게 읽기 권한이 없는 항목을 볼 수 있습니다.


$ ldapsearch -h host1.Example.com -p 389 -D cn=admin,cn=Administrators,cn=config -w - \
 -c "dn: uid=cfuente,ou=People,dc=example,dc=com" -b "dc=example,dc=com" \
 "(objectclass=*)" aclRights
Enter bind password:
dn: dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0
dn: ou=Groups, dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0
dn: cn=Directory Administrators, dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:0,write:0,proxy:0
dn: ou=Special Users,dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:0,write:0,proxy:0
dn: ou=People, dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0
dn: cn=Accounting Managers,ou=groups,dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0
dn: cn=HR Managers,ou=groups,dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0
dn: uid=bjensen,ou=People, dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0
dn: uid=cfuente, ou=People, dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:1,proxy:0

위의 결과에서 디렉토리 관리자는 Carla Fuente가 디렉토리 트리의 Special Users나 Directory Administrators 분기를 볼 수도 없다는 것을 확인할 수 있습니다. 아래 예에서 디렉토리 관리자는 Carla Fuente가 자신의 항목에 있는 mail 및 manager 속성을 수정할 수 없다는 것을 확인할 수 있습니다.


$ ldapsearch -h host1.Example.com -p 389 -D cn=admin,cn=Administrators,cn=config -w - \
 -c "dn: uid=cfuente,ou=People,dc=example,dc=com" -b "dc=example,dc=com" \
 "(uid=cfuente)" aclRights "*"
Enter bind password:
version: 1
dn: uid=cfuente, ou=People, dc=example,dc=com
aclRights;attributeLevel;mail: search:1,read:1,compare:1,
 write:0,selfwrite_add:0,selfwrite_delete:0,proxy:0
mail: cfuente@Example.com
aclRights;attributeLevel;uid: search:1,read:1,compare:1,
 write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0
uid: cfuente
aclRights;attributeLevel;givenName: search:1,read:1,compare:1,
 write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0
givenName: Carla
aclRights;attributeLevel;sn: search:1,read:1,compare:1,
 write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0
sn: Fuente
aclRights;attributeLevel;cn: search:1,read:1,compare:1,
 write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0
cn: Carla Fuente
aclRights;attributeLevel;userPassword: search:0,read:0,
 compare:0,write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0
userPassword: {SSHA}wnbWHIq2HPiY/5ECwe6MWBGx2KMiZ8JmjF80Ow==
aclRights;attributeLevel;manager: search:1,read:1,compare:1,
 write:0,selfwrite_add:0,selfwrite_delete:0,proxy:0
manager: uid=bjensen,ou=People,dc=example,dc=com
aclRights;attributeLevel;telephoneNumber: search:1,read:1,compare:1,
 write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0
telephoneNumber: (234) 555-7898
aclRights;attributeLevel;objectClass: search:1,read:1,compare:1,
 write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0

고급 액세스 제어: 매크로 ACI 사용

반복 디렉토리 트리 구조를 사용하는 조직에서는 매크로를 사용하여 디렉토리에 사용되는 ACI 수를 최적화할 수 있습니다. 디렉토리 트리에서 ACI 수를 줄이면 액세스 제어 정책을 관리하기가 쉽고 ACI 메모리 사용 효율성도 향상됩니다.

매크로는 ACI에서 DN 또는 DN의 일부를 나타내는 자리 표시자입니다. 매크로를 사용하여 ACI의 대상 부분, 바인드 규칙 부분 또는 두 부분에서 모두 DN을 나타낼 수 있습니다. 실제로 LDAP 작업이 수신되면 디렉토리 서버는 ACI 매크로를 LDAP 작업의 대상 자원과 비교하여 일치하는 하위 문자열이 있는지 확인합니다. 일치하는 하위 문자열이 있으면 이 문자열을 사용하여 바인드 규칙측 매크로를 확장하고 확장된 바인드 규칙을 평가하여 자원에 대한 액세스를 결정합니다.

이 절은 매크로 ACI의 예와 매크로 ACI 구문에 대한 정보로 구성되어 있습니다.

매크로 ACI 예

예를 사용하면 매크로 ACI의 혜택과 작동 방식을 명확히 이해할 수 있습니다. 그림 7–1 에서는 매크로 ACI를 사용하여 전체 ACI 수를 효과적으로 줄일 수 있는 디렉토리 트리를 보여줍니다.

이 그림에서는 하위 도메인의 반복 패턴이 동일한 트리 구조(ou=groups,ou=people)를 갖습니다. Example.com 디렉토리 트리에는 그림에 표시되지 않은 두 접미어(dc=hostedCompany2,dc=example,dc=com 및 dc=hostedCompany3,dc=example,dc=com)가 저장되어 있기 때문에 이 패턴도 트리 전체에 걸쳐 반복됩니다.

디렉토리 트리의 ACI에도 반복 패턴이 있습니다. 예를 들어 dc=hostedCompany1,dc=example,dc=com 노드에는 아래 ACI가 있습니다.


aci: (targetattr="*")
 (targetfilter=(objectClass=nsManagedDomain))(version 3.0;
 acl "Domain access"; allow (read,search) groupdn=
 "ldap:///cn=DomainAdmins,ou=Groups,dc=hostedCompany1,
 dc=example,dc=com";)

이 ACI는 domainAdmins 그룹에 dc=hostedCompany1,dc=example,dc=com 트리의 항목에 대한 읽기 및 검색 권한을 부여합니다.

그림 7–1 매크로 ACI의 디렉토리 트리 예

dc=hostedcompany1,dc=example,dc=com 및 다양한 하위 도메인을 보여주는 디렉토리 트리 형태 예

dc=hostedCompany1,dc=example,dc=com 노드에는 아래 ACI가 있습니다.


aci: (targetattr="*")
 (targetfilter=(objectClass=nsManagedDomain))
 (version 3.0; acl "Domain access"; allow (read,search)
 groupdn="ldap:///cn=DomainAdmins,ou=Groups,dc=hostedCompany1,dc=example,dc=com";)

dc=subdomain1,dc=hostedCompany1, dc=example,dc=com 노드에는 아래 ACI가 있습니다.


aci: (targetattr="*")
 (targetfilter=(objectClass=nsManagedDomain))
 (version 3.0; acl "Domain access"; allow (read,search)
 groupdn="ldap:///cn=DomainAdmins,ou=Groups,dc=subdomain1,dc=hostedCompany1,
  dc=example,dc=com";)

dc=hostedCompany2,dc=example,dc=com 노드에는 아래 ACI가 있습니다.


aci: (targetattr="*")
 (targetfilter=(objectClass=nsManagedDomain))
 (version 3.0; acl "Domain access"; allow (read,search)
 groupdn="ldap:///cn=DomainAdmins,ou=Groups,dc=hostedCompany2, dc=example,dc=com";)

dc=subdomain1,dc=hostedCompany2, dc=example,dc=com 노드에는 아래 ACI가 있습니다.


aci: (targetattr="*")
 (targetfilter=(objectClass=nsManagedDomain))
 (version 3.0; acl "Domain access"; allow (read,search)
 groupdn="ldap:///cn=DomainAdmins,ou=Groups,dc=subdomain1,dc=hostedCompany2,
 dc=example,dc=com";)

앞의 네 개의 ACI에서 유일한 차이점은 groupdn 키워드에 지정된 DN입니다. 이 경우 DN에 매크로를 사용하여 dc=example,dc=com 노드에서 트리의 루트에 있는 한 개의 ACI로 네 개의 ACI를 대체할 수 있습니다. 이 매크로 ACI는 다음과 같이 표시됩니다.


aci: (target="ldap:///ou=Groups,($dn),dc=example,dc=com")
 (targetattr="*")(targetfilter=(objectClass=nsManagedDomain))
 (version 3.0; acl "Domain access"; allow (read,search) 
 groupdn="ldap:///cn=DomainAdmins,ou=Groups,[$dn],dc=example,dc=com";)

이 경우 이전에 사용하지 않았던 target 키워드가 사용되었습니다.

위의 예에서는 ACI 수가 4개에서 1개로 줄었습니다. 하지만 전체 디렉토리 트리의 반복 패턴 수가 줄어든다는 것에 가장 큰 이점이 있습니다.

매크로 ACI 구문

이 절에서는 설명을 간소화하기 위해 userdn, roledn, groupdn 및 userattr 등 바인드 자격 증명을 제공하는 데 사용되는 ACI 키워드를 총체적으로 ACI의 주제라고 부릅니다. 주제는 ACI의 적용 대상을 결정합니다.

아래 표는 특정 ACI 키워드를 대체하는 데 사용할 수 있는 매크로를 보여줍니다.

표 7–1 매크로 ACI 키워드

매크로 

설명 

ACI 키워드 

($dn)

대상 일치 및 주제의 직접 대체에 사용합니다. 

target, targetfilter, userdn, roledn, groupdn, userattr

[$dn]

주제의 하위 트리에서 작동하는 여러 RDN을 대체하는 데 사용합니다. 

targetfilter, userdn, roledn, groupdn, userattr

($attr.attrName)

대상 항목의 attributeName 속성 값을 주제로 대체하는 데 사용합니다.

userdn, roledn, groupdn, userattr

매크로 ACI 키워드에 적용되는 제한 사항은 다음과 같습니다.

대상의 ($dn) 일치

ACI의 대상에 있는 ($dn) 매크로는 LDAP 요청의 대상 항목에 따라 대체 값을 결정합니다. 예를 들어 이 항목에서 대상으로 하는 LDAP 요청이 있습니다.


cn=all,ou=groups,dc=subdomain1, dc=hostedCompany1,dc=example,dc=com

또한, 다음과 같이 대상을 정의하는 ACI가 있습니다.


(target="ldap:///ou=Groups,($dn),dc=example,dc=com")

($dn) 매크로는 "dc=subdomain1, dc=hostedCompany1"과 일치하므로 ACI 주제에 이 하위 문자열이 대체됩니다.

주제의 ($dn) 대체

ACI 주제에 있는 ($dn) 매크로는 대상에서 일치하는 전체 하위 문자열로 대체됩니다. 예를 들면 다음과 같습니다.


groupdn="ldap:///cn=DomainAdmins,ou=Groups,($dn),dc=example,dc=com"

주제는 다음과 같습니다.


groupdn="ldap:///cn=DomainAdmins,ou=Groups,
 dc=subdomain1,dc=hostedCompany1,dc=example,dc=com"

매크로가 확장되면 디렉토리 서버는 일반 프로세스에 따라 ACI를 평가하여 액세스 권한을 부여할지 여부를 결정합니다.

주 –

매크로 대체를 사용하는 ACI는 표준 ACI와 달리 반드시 대상 항목의 자식에 대한 액세스 권한을 부여하지는 않습니다. 자식 DN이 대상이면 대체를 통해 주제 문자열에 유효한 DN을 작성할 수 없기 때문입니다.

주제의 [$dn] 대체

[$dn]의 대체 메커니즘은 ($dn)의 경우와 약간 다릅니다. 일치를 발견할 때까지 대상 자원의 DN을 여러 번 검사하며 매번 가장 왼쪽의 RDN 구성 요소를 삭제합니다.

예를 들어 cn=all,ou=groups, dc=subdomain1,dc=hostedCompany1,dc=example,dc=com 하위 트리를 대상으로 하는 LDAP 요청과 다음과 같은 ACI가 있다고 가정합니다.


aci: (targetattr="*")
 (target="ldap:///ou=Groups,($dn),dc=example,dc=com")
 (version 3.0; acl "Domain access"; allow (read,search)
 groupdn="ldap:///cn=DomainAdmins,ou=Groups,[$dn],
 dc=example,dc=com";)

    서버는 다음과 같이 이 ACI를 확장합니다.

  1. 서버는 대상의 ($dn)이 dc=subdomain1,dc=hostedCompany1과 일치하는지 확인합니다.

  2. 주제의 [$dn]을 dc=subdomain1,dc=hostedCompany1로 대체합니다.

    따라서 주제는 groupdn="ldap:///cn=DomainAdmins,ou=Groups, dc=subdomain1,dc=hostedCompany1,dc=example,dc=com"이 됩니다. 바인드 DN이 이 그룹의 구성원이어서 액세스 권한이 부여되면 매크로 확장이 중단되고 ACI 평가가 수행됩니다. 바인드 DN이 그룹의 구성원이 아니면 프로세스가 계속됩니다.

  3. 주제의 [$dn]을 dc=hostedCompany1로 대체합니다.

    따라서 주제는 groupdn="ldap:///cn=DomainAdmins,ou=Groups, dc=hostedCompany1,dc=example,dc=com"이 됩니다. 다시 바인드 DN이 이 그룹의 구성원인지 테스트하여, 구성원일 경우 ACI를 완전히 평가합니다. 바인드 DN이 그룹의 구성원이 아니면 일치한 값의 마지막 RDN에서 매크로 확장이 중단되고 이 ACI에 대한 평가가 완료됩니다.

[$dn] 매크로를 사용할 경우 도메인 수준 관리자에게 디렉토리 트리의 모든 하위 도메인에 대한 액세스 권한을 유연성 있게 부여할 수 있다는 장점이 있습니다. 따라서 [$dn] 매크로는 도메인간 계층 관계를 표시할 때 유용합니다.

예를 들어 다음과 같은 ACI를 가정해 보십시오.


aci: (target="ldap:///ou=*,($dn),dc=example,dc=com") (targetattr="*")
(targetfilter=(objectClass=nsManagedDomain)) 
(version 3.0; acl "Domain access"; allow (read,search) groupdn= 
"ldap:///cn=DomainAdmins,ou=Groups,[$dn],dc=example,dc=com";)

ACI는 cn=DomainAdmins,ou=Groups, dc=hostedCompany1,dc=example,dc=com 구성원에게 dc=hostedCompany1 아래의 모든 하위 도메인에 대한 액세스 권한을 부여합니다. 따라서 해당 그룹에 속하는 관리자는 ou=people,dc=subdomain1.1,dc=subdomain1과 같은 하위 트리에 액세스할 수 있습니다.

하지만 이와 동시에 cn=DomainAdmins,ou=Groups, dc=subdomain1.1의 구성원에게는 ou=people,dc=subdomain1, dc=hostedCompany1 및 ou=people,dc=hostedCompany1 노드에 대한 액세스가 거부됩니다.

($attr.attrName )의 매크로 일치

($attr.attrname) 매크로는 항상 DN의 주제 부분에서 사용됩니다. 예를 들어 다음과 같은 roledn을 정의할 수 있습니다.


roledn = "ldap:///cn=DomainAdmins,($attr.ou),dc=HostedCompany1,dc=example,dc=com"

이제 서버가 아래 항목을 대상으로 하는 LDAP 작업을 수신한다고 가정합니다.


dn: cn=Babs Jensen,ou=People,dc=HostedCompany1,dc=example,dc=com
cn: Babs Jensen
sn: Jensen
ou: Sales
...

ACI의 roledn 부분을 평가하기 위해 서버는 대상 항목에 저장된 ou 속성 값을 읽습니다. 그런 다음 주제에서 해당 값을 대체하여 매크로를 확장합니다. 이 예에서 roledn은 다음과 같이 확장됩니다.


roledn = "ldap:///cn=DomainAdmins,ou=Sales,dc=HostedCompany1,dc=example,dc=com"

그런 다음 디렉토리 서버는 일반 ACI 평가 알고리즘에 따라 ACI를 평가합니다.

매크로에 지정된 속성이 여러 값을 갖는 경우 각 값을 차례로 사용하여 매크로를 확장합니다. 처음 일치하는 항목을 제공한 값이 사용됩니다.

액세스 제어 로깅 정보

오류 로그에서 액세스 제어에 대한 정보를 얻으려면 적절한 로그 수준을 설정해야 합니다.

ProcedureACI에 대한 로깅을 설정하는 방법

DSCC를 사용하여 이 작업을 수행할 수 없습니다. 이 절차에 설명된 것처럼 명령줄을 사용하십시오.

  1. ACI 처리에 사용할 로그 수준을 설정합니다.


    $ dsconf set-log-prop -h host -p port error level:err-acl

TCP 래핑을 통한 클라이언트-호스트 액세스 제어

TCP 래퍼를 사용하여 TCP 수준에서 연결이 허용되거나 거부된 호스트 또는 IP 주소를 제어할 수 있습니다. TCP 래핑을 통해 클라이언트-호스트 액세스를 제한할 수 있습니다. 이렇게 하면 디렉토리 서버에 대한 초기 TCP 연결을 호스트와 독립적으로 보호할 수 있습니다.

디렉토리 서버에 대한 TCP 래핑을 설정할 수는 있지만 TCP 래핑은 특히 서비스 거부(DoS) 공격 중에 상당한 성능 저하를 초래할 수 있습니다. 디렉토리 서버 외부에서 유지 관리되는 호스트 기반 방화벽이나 IP 포트 필터링을 사용하여 최상의 성능을 얻을 수 있습니다.

ProcedureTCP 래핑을 사용 가능하게 하는 방법

DSCC를 사용하여 이 작업을 수행할 수 없습니다. 이 절차에 설명된 것처럼 명령줄을 사용하십시오.

  1. 인스턴스 경로 내의 다른 위치에서 hosts.allow 파일이나 hosts.deny 파일을 작성합니다.

    예를 들어 instance-path/config에 파일을 작성합니다. 작성하는 파일의 서식이 hosts_access(4)를 준수해야 합니다.

  2. 경로를 액세스 파일로 설정합니다. 


    $ dsconf set-server-prop -h host -p port host-access-dir-path:path-to-file

    예를 들면 다음과 같습니다.


    $ dsconf set-server-prop -h host -p port host-access-dir-path:/local/ds1/config
"host-access-dir-path" property has been set to "/local/ds1/config".
The "/local/ds1/config" directory on host1 must contain valid hosts.allow
and/or hosts.deny files.
Directory Server must be restarted for changes to take effect.

ProcedureTCP 래핑을 사용 불가능하게 하는 방법

DSCC를 사용하여 이 작업을 수행할 수 없습니다. 이 절차에 설명된 것처럼 명령줄을 사용하십시오.

  1. 호스트 액세스 경로를 ""로 설정합니다. 


    $ dsconf set-server-prop -h host -p port host-access-dir-path:""