Sun ONE 로고     이전     목차     색인     DocHome     다음    
Sun ONE Directory Server 관리 설명서



6장   액세스 제어 관리

디렉토리 내용에 대한 액세스를 제어하는 것은 디렉토리 보안에 있어 핵심적인 부분입니다. 이 장에서는 디렉토리에 액세스하는 사용자에게 부여할 권한을 결정하는 액세스 제어 명령(ACI)에 대해 설명합니다. Sun ONE Directory Server 5.2는 지정된 항목에 대한 특정 사용자의 유효 권한을 볼 수 있는 기능을 제공합니다. 이 기능을 사용하면 복잡하면서도 강력한 액세스 제어 메커니즘을 간단하게 관리할 수 있습니다.

전체 보안 정책을 제공하는 액세스 제어 전략은 디렉토리 배포의 계획 단계에서 정의해야 합니다. 액세스 제어 전략을 계획하는 방법은 Sun ONE Directory Server Deployment Guide의 Chapter 7, "Designing Access Control"을 참조하십시오.

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

액세스 제어 원칙

액세스를 정의하는 메커니즘을 액세스 제어라고 합니다. 요청이 수신되면 서버는 바인드 작업 시 사용자가 제공한 인증 정보와 서버에 정의된 액세스 제어 명령(ACI)을 사용하여 디렉토리 정보에 대한 액세스를 허용하거나 거부합니다. 서버는 읽기, 쓰기, 검색 또는 비교 권한을 허용하거나 거부할 수 있습니다. 사용자에게 부여되는 권한 수준은 제공된 인증 정보에 따라 달라집니다.

액세스 제어를 사용하면 전체 디렉토리, 디렉토리의 하위 트리, 디렉토리의 특정 항목(구성 작업을 정의하는 항목 포함) 또는 항목 속성의 특정 집합에 대한 액세스를 제어할 수 있습니다. 특정 사용자, 특정 그룹이나 역할에 속한 모든 사용자 또는 디렉토리에 있는 모든 사용자의 권한을 설정할 수 있습니다. 마지막으로 IP 주소나 DNS 이름으로 식별된 특정 클라이언트에 대해서도 액세스를 정의할 수 있습니다.

ACI 구조

액세스 제어 명령은 항목 속성으로 디렉토리에 저장됩니다. aci 속성은 작동 가능 속성으로, 항목의 개체 클래스에 정의되어 있지 않아도 디렉토리의 모든 항목에서 사용할 수 있습니다. 클라이언트로부터 LDAP 요청이 수신되면 디렉토리 서버는 이 속성을 사용하여 부여하거나 거부할 권한을 평가합니다. 특별한 요청이 있을 경우 aci 속성은 ldapsearch 작업으로 반환됩니다.

ACI 명령문은 크게 세 부분으로 구성됩니다.

  • 대상 - 권한을 적용할 항목이나 속성을 지정합니다.

  • 권한 - 허용 또는 거부되는 작업을 정의합니다.

  • 바인드 규칙 - 바인드 DN을 기준으로 ACI에 적용되는 사용자를 지정합니다.

ACI의 권한 부분과 바인드 규칙 부분은 한 쌍으로 설정되며 액세스 제어 규칙(ACR)이라고도 합니다. 대상에 대한 액세스 권한은 해당 규칙의 평가 결과에 따라 부여되거나 거부됩니다. 자세한 내용은 "ACI 구문"을 참조하십시오.

ACI 배치

ACI가 포함된 항목에 자식 항목이 없으면 해당 항목에만 ACI가 적용됩니다. 항목에 자식 항목이 있으면 해당 항목 및 모든 하위 항목에 ACI가 적용됩니다. 따라서 서버는 지정된 항목에 대한 액세스 권한을 평가할 때 요청된 항목과 루트 접미사의 기본 항목 사이에 있는 모든 항목에 대해 ACI를 확인합니다.

aci 속성은 여러 값을 가지므로 동일한 항목 또는 하위 트리에 대해 여러 개의 ACI를 정의할 수 있습니다.

해당 항목에 직접 적용되지는 않지만 하위 트리의 일부 또는 모든 항목에 적용되는 ACI를 항목에 작성할 수 있습니다. 이 경우, 실제로 디렉토리 트리의 하위 수준에 있는 항목에 적용되는 일반 ACI를 디렉토리 트리의 상위 수준에 배치할 수 있다는 이점이 있습니다. 예를 들어, organizationalUnit 항목이나 locality 항목 수준에서 inetorgperson 개체 클래스가 있는 항목을 대상으로 하는 ACI를 작성할 수 있습니다.

이 기능을 사용하면 상위 수준 분기점에 일반 규칙을 배치하여 디렉토리 트리의 ACI 수를 최소화할 수 있습니다. 특정 규칙의 범위를 제한하려면 최대한 리프 항목 가까이에 규칙을 배치해야 합니다.


주

DN ""을 가진 루트 DSE 항목에 배치된 ACI는 해당 항목에만 적용됩니다.

ACI 평가

서버는 특정 항목에 대한 액세스 권한을 평가하기 위해 항목 루트 접미사의 기본 항목에 이르기까지 항목 자체 및 부모 항목에 있는 ACI 목록을 작성합니다. 평가 중에 서버는 이 순서대로 ACI를 처리합니다. ACI는 항목과 루트 접미사의 기본 항목 사이에 있는 모든 접미사 및 하위 접미사에서 평가되지만 다른 서버에 있는 연결 접미사에서는 평가되지 않습니다.


주

디렉토리 관리자는 액세스 제어가 적용되지 않는 권한을 가진 유일한 사용자입니다. 클라이언트가 디렉토리 관리자로 디렉토리에 바인드하면 서버는 작업 수행 전에 ACI를 평가하지 않습니다.

따라서 디렉토리 관리자로 LDAP 작업을 수행하면 다른 사용자에 비해 성능이 훨씬 증가하기 때문에 항상 일반 사용자 ID로 디렉토리 성능을 테스트해야 합니다.

항목에 적용되는 ACI가 없으면 기본적으로 디렉토리 관리자를 제외한 모든 사용자의 액세스가 거부됩니다. 사용자가 서버 항목에 액세스하려면 ACI에서 명시적으로 액세스 권한을 부여해야 합니다. 기본 ACI는 익명 읽기 액세스를 정의하며 사용자가 보안에 필요한 속성을 제외한 자신의 항목을 수정할 수 있도록 허용합니다. 자세한 내용은 "기본 ACI"를 참조하십시오.

서버는 대상 항목 가까이에 있는 ACI부터 먼저 처리하지만 항목에 적용되는 모든 ACI의 결과는 누적됩니다. 특정 ACI에서 액세스를 거부하지 않으면 ACI에서 부여한 액세스는 모두 허용됩니다. 목록 어디에 있건 동일 자원에 대해 액세스를 허용하는 ACI보다 액세스를 거부하는 ACI가 우선적으로 적용됩니다.

예를 들어, 디렉토리의 루트 수준에서 쓰기 권한을 거부하면 사용자는 자신에게 부여된 특정 권한에 관계 없이 디렉토리에 쓸 수 없습니다. 특정 사용자에게 디렉토리에 대한 쓰기 권한을 부여하려면 이 사용자가 포함되지 않도록 쓰기 권한에 대한 기존 거부 범위를 제한해야 합니다.

ACI 제한

디렉토리 서비스에 대한 액세스 제어 정책을 작성하는 경우 다음과 같은 제한에 주의해야 합니다.

  • 연결 기능을 사용하여 여러 서버에 디렉토리 트리를 배포하는 경우 액세스 제어 명령문에서 사용할 수 있는 키워드에 몇 가지 제한이 적용됩니다.

    • 그룹 항목을 사용하는 ACI(groupdn 키워드)는 그룹 항목과 같은 서버에 있어야 합니다. 동적 그룹일 경우 그룹의 모든 구성원 항목도 이 서버에 있어야 합니다. 정적 그룹일 경우에는 원격 서버에 구성원 항목이 위치할 수 있습니다.

    • 역할 정의를 사용하는 ACI(roledn 키워드)는 역할 정의 항목과 같은 서버에 있어야 합니다. 해당 역할을 지정할 모든 항목도 동일한 서버에 있어야 합니다.

    하지만 userattr 키워드 등을 사용하여 대상 항목에 저장된 값을 바인드 사용자 항목에 저장된 값과 일치시킬 수 있으므로 ACI가 포함된 서버에 바인드 사용자 항목이 없어도 정상적으로 액세스 평가가 이루어집니다.

    액세스 제어 평가를 연결하는 방법은 "연결 접미사를 통한 액세스 제어"를 참조하십시오.

  • CoS에서 생성된 속성은 일부 ACI 키워드에서만 사용할 수 있습니다. 특히 CoS에서 생성된 속성을 userattr 키워드 및 userdnattr 키워드와 함께 사용하면 액세스 제어 규칙이 작동하지 않습니다. 자세한 내용은 "userattr 키워드 사용"을 참조하십시오. CoS에 대한 자세한 내용은 5장 "고급 항목 관리를 참조하십시오.

  • 액세스 제어 규칙은 항상 로컬 서버에서 평가됩니다. ACI 키워드에 사용된 LDAP URL에는 서버의 호스트 이름이나 포트 번호를 지정할 수 없습니다. 이 경우 LDAP URL이 적용되지 않습니다. 자세한 내용은 Sun ONE Directory Server Reference Manual의 Appendix D, "LDAP URLs"을 참조하십시오.

  • 프록시 권한을 부여하는 경우 사용자에게 디렉토리 관리자로서의 프록시 권한을 부여하거나 디렉토리 관리자에게 프록시 권한을 부여할 수 없습니다.

기본 ACI

디렉토리 서버를 설치하면 구성 중에 지정한 루트 접미사에 다음과 같은 기본 ACI가 정의됩니다.

  • 모든 사용자는 검색, 비교 및 읽기 작업을 위해 디렉토리에 대한 익명 액세스 권한을 갖습니다.

  • 바인드된 사용자는 디렉토리에 있는 자신의 항목을 수정할 수 있지만 삭제할 수는 없습니다. 또한 aci, nsroledn 및 passwordPolicySubentry 속성과 자원 제한 속성, 암호 정책 상태 속성, 계정 잠금 상태 속성 등은 수정할 수 없습니다.

  • 구성 관리자(기본적으로 uid=admin,ou=Administrators, ou=TopologyManagement,o=NetscapeRoot)는 프록시 권한을 제외한 모든 권한을 갖습니다.

  • 구성 관리자 그룹의 모든 구성원은 프록시 권한을 제외한 모든 권한을 갖습니다.

  • 디렉토리 관리자 그룹의 모든 구성원은 프록시 권한을 제외한 모든 권한을 갖습니다.

  • SIE 그룹의 모든 구성원은 프록시 권한을 제외한 모든 권한을 갖습니다. SIE 그룹은 관리 서버에서 이 디렉토리 서버 그룹의 관리자 그룹입니다.

디렉토리에 새 루트 접미사를 작성하면 해당 기본 항목에는 위에 열거된 기본 ACI(자체 수정 ACI 제외)가 포함됩니다. 보안을 강화하려면 "콘솔에서 새 루트 접미사 작성"에 설명된 것처럼 이 ACI를 추가해야 합니다.

관리 서버의 NetscapeRoot 하위 트리에는 자체 기본 ACI 집합이 있습니다.

  • 구성 관리자 그룹의 모든 구성원은 프록시 권한을 제외하고 NetscapeRoot 하위 트리에 대한 모든 권한을 가지므로 구성 관리자 그룹에 새 구성원을 추가할 수 있습니다.

  • 모든 사용자는 검색 및 읽기 작업을 위해 NetscapeRoot 하위 트리에 대한 익명 액세스 권한을 갖습니다.

  • 관리 그룹의 구성원은 그룹 확장 ACI를 사용하여 그룹 정의에 액세스할 수 있습니다.

다음 절에서는 이러한 기본 설정을 조직의 요구에 맞게 수정하는 방법에 대해 설명합니다.

ACI 구문

ACI는 다양한 변형이 가능한 복잡한 구조로 이루어져 있습니다. 콘솔 또는 명령줄에서 ACI를 작성하고 수정하는 경우 LDIF 형식의 ACI 구문을 명확히 이해해야 합니다. ACI 구문에 대해서는 다음 절에서 자세히 설명합니다.


팁

ACI는 매우 복잡하기 때문에 Directory Server 콘솔에서 모든 ACI를 시각적으로 편집할 수는 없습니다. 또한 다수의 디렉토리 항목에 대한 액세스 제어를 설정하는 경우 명령줄을 사용하는 것이 훨씬 빠릅니다. 따라서 ACI 구문을 명확히 이해해야만 효과적인 액세스 제어가 설정된 보안 디렉토리를 작성할 수 있습니다.

aci 속성 구문은 다음과 같습니다.

aci: (target)(version 3.0;acl "name";permission bindRules;)

여기서,

  • target은 액세스를 제어할 항목, 속성 또는 항목과 속성 집합을 지정합니다. 고유 이름이나 하나 이상의 속성, 또는 한 개의 LDAP 필터를 대상으로 지정할 수 있습니다. 대상은 선택 사항으로, 대상을 지정하지 않으면 ACI가 정의된 전체 항목과 모든 자식 항목에 해당 ACI가 적용됩니다.

  • version 3.0은 ACI 버전을 식별하는 필수 문자열입니다.

  • "name"은 ACI의 이름입니다. ACI를 식별하는 모든 문자열은 이름이 될 수 있습니다. ACI 이름은 필수이며 ACI의 결과를 설명하는 이름이어야 합니다.

  • permission은 허용 또는 거부되는 권한(예: 읽기 권한이나 검색 권한)을 구체적으로 열거합니다.

  • bindRules는 액세스 권한을 부여 받기 위해 사용자가 제공해야 하는 자격 증명과 바인드 매개 변수를 지정합니다. 바인드 규칙은 사용자나 그룹 구성원 자격 또는 클라이언트의 연결 등록정보를 기준으로 할 수도 있습니다.

여러 개의 대상과 권한-바인드 규칙 쌍을 지정할 수 있으므로 대상으로 지정되는 항목과 속성을 모두 구체화하여 지정된 대상에 대해 다양한 액세스 제어를 효율적으로 설정할 수 있습니다. 예를 들면 다음과 같습니다.

aci: (target)...(target)(version 3.0;acl "name"; permission bindRule;
 permission bindRule; ...; permission bindRule;)

완성된 LDIF ACI의 예는 다음과 같습니다.

aci: (target="ldap:///uid=bjensen,dc=example,dc=com")(targetattr=*)
 (version 3.0; acl "aci1"; allow (write) userdn="ldap:///self";)

이 예제에서 ACI는 사용자 bjensen이 자신의 디렉토리 항목에 있는 모든 속성을 수정할 수 있는 권한이 있음을 나타냅니다.

다음 절에서는 ACI 각 부분의 구문에 대해 자세히 설명합니다.

대상 정의

대상은 ACI가 어디에 적용되는지 식별합니다. 클라이언트에서 항목의 속성에 대한 작업을 요청하면 서버는 ACI를 평가하여 이 작업을 허용해야 할지 거부해야 할지를 확인하기 위해 대상을 평가합니다. 대상을 지정하지 않으면 ACI는 aci 속성이 있는 항목과 하위 항목의 모든 속성에 적용됩니다.

일반적인 대상 구문은 다음 중 하나를 사용합니다.

(keyword = "expression")

(keyword != "expression")

여기서,

  • keyword는 대상 유형을 나타냅니다. 표 6-1의 키워드는 다음과 같은 대상 유형을 정의합니다.

    • 디렉토리 항목이나 하위 트리

    • 항목 속성

    • LDAP 필터와 일치하는 항목이나 속성 집합

    • LDAP 필터와 일치하는 속성 값이나 값 조합

  • 같음(=)은 대상이 expression에 지정된 개체임을 나타내며, 같지 않음(!=)은 대상이 expression에 지정된 개체가 아님을 나타냅니다.

  • expression은 키워드를 사용하여 대상을 식별하며 인용 부호(" ")로 expression을 묶어야 합니다.

아래 표에는 각 키워드 및 관련된 표현식이 나와 있습니다.

표 6-1    LDIF target 키워드

키워드

유효한 표현식

와일드카드
허용 여부

target

ldap:///distinguished_name

예

targetattr

속성

예

targetfilter

LDAP_filter

예

targattrfilters

LDAP_operation:LDAP_filter

예

디렉토리 항목 대상 지정

특정 디렉토리 항목과 하위 항목을 대상으로 지정하려면 LDAP URL에서 DN과 target 키워드를 사용합니다. 지정된 DN은 ACI가 정의된 항목의 하위 트리에 위치해야 합니다. 대상 표현식 구문은 다음과 같습니다.

(target = "ldap:///distinguished_name")
(target != "ldap:///distinguished_name")

고유 이름은 ACI가 정의된 항목이 루트가 되는 하위 트리에 위치해야 합니다. 예를 들어, ou=People,dc=example,dc=com에 대한 ACI에서는 다음과 같은 대상을 사용할 수 있습니다.

(target = "ldap:///uid=bjensen,ou=People,dc=example,dc=com")


주

액세스 제어 규칙이 적용되는 항목의 DN에 쉼표가 있으면 역슬래시(\)를 사용하여 쉼표를 이스케이프해야 합니다. 예를 들면 다음과 같습니다.

(target="ldap:///uid=cfuentes,o=Example Bolivia\, S.A.")


DN에 와일드카드를 사용하여 LDAP URL과 일치하는 항목을 모두 대상으로 지정할 수도 있습니다. 다음은 와일드카드를 올바로 사용한 예입니다.

  • (target="ldap:///uid=*,dc=example,dc=com")

    • 전체 example.com 트리에서 항목 RDN에 uid 속성이 있는 모든 항목이 대상이 됩니다. 깊이에 관계 없이 트리에 있는 모든 항목이 대상이 되며, 예를 들면 다음과 같습니다.

    uid=tmorris,ou=sales,dc=example,dc=com
    uid=yyorgens,ou=marketing,dc=example,dc=com
    uid=bjensen,ou=eng,ou=east,dc=example,dc=com

  • (target="ldap:///uid=*Anderson,ou=People,dc=example,dc=com")

    • uid가 Anderson으로 끝나는 ou=People 분기의 모든 항목이 대상이 됩니다.

  • (target="ldap:///*Anderson,ou=People,dc=example,dc=com")

    • 이름 지정 속성에 관계 없이 RDN이 Anderson으로 끝나는 ou=People 분기의 모든 항목이 대상이 됩니다.

uid=*,ou=*,dc=example,dc=com에서와 같이 여러 개의 와일드카드를 사용할 수 있습니다. 이 예제에서는 example.com 트리에서 uid 및 ou 속성만 포함된 고유 이름을 가진 모든 항목이 대상이 됩니다.


주

고유 이름의 접미사 부분에는 와일드카드를 사용할 수 없습니다. 즉, 디렉토리에 접미사 c=US와 c=GB를 사용한 경우에는 다음과 같은 대상을 사용하여 두 접미사를 참조할 수 없습니다.

(target="ldap:///dc=example,c=*").

uid=bjensen,o=*.com과 같은 대상을 사용할 수도 없습니다.

속성 대상 지정

디렉토리 항목을 대상으로 지정하는 것 이외에 대상 항목에 있는 하나 이상의 속성 또는 하나 이상의 속성을 제외한 모든 속성을 대상으로 지정할 수도 있습니다. 이 방법은 부분적인 항목 정보에 대한 액세스를 허용하거나 거부할 경우에 유용합니다. 예를 들어 정해진 항목의 이름, 성, 전화 번호 속성에 대해서만 액세스를 허용할 수 있습니다. 또는 개인 데이터와 같은 중요한 정보에 대한 액세스를 거부할 수 있습니다.

대상으로 지정한 속성이 대상 항목이나 하위 트리에 반드시 포함될 필요는 없지만 ACI는 이 속성이 포함되어 있을 때 적용됩니다. 대상으로 지정한 속성은 스키마에 정의하지 않아도 됩니다. 스키마 검사를 사용하지 않으면 데이터와 스키마를 가져오기 전에 액세스 제어 정책을 구현할 수 있습니다.

대상 속성을 지정하려면 targetattr 키워드를 사용하고 속성 이름을 지정합니다. targetattr 키워드에 사용되는 구문은 다음과 같습니다.

(targetattr = "attribute")
(targetattr != "attribute")

targetattr 키워드를 아래 구문으로 사용하면 여러 속성을 대상으로 지정할 수 있습니다.

(targetattr = "attribute1 || attribute2 ... || attributen")
(targetattr != "attribute1 || attribute2 ... || attributen")

예를 들어 항목의 이름, 성, uid 속성을 대상으로 지정하려면 다음과 같은 구문을 사용합니다.

(targetattr = "cn || sn || uid")

대상 속성에는 지정된 속성의 하위 유형이 모두 포함됩니다. 예를 들어, (targetattr = "locality")는 locality;fr도 대상으로 지정합니다. (targetattr = "locality;fr;quebec")와 같이 특별히 하위 유형을 대상으로 지정할 수도 있습니다.

항목과 속성에 의한 대상 지정

기본적으로 targetattr 키워드가 포함된 ACI는 이 ACI가 위치해 있는 항목을 대상으로 지정합니다. 즉, 다음과 같은 ACI를 가정해 보십시오.

aci: (targetattr = "uid")(accessControlRules;)

위의 ACI를 ou=Marketing, dc=example,dc=com 항목에 배치하면 전체 Marketing 하위 트리에 ACI가 적용됩니다. 하지만 다음과 같이 target 키워드를 사용하여 명시적으로 대상을 지정할 수도 있습니다.

aci: (target="ldap:///uid=*,ou=Marketing,dc=example,dc=com")
 (targetattr="uid") (accessControlRules;)

target 키워드와 targetattr 키워드를 지정하는 순서는 중요하지 않습니다.

LDAP 필터를 사용한 항목 또는 속성 대상 지정

LDAP 필터를 사용하여 특정 조건에 맞는 항목 집합을 대상으로 지정할 수 있습니다. 이렇게 하려면 targetfilter 키워드를 LDAP 필터와 함께 사용합니다. ACI가 포함된 항목의 하위 트리에서 필터와 일치하는 모든 항목에 ACI가 적용됩니다.

targetfilter 키워드 구문은 다음과 같습니다.

(targetfilter = "LDAPfilter")

여기서 LDAPfilter는 표준 LDAP 검색 필터입니다. 필터 구문에 대한 자세한 내용은 Sun ONE Directory Server Getting Started Guide의 Chapter 4, "LDAP Search Filters"를 참조하십시오.

예를 들어, 직원을 나타내는 모든 항목에 정규직이나 계약직 상태가 있고, 근무 시간을 나타내는 속성이 상근직 비율로 표시된다고 가정해 보십시오. 계약 직원이나 파트 타임 직원을 나타내는 모든 항목을 대상으로 지정하려면 다음과 같은 필터를 사용합니다.

(targetfilter = "(|(status=contractor)(fulltime<=79))")


주

ACI에서는 국가별 값에 대한 일치 규칙을 설명하는 필터 구문은 지원되지 않습니다. 예를 들어 다음과 같은 대상 필터는 잘못된 것입니다.

(targetfilter = "(locality:fr:=<= Quebec)")

대상 필터는 모든 항목을 ACI의 대상으로 선택합니다. targetfilter 키워드와 targetattr 키워드를 결합하여 대상 항목에 포함된 속성의 부분 집합에 적용되는 ACI를
작성할 수 있습니다.

아래의 LDIF 예제를 사용하면 Engineering Admins 그룹의 모든 구성원이 Engineering 업종에 속한 모든 항목의 departmentNumber 및 manager 속성을 수정할 수 있습니다. 이 예제에서는 LDAP 필터링을 사용하여 businessCategory 속성이 Engineering으로 설정된 모든 항목을 선택합니다.

dn: dc=example,dc=com
objectClass: top
objectClass: organization
aci: (targetattr="departmentNumber || manager")
 (targetfilter="(businessCategory=Engineering)")
 (version 3.0; acl "eng-admins-write"; allow (write)
 groupdn ="ldap:///cn=Engineering Admins, dc=example,dc=com";)


팁

디렉토리에 분포된 속성과 항목을 대상으로 지정할 경우 LDAP 필터가 유용하긴 하지만 필터는 액세스가 관리되는 개체 이름을 직접 지정하지 않으므로 예측할 수 없는 결과가 발생하기도 합니다.
속성을 추가하거나 삭제하면 필터링된 ACI의 대상 항목 집합이 변경되므로 ACI에서 LDAP 필터를 사용하는 경우에는 ldapsearch 작업에 동일한 필터를 사용하여
필터가 올바른 항목과 속성을 대상으로 지정하는지 확인해야 합니다.

LDAP 필터를 사용한 속성 값 대상 지정

액세스 제어를 사용하여 특정 속성 값을 대상으로 지정할 수 있으므로 속성 값이 ACI에 정의된 조건에 부합되는 경우 속성에 대한 권한을 부여하거나 거부할 수 있습니다. 속성 값을 기준으로 액세스 권한을 부여하거나 거부하는 ACI를 값 기반 ACI라고 합니다.

예를 들어, 조직의 모든 사용자에게 자신의 항목에 있는 nsRoleDN 속성을 수정할 수 있는 권한을 부여할 수 있습니다. 하지만 "최상위 수준의 관리자"와 같은 중요 역할은 자신에게 할당할 수 없도록 설정하려고 합니다. 이 경우 LDAP 필터를 사용하여 속성 값 조건을 만족하는지 검사할 수 있습니다.

값 기반 ACI를 작성하려면 targattrfilters 키워드를 다음과 같은 구문으로 사용해야 합니다.

(targattrfilters="add=attr1:F1 && attr2:F2... && attrn:Fn,
                  del=attr1:F1 && attr2:F2 ... && attrn:Fn")

여기서,

    • add는 속성 작성 작업을 나타냅니다.

    • del은 속성 삭제 작업을 나타냅니다.

    • attrn은 대상 속성을 나타냅니다.

    • Fn은 연결된 속성에만 적용되는 필터를 나타냅니다.

항목을 작성하는 경우 필터가 새 항목의 속성에 적용되면 해당 속성의 각 인스턴스가 필터를 만족해야 합니다. 항목을 삭제하는 경우에도 필터가 항목의 속성에 적용되면 해당 속성의 각 인스턴스가 필터를 만족해야 합니다.

항목을 수정하여 속성을 추가하는 경우 해당 속성에 적용되는 추가 필터를 만족해야 하고, 속성을 삭제하는 경우 해당 속성에 적용되는 삭제 필터를 만족해야 합니다. 항목의 개별 속성 값을 바꾸는 경우에는 추가 필터와 삭제 필터를 모두 만족해야 합니다.

예를 들어 다음과 같은 속성 필터를 가정해 보십시오.

(targattrfilters="add=nsroleDN:(!(nsRoleDN=cn=superAdmin)) && telephoneNumber:(telephoneNumber=123*)")

이 필터를 사용하면 사용자가 superAdmin 역할을 제외한 모든 역할(nsRoleDN 속성)을 자신의 항목에 추가할 수 있으며 123 접두어가 있는 전화 번호를 추가할 수도 있습니다.


주

서버 콘솔에서 값 기반 ACI를 작성할 수는 없습니다.


한 개의 디렉토리 항목을 대상으로 지정

한 개의 항목을 대상으로 지정하는 명시적인 방법은 없지만 다음과 같은 대체 방법을 사용할 수 있습니다.

  • 바인드 요청의 사용자 입력을 대상 항목에 저장된 속성 값과 일치시키는 바인드 규칙을 작성합니다. 자세한 내용은 "값 일치에 따른 액세스 정의"를 참조하십시오.

  • targetfilter 키워드를 사용합니다.

targetfilter 키워드를 사용하여 원하는 항목에만 표시되는 속성 값을 지정할 수 있습니다. 예를 들어, 디렉토리 서버를 설치하는 동안 다음과 같은 ACI가 작성됩니다.

aci: (targetattr="*")(targetfilter=(o=NetscapeRoot))(version 3.0;
 acl "Default anonymous access"; allow (read, search)
 userdn="ldap:///anyone";)

이 ACI는 o 속성이 NetscapeRoot 값을 갖는 o=NetscapeRoot 항목에만 적용됩니다.

이러한 방법을 사용할 경우 나중에 디렉토리 트리가 변경되면 이에 따라 ACI를 수정해야 하는 단점이 있습니다.

권한 정의

권한은 허용 또는 거부되는 액세스 유형을 지정합니다. 디렉토리에서 특정 작업을 수행할 수 있는 권한을 허용하거나 거부할 수 있으며, 지정할 수 있는 다양한 작업도 권한이라고 합니다.

권한 설정은 다음 두 단계로 이루어져 있습니다.

  • 액세스 허용 또는 거부

  • 권한 지정

액세스 허용 또는 거부

디렉토리 트리에 대한 액세스 권한을 명시적으로 허용하거나 거부할 수 있습니다. 액세스를 허용하는 경우와 거부하는 경우에 대한 자세한 지침은 Sun ONE Directory Server Deployment Guide의 Chapter 7, "Designing Access Control"을 참조하십시오.


주

서버 콘솔에서는 명시적으로 액세스를 거부할 수 없으며 권한 부여만 가능합니다.

권한 지정

권한은 사용자가 디렉토리 데이터에 대해 수행할 수 있는 특정 작업을 자세히 설명합니다. 모든 권한을 허용 또는 거부하거나 다음 중 하나 이상의 권한을 지정할 수 있습니다.

읽기. 사용자가 디렉토리 데이터를 읽을 수 있는지 여부를 나타냅니다. 이 권한은 검색 작업에만 적용됩니다.

쓰기. 사용자가 속성을 추가, 수정 또는 삭제하여 항목을 수정할 수 있는지 여부를 나타냅니다. 이 권한은 수정 작업과 modrdn 작업에 적용됩니다.

추가. 사용자가 항목을 작성할 수 있는지 여부를 나타냅니다. 이 권한은 추가 작업에만 적용됩니다.

삭제. 사용자가 항목을 삭제할 수 있는지 여부를 나타냅니다. 이 권한은 삭제 작업에만 적용됩니다.

검색. 사용자가 디렉토리 데이터를 검색할 수 있는지 여부를 나타냅니다. 사용자는 검색 및 읽기 권한이 있어야만 검색 결과의 일부로 반환된 데이터를 볼 수 있습니다. 이 권한은 검색 작업에만 적용됩니다.

비교. 사용자가 자신이 제공한 데이터와 디렉토리에 저장된 데이터를 비교할 수 있는지 여부를 나타냅니다. 비교 권한이 있을 경우 디렉토리에서 조회에 응답하여 성공 또는 실패 메시지를 반환하지만 사용자가 항목이나 속성 값을 볼 수는 없습니다. 이 권한은 비교 작업에만 적용됩니다.

자체 쓰기. 사용자가 대상 항목의 속성에 자신의 DN을 추가하거나 삭제할 수 있는지 여부를 나타냅니다. 이 권한은 그룹 관리에만 사용됩니다. 자체 쓰기는 프록시 인증과 함께 작동하여, 그룹 항목에 바인드된 사용자의 DN이 아닌 프록시 DN을 추가하거나 삭제할 수 있는 권한을 부여합니다.

프록시. 지정된 DN이 다른 항목의 권한을 사용하여 대상에 액세스할 수 있는지 여부를 나타냅니다. 디렉토리 관리자 DN을 제외하고 디렉토리의 모든 사용자 DN을 사용한 프록시 액세스 권한을 부여할 수 있습니다. 디렉토리 관리자에게는 프록시 권한을 부여할 수 없습니다. "프록시 인증 ACI 예제"에 자세한 예제가 나와 있습니다. 프록시 액세스에 대한 개요는 Sun ONE Directory Server Deployment Guide를 참조하십시오.

모두. 지정된 DN에 프록시 권한을 제외한 대상 항목에 대한 모든 권한(읽기, 쓰기, 검색, 삭제, 비교 및 자체 쓰기)이 있음을 나타냅니다.

권한은 서로 독립적으로 부여됩니다. 예를 들어, 추가 권한을 가진 사용자는 항목을 작성할 수 있지만 삭제 권한이 특별히 부여되지 않은 경우 항목을 삭제할 수는 없습니다. 따라서 디렉토리에 대한 액세스 제어 정책을 계획할 때는 사용자에게 합리적인 방식으로 권한을 부여해야 합니다. 예를 들어, 읽기 권한과 검색 권한을 부여하지 않고 쓰기 권한만 부여하는 것은 합리적이지 않습니다.

LDAP 작업에 필요한 권한

이 절에서는 사용자에게 허용하려는 LDAP 작업 유형에 따라 부여해야 하는 권한에 대해 설명합니다.

항목 추가

  • 추가할 항목에 대한 추가 권한을 부여합니다.

  • 항목의 각 속성 값에 대한 쓰기 권한을 부여합니다. 이 권한은 기본적으로 부여되지만 targattrfilters 키워드를 사용하여 제한할 수 있습니다.

항목 삭제

  • 삭제할 항목에 대한 삭제 권한을 부여합니다.

  • 항목의 각 속성 값에 대한 쓰기 권한을 부여합니다. 이 권한은 기본적으로 부여되지만 targattrfilters 키워드를 사용하여 제한할 수 있습니다.

항목의 속성 수정

  • 속성 유형에 대한 쓰기 권한을 부여합니다.

  • 각 속성 유형 값에 대한 쓰기 권한을 부여합니다. 이 권한은 기본적으로 부여되지만 targattrfilters 키워드를 사용하여 제한할 수 있습니다.

항목의 RDN 수정

  • 항목에 대한 쓰기 권한을 부여합니다.

  • 새 RDN에 사용된 속성 유형에 대한 쓰기 권한을 부여합니다.

  • 이전 RDN을 삭제할 수 있는 권한을 부여하려면 이전 RDN에 사용된 속성 유형에 대한 쓰기 권한을 부여합니다.

  • 새 RDN에 사용된 속성 유형 값에 대한 쓰기 권한을 부여합니다. 이 권한은 기본적으로 부여되지만 targattrfilters 키워드를 사용하여 제한할 수 있습니다.

속성 값 비교

  • 속성 유형에 대한 비교 권한을 부여합니다.

항목 검색

  • 검색 필터에 사용된 각 속성 유형에 대한 검색 권한을 부여합니다.

  • 항목에 사용된 속성 유형에 대한 읽기 권한을 부여합니다.

예제를 통해 살펴보면 사용자가 디렉토리를 검색할 수 있도록 허용하기 위해 설정해야 하는 권한을 명확히 이해할 수 있습니다. 아래의 ldapsearch 작업을 가정해 보십시오.

% ldapsearch -h host -s suffix -b "uid=bjensen,dc=example,dc=com" \
             objectclass=* mail

bkolics 사용자에게 액세스 권한을 부여할 수 있는지 확인하려면 아래 ACI를 사용합니다.

aci: (targetattr = "mail")(version 3.0; acl "self access to mail";
 allow (read, search) userdn = "ldap:///self";)

이 ACI는 objectclass 속성에 대한 액세스를 부여하지 않기 때문에 빈 검색 결과 목록이 표시됩니다. 위에서 설명한 검색 작업이 성공하려면 ACI를 다음과 같이 수정해야 합니다.

aci: (targetattr = "mail || objectclass")(version 3.0; acl "self
 access to mail"; allow (read, search) userdn = "ldap:///self";)

권한 구문

ACI 명령문의 권한 구문은 다음과 같습니다.

allow|deny (rights)

여기서 rights는 쉼표로 구분된 1-8자의 키워드 목록으로 각 키워드는 괄호로 묶여 있습니다.
유효한 키워드는 read, write, add, delete, search, compare, selfwrite, proxy 또는 all입니다.

아래 예제에서는 바인드 규칙이 참일 경우 읽기, 검색 및 비교 액세스가 허용됩니다.

aci: (target="ldap:///dc=example,dc=com") (version 3.0;acl "example";
 allow (read, search, compare) bindRule;)

바인드 규칙

특정 작업의 경우 디렉토리에 정의된 ACI에 따라 디렉토리에 바인드해야 합니다. 바인드란 바인드 DN과 암호(SSL을 사용하는 경우에는 인증서)를 제공하여 디렉토리에 로그인하거나 자체 인증하는 것을 의미합니다. 바인드 작업에 제공된 자격 증명과 바인드 환경에 따라 디렉토리에 대한 액세스의 허용 여부가 결정됩니다.

ACI에 설정된 각 권한에는 필수 인증서와 바인드 매개 변수를 자세히 설명하는 해당 바인드 규칙이 있습니다.

단순한 바인드 규칙은 디렉토리에 액세스하는 사람이 특정 그룹에 속해야 한다는 것만 지정할 수 있습니다. 보다 복잡한 바인드 규칙은 이 사람이 특정 그룹에 속해야 하며 오전 8시부터 오후 5시 사이에 특정 IP 주소의 시스템에서 로그인해야 한다고 지정할 수 있습니다.

바인드 규칙은 디렉토리에 액세스할 수 있는 사람, 액세스 시기 및 장소를 정의합니다. 보다 구체적으로, 바인드 규칙은 다음과 같은 항목을 지정할 수 있습니다.

  • 액세스 권한이 있는 사용자, 그룹 및 역할

  • 항목의 바인드 위치

  • 바인드 시간 또는 요일

  • 바인드 중에 사용해야 하는 인증 유형

또한 부울 연산자로 이러한 조건을 결합하여 복잡한 바인드 규칙을 구성할 수 있습니다. 자세한 내용은 "부울 바인드 규칙 사용"을 참조하십시오.

서버는 RFC 2251 Lightweight Directory Access Protocol (v3)에 설명된 것처럼 LDAP 필터 평가에 사용되는 논리와 유사한 3개 값 논리에 따라 ACI에 사용된 논리 표현식을 평가합니다. 즉, 자원 제한으로 인해 표현식 평가가 중단된 경우처럼 표현식의 구성 요소가 "정의되지 않음"으로 평가되어도 서버에서 이를 올바로 처리합니다. "정의되지 않음" 값이 복잡한 부울 표현식에서 발생했으므로 액세스 권한이 잘못 부여되지는 않습니다.

바인드 규칙 구문

액세스 허용 여부는 ACI의 바인드 규칙이 참인지 여부에 따라 결정됩니다. 바인드 규칙은 다음 두 가지 패턴 중 하나를 사용합니다.

keyword = "expression";

keyword != "expression";

여기서 같음(=)은 바인드 규칙이 참이 되려면 keyword와 expression이 일치해야 한다는 것을 나타내고, 같지 않음(!=)은 keyword와 expression이 일치하지 않아야 한다는 것을 나타냅니다.


주

timeofday 키워드는 부등식(<, <=, >, >=)도 지원합니다. 부등식은 이 키워드에서만 지원됩니다.

expression은 인용 부호("")로 묶고 세미콜론(;)으로 구분해야 합니다. 사용할 수 있는 표현식은 관련 keyword에 따라 달라집니다.

아래 표에는 각 키워드 및 관련 표현식이 나와 있으며 표현식에 와일드카드를 사용할 수 있는지 여부도 표시되어 있습니다.

표 6-2    LDIF 바인드 규칙 키워드 

키워드

유효한 표현식

와일드카드 허용 여부

userdn

ldap:///distinguished_name
ldap:///all
ldap:///anyone
ldap:///self
ldap:///parent
ldap:///suffix??sub?(filter)

예, DN에서만

groupdn

ldap:///DN || DN

아니요

roledn

ldap:///DN || DN

아니요

userattr

attribute#bindType 또는
attribute#value

아니요

ip

IP_address

예

dns

DNS_host_name

예

dayofweek

sun
mon
tue
wed
thu
fri
sat

아니요

timeofday

0 - 2359

아니요

authmethod

none
simple
ssl
sasl authentication_method

아니요

다음 절에서는 각 키워드의 바인드 규칙 구문에 대해 자세히 설명합니다.

사용자 액세스 정의 - userdn 키워드

사용자 액세스는 userdn 키워드를 사용하여 정의됩니다. userdn 키워드에는 다음 형식의 유효한 고유 이름이 하나 이상 있어야 합니다.

userdn = "ldap:///dn [|| ldap:///dn]...[||ldap:///dn]"

여기서 dn은 DN일 수도 있고 anyone, all, self 또는 parent 표현식 중 하나일 수도 있습니다. 표현식은 다음과 같은 사용자를 참조합니다.

  • userdn = "ldap:///anyone" - 익명 사용자와 인증된 사용자를 모두 참조합니다.

  • userdn = "ldap:///all" - 인증된 사용자만 참조합니다.

  • userdn = "ldap:///self" - ACI의 대상 항목과 동일한 사용자만 참조합니다.

  • userdn = "ldap:///parent" - ACI 대상의 부모 항목만 참조합니다.

userdn 키워드는 다음과 같은 형식의 LDAP 필터로 표현할 수도 있습니다.

ldap:///suffix??sub?(filter)


주

DN에 쉼표가 있으면 쉼표 앞에 역슬래시(\) 이스케이프 문자를 사용해야 합니다.

익명 액세스(anyone 키워드)

디렉토리에 대한 익명 액세스를 부여하면 바인드 DN이나 암호를 제공하지 않아도 바인드 상황에 관계 없이 모든 사람이 디렉토리에 액세스할 수 있습니다. 익명 액세스를 특정 유형의 액세스(예: 읽기 액세스 또는 검색 액세스)로 제한하거나 디렉토리의 개별 항목이나 특정 하위 트리로 제한할 수 있습니다. anyone 키워드를 사용한 익명 액세스는 인증된 모든 사용자의 액세스도 허용합니다.

일반 액세스(all 키워드)

바인드 규칙을 사용하여 특정 권한이 디렉토리에 성공적으로 바인드한 모든 사람에게 적용됨을 나타낼 수 있습니다. 이 경우 all 키워드는 인증된 모든 사용자의 액세스를 허용하므로 익명 액세스를 방지하는 동시에 일반 액세스를 허용할 수 있습니다.

자체 액세스(self 키워드)

사용자에게 자신의 항목에 대한 액세스 권한이 부여되거나 거부되도록 지정합니다. 이 경우 바인드 DN이 대상 항목의 DN과 일치하면 액세스 권한이 부여되거나 거부됩니다.

부모 액세스(parent 키워드)

바인드 DN이 대상 항목의 부모인 경우에만 사용자에게 항목에 대한 액세스 권한이 부여되거나 거부되도록 지정합니다. parent 키워드를 사용하려면 서버 콘솔에서 수동으로 ACI를 편집해야 합니다.

LDAP URL

다음과 같이 URL을 필터와 함께 사용하여 ACI에서 동적으로 사용자를 지정할 수 있습니다.

userdn = "ldap:///<suffix>??sub?(filter)"

예를 들어, example.com 트리의 accounting 분기와 engineering 분기에 있는 모든 사용자는 다음 URL을 기준으로 대상 자원에 대한 액세스 권한이 동적으로 부여되거나 거부됩니다.

userdn = "ldap:///dc=example,dc=com??sub?(|(ou=engineering)(ou=accounting))"


주

LDAP URL에 호스트 이름이나 포트 번호를 지정하지 마십시오. LDAP URL은 항상 로컬 서버에 적용됩니다.

LDAP URL에 대한 자세한 내용은 Sun ONE Directory Server Getting Started Guide의 해당 장을 참조하십시오.

와일드카드

와일드카드 문자(*)를 사용하여 사용자 집합을 지정할 수도 있습니다. 예를 들어, 사용자 DN을 uid=u*,dc=example,dc=com으로 지정하면 바인드 DN이 u 문자로 시작하는 사용자에게만 설정된 권한을 기준으로 액세스 권한이 부여되거나 거부됩니다.

사용자 액세스 권한은 서버 콘솔의 액세스 제어 편집기에서 설정합니다. 자세한 내용은 "콘솔에서 ACI 작성"을 참조하십시오.

예

이 절에서는 userdn 구문의 예를 소개합니다.

LDAP URL이 포함된 userdn 키워드

userdn = "ldap:///uid=*,dc=example,dc=com";

사용자가 지정된 패턴의 고유 이름을 사용하여 디렉토리에 바인드하면 바인드 규칙은 참이 됩니다. 예를 들어 아래의 두 바인드 DN은 모두 참으로 평가됩니다.

uid=ssarette,dc=example,dc=com
uid=tjaz,ou=Accounting,dc=example,dc=com

반면에 아래의 바인드 DN은 거짓으로 평가됩니다.

cn=Babs Jensen,dc=example,dc=com

LDAP URL의 논리적 OR이 포함된 userdn 키워드

userdn="ldap:///uid=bj,c=example.com || ldap:///uid=kc,dc=example,dc=com";

클라이언트가 제공된 두 개의 고유 이름 중 하나로 바인드하면 바인드 규칙은 참이 됩니다.

특정 LDAP URL을 제외한 userdn 키워드

userdn != "ldap:///uid=*,ou=Accounting,dc=example,dc=com";

클라이언트가 accounting 하위 트리에 있는 UID 기반의 고유 이름으로 바인드하지 않으면 바인드 규칙은 참이 됩니다. 이 바인드 규칙은 대상 항목이 디렉토리 트리에서 accounting 분기 이외의 위치에 있는 경우에만 적용됩니다.

self 키워드가 포함된 userdn 키워드

userdn = "ldap:///self";

사용자가 디렉토리에 바인드할 때 사용한 DN에 해당하는 항목에 액세스하면 바인드 규칙은 참이 됩니다. 즉, 사용자가 uid=ssarette, dc=example,dc=com으로 바인드한 경우 uid=ssarette,dc=example,dc=com 항목에 대한 작업을 시도하면 바인드 규칙은 참이 됩니다.

예를 들어, example.com 트리의 모든 사용자에게 userPassword 속성에 대한 쓰기 액세스 권한을 부여하려면 dc=example,dc=com 노드에 아래 ACI를 작성합니다.

aci: (targetattr = "userPassword") (version 3.0;
 acl "write-self"; allow (write) userdn = "ldap:///self";)

all 키워드가 포함된 userdn 키워드

userdn = "ldap:///all";

바인드 DN이 유효하면 바인드 규칙은 참이 됩니다. 즉, 사용자가 바인드 작업 중에 유효한 고유 이름과 암호를 제공한 경우에만 바인드 규칙이 참이 됩니다.

예를 들어, 모든 인증된 사용자에게 전체 트리에 대한 읽기 액세스 권한을 부여하려면 dc=example,dc=com 노드에 아래 ACI를 작성합니다.

aci: (version 3.0; acl "all-read"; allow (read)
 userdn="ldap:///all";)

anyone 키워드가 포함된 userdn 키워드

userdn = "ldap:///anyone";

이 바인드 규칙은 모든 사람에 대해 참이 되므로 디렉토리에 대한 익명 액세스를 제공하려면 이 키워드를 사용합니다.

예를 들어, 전체 example.com 트리에 대한 익명 읽기 및 검색 액세스를 허용하려면 dc=example,dc=com 노드에 아래 ACI를 작성합니다.

aci: (version 3.0; acl "anonymous-read-search";
 allow (read, search) userdn = "ldap:///anyone";)

parent 키워드가 포함된 userdn 키워드

userdn = "ldap:///parent";

바인드 DN이 대상 항목의 부모이면 바인드 규칙은 참이 됩니다.

예를 들어, 모든 사용자의 자식 항목에 대한 쓰기 액세스 권한을 부여하려면 dc=example,dc=com 노드에 아래 ACI를 작성합니다.

aci: (version 3.0; acl "parent access";
 allow (write) userdn="ldap:///parent";)

사용자가 engineering 또는 sales 하위 트리에 속하면 바인드 규칙은 참이 됩니다.

그룹 액세스 정의 - groupdn 키워드

특정 그룹의 구성원이 대상 자원에 액세스하는 것을 그룹 액세스라고 합니다. 사용자가 특정 그룹에 속한 DN을 사용하여 바인드할 경우 대상 항목에 대한 액세스가 부여되거나 거부되도록 지정하려면 groupdn 키워드를 사용하여 그룹 액세스를 정의합니다.

groupdn 키워드에는 다음과 같은 형식의 유효한 고유 이름이 하나 이상 있어야 합니다.

groupdn="ldap:///dn [|| ldap:///dn]...[|| ldap:///dn]"

바인드 DN이 지정된 그룹에 속하면 바인드 규칙은 참이 됩니다.


주

DN에 쉼표가 있으면 역슬래시(\)를 사용하여 쉼표를 이스케이프해야 합니다.

서버 콘솔에서 액세스 제어 편집기를 사용하여 특정 그룹을 정의할 수 있습니다. 자세한 내용은 "콘솔에서 ACI 작성"을 참조하십시오.

예

이 절에서는 groupdn 구문의 예를 소개합니다.

LDAP URL이 포함된 groupdn 키워드

groupdn = "ldap:///cn=Administrators,dc=example,dc=com";

바인드 DN이 Administrators 그룹에 속하면 바인드 규칙은 참이 됩니다. Administrators 그룹에 전체 디렉토리 트리에 대한 쓰기 권한을 부여하려면 dc=example,dc=com 노드에 아래 ACI를 작성합니다.

aci: (version 3.0; acl "Administrators-write"; allow (write)
 groupdn="ldap:///cn=Administrators,dc=example,dc=com";)

LDAP URL의 논리적 OR이 포함된 groupdn 키워드

groupdn = "ldap:///cn=Administrators,dc=example,dc=com ||
ldap:///cn=Mail Administrators,dc=example,dc=com";

바인드 DN이 Administrators 그룹이나 Mail Administrators 그룹에 속하면 바인드 규칙은 참이 됩니다.

역할 액세스 정의 - roledn 키워드

특정 역할의 구성원이 대상 자원에 액세스하는 것을 역할 액세스라고 합니다. 사용자가 특정 역할에 속한 DN을 사용하여 바인드하는 경우 대상 항목에 대한 액세스 권한이 부여되거나 거부되도록 지정하려면 roledn 키워드를 사용하여 역할 액세스를 정의합니다.

roledn 키워드에는 다음 형식의 유효한 고유 이름이 하나 이상 있어야 합니다.

roledn = "ldap:///dn [|| ldap:///dn]... [|| ldap:///dn]"

바인드 DN이 지정된 역할에 속하면 바인드 규칙은 참이 됩니다.


주

DN에 쉼표가 있으면 역슬래시(\)를 사용하여 쉼표를 이스케이프해야 합니다.

roledn 키워드는 groupdn 키워드와 동일한 구문으로 사용됩니다.

값 일치에 따른 액세스 정의

디렉토리에 바인드하는 데 사용되는 항목의 속성 값이 대상 항목의 속성 값과 일치하도록 지정하는 바인드 규칙을 설정할 수 있습니다.

예를 들어, 바인드 DN이 사용자 항목의 manager 속성에 있는 DN과 일치할 경우에만 ACI를 적용하도록 지정할 수 있습니다. 이 경우 사용자의 관리자만 항목에 액세스할 수 있습니다.

이 예제는 DN 일치를 기준으로 하지만 바인드에 사용된 항목의 모든 속성을 대상 항목과 일치시킬 수 있습니다. 예를 들어, favoriteDrink 속성이 "beer"인 사용자가 동일한 favoriteDrink 값을 갖는 다른 사용자의 모든 항목을 읽을 수 있도록 허용하는 ACI를 작성할 수 있습니다

userattr 키워드 사용

userattr 키워드를 사용하여 바인드에 사용된 항목과 대상 항목 간에 일치시킬 속성 값을 지정할 수 있습니다.

다음과 같은 속성 값을 지정할 수 있습니다.

  • 사용자 DN

  • 그룹 DN

  • 역할 DN

  • LDAP URL의 LDAP 필터

  • 모든 속성 유형

userattr 키워드의 LDIF 구문은 다음과 같습니다.

userattr = "attrName#bindType"

사용자 DN, 그룹 DN, 역할 DN이나 LDAP 필터 이외의 값이 필요한 속성 유형을 사용하는 경우 LDIF 구문은 다음과 같습니다.

userattr = "attrName#attrValue"

여기서,

  • attrName은 값 일치에 사용되는 속성 이름입니다.

  • bindType은 USERDN,GROUPDN,LDAPURL 중 하나입니다.

  • attrValue는 속성 값을 나타내는 문자열입니다.


주

서비스 클래스(CoS) 정의에서 생성된 속성은 userattr 키워드와 함께 사용할 수 없습니다. 이 경우 CoS에서 생성된 속성 값을 사용하는 바인드 규칙이 포함된 ACI가 작동하지 않습니다.

다음 절에는 userattr 키워드를 다양한 바인드 유형과 함께 사용하는 예를 소개합니다.

USERDN 바인드 유형을 사용한 예

사용자 DN을 기준으로 하는 바인드에 사용된 userattr 키워드의 예는 다음과 같습니다.

userattr = "manager#USERDN"

바인드 DN이 대상 항목의 manager 속성 값과 일치하면 바인드 규칙은 참이 됩니다. 이 메커니즘을 사용하면 사용자의 관리자가 직원의 속성을 수정할 수 있습니다. 이 메커니즘은 대상 항목의 manager 속성이 전체 DN으로 표시된 경우에만 작동합니다.

아래 예제에서는 관리자에게 직원 항목에 대한 전체 액세스 권한을 부여합니다.

aci: (target="ldap:///dc=example,dc=com")(targetattr=*)(version 3.0;
 acl "manager-write"; allow (all) userattr = "manager#USERDN";)

GROUPDN 바인드 유형을 사용한 예

그룹 DN을 기준으로 하는 바인드에 사용된 userattr 키워드의 예는 다음과 같습니다.

userattr = "owner#GROUPDN"

바인드 DN이 대상 항목의 owner 속성에 지정된 그룹의 구성원이면 바인드 규칙은 참이 됩니다. 예를 들어, 이 메커니즘을 사용하여 그룹이 직원의 상태 정보를 관리하도록 허용할 수 있습니다. 속성에 그룹 항목의 DN이 포함되어 있으면 owner 이외의 속성을 사용할 수도 있습니다.

사용자가 가리키는 그룹은 동적 그룹일 수 있으며, 그룹 DN은 디렉토리의 모든 접미사에 위치할 수 있습니다. 하지만 서버에서 이 유형의 ACI를 평가하려면 많은 자원이 필요합니다.

대상 항목과 동일한 접미사에 있는 정적 그룹을 사용하는 경우 다음과 같은 표현식을 사용할 수 있습니다.

userattr = "ldap:///dc=example,dc=com?owner#GROUPDN"

이 예제에서 그룹 항목은 dc=example,dc=com 접미사에 있습니다. 이 유형의 구문은 이전 예보다 서버에서 빨리 처리될 수 있습니다.

ROLEDN 바인드 유형을 사용한 예

역할 DN을 기준으로 하는 바인드에 사용된 userattr 키워드의 예는 다음과 같습니다.

userattr = "exampleEmployeeReportsTo#ROLEDN"

바인드 DN이 대상 항목의 exampleEmployeeReportsTo 속성에 지정된 역할에 속하면 바인드 규칙은 참이 됩니다. 예를 들어, 회사의 모든 관리자에 대해 중첩된 역할을 작성할 경우 이 메커니즘을 사용하여 모든 수준의 관리자가 자신보다 등급이 낮은 직원에 대한 정보에 액세스할 수 있도록 액세스 권한을 부여할 수 있습니다.

역할 DN은 디렉토리의 모든 접미사에 위치할 수 있습니다. 또한 필터링된 역할을 사용하는 경우 이 유형의 ACI를 평가하려면 많은 서버 자원이 필요합니다.

LDAPURL 바인드 유형을 사용한 예

LDAP 필터를 기준으로 하는 바인드에 사용된 userattr 키워드의 예는 다음과 같습니다.

userattr = "myfilter#LDAPURL"

바인드 DN이 대상 항목의 myfilter 속성에 지정된 필터와 일치하면 바인드 규칙은 참이 됩니다. myfilter 속성을 LDAP 필터가 포함된 속성으로 바꿀 수 있습니다.

속성 값이 있는 예

속성 값을 기준으로 하는 바인드에 사용된 userattr 키워드의 예는 다음과 같습니다.

userattr = "favoriteDrink#Beer"

바인드 DN과 대상 DN에 포함된 favoriteDrink 속성 값이 Beer이면 바인드 규칙은 참이 됩니다

상속 기능과 함께 userattr 키워드 사용

userattr 키워드를 사용하여 바인드에 사용된 항목을 대상 항목과 연결하면 ACI는 지정된 대상에만 적용되고 하위 항목에는 적용되지 않습니다. ACI의 응용을 대상 항목보다 몇 수준 아래까지 확장하려는 경우 parent 키워드를 사용하고 ACI를 상속할 대상 아래의 수준 수를 지정합니다.

userattr 키워드를 parent 키워드와 함께 사용하는 구문은 다음과 같습니다.

userattr = "parent[inheritance_level].attribute#bindType"

조건:

  • inheritance_level은 ACI를 상속할 대상 아래의 수준 수를 나타내는 쉼표로 구분된 목록입니다. 대상 항목 아래에 5개 수준[0,1,2,3,4]을 포함할 수 있으며 제로(0)는 대상 항목을 나타냅니다.

  • attribute는 userattr 키워드나 groupattr 키워드로 지정되는 대상 속성입니다.

  • bindType은 USERDN이나 GROUPDN입니다. LDAPURL과 ROLEDN 바인드 유형에는 상속 기능이 지원되지 않습니다.

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

userattr = "parent[0,1].manager#USERDN"

바인드 DN이 대상 항목의 manager 속성과 일치하면 이 바인드 규칙은 참이 됩니다. 바인드 규칙이 참으로 평가될 때 부여된 권한은 대상 항목 및 바로 아래의 모든 항목에 적용됩니다.

userattr 상속을 사용한 예

아래 그림의 예제에서는 bjensen 사용자가 cn=Profiles 항목 및 cn=mail과 cn=news가 포함된 첫 수준의 자식 항목을 읽고 검색할 수 있으므로 자신의 우편 및 뉴스 ID 검색이 허용됨을 나타냅니다.

그림 6-1    상속 기능과 함께 userattr 키워드 사용

이 예제에서 상속을 사용하지 않은 경우 동일한 결과를 얻으려면 다음 중 하나를 수행해야 합니다.

  • 디렉토리의 cn=Profiles, cn=mail 및 cn=news 항목에 bjensen 사용자에 대해 읽기 및 검색 액세스 권한을 명시적으로 설정합니다.

  • bjensen 값을 가진 owner 속성을 cn=mail 및 cn=news 항목에 추가한 다음 cn=mail 및 cn=news 항목에 아래 ACI를 추가합니다.

    • aci: (targetattr="*") (version 3.0; acl "profiles access"; allow
     (read,search) userattr="owner#USERDN";)

userattr 키워드를 사용한 추가 권한 부여

userattr 키워드를 all 또는 add 권한과 함께 사용하면 서버가 예상과 달리 작동할 수 있습니다. 일반적으로 Directory Server는 디렉토리에 새 항목을 작성할 때 부모 항목이 아닌 작성되는 항목에 대한 액세스 권한을 평가합니다. 하지만 userattr 키워드를 사용하는 ACI의 경우 이 동작으로 인해 보안 허점이 생길 수 있으므로 정상적인 서버 동작이 수정됩니다.

아래 예제를 가정해 보십시오.

aci: (target="ldap:///dc=example,dc=com")(targetattr=*)(version 3.0;
 acl "manager-write"; allow (all) userattr = "manager#USERDN";)

이 ACI는 관리자에게 보고하는 직원 항목에 대한 모든 권한을 관리자에게 부여합니다. 하지만 이 ACI 유형을 사용할 경우 작성되는 항목에 대해서만 액세스 권한이 평가되므로 모든 직원이 자신의 DN으로 설정된 manager 속성을 가진 항목을 작성할 수도 있습니다. 예를 들어, 불만을 품은 직원인 Joe(cn=Joe,ou=eng,dc=example,dc=com)는 트리의 Human Resources 분기에 항목을 작성하여 Human Resources 직원에게 부여된 권한을 사용(또는 남용)할 수 있습니다.

이 경우 다음과 같은 항목만 작성하면 됩니다.

dn: cn= Trojan Horse,ou=Human Resources,dc=example,dc=com
objectclass: top
...
cn: Trojan Horse
manager: cn=Joe,ou=eng,dc=example,dc=com

이러한 보안 문제를 방지하기 위해 ACI 평가 프로세스는 수준 0, 즉 항목 자체에 대한 추가 권한을 부여하지 않습니다. 하지만 parent 키워드를 사용하여 기존 항목 아래에 추가 권한을 부여할 수 있습니다. 이 경우 추가 권한에 대한 부모 아래의 수준 수를 지정해야 합니다. 예를 들어, 아래 ACI에서는 manager 속성이 바인드 DN과 일치하는 dc=example,dc=com의 모든 항목에 자식 항목을 추가할 수 있습니다.

aci: (target="ldap:///dc=example,dc=com")(targetattr=*)
 (version 3.0; acl "parent-access"; allow (add)
 userattr = "parent[0,1].manager#USERDN";)

이 ACI를 사용하면 바인드 DN이 부모 항목의 manager 속성과 일치하는 사용자에게만 추가 권한이 부여됩니다.

특정 IP 주소로부터의 액세스 정의

바인드 규칙을 사용하여 바인드 작업이 반드시 특정 IP 주소로부터 시작되도록 지정할 수 있습니다. 이 액세스 정의는 주로 특정 시스템이나 네트워크 도메인에서 모든 디렉토리 업데이트를 수행하도록 강제하는 데 사용됩니다.

IP 주소를 기준으로 바인드 규칙을 설정하는 LDIF 구문은 다음과 같습니다.

ip = "IPaddressList" or ip != "IPaddressList"

IPaddressList는 다음 중 하나 이상의 요소가 쉼표로 구분된 목록입니다.

  • 특정 IPv4 주소: 123.45.6.7

  • 와일드카드를 사용하여 서브네트워크를 지정한 IPv4 주소: 12.3.45.*

  • 서브네트워크 마스크가 있는 IPv4 주소 또는 서브네트워크: 123.45.6.*+255.255.255.115

  • RFC 2373(http://www.ietf.org/rfc/rfc2373.txt)에 정의된 올바른 형식의 IPv6 주소. 다음은 모두 동일한 주소를 나타냅니다.

    • 12AB:0000:0000:CD30:0000:0000:0000:0000

    • 12AB::CD30:0:0:0:0

    • 12AB:0:0:CD30::

  • 서브넷 접두어 길이가 있는 IPv6 주소: 12AB::CD30:0:0:0:0/60

디렉토리에 액세스하는 클라이언트가 지정된 IP 주소에 위치해 있으면 바인드 규칙은 참이 됩니다. 이 메커니즘은 특정 서브넷 또는 시스템으로부터의 특정 디렉토리 액세스만 허용하는 경우에 유용합니다.

서버 콘솔의 액세스 제어 편집기를 사용하여 ACI가 적용되는 특정 시스템을 정의할 수 있습니다. 자세한 내용은 "콘솔에서 ACI 작성"을 참조하십시오.

특정 도메인으로부터의 액세스 정의

바인드 규칙은 바인드 작업이 반드시 특정 도메인이나 호스트 시스템으로부터 시작되도록 지정할 수 있습니다. 이 액세스 정의는 주로 특정 시스템이나 네트워크 도메인에서 모든 디렉토리 업데이트를 수행하도록 강제하는 데 사용됩니다.

DNS 호스트 이름을 기준으로 바인드 규칙을 설정하는 LDIF 구문은 다음과 같습니다.

dns = "DNS_Hostname" or dns != "DNS_Hostname"


주의

dns 키워드를 사용하려면 시스템에서 DNS를 이름 지정 서비스로 사용해야 합니다. DNS를 이름 지정 서비스로 사용하지 않는 경우에는 ip 키워드를 사용해야 합니다.

dns 키워드에는 전체 DNS 도메인 이름을 지정해야 합니다. 도메인을 지정하지 않고 호스트에 대한 액세스 권한을 부여하면 보안 문제가 발생할 수 있습니다.
예를 들어, 아래 표현식은 사용할 수는 있지만 바람직하지 않습니다.

dns = "legend.eng";

이 경우 다음과 같은 정규화된 이름을 사용해야 합니다.

dns = "legend.eng.example.com";

dns 키워드에는 와일드카드를 사용할 수 있습니다. 예를 들면 다음과 같습니다.

dns = "*.example.com";

디렉토리에 액세스하는 클라이언트가 지정된 도메인에 위치해 있으면 바인드 규칙은 참이 됩니다. 이 메커니즘은 특정 도메인으로부터의 액세스만 허용하는 경우에 유용합니다. 시스템에서 DNS 이외의 이름 지정 서비스를 사용하면 와일드카드는 작동하지 않습니다. 이 경우 액세스를 특정 도메인으로 제한하려면 "특정 IP 주소로부터의 액세스 정의"에 설명된 것처럼 ip 키워드를 사용합니다.

특정 시간 또는 요일의 액세스 정의

특정 시간이나 특정 요일에만 바인드할 수 있도록 바인드 규칙을 지정할 수 있습니다. 예를 들어, 월요일부터 금요일까지 오전 8시와 오후 5시 사이에만 액세스를 허용하는 규칙을 설정할 수 있습니다. 액세스 권한 평가에 사용되는 시간은 클라이언트 시간이 아닌 디렉토리 서버 시간입니다.

시간을 기준으로 바인드 규칙을 설정하는 LDIF 구문은 다음과 같습니다.

timeofday operator "time"

여기서 operator는 같음(=), 같지 않음(!=), 보다 큼(>), 크거나 같음(>=), 보다 작음(<), 작거나 같음(<=) 중 하나입니다.

timeofday 키워드에는 24시간 시계의 시간과 분으로 표시된 시간(0 - 2359)을 지정해야 합니다.


주

평가에 사용되는 시간은 클라이언트 시간이 아닌 디렉토리 서버 시간입니다.

요일을 기준으로 바인드 규칙을 설정하는 LDIF 구문은 다음과 같습니다.

dayofweek = "day1, day2 ..."

dayofweek 키워드에는 요일을 나타내는 3자의 영문 약어(sun, mon, tue, wed, thu, fri, sat)를 지정합니다.

예

timeofday 및 dayofweek 구문의 예는 다음과 같습니다.

timeofday = "1200";

클라이언트가 12시 정각에 디렉토리에 액세스하면 바인드 규칙은 참이 됩니다.

timeofday != "0100";

클라이언트가 오전 1시 이외의 시간에 디렉토리에 액세스하면 바인드 규칙은 참이 됩니다.

timeofday > "0800";

클라이언트가 오전 8시 이후에 디렉토리에 액세스하면 바인드 규칙은 참이 됩니다.

timeofday < "1800";

클라이언트가 오후 6시 전에 디렉토리에 액세스하면 바인드 규칙은 참이 됩니다.

timeofday >= "0800";

클라이언트가 오전 8시 이후에 디렉토리에 액세스하면 바인드 규칙은 참이 됩니다.

timeofday <= "1800";

클라이언트가 오후 6시 이전에 디렉토리에 액세스하면 바인드 규칙은 참이 됩니다.

dayofweek = "Sun, Mon, Tue";

클라이언트가 일요일, 월요일 또는 화요일에 디렉토리에 액세스하면 바인드 규칙은 참이 됩니다.

인증 방법에 따른 액세스 정의

클라이언트가 특정 인증 방법을 사용하여 디렉토리에 바인드하도록 바인드 규칙을 설정할 수 있습니다. 사용할 수 있는 인증 방법은 다음과 같습니다.

  • 없음 - 인증이 필요 없습니다. 이것이 기본값이며 익명 액세스를 나타냅니다.

  • 단순 - 클라이언트가 디렉토리에 바인드하려면 사용자 이름과 암호를 제공해야 합니다.

  • SSL - 클라이언트가 SSL(Secure Sockets Layer)이나 TLS(Transport Layer Security) 연결을 통해 디렉토리에 바인드해야 합니다.

    • SSL은 LDAPS 제2 포트에 연결되고 TLS은 TLS 시작 작업을 통해 연결됩니다. 두 경우 모두 인증서를 제공해야 합니다. SSL 설정에 대한 자세한 내용은 11장 "보안 구현을 참조하십시오.

  • SASL - 클라이언트가 SASL(Simple Authentication and Security Layer) 연결을 통해 디렉토리에 바인드해야 합니다. Sun ONE Directory Server에서는 SASL 모듈을 제공하지 않습니다.

인증 기반의 바인드 규칙은 액세스 제어 편집기에서 설정할 수 없습니다.

인증 방법에 따라 바인드 규칙을 설정하는 LDIF 구문은 다음과 같습니다.

authmethod = "authentication_method"

여기서 authentication_method는 none, simple, ssl 또는 "sasl sasl_mechanism"입니다.

예

authmethod 키워드의 예는 다음과 같습니다.

authmethod = "none";

바인드 규칙을 평가하는 동안 인증을 검사하지 않습니다.

authmethod = "simple";

클라이언트가 사용자 이름과 암호를 사용하여 디렉토리에 액세스하면 바인드 규칙은 참이 됩니다.

authmethod = "ssl";

클라이언트가 인증서를 사용하여 LDAPS를 통해 디렉토리에 인증하면 바인드 규칙은 참이 됩니다. 클라이언트가 단순 인증(바인드 DN과 암호)을 사용하여 LDAPS를 통해 인증하는 경우에는 참이 아닙니다.

authmethod = "sasl DIGEST-MD5";

클라이언트가 SASL DIGEST-MD5 메커니즘을 사용하여 디렉토리에 액세스하면 바인드 규칙은 참이 됩니다. 지원되는 다른 SASL 메커니즘에는 EXTERNAL과 GSSAPI(Solaris 시스템에서만) 등이 있습니다.

부울 바인드 규칙 사용

부울 연산자인 AND, OR, NOT을 사용하여 세부적인 액세스 규칙을 설정하는 복잡한 바인드 규칙을 작성할 수 있습니다. 서버 콘솔에서는 부울 바인드 규칙이 아닌 LDIF 명령문을 작성해야 합니다.

부울 바인드 규칙을 작성하는 LDIF 구문은 다음과 같습니다.

bindRule [boolean][bindRule][boolean][bindRule]...;)

예를 들어, 바인드 DN이 administrators 그룹이나 mail administrators 그룹 중 하나의 구성원이고 클라이언트가 example.com 도메인에서 실행되면 아래 바인드 규칙은 참이 됩니다.

(groupdn = "ldap:///cn=administrators,dc=example,dc=com" or
groupdn = "ldap:///cn=mail administrators,dc=example,dc=com" and
dns = "*.example.com";)

뒤에 있는 세미콜론(;)은 필수 구분 기호로 최종 바인드 규칙 뒤에 반드시 입력해야 합니다.

부울 표현식은 다음 순서로 평가됩니다.

  • 가장 안쪽의 괄호 표현식에서 가장 바깥쪽 괄호 표현식으로 평가

  • 왼쪽에서 오른쪽으로 평가

  • AND 또는 OR 연산자보다 NOT 연산자부터 평가

부울 연산자 OR 및 AND에는 우선 순위가 없습니다.

다음과 같은 부울 바인드 규칙을 가정해 보십시오.

(bindRule_A) OR (bindRule_B)

(bindRule_B) OR (bindRule_A)

부울 표현식은 왼쪽에서 오른쪽으로 평가하기 때문에 첫 번째 경우에서는 바인드 규칙 A를 평가한 후 바인드 규칙 B를 평가하고, 두 번째 경우에서는 바인드 규칙 B를 평가한 후 바인드 규칙 A를 평가합니다.

하지만 부울 연산자 OR과 AND를 평가하기 전에 부울 연산자 NOT을 먼저 평가합니다. 아래의 예제를 가정해 보십시오.

(bindRule_A) AND NOT (bindRule_B)

이 경우에는 왼쪽에서 오른쪽으로 평가한다는 규칙에 위배되지만 바인드 규칙 B를 먼저 평가한 후에 바인드 규칙 A를 평가합니다.

명령줄에서 ACI 작성

LDIF 명령문을 사용하여 수동으로 액세스 제어 명령을 작성한 다음 ldapmodify 명령을 사용하여 디렉토리 트리에 추가할 수 있습니다. ACI 값은 매우 복잡할 수 있으므로 기존 값을 보고 이를 복사하여 새 값을 작성하는 것이 좋습니다.

aci 속성 값 보기

ACI는 하나 이상의 aci 속성 값으로 항목에 저장됩니다. aci 속성은 디렉토리 사용자가 읽고 수정할 수 있는 여러 값을 갖는 작동 가능 속성으로, 이 속성 자체도 ACI로 보호해야 합니다. 대체로 관리자 사용자는 aci 속성에 대한 전체 액세스 권한을 가지며 다음 중 한 가지 방법으로 속성 값을 볼 수 있습니다.

일반 편집기에서 다른 값과 같은 방식으로 aci 속성 값을 볼 수 있습니다. Directory Server 콘솔의 최상위 수준 "디렉토리" 탭에서 ACI가 있는 항목을 마우스 오른쪽 버튼으로 누르고 "일반 편집기로 편집" 메뉴 항목을 선택합니다. 하지만 aci 값은 대체로 긴 문자열이기 때문에 이 대화 상자에서 보고 편집하기는 어렵습니다.

이 경우에는 디렉토리 트리에서 해당 항목을 마우스 오른쪽 버튼으로 누르고 "액세스 권한 설정" 메뉴 항목을 선택하여 액세스 제어 편집기를 실행할 수 있습니다. ACI 를 선택하고 "편집"을 누른 다음 "수동으로 편집"을 눌러 해당 aci 값을 표시합니다. ACI 수동 편집기와 시각 편집기를 전환하여 aci 값 구문을 구성과 비교할 수 있습니다.

사용 중인 운영 체제에 따라 일반 편집기나 수동 액세스 제어 편집기에서 aci 값을 복사하여 LDIF 파일에 붙여넣을 수 있습니다. 관리자 사용자는 아래의 ldapsearch 명령을 실행하여 항목의 aci 속성을 볼 수도 있습니다.

% ldapsearch -h host -p port -D "cn=Directory Manager" -w password \
             -b entryDN -s base aci

결과는 LDIF 텍스트로 표시되며, 이 텍스트를 새 LDIF ACI 정의에 복사하여 편집할 수 있습니다.


주

aci 값에 따라 부여되거나 거부되는 권한을 확인하려면 "유효 권한 보기"를 참조하십시오.


콘솔에서 ACI 작성

디렉토리에서 aci 속성이 있는 항목을 표시하도록 Directory Server 콘솔을 구성할 수 있습니다. 이 디스플레이를 전환하려면 "보기 > 표시 > ACI 개수" 메뉴 항목을 선택하거나 선택 취소합니다. 최상위 수준 "디렉토리" 탭에 열거된 각 항목 뒤에 해당 aci 속성에 정의된 ACI 수가 표시됩니다. 그런 후에 Directory Server 콘솔을 사용하여 디렉토리에 대한 액세스 제어 명령을 보거나 작성하고 편집 및 삭제할 수 있습니다.

Directory Server 보안 정책에서 일반적으로 사용되는 액세스 제어 규칙 모음과 Directory Server 콘솔을 사용하여 액세스 제어 규칙을 작성하는 단계별 지침은 "액세스 제어 사용 예제"를 참조하십시오.

일부 복잡한 ACI는 시각적 편집 모드의 액세스 제어 편집기에서 구성할 수 없습니다. 특히 액세스 제어 편집기에서 다음과 같은 작업은 수행할 수 없습니다.


팁

액세스 제어 편집기에서 "수동으로 편집" 버튼을 클릭하면 언제든지 그래픽 인터페이스를 통해 변경한 사항을 LDIF 표시로 확인할 수 있습니다.

항목의 ACI 보기

  1. Directory Server 콘솔의 최상위 수준 "디렉토리" 탭에서 디렉토리 트리를 탐색하여 액세스 제어를 설정할 항목을 표시합니다. ACI를 편집하려면 디렉토리 관리자(directory administrator) 또는 디렉토리 관리자(directory manager) 권한이 있어야 합니다.

  2. 항목을 마우스 오른쪽 버튼으로 누르고 팝업 메뉴에서 "액세스 권한 설정"을 선택합니다. 또는 항목을 왼쪽 마우스 버튼으로 눌러 선택한 다음 "개체" 메뉴에서 "액세스 권한 설정"을 선택합니다.

    3. 아래 그림과 같이 "액세스 제어 관리" 대화 상자가 표시됩니다. 이 대화 상자에는 선택한 항목에 정의된 모든 ACI에 대한 설명이 표시되며 ACI를 편집하거나 제거하고 새 ACI를 작성할 수 있습니다.

그림 6-2    액세스 제어 관리 대화 상자

"상속된 ACI 표시" 확인란을 선택한 경우에도 선택한 항목의 부모에 의해 정의된 ACI와 선택한 항목에 적용되는 ACI가 모두 표시됩니다. 하지만 상속된 ACI는 편집하거나 제거할 수 없으므로 해당 ACI가 정의된 항목에서 관리해야 합니다.

  • 선택한 개체와 전체 하위 트리에 대한 새 액세스 권한을 정의하려면 "새로 만들기"를 누릅니다. 아래 그림과 같이 ACI 편집기가 표시됩니다.

    • 그림 6-3    ACI 편집기 대화 상자

    이 대화 상자의 맨 위에 있는 ACI 이름은 ACI에 대한 설명으로 "액세스 제어 관리" 대화 상자에 표시됩니다. ACI를 설명하는 이름을 지정하면 디렉토리에서, 특히 리프 항목에서 상속된 ACI를 볼 때 쉽게 ACI를 관리할 수 있습니다.

    액세스 제어 편집기의 탭을 사용하면 액세스 권한이 부여되거나 거부된 사용자, 액세스 중이거나 액세스가 제한된 대상, 허용된 호스트 이름 및 작동 시간과 같은 고급 매개 변수를 지정할 수 있습니다. "액세스 제어" 탭의 개별 필드에 대한 자세한 내용은 온라인 도움말을 참조하십시오.

    ACI 편집기의 탭은 ACI 값의 내용을 그래픽으로 표시합니다. 텍스트로 ACI 값을 보고 편집하려면 "수동으로 편집"을 누릅니다. 텍스트 편집기에서는 탭에서 정의할 수 없는 고급 ACI를 정의할 수 있습니다. 하지만 ACI 값을 편집한 후에는 고급 기능을 사용하지 않더라도 더 이상 시각적으로 ACI를 편집할 수 없습니다.

    새 ACI 작성

    1. 액세스 제어 편집기를 표시합니다.

      2. 이 작업에 대해서는 "항목의 ACI 보기"에서 설명합니다.

      그림 6-3과 다르게 표시되면 "시각적으로 편집" 버튼을 누릅니다.

    2. "ACI 이름" 텍스트 상자에 이름을 입력하여 ACI를 지정합니다.

      3. ACI를 고유하게 식별하는 문자열을 이름으로 사용할 수 있습니다. 이름을 입력하지 않으면 서버는 unnamed ACI를 사용합니다.

    3. "사용자/그룹" 탭에서 "모든 사용자"를 강조 표시하거나 "추가" 버튼을 눌러 디렉토리에서 추가할 사용자를 검색하여 액세스 권한을 부여할 사용자를 선택합니다.

      4. "사용자 및 그룹 추가" 창에서 다음을 수행합니다.

      1. 드롭다운 목록에서 검색 영역을 선택하고 "검색" 필드에 검색 문자열을 입력한 다음
        "검색" 버튼을 누릅니다.

        2. 아래 목록에 검색 결과가 표시됩니다.

      2. 검색 결과 목록에서 원하는 항목을 강조 표시한 다음 "추가" 버튼을 눌러 액세스 권한이 있는 항목 목록에 추가합니다.

      3. "확인"을 눌러 "사용자 및 그룹 추가" 창을 닫습니다.

        4. 이제 선택한 항목이 ACI 편집기의 "사용자/그룹" 탭에 표시됩니다.

    4. 액세스 제어 편집기에서 "권한" 탭을 누르고 확인란을 사용하여 부여할 권한을 선택합니다.

    5. "대상" 탭을 누른 다음 "이 항목"을 눌러 ACI 대상 노드를 표시합니다.

      6. 대상 DN 값을 변경할 수는 있지만 새 DN은 선택한 항목의 직접 또는 간접 자식이어야 합니다.

      이 노드의 하위 트리에 있는 일부 항목에만 ACI를 적용하려면 "하위 항목의 필터" 필드에 필터를 입력해야 합니다.

      또한 속성 목록에서 대상 속성을 선택하면 특정 속성에만 ACI가 적용되도록 범위를 제한할 수 있습니다.

    6. "호스트" 탭을 누른 다음 "추가" 버튼을 눌러 "호스트 필터 추가" 대화 상자를 표시합니다.

      7. 호스트 이름이나 IP 주소를 지정할 수 있습니다. IP 주소를 지정할 경우 와일드카드 문자(*)를 사용할 수 있습니다.

    7. "시간" 탭을 눌러 액세스 허용 시간을 나타내는 테이블을 표시합니다.

      8. 기본적으로 항상 액세스가 허용됩니다. 테이블을 누른 상태에서 커서를 끌어 액세스 시간을 변경할 수 있습니다. 시간 블록을 개별적으로 선택할 수는 없습니다.

    8. ACI 편집이 끝나면 "확인"을 누릅니다.

      9. ACI 편집기가 닫히고 "ACI 관리자" 창에 새 ACI가 표시됩니다.


    주

    ACI 작성 중에 언제든지 "수동으로 편집" 버튼을 눌러 입력 내용에 해당하는 LDIF 명령문을 표시할 수 있습니다. 이 명령문을 수정할 수는 있지만 변경 사항이 그래픽 인터페이스에 항상 표시되는 것은 아닙니다.

    ACI 편집

    ACI를 편집하려면 다음을 수행합니다.

    1. "디렉토리" 탭의 하위 트리에서 최상위 항목을 마우스 오른쪽 버튼으로 누르고 팝업 메뉴에서 "액세스 권한 설정"을 선택합니다.

      2. "액세스 제어 관리자" 창이 표시됩니다. 이 창에는 해당 항목에 속하는 ACI 목록이 포함되어 있습니다.

    2. "액세스 제어 관리자" 창에서 편집할 ACI를 강조 표시한 다음 "편집"을 누릅니다.

      3. 액세스 제어 편집기가 표시됩니다. 이 대화 상자를 사용하여 편집할 수 있는 정보에 대한 자세한 내용은 온라인 도움말을 참조하십시오.

    3. 액세스 제어 편집기의 여러 탭에서 원하는 항목을 변경합니다.

    4. ACI 편집이 끝나면 "확인"을 누릅니다.

      5. ACI 편집기가 닫히고 "ACI 관리자" 창에 수정된 ACI가 표시됩니다.

    ACI 삭제

    ACI를 삭제하려면 다음을 수행합니다.

    1. "디렉토리" 탭의 하위 트리에서 최상위 항목을 마우스 오른쪽 버튼으로 누르고 팝업 메뉴에서 "액세스 권한 설정"을 선택합니다.

      2. "액세스 제어 관리자" 창이 표시됩니다. 이 창에는 해당 항목에 속하는 ACI 목록이 포함되어 있습니다.

    2. "액세스 제어 관리자" 창에서 삭제할 ACI를 선택합니다.

    3. "제거"를 누릅니다.

      4. 해당 ACI가 액세스 제어 관리자에 표시되지 않습니다.

    액세스 제어 사용 예제

    이 절에서는 가상의 ISP 업체인 example.com에서 액세스 제어 정책을 구현하는 예제를 제공합니다. 모든 예제는 콘솔 및 LDIF 파일을 사용하여 지정된 작업을 수행하는 방법에 대해 설명합니다.

    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" and
     dns="*.example.com";)

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

    콘솔에서 다음을 수행하여 이 권한을 설정할 수 있습니다.

    1. "디렉토리" 탭의 왼쪽 탐색 트리에서 example.com 노드를 마우스 오른쪽 버튼으로 누르고 팝업 메뉴에서 "액세스 권한 설정"을 선택하여 "액세스 제어 관리자"를 표시합니다.

    2. "새로 만들기"를 눌러 "액세스 제어 편집기"를 표시합니다.

    3. "사용자/그룹" 탭의 ACI 이름 필드에 "Anonymous example.com"을 입력합니다. 액세스 권한이 부여된 사용자 목록에 "모든 사용자"가 표시되어 있는지 확인합니다.

    4. "권한" 탭에서 읽기, 비교 및 검색 권한 확인란을 선택합니다. 다른 확인란은 모두 선택 취소해야 합니다.

    5. "대상" 탭에서 "이 항목"을 눌러 대상 디렉토리 항목 필드에 dc=example,dc=com 접미사를 표시합니다. 속성 테이블에서 userPassword 속성을 찾아 해당 확인란을 선택 취소합니다.

      6. 다른 확인란은 모두 선택해야 합니다. 간편하게 이 작업을 수행하려면 "이름" 머리글을 눌러 속성 목록을 알파벳순으로 정렬합니다.

    6. "호스트" 탭에서 "추가"를 누른 다음 DNS 호스트 필터 필드에 *.example.com을 입력합니다. "확인"을 눌러 대화 상자를 닫습니다.

    7. "액세스 제어 편집기" 창에서 "확인"을 누릅니다.

      8. "액세스 제어 관리자" 창의 목록에 새 ACI가 추가됩니다.

    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를 추가한다고 가정합니다. 또한 모든 가입자 항목에 '예'나 '아니요'로 설정된 unlistedSubscriber 속성이 있다고 가정합니다. 대상 정의는 이 속성 값을 기준으로 목록에 없는 가입자를 필터링합니다. 필터 정의에 대한 자세한 내용은 "필터링을 사용한 대상 설정"을 참조하십시오.

    콘솔에서 다음을 수행하여 이 권한을 설정할 수 있습니다.

    1. "디렉토리" 탭의 왼쪽 탐색 트리에서 example.com 노드 아래의 Subscribers 항목을 마우스 오른쪽 버튼으로 누르고 팝업 메뉴에서 "액세스 권한 설정"을 선택하여 "액세스 제어 관리자"를 표시합니다.

    2. "새로 만들기"를 눌러 "액세스 제어 편집기"를 표시합니다.

    3. "사용자/그룹" 탭의 ACI 이름 필드에 "Anonymous World"를 입력합니다. 액세스 권한이 부여된 사용자 목록에 "모든 사용자"가 표시되어 있는지 확인합니다.

    4. "권한" 탭에서 읽기 및 검색 권한 확인란을 선택합니다. 다른 확인란은 모두 선택 취소해야 합니다.

    5. "대상" 탭에서 "이 항목"을 눌러 대상 디렉토리 항목 필드에 dc=subscribers, dc=example,dc=com 접미사를 표시합니다.

      1. 하위 항목 필터 필드에 아래 필터를 입력합니다.

        2. (!(unlistedSubscriber=yes))

      2. 속성 테이블에서 homePhone, homePostalAddress 및 mail 속성에 해당하는 확인란을 선택합니다.

        3. 다른 확인란은 모두 선택 취소해야 합니다. 간편하게 이 작업을 수행하려면 "선택 안 함" 버튼을 눌러 테이블에 있는 모든 속성의 확인란을 선택 취소한 다음, "이름" 머리글을 눌러 속성을 알파벳순으로 정렬하고 해당 속성을 선택합니다.

    6. "확인"을 누릅니다.

      7. "액세스 제어 관리자" 창의 목록에 새 ACI가 추가됩니다.

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

    대부분의 디렉토리 관리자는 내부 사용자가 자신의 항목에 있는 일부 속성만 변경할 수 있도록 설정합니다. example.com의 디렉토리 관리자도 사용자가 자신의 암호, 집 전화 번호 및 집 주소만 변경할 수 있도록 설정하려고 합니다. 여기에 대해서는 ACI "Write example.com" 예제에서 설명합니다.

    또한 example.com의 정책은 가입자가 SSL을 통해 디렉토리에 연결하면 example.com 트리에서 자신의 개인 정보를 업데이트할 수 있도록 허용합니다. 여기에 대해서는 ACI "Write Subscribers" 예제에서 설명합니다.

    ACI "Write example.com"


    주

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

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

    aci: (targetattr="userPassword || homePhone || homePostalAddress")
     (version 3.0; acl "Write example.com"; allow (write) userdn=
     "ldap:///self" and dns="*.example.com";)

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

    콘솔에서 다음을 수행하여 이 권한을 설정할 수 있습니다.

    1. "디렉토리" 탭의 왼쪽 탐색 트리에서 example.com 노드를 마우스 오른쪽 버튼으로 누르고 팝업 메뉴에서 "액세스 권한 설정"을 선택하여 "액세스 제어 관리자"를 표시합니다.

    2. "새로 만들기"를 눌러 "액세스 제어 편집기"를 표시합니다.

    3. "사용자/그룹" 탭의 ACI 이름 필드에 "Write example.com"을 입력합니다. 액세스 권한이 부여된 사용자 목록에서 다음을 수행합니다.

      1. "모든 사용자"를 선택하여 제거한 다음 "추가"를 누릅니다.

        2. "사용자 및 그룹 추가" 대화 상자가 표시됩니다.

      2. "검색 영역"을 "특수 권한"으로 설정하고 "검색 결과" 목록에서 "자신"을 선택합니다.

      3. "추가" 버튼을 눌러 액세스 권한이 부여된 사용자 목록에 "자신"을 추가합니다.

      4. "확인"을 눌러 "사용자 및 그룹 추가" 대화 상자를 닫습니다.

    4. "권한" 탭에서 쓰기 권한 확인란을 선택합니다. 다른 확인란은 모두 선택 취소해야 합니다.

    5. "대상" 탭에서 "이 항목"을 눌러 대상 디렉토리 항목 필드에 dc=example,dc=com 접미사를 표시합니다. 속성 테이블에서 homePhone, homePostalAddress 및 userPassword 속성에 해당하는 확인란을 선택합니다.

      6. 다른 확인란은 모두 선택 취소해야 합니다. 간편하게 이 작업을 수행하려면 "선택 안 함" 버튼을 눌러 테이블에 있는 모든 속성의 확인란을 선택 취소한 다음, "이름" 머리글을 눌러 속성을 알파벳순으로 정렬하고 해당 속성을 선택합니다.

    6. "호스트" 탭에서 "추가"를 눌러 "호스트 필터 추가" 대화 상자를 표시합니다. DNS 호스트 필터 필드에 *.example.com을 입력합니다. "확인"을 눌러 대화 상자를 닫습니다.

    7. "액세스 제어 편집기" 창에서 "확인"을 누릅니다.

      8. "액세스 제어 관리자" 창의 목록에 새 ACI가 추가됩니다.

    ACI "Write Subscribers"


    주

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

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

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

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

    example.com 가입자에게는 집 주소에 대한 쓰기 액세스 권한이 없습니다. 이 속성은 example.com의 필수 결제 정보로 업무상 중요하기 때문에 가입자가 삭제하지 못하도록 액세스가 거부됩니다.

    콘솔에서 다음을 수행하여 이 권한을 설정할 수 있습니다.

    1. "디렉토리" 탭의 왼쪽 탐색 트리에서 example.com 노드 아래의 Subscribers 항목을 마우스 오른쪽 버튼으로 누르고 팝업 메뉴에서 "액세스 권한 설정"을 선택하여 "액세스 제어 관리자"를 표시합니다.

    2. "새로 만들기"를 눌러 "액세스 제어 편집기"를 표시합니다.

    3. "사용자/그룹" 탭의 ACI 이름 필드에 "Write Subscribers"를 입력합니다. 액세스 권한이 부여된 사용자 목록에서 다음을 수행합니다.

      1. "모든 사용자"를 선택하여 제거한 다음 "추가"를 누릅니다.

        2. "사용자 및 그룹 추가" 대화 상자가 표시됩니다.

      2. "검색 영역"을 "특수 권한"으로 설정하고 "검색 결과" 목록에서 "자신"을 선택합니다.

      3. "추가" 버튼을 눌러 액세스 권한이 부여된 사용자 목록에 "자신"을 추가합니다.

      4. "확인"을 눌러 "사용자 및 그룹 추가" 대화 상자를 닫습니다.

    4. "권한" 탭에서 쓰기 확인란을 선택합니다. 다른 확인란은 모두 선택 취소해야 합니다.

    5. "대상" 탭에서 "이 항목"을 눌러 대상 디렉토리 항목 필드에 dc=subscribers, dc=example,dc=com 접미사를 표시합니다.

      1. 하위 항목 필터 필드에 아래 필터를 입력합니다.

        2. (!(unlistedSubscriber=yes))

      2. 속성 테이블에서 homePhone, homePostalAddress 및 mail 속성에 해당하는 확인란을 선택합니다.

        3. 다른 확인란은 모두 선택 취소해야 합니다. 간편하게 이 작업을 수행하려면 "선택 안 함" 버튼을 눌러 테이블에 있는 모든 속성의 확인란을 선택 취소한 다음, "이름" 머리글을 눌러 속성을 알파벳순으로 정렬하고 해당 속성을 선택합니다.

    6. SSL을 사용하여 사용자를 인증하려면 "수동으로 편집" 버튼을 눌러 수동 편집으로 전환하고 다음과 같이 LDIF 명령문에 authmethod=ssl을 추가합니다.

      7. (targetattr="homePostalAddress || homePhone || mail") (version 3.0; acl "Write Subscribers"; allow (write) (userdn= "ldap:///self") and authmethod="ssl";)

    7. "확인"을 누릅니다.

      8. "액세스 제어 관리자" 창의 목록에 새 ACI가 추가됩니다.

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

    디렉토리에서 역할 정의를 사용하여 업무상 중요한 기능이나 네트워크 및 디렉토리 관리 또는 다른 용도를 식별할 수 있습니다.

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

    중요한 기업 또는 비즈니스 기능에 대한 사용자 권한을 부여하는 역할이 있을 경우 이 역할에 대한 액세스를 제한해야 합니다. 예를 들어, example.com의 직원들은 superAdmin 역할을 제외한 모든 역할을 자신의 항목에 추가할 수 있습니다. 여기에 대해서는 ACI "Roles" 예제에서 설명합니다.

    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" and dns="*.example.com";)

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

    콘솔에서 다음을 수행하여 이 권한을 설정할 수 있습니다.

    1. "디렉토리" 탭의 왼쪽 탐색 트리에서 example.com 노드를 마우스 오른쪽 버튼으로 누르고 팝업 메뉴에서 "액세스 권한 설정"을 선택하여 "액세스 제어 관리자"를 표시합니다.

    2. "새로 만들기"를 눌러 "액세스 제어 편집기"를 표시합니다.

    3. "사용자/그룹" 탭의 ACI 이름 필드에 "Roles"를 입력합니다. 액세스 권한이 부여된 사용자 목록에서 다음을 수행합니다.

      1. "모든 사용자"를 선택하여 제거한 다음 "추가"를 누릅니다.

        2. "사용자 및 그룹 추가" 대화 상자가 표시됩니다.

      2. "사용자 및 그룹 추가" 대화 상자에서 "검색 영역"을 "특수 권한"으로 설정하고 "검색 결과" 목록에서 "자신"을 선택합니다.

      3. "추가" 버튼을 눌러 액세스 권한이 부여된 사용자 목록에 "자신"을 추가합니다.

      4. "확인"을 눌러 "사용자 및 그룹 추가" 대화 상자를 닫습니다.

    4. "권한" 탭에서 쓰기 확인란을 선택합니다. 다른 확인란은 모두 선택 취소해야 합니다.

    5. "호스트" 탭에서 "추가"를 눌러 "호스트 필터 추가" 대화 상자를 표시합니다. DNS 호스트 필터 필드에 *.example.com을 입력합니다. "확인"을 눌러 대화 상자를 닫습니다.

    6. 역할에 대한 값 기반의 필터를 작성하려면 "수동으로 편집" 버튼을 눌러 수동 편집으로 전환합니다. LDIF 명령문의 시작 부분에 아래 명령을 추가합니다.

      7. (targattrfilters="add=nsRoleDN:(nsRoleDN != "cn=superAdmin, dc=example,dc=com")")

      LDIF 명령문이 다음과 같이 표시됩니다.

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

    7. "확인"을 누릅니다.

      8. "액세스 제어 관리자" 창의 목록에 새 ACI가 추가됩니다.

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

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

    예를 들어, 일반 설치 프로세스를 사용하여 Directory Server를 설치하면 디렉토리에 대한 전체 액세스 권한을 가진 관리자 그룹이 기본적으로 작성됩니다.

    example.com의 경우 Human Resources 그룹은 디렉토리의 ou=example-people 분기에 대한 전체 액세스 권한을 갖고 있으므로 직원 디렉토리를 업데이트할 수 있습니다. 여기에 대해서는 ACI "HR" 예제에서 설명합니다.

    ACI "HR"

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

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

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

    콘솔에서 다음을 수행하여 이 권한을 설정할 수 있습니다.

    1. "디렉토리" 탭의 왼쪽 탐색 트리에서 example.com 노드 아래의 example.com-people 항목을 마우스 오른쪽 버튼으로 누르고 팝업 메뉴에서 "액세스 권한 설정"을 선택하여 "액세스 제어 관리자"를 표시합니다.

    2. "새로 만들기"를 눌러 "액세스 제어 편집기"를 표시합니다.

    3. "사용자/그룹" 탭의 ACI 이름 필드에 "HR"을 입력합니다. 액세스 권한이 부여된 사용자 목록에서 다음을 수행합니다.

      1. "모든 사용자"를 선택하여 제거한 다음 "추가"를 누릅니다.

        2. "사용자 및 그룹 추가" 대화 상자가 표시됩니다.

      2. "검색 영역"을 "사용자 및 그룹"으로 설정하고 "검색 대상" 필드에 "Hrgroup"을 입력합니다.

        3. 이 예제에서는 HR 그룹이나 역할이 작성되어 있다고 가정합니다. 그룹 및 역할에 대한 자세한 내용은 5장 "고급 항목 관리를 참조하십시오.

      3. "추가" 버튼을 눌러 액세스 권한이 부여된 사용자 목록에 HR 그룹을 표시합니다.

      4. "확인"을 눌러 "사용자 및 그룹 추가" 대화 상자를 닫습니다.

    4. "권한" 탭에서 "모두 선택" 버튼을 누릅니다.

      5. 프록시 권한을 제외한 모든 확인란이 선택됩니다.

    5. "확인"을 누릅니다.

      6. "액세스 제어 관리자" 창의 목록에 새 ACI가 추가됩니다.

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

    일부 기업은 직원들이 효율성을 높이고 기업의 활력소 역할을 하는 항목을 트리에 작성할 수 있도록 허용합니다.

    예를 들어 example.com에는 테니스, 수영, 스키, 롤 플레잉 등 여러 클럽으로 구성된 활동적인 사교 모임이 있으며 example.com의 직원이라면 누구든지 새 클럽을 나타내는 그룹 항목을 작성할 수 있습니다. 여기에 대해서는 ACI "Create Group" 예제에서 설명합니다. example.com의 모든 직원은 이러한 그룹 중 하나의 구성원이 될 수 있습니다. 여기에 대해서는 "사용자가 그룹에 자신을 추가 또는 제거할 수 있도록 허용"의 ACI "Group Members"에서 설명합니다. 하지만 그룹 소유자만 그룹 항목을 수정하거나 삭제할 수 있습니다. 여기에 대해서는 ACI "Delete Group" 예제에서 설명합니다.

    ACI "Create Group"

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

    aci: (target="ldap:///ou=social committee,dc=example,dc=com)
     (targetattr="*")(targattrfilters="add=objectClass:
     (objectClass=groupOfNames)") (version 3.0; acl "Create Group";
     allow (read,search,add) (userdn= "ldap:///uid=*,ou=example-people,
     dc=example,dc=com") and dns="*.example.com";)


    주

    이 ACI는 쓰기 권한을 부여하지 않기 때문에 항목 작성자가 항목을 수정할 수 없습니다.

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

    콘솔에서 다음을 수행하여 이 권한을 설정할 수 있습니다.

    1. "디렉토리" 탭의 왼쪽 탐색 트리에서 example.com 노드 아래의 Social Committee 항목을 마우스 오른쪽 버튼으로 누르고 팝업 메뉴에서 "액세스 권한 설정"을 선택하여 "액세스 제어 관리자"를 표시합니다.

    2. "새로 만들기"를 눌러 "액세스 제어 편집기"를 표시합니다.

    3. "사용자/그룹" 탭의 ACI 이름 필드에 "Create Group"을 입력합니다. 액세스 권한이 부여된 사용자 목록에서 다음을 수행합니다.

      1. "모든 사용자"를 선택하여 제거한 다음 "추가"를 누릅니다.

        2. "사용자 및 그룹 추가" 대화 상자가 표시됩니다.

      2. "검색 영역"을 "특수 권한"으로 설정하고 "검색 결과" 목록에서 "모든 인증된 사용자"를 선택합니다.

      3. "추가" 버튼을 눌러 액세스 권한이 부여된 사용자 목록에 "모든 인증된 사용자"를 추가합니다.

      4. "확인"을 눌러 "사용자 및 그룹 추가" 대화 상자를 닫습니다.

    4. "권한" 탭에서 읽기, 검색 및 추가 확인란을 선택합니다. 다른 확인란은 모두 선택 취소해야 합니다.

    5. "대상" 탭에서 "이 항목"을 눌러 대상 디렉토리 항목 필드에 ou=social committee, dc=example,dc=com 접미사를 표시합니다.

    6. "호스트" 탭에서 "추가"를 눌러 "호스트 필터 추가" 대화 상자를 표시합니다. DNS 호스트 필터 필드에 *.example.com을 입력합니다. "확인"을 눌러 대화 상자를 닫습니다.

    7. 직원들이 이 하위 트리에 그룹 항목만 추가할 수 있도록 값 기반의 필터를 작성하려면 "수동으로 편집" 버튼을 눌러 수동 편집으로 전환합니다. LDIF 명령문의 시작 부분에 아래 명령을 추가합니다.

      8. (targattrfilters="add=objectClass:(objectClass=groupOfNames)")

      LDIF 명령문이 다음과 같이 표시됩니다.

      (targetattr = "*") (targattrfilters="add=objectClass:(objectClass=groupOfNames)") (target="ldap:///ou=social committee,dc=example,dc=com) (version 3.0; acl "Create Group"; allow (read,search,add) (userdn= "ldap:///all") and (dns="*.example.com"); )

    8. "확인"을 누릅니다.

      9. "액세스 제어 관리자" 창의 목록에 새 ACI가 추가됩니다.

    ACI "Delete Group"

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

    aci: (target="ou=social committee,dc=example,dc=com)(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를 추가한다고 가정합니다.

    콘솔을 사용할 경우 수동 편집 모드로 대상 필터를 작성하고 그룹 소유권을 확인해야 하기 때문에 이 ACI를 작성하는 데는 효과적인 방법이 아닙니다.

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

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

    예를 들어, example.com은 자사가 호스팅 서비스를 제공하는 두 회사인 Company333과 Company999에 대해 각각 디렉토리 관리자 역할을 작성했습니다. example.com은 두 회사가 자사 데이터를 관리하고 액세스 제어 규칙을 구현할 수 있는 동시에 침입자로부터 데이터를 보호할 수 있기를 원합니다. 이런 이유로 Company333과 Company999는 다음과 같은 조건에 부합될 경우 디렉토리 트리의 해당 분기에 대한 전체 권한을 갖습니다.

    • 인증서를 사용하여 SSL을 통해 인증된 연결

    • 월요일부터 목요일까지 오전 8시에서 오후 6시 사이에 요청한 액세스

    • 각 회사에 지정된 IP 주소로부터 요청한 액세스

    이러한 조건에 대해서는 각 회사별 ACI(ACI "Company333" 및 ACI "Company999")에서 설명합니다. 두 ACI의 내용이 같기 때문에 아래 예제에서는 "Company333" ACI에 대해서만 설명합니다.

    ACI "Company333"

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

    aci: (target="ou=Company333,ou=corporate-clients,dc=example,dc=com")
     (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를 추가한다고 가정합니다.

    콘솔에서 다음을 수행하여 이 권한을 설정할 수 있습니다.

    1. "디렉토리" 탭의 왼쪽 탐색 트리에서 example.com 노드 아래의 Company333 항목을 마우스 오른쪽 버튼으로 누르고 팝업 메뉴에서 "액세스 권한 설정"을 선택하여 "액세스 제어 관리자"를 표시합니다.

    2. "새로 만들기"를 눌러 "액세스 제어 편집기"를 표시합니다.

    3. "사용자/그룹" 탭의 ACI 이름 필드에 "Company333"을 입력합니다. 액세스 권한이 부여된 사용자 목록에서 다음을 수행합니다.

      1. "모든 사용자"를 선택하여 제거한 다음 "추가"를 누릅니다.

        2. "사용자 및 그룹 추가" 대화 상자가 표시됩니다.

      2. "검색 영역"을 "사용자 및 그룹"으로 설정하고 "검색 대상" 필드에 "DirectoryAdmin"을 입력합니다.

        3. 이 예제에서는 cn이 DirectoryAdmin인 관리자 역할이 작성되어 있다고 가정합니다.

      3. "추가" 버튼을 눌러 액세스 권한이 부여된 사용자 목록에 관리자 역할을 표시합니다.

      4. "확인"을 눌러 "사용자 및 그룹 추가" 대화 상자를 닫습니다.

    4. "권한" 탭에서 "모두 선택" 버튼을 누릅니다.

    5. "대상" 탭에서 "이 항목"을 눌러 대상 디렉토리 항목 필드에 ou=Company333,ou=corporate-clients,dc=example,dc=com 접미사를 표시합니다.

    6. "호스트" 탭에서 "추가"를 눌러 "호스트 필터 추가" 대화 상자를 표시합니다. IP 주소 호스트 필터 필드에 255.255.123.234를 입력합니다. "확인"을 눌러 대화 상자를 닫습니다.

      7. IP 주소는 Company333 관리자가 example.com 디렉토리에 연결할 때 사용하는 호스트 시스템의 유효한 IP 주소여야 합니다.

    7. "시간" 탭에서 월요일에서 목요일까지, 오전 8시에서 오후 6시까지에 해당하는 시간 블록을 선택합니다.

      8. 선택한 시간 블록을 지정하는 메시지가 테이블 아래에 나타납니다.

    8. Company333 관리자로부터의 SSL 인증을 실행하려면 "수동으로 편집" 버튼을 눌러 수동 편집으로 전환합니다. LDIF 명령문의 끝 부분에 아래 명령을 추가합니다.

      9. and (authmethod="ssl")

      LDIF 명령문이 다음과 같이 표시됩니다.

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

    9. "확인"을 누릅니다.

      10. "액세스 제어 관리자" 창의 목록에 새 ACI가 추가됩니다.

    액세스 거부

    디렉토리에 업무상 중요한 정보가 있으면 디렉토리에 대한 액세스를 구체적으로 거부할 수 있습니다.

    예를 들어, example.com은 모든 가입자가 자신의 항목에서 연결 시간이나 계좌 잔고와 같은 결제 정보를 읽을 수 있도록 허용하지만 이 정보에 대한 쓰기 액세스는 명시적으로 거부합니다. 여기에 대해서는 ACI "Billing Info Read" 및 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를 추가한다고 가정합니다.

    콘솔에서 다음을 수행하여 이 권한을 설정할 수 있습니다.

    1. "디렉토리" 탭의 왼쪽 탐색 트리에서 example.com 노드 아래의 Subscribers 항목을 마우스 오른쪽 버튼으로 누르고 팝업 메뉴에서 "액세스 권한 설정"을 선택하여 "액세스 제어 관리자"를 표시합니다.

    2. "새로 만들기"를 눌러 "액세스 제어 편집기"를 표시합니다.

    3. "사용자/그룹" 탭의 ACI 이름 필드에 "Billing Info Read"를 입력합니다. 액세스 권한이 부여된 사용자 목록에서 다음을 수행합니다.

      1. "모든 사용자"를 선택하여 제거한 다음 "추가"를 누릅니다.

        2. "사용자 및 그룹 추가" 대화 상자가 표시됩니다.

      2. "사용자 및 그룹 추가" 대화 상자에서 "검색 영역"을 "특수 권한"으로 설정하고 "검색 결과" 목록에서 "자신"을 선택합니다.

      3. "추가" 버튼을 눌러 액세스 권한이 부여된 사용자 목록에 "자신"을 추가합니다.

      4. "확인"을 눌러 "사용자 및 그룹 추가" 대화 상자를 닫습니다.

    4. "권한" 탭에서 검색 및 읽기 권한 확인란을 선택합니다. 다른 확인란은 모두 선택 취소해야 합니다.

    5. "대상" 탭에서 "이 항목"을 눌러 대상 디렉토리 항목 필드에 ou=subscribers, dc=example,dc=com 접미사를 표시합니다. 속성 테이블에서 connectionTime 속성과 accountBalance 속성에 해당하는 확인란을 선택합니다.

      6. 다른 확인란은 모두 선택 취소해야 합니다. 간편하게 이 작업을 수행하려면 "선택 안 함" 버튼을 눌러 테이블에 있는 모든 속성의 확인란을 선택 취소한 다음, "이름" 머리글을 눌러 속성을 알파벳순으로 정렬하고 해당 속성을 선택합니다.

      이 예제에서는 connectionTime 속성과 accountBalance 속성이 스키마에 추가되어 있다고 가정합니다.

    6. "확인"을 누릅니다.

      7. "액세스 제어 관리자" 창의 목록에 새 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를 추가한다고 가정합니다.

    콘솔에서 다음을 수행하여 이 권한을 설정할 수 있습니다.

    1. "디렉토리" 탭의 왼쪽 탐색 트리에서 example.com 노드 아래의 Subscribers 항목을 마우스 오른쪽 버튼으로 누르고 팝업 메뉴에서 "액세스 권한 설정"을 선택하여 "액세스 제어 관리자"를 표시합니다.

    2. "새로 만들기"를 눌러 "액세스 제어 편집기"를 표시합니다.

    3. "사용자/그룹" 탭의 ACI 이름 필드에 "Billing Info Deny"를 입력합니다. 액세스 권한이 부여된 사용자 목록에서 다음을 수행합니다.

      1. "모든 사용자"를 선택하여 제거한 다음 "추가"를 누릅니다.

        2. "사용자 및 그룹 추가" 대화 상자가 표시됩니다.

      2. "사용자 및 그룹 추가" 대화 상자에서 "검색 영역"을 "특수 권한"으로 설정하고 "검색 결과" 목록에서 "자신"을 선택합니다.

      3. "추가" 버튼을 눌러 액세스 권한이 부여된 사용자 목록에 "자신"을 추가합니다.

      4. "확인"을 눌러 "사용자 및 그룹 추가" 대화 상자를 닫습니다.

    4. "권한" 탭에서 쓰기 확인란을 선택합니다. 다른 확인란은 모두 선택 취소해야 합니다.

    5. "수동으로 편집" 버튼을 누르고 표시된 LDIF 명령문에서 allow를 deny로 변경합니다.

    6. "대상" 탭에서 "이 항목"을 눌러 대상 디렉토리 항목 필드에 ou=subscribers, dc=example,dc=com 접미사를 표시합니다. 속성 테이블에서 connectionTime 속성과 accountBalance 속성에 해당하는 확인란을 선택합니다.

      7. 다른 확인란은 모두 선택 취소해야 합니다. 간편하게 이 작업을 수행하려면 "선택 안 함" 버튼을 눌러 테이블에 있는 모든 속성의 확인란을 선택 취소한 다음, "이름" 머리글을 눌러 속성을 알파벳순으로 정렬하고 해당 속성을 선택합니다.

      이 예제에서는 connectionTime 속성과 accountBalance 속성이 스키마에 추가되어 있다고 가정합니다.

    7. "확인"을 누릅니다.

      8. "액세스 제어 관리자" 창의 목록에 새 ACI가 추가됩니다.

    필터링을 사용한 대상 설정

    디렉토리에 분산된 여러 항목에 대한 액세스를 허용하는 액세스 제어를 설정하려면 필터를 사용하여 대상을 설정할 수 있습니다. 검색 필터는 액세스가 관리되는 개체의 이름을 직접 지정하지 않으므로 특히 디렉토리가 복잡할수록 실수로 잘못된 개체에 대한 액세스 권한을 부여하거나 거부할 수 있습니다. 또한 필터를 사용할 경우 디렉토리 내의 액세스 제어 문제점을 해결하기 어렵다는 단점이 있습니다.

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

    대부분의 디렉토리는 사용자가 그룹에 자신을 추가하거나 제거할 수 있도록 허용하는 ACI를 설정합니다. 예를 들어, 사용자가 우편 목록에 자신을 추가하거나 제거할 수 있도록 허용할 경우 이러한 ACI를 설정할 수 있습니다.

    example.com 직원들은 ou=social committee 하위 트리의 모든 그룹 항목에 자신을 추가할 수 있습니다. 여기에 대해서는 ACI "Group Members" 예제에서 설명합니다.

    ACI "Group Members"

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

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

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

    콘솔에서 다음을 수행하여 이 권한을 설정할 수 있습니다.

    1. "디렉토리" 탭의 왼쪽 탐색 트리에서 example.com 노드 아래의 example-people 항목을 마우스 오른쪽 버튼으로 누른 다음 팝업 메뉴에서 "액세스 권한 설정"을 선택하여 액세스 제어 관리자를 표시합니다.

    2. "새로 만들기"를 눌러 "액세스 제어 편집기"를 표시합니다.

    3. "사용자/그룹" 탭의 ACI 이름 필드에 "Group Members"를 입력합니다. 액세스 권한이 부여된 사용자 목록에서 다음을 수행합니다.

      1. "모든 사용자"를 선택하여 제거한 다음 "추가"를 누릅니다.

        2. "사용자 및 그룹 추가" 대화 상자가 표시됩니다.

      2. "사용자 및 그룹 추가" 대화 상자에서 "검색 영역"을 "특수 권한"으로 설정하고 "검색 결과" 목록에서 "모든 인증된 사용자"를 선택합니다.

      3. "추가" 버튼을 눌러 액세스 권한이 부여된 사용자 목록에 "모든 인증된 사용자"를 추가합니다.

      4. "확인"을 눌러 "사용자 및 그룹 추가" 대화 상자를 닫습니다.

    4. "권한" 탭에서 자체 쓰기 확인란을 선택합니다. 다른 확인란은 모두 선택 취소해야 합니다.

    5. "대상" 탭의 대상 디렉토리 항목 필드에 dc=example,dc=com 접미사를 입력합니다. 속성 테이블에서 member 속성에 해당하는 확인란을 선택합니다.

      6. 다른 확인란은 모두 선택 취소해야 합니다. 간편하게 이 작업을 수행하려면 "선택 안 함" 버튼을 눌러 테이블에 있는 모든 속성의 확인란을 선택 취소한 다음, "이름" 머리글을 눌러 속성을 알파벳순으로 정렬하고 해당 속성을 선택합니다.

    6. "확인"을 누릅니다.

      7. "액세스 제어 관리자" 창의 목록에 새 ACI가 추가됩니다.

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

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

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

    프록시 인증 ACI 예제

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

    이 예제에서는 다음과 같이 가정합니다.

    • 클라이언트 응용 프로그램의 바인드 DN은 "uid=MoneyWizAcctSoftware, ou=Applications,dc=example,dc=com"입니다.

    • 클라이언트 응용 프로그램이 액세스를 요청하는 대상 하위 트리는 ou=Accounting,dc=example,dc=com입니다.

    • ou=Accounting,dc=example,dc=com 하위 트리에 대한 액세스 권한을 가진 계정 관리자가 디렉토리에 있습니다.

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

    • 계정 관리자에게 ou=Accounting,dc=example,dc=com 하위 트리에 대한 액세스 권한이 있어야 합니다. 예를 들어, 아래 ACI는 계정 관리자 항목에 모든 권한을 부여합니다.

      • aci: (target="ldap:///ou=Accounting,dc=example,dc=com")
       (targetattr="*") (version 3.0; acl "allowAll-AcctAdmin"; allow
       (all) userdn="uid=AcctAdministrator,ou=Administrators,
       dc=example,dc=com")

    • 클라이언트 응용 프로그램에 프록시 권한을 부여하는 아래 ACI가 디렉토리에 있어야 합니다.

      • aci: (target="ldap:///ou=Accounting,dc=example,dc=com")
       (targetattr="*") (version 3.0; acl "allowproxy-
       accountingsoftware"; allow (proxy) userdn=
       "uid=MoneyWizAcctSoftware,ou=Applications,dc=example,dc=com")

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

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

    # ldapsearch -w password \
    -D "uid=MoneyWizAcctSoftware,ou=Applications,dc=example,dc=com" \
    -y "uid=AcctAdministrator,ou=Administrators,dc=example,dc=com" ...

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


    주

    디렉토리 관리자의 DN은 프록시 DN으로 사용할 수 없으며 디렉토리 관리자에게 프록시 권한을 부여할 수도 없습니다. 또한 Directory Server가 한 개의 바인드 작업에서 프록시 인증 제어를 둘 이상 수신하면 클라이언트 응용 프로그램에 오류가 반환되고 바인드 시도는 실패합니다.

    유효 권한 보기

    디렉토리 항목에 대한 액세스 정책을 유지관리할 때 정의한 ACI의 보안에 미치는 영향을 확인할 수 있다면 큰 도움이 됩니다. Sun ONE Directory Server 5.2에서는 기존 ACI를 평가하고 지정된 항목의 특정 사용자에게 부여되는 유효 권한을 보고하는 새로운 메커니즘을 제공합니다.

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


    주의

    유효 권한 보기는 그 자체가 디렉토리 작업이므로 보호 및 적절한 제한이 필요합니다. 이 정보에 대한 디렉토리 사용자의 액세스를 제한하려면 aclRights 및 aclRightsInfo 속성에 대한 ACI를 추가로 작성합니다.

    유효 권한 기능은 LDAP 컨트롤을 사용합니다. 연결 접미사에 대한 유효 권한을 보려면 "연결 정책 구성"에 설명된 것처럼 연결 정책에서 이 컨트롤을 활성화해야 합니다. 원격 서버에 바인드할 때 사용한 프록시 ID도 유효 권한 속성에 액세스할 수 있어야 합니다.

    유효 권한 보기 컨트롤 사용

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

    • -c "dn: DN" - 지정된 DN을 사용한 사용자 바인드의 유효 권한을 검색 결과로 표시합니다. 관리자는 이 옵션을 사용하면 다른 사용자의 유효 권한을 확인할 수 있습니다. -c "dn:" 옵션은 익명 인증에 대한 유효 권한을 표시합니다.

    • -X "attributeName ..." - 지정된 속성에 대한 유효 권한도 검색 결과에 포함됩니다. 검색 결과에 표시되지 않는 속성을 지정하려면 이 옵션을 사용합니다. 예를 들어, 사용자가 현재 항목에 없는 속성을 추가할 수 있는 권한을 갖고 있는지 확인할 수 있습니다.

    -c 및 -X 속성 중 한 개나 둘 모두를 사용할 경우 "유효 권한 보기" 컨트롤의 OID에 -J 옵션이 암묵적으로 지정되므로 별도로 지정할 필요가 없습니다.

    그런 다음, 간단히 권한만 볼 것인지 아니면 이러한 권한이 어떻게 부여 또는 거부되는지 설명하는 자세한 로깅 정보를 볼 것인지 선택합니다. 각각 aclRights 또는 aclRightsInfo;logs를 검색 결과로 반환할 속성에 추가하여 정보 유형을 결정합니다. 간단한 권한 정보는 자세한 로깅 정보의 내용과 중복되지만 두 속성을 모두 요청하여 유효 권한 정보를 모두 받을 수도 있습니다.


    주

    aclRights 및 aclRightsInfo;logs 속성은 가상의 작동 가능 속성으로 동작합니다. 두 속성은 디렉토리에 저장되지 않으므로 명시적으로 요청해야만 반환됩니다. Directory Server는 "유효 권한 보기" 컨트롤에 응답하여 두 속성을 생성합니다.

    이런 이유로 두 속성은 모든 종류의 검색 작업이나 필터에 사용할 수 없습니다.

    아래 예제에서는 어떻게 사용자가 디렉토리에서 자신의 권한을 볼 수 있는지 보여줍니다. 결과에서 1은 권한이 부여된 것을, 0은 권한이 거부된 것을 의미합니다.

    % ldapsearch -J "1.3.6.1.4.1.42.2.27.9.5.2" \
                 -h rousseau.example.com -p 389 \
                 -D "uid=cfuente,ou=People,dc=example,dc=com" \
                 -w password -b "dc=example,dc=com" \
                 "(objectclass=*)" aclRights

    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 rousseau.example.com -p 389 \
                 -D "cn=Directory Manager" -w password \
                 -c "dn: uid=cfuente,ou=People,dc=example,dc=com" \
                 -b "dc=example,dc=com" \
                 "(objectclass=*)" aclRights

    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 rousseau.example.com -p 389 \
                 -D "cn=Directory Manager" -w password \
                 -c "dn: uid=cfuente,ou=People,dc=example,dc=com" \
                 -b "dc=example,dc=com" \
                 "(uid=cfuente)" aclRights "*"

    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

    aclRights 및 aclRightsInfo;logs 속성 형식에 대해서는 Sun ONE Directory Server Deployment Guide의 Chapter 7, "Understanding the Effective Rights Results"에서 자세히 설명합니다.

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

    반복 디렉토리 트리 구조를 사용하는 조직에서는 매크로를 사용하여 디렉토리에 사용되는 ACI 수를 최소화할 수 있습니다. 디렉토리 트리의 ACI 수를 줄이면 액세스 제어 정책의 관리가 용이해지며 ACI 메모리를 효율적으로 사용할 수 있습니다.

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

    매크로 ACI 예제

    예제를 통해 살펴보면 매크로 ACI의 이점과 작동 방식을 명확히 이해할 수 있습니다. 그림 6-4에서는 매크로 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 트리의 모든 항목에 대한 읽기 및 검색 권한을 부여합니다.

    그림 6-4    매크로 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";)

    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에는 DN 또는 DN의 일부분을 대체하는 다음과 같은 유형의 표현식이 포함됩니다.

    • ($dn) - 대상 일치 및 주제의 직접 대체에 사용합니다.

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

    • ($attr.attributeName) - 대상 항목의 attributeName 속성 값을 주제로 대체하는 데 사용합니다.

    표 6-3에는 ACI에서 DN 매크로를 사용할 수 있는 부분이 나와 있습니다.

    표 6-3    ACI 키워드의 매크로

    매크로

    ACI 키워드

    ($dn)

    target, targetfilter, userdn, roledn, groupdn, userattr

    [$dn]

    targetfilter, userdn, roledn, groupdn, userattr

    ($attr.attrName)

    userdn, roledn, groupdn, userattr

    다음과 같은 제한이 적용됩니다.

    • 주제에서 ($dn) 및 [$dn] 매크로를 사용할 경우 ($dn) 매크로가 포함된 대상을 반드시 정의해야 합니다.

    • 주제에서 ($dn) 매크로는 ($attr.attrName) 매크로와 함께 사용할 수 있지만 [$dn] 매크로는 함께 사용할 수 없습니다.

    대상의 ($dn) 일치

    ACI의 대상에 있는 ($dn) 매크로는 LDAP 요청의 대상 항목에 따라 대체 값을 결정합니다. 예를 들어, cn=all,ou=groups,dc=subdomain1, dc=hostedCompany1,
    dc=example,dc=com     항목을 대상으로 하는 LDAP 요청과 대상을 다음과 같이 정의하는 ACI가 있습니다.

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

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

    주제의 ($dn) 대체

    ACI 주제에 있는 ($dn) 매크로는 대상에서 일치하는 전체 하위 문자열로 대체됩니다. 예를 들어, 다음과 같은 ACI 주제를 가정해 보십시오.

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

    위의 ACI 주제는 다음과 같이 표시됩니다.

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

    매크로가 확장되면 Directory Server는 일반 프로세스에 따라 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로 대체합니다.

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

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

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

    [$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"

    그런 다음 Directory Server는 일반 ACI 평가 알고리즘에 따라 ACI를 평가합니다.

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

    액세스 제어 및 복제

    ACI는 항목의 속성으로 저장되므로 ACI가 포함된 항목이 복제된 접미사의 일부일 경우 ACl도 다른 속성과 마찬가지로 복제됩니다.

    ACI는 항상 받는 LDAP 요청을 처리하는 Directory Server에서 평가됩니다. 따라서 업데이트 요청이 수신되면 소비자 서버는 마스터 서버에서 이 요청을 처리할 수 있는지 여부를 평가하기 전에 마스터 서버에 대한 참조를 반환합니다.

    액세스 제어 정보의 로깅

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

    콘솔에서 오류 로그 수준을 설정하려면 다음을 수행합니다.

    1. Directory Server 콘솔의 최상위 수준 "디렉토리" 탭에서 cn=config 노드를 마우스 오른쪽 버튼으로 누른 다음 팝업 메뉴에서 "일반 편집기로 편집"을 선택합니다.

      2. cn=config 항목의 내용이 표시된 일반 편집기가 나타납니다.

    2. 속성 값 쌍의 목록을 아래로 스크롤하여 nsslapd-errorlog-level 속성을 찾습니다.

    3. nsslapd-errorlog-level 필드의 값에 128을 더합니다.

      4. 예를 들어, 표시된 값이 8192(복제 디버깅)이면 이 값을 8320으로 변경해야 합니다. 오류 로그 수준에 대한 자세한 내용은 Sun ONE Directory Server Reference Manual을 참조하십시오.

    4. "확인"을 눌러 변경 사항을 저장하고 일반 편집기를 닫습니다.

    이전 릴리스와의 호환성

    Directory Server의 이전 릴리스에서 사용되었던 일부 ACI 키워드는 Sun ONE Directory Server 5.2에서 더 이상 사용되지 않습니다. 하지만 이전 버전과의 호환성을 위해 이러한 키워드도 계속 지원됩니다. 예를 들면 다음과 같습니다.

    • userdnattr

    • groupdnattr

    따라서 레거시 공급업체 서버와 소비자 Directory Server 5.2 간에 복제 계약을 설정한 경우에도 ACI 복제 시 문제가 발생하지 않습니다.

    하지만 "값 일치에 따른 액세스 정의"에 설명된 것처럼 이러한 키워드는 userattr 키워드의 기능으로 바꾸는 것이 좋습니다.

    이전     목차     색인     DocHome     다음    
    Copyright 2003 Sun Microsystems, Inc. 모든 권리는 저작권자의 소유입니다.