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

9장 디렉토리 서버 그룹, 역할 및 CoS

디렉토리의 계층적 데이터 구조에 제한을 받지 않고 자유롭게 사용자 항목을 관리하기 위해 그룹을 만들어 공통 속성 값을 공유해야 하는 경우가 있습니다. 디렉토리 서버는 그룹, 역할 및 서비스 클래스(CoS)를 통해 이러한 고급 항목 관리 기능을 제공합니다.

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

그룹, 역할 및 서비스 클래스 정보

그룹, 역할 및 CoS는 다음과 같이 정의됩니다.

그룹은 구성원 목록이나 구성원 필터로 다른 항목의 이름을 지정하는 항목입니다. 구성원 목록으로 구성되는 그룹에 대해 디렉토리 서버는 각 사용자 항목의 isMemberOf 속성 값을 생성합니다. 따라서 사용자 항목의 isMemberOf 속성은 해당 항목이 속하는 모든 그룹을 표시합니다.
역할도 특정 역할의 각 구성원에 nsrole 속성을 생성하는 메커니즘을 통해 그룹과 동일한 기능을 제공하지만, 훨씬 더 기능이 다양합니다.
CoS는 계산된 속성을 생성함으로써 각 항목에 속성을 저장할 필요 없이 여러 항목이 공통 속성 값을 공유할 수 있게 합니다.

isMemberOf 속성을 사용하여 정적 그룹의 모든 구성원이 계산된 공통 속성 값으로부터 자동으로 상속되도록 만들 수 없습니다.

디렉토리 서버는 역할 값과 그룹 및 CoS에서 계산된 속성을 기반으로 검색을 수행하는 기능을 제공합니다. 작업에 사용되는 필터 문자열은 nsRole 속성이나 CoS 정의에 따라 생성되는 모든 속성을 포함할 수 있습니다. 또한 필터 문자열을 사용하여 이 속성 값에 대한 비교 작업을 수행할 수 있습니다. 그러나 계산된 CoS 속성은 색인화할 수 없습니다. 따라서 CoS에서 생성된 속성을 포함하는 모든 검색에서는 시간과 메모리 자원을 많이 소모할 수 있습니다.

역할, 그룹 및 서비스 클래스에서 제공하는 기능을 최대한 활용하려면 디렉토리 배포의 계획 단계에서 그룹화 전략을 결정합니다. 이러한 기능과 해당 기능이 토폴로지를 간소화하는 방법에 대한 자세한 내용은 Sun Java System Directory Server Enterprise Edition 6.2 Deployment Planning Guide의 Grouping Directory Data and Managing Attributes를 참조하십시오.

역할 및 그룹 작업 방법에 대한 자세한 내용은 Sun Java System Directory Server Enterprise Edition 6.2 Reference의 8 장, Directory Server Groups and Roles를 참조하십시오. CoS에 대한 자세한 내용은 Sun Java System Directory Server Enterprise Edition 6.2 Reference의 9 장, Directory Server Class of Service를 참조하십시오.

그룹 관리

그룹을 사용하면 관리 작업의 편의를 위해 항목을 연결할 수 있습니다. 예를 들어 그룹을 사용하여 액세스 제어 지침(ACI)을 쉽게 정의할 수 있습니다. 그룹 정의는 해당 구성원의 이름을 정적 목록으로 지정하거나 동적 항목 집합을 정의하는 필터를 제공하는 특수 항목입니다.

그룹 정의 항목이 저장된 위치에 관계 없이 전체 디렉토리가 그룹 구성원이 될 수 있습니다. 관리를 간소화하기 위해 모든 그룹 정의 항목은 대체로 한 위치(루트 접미어 아래의 ou=Groups)에 저장됩니다.

그룹에는 정적 그룹과 동적 그룹의 두 유형이 있습니다.

정적 그룹.정적 그룹을 정의하는 항목은 groupOfNames 또는 groupOfUniqueNames 객체 클래스에서 상속됩니다. 그룹 구성원은 DN에 따라 member 또는 uniqueMember 속성의 여러 값으로 나열됩니다.

또는 정적 그룹의 isMemberOf 속성을 사용할 수 있습니다. isMemberOf 속성은 검색을 시작할 때 계산되어 사용자 항목에 추가됩니다. 그런 다음 검색이 완료되면 다시 제거됩니다. 이 기능을 사용하면 그룹을 쉽게 관리하고 빠르게 읽기 액세스할 수 있습니다.
동적 그룹.동적 그룹을 정의하는 항목은 groupOfURLs 객체 클래스로부터 상속됩니다. 그룹 구성원은 여러 값을 갖는 memberURL 속성에 지정된 하나 이상의 필터로 정의됩니다. 동적 그룹의 구성원은 필터가 평가될 때마다 해당 필터 중 하나에 일치하는 항목입니다.

새 정적 그룹을 만드는 방법

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

ldapmodify 명령을 사용하여 새 정적 그룹을 만듭니다.

예를 들어 System Administrators라는 새 정적 그룹을 만들고 일부 구성원을 추가하려면 다음 명령을 사용할 수 있습니다.

$ ldapmodify -a -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w -
dn: cn=System Administrators, ou=Groups, dc=example,dc=com
changetype: add
cn: System Administrators
objectclass: top
objectclass: groupOfNames
ou: Groups
member: uid=kvaughan, ou=People, dc=example,dc=com
member: uid=rdaugherty, ou=People, dc=example,dc=com
member: uid=hmiller, ou=People, dc=example,dc=com

새 그룹이 만들어졌고 구성원이 추가되었는지 확인합니다.

예를 들어 Kirsten Vaughan이 새 System Administrators 그룹에 있는지 확인하려면 다음과 같이 입력합니다.

$ ldapsearch -b "dc=example,dc=com" uid=kvaughan isMemberOf
uid=kvaughan,ou=People,dc=example,dc=com
isMemberOf: cn=System Administrators, ou=Groups, dc=example,dc=com 
isMemberOf: cn=HR Managers,ou=groups,dc=example,dc=com

새 동적 그룹을 만드는 방법

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

ldapmodify 명령을 사용하여 새 동적 그룹을 만듭니다.

예를 들어 "3rd Floor"라는 새 동적 그룹을 만들고 방 번호가 3으로 시작하는 모든 구성원을 포함시키려면 다음 명령을 사용할 수 있습니다.

$ ldapmodify -a -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w -
dn: cn=3rd Floor, ou=Groups, dc=example,dc=com
changetype: add
cn: 3rd Floor
objectclass: top
objectclass: groupOfUrls
ou: Groups
memberURL: ldap:///dc=example,dc=com??sub?(roomnumber=3*)

역할 관리

역할은 응용 프로그램을 보다 쉽고 효율적으로 사용하기 위해 설계한 대체 그룹화 메커니즘입니다. 그룹과 마찬가지로 역할이 정의되어 있고 관리되는 동안, 각 구성원 항목에 생성된 역할 속성은 자동으로 항목의 역할을 나타냅니다. 예를 들어 응용 프로그램은 그룹을 선택하여 구성원 목록을 탐색할 필요 없이 항목의 역할을 읽을 수 있습니다.

기본적으로 역할의 범위는 해당 역할이 정의된 하위 트리로 제한됩니다. 그러나 중첩된 역할의 범위를 확장할 수 있습니다. 해당 범위에서 다른 하위 트리에 있는 역할을 중첩시키고 디렉토리의 어느 곳에서나 구성원을 가질 수 있습니다. 자세한 내용은 역할 범위를 확장하는 방법 및 중첩된 역할 정의 예를 참조하십시오.

이 절에서는 역할을 안전하게 사용하는 방법과 명령줄에서 역할을 관리하는 방법에 대해 설명합니다.

역할을 안전하게 사용

역할을 안전하게 사용하려면 액세스 제어 지침(ACI)을 설정하여 해당 속성을 보호해야 합니다. 예를 들어 사용자 A가 관리된 역할(MR)을 소유합니다. 관리된 역할은 정적 그룹에 해당하며 nsRoleDN 속성을 항목에 추가하여 각 구성원 항목에 역할을 명시적으로 할당합니다. 명령줄에서 계정 비활성화를 사용하여 MR 역할을 잠갔습니다. 즉, nsAccountLock 속성이 사용자 A에 대해 "true"로 계산되기 때문에 해당 사용자는 서버에 바인드할 수 없습니다. 그러나 사용자가 이미 바인드되어 있고 지금 MR 역할을 통해 잠긴다는 알림을 받았다고 가정합니다. 사용자가 nsRoleDN 속성에 쓰기 액세스하지 못하도록 금지하는 ACI가 없는 경우 사용자는 nsRoleDN 속성을 자신의 항목에서 제거하여 직접 잠금 해제할 수 있습니다.

사용자가 nsRoleDN 속성을 제거하지 못하도록 금지하려면 ACI를 적용해야 합니다. 역할을 필터링한 상태에서 사용자가 속성을 수정하여 필터링된 역할을 사용하지 못하도록 필터 부분을 보호해야 합니다. 사용자는 필터링된 역할에 사용되는 속성을 추가, 삭제 또는 수정할 수 없습니다. 이와 동일한 방법으로, 필터 속성 값이 계산되는 경우 필터 속성 값을 수정할 수 있는 모든 속성을 보호해야 합니다. 중첩된 역할은 필터링된 역할과 관리된 역할을 포함할 수 있으므로 중첩된 역할에 포함되는 각 역할에 대해서는 이전에 설명한 내용을 고려해야 합니다.

보안을 위한 ACI 설정에 대한 자세한 내용은 6 장, 디렉토리 서버 액세스 제어을 참조하십시오.

명령줄에서 역할 관리

역할은 디렉토리 어드민 관리자가 명령줄 유틸리티를 통해 액세스할 수 있는 항목에 정의됩니다. 역할을 만들고 나면 다음과 같이 구성원을 역할에 지정합니다.

관리된 역할의 구성원에는 해당 항목의 nsRoleDN 속성이 있습니다.
필터링된 역할의 구성원은 nsRoleFilter 속성에 지정된 필터와 일치하는 항목입니다.
중첩된 역할의 구성원은 중첩된 역할 정의 항목의 nsRoleDN 속성에 지정된 역할의 구성원입니다.

모든 역할 정의는 LDAPsubentry 및 nsRoleDefinition 객체 클래스로부터 상속됩니다. 아래 예에서는 역할 유형별 추가 객체 클래스 및 관련 속성을 보여줍니다.

관리된 역할 정의 예

모든 마케팅 직원에 대한 역할을 만들려면 다음 ldapmodify 명령을 사용합니다.

$ ldapmodify -a -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w -
dn: cn=Marketing,ou=marketing,ou=People,dc=example,dc=com
objectclass: top
objectclass: LDAPsubentry
objectclass: nsRoleDefinition
objectclass: nsSimpleRoleDefinition
objectclass: nsManagedRoleDefinition
cn: Marketing
description: managed role for marketing staff

nsManagedRoleDefinition 객체 클래스는 LDAPsubentry, nsRoleDefinition 및 nsSimpleRoleDefinition 객체 클래스로부터 상속됩니다.

Bob이라는 마케팅 직원의 항목을 다음과 같이 업데이트하여 역할을 할당합니다.

$ ldapmodify -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w -
dn: cn=Bob Arnold,ou=marketing,ou=People,dc=example,dc=com
changetype: modify
add: nsRoleDN
nsRoleDN: cn=Marketing,ou=marketing,ou=People,dc=example,dc=com

nsRoleDN 속성은 항목이 관리된 역할의 구성원임을 나타냅니다. 관리된 역할은 역할 정의의 DN으로 식별됩니다. 사용자가 자신의 nsRoleDN 속성을 수정하도록 허용하고 nsManagedDisabledRole을 추가하거나 제거하지 못하도록 금지하려면 다음 ACI를 추가합니다.

aci: (targetattr="nsRoleDN")(targattrfilters="add=nsRoleDN: 
(!(nsRoleDN=cn=AdministratorRole,dc=example,dc=com)), 
del=nsRoleDN:(!(nsRoleDN=cn=nsManagedDisabledRole,dc=example, dc=com)") 
(version3.0;aci "allow mod of nsRoleDN by self except for critical values"; 
allow(write) userdn="ldap:///self";)

필터링된 역할 정의 예

영업 책임자에 대한 필터링된 역할을 설정하려면 모든 책임자에게 isManager 속성이 있다는 전제 하에 다음 ldapmodify 명령을 사용합니다.

$ ldapmodify -a -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w -
dn: cn=ManagerFilter,ou=sales,ou=People,dc=example,dc=com
objectclass: top
objectclass: LDAPsubentry
objectclass: nsRoleDefinition
objectclass: nsComplexRoleDefinition
objectclass: nsFilteredRoleDefinition
cn: ManagerFilter 
nsRoleFilter: (isManager=True)
Description: filtered role for sales managers

nsFilteredRoleDefinition 객체 클래스는 LDAPsubentry, nsRoleDefinition, 및 nsComplexRoleDefinition 객체 클래스로부터 상속됩니다. nsRoleFilter 속성은 ou=sales 하위 항목이 있는 조직에서 모든 직원을 찾는 필터를 지정합니다. 예를 들면 다음과 같습니다.

$ ldapsearch -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - \
 -b "ou=People,dc=example,dc=com" -s sub "(cn=*Fuentes)"
dn: cn=Carla Fuentes,ou=sales,ou=People,dc=example,dc=comcn: Carla Fuentes 
isManager: TRUE...
nsRole: cn=ManagerFilter,ou=sales,ou=People,
dc=example,dc=com

주 –

필터링된 역할의 필터 문자열은 CoS 메커니즘에 의해 생성된 계산된 속성을 제외한 모든 속성에 기반을 둘 수 있습니다.

필터링된 역할 구성원이 사용자 항목인 경우 해당 사용자가 자신을 역할에 추가하거나 역할에서 제거하는 기능을 제한할 수도 있습니다. ACI를 사용하여 필터링된 속성을 보호합니다.

중첩된 역할 정의 예

중첩된 역할 내에서 중첩되는 역할은 nsRoleDN 속성을 사용하여 지정됩니다. 이전 예에서 만든 역할의 마케팅 직원과 영업 책임자 구성원을 모두 포함하는 역할을 만들려면 다음 명령을 사용합니다.

$ ldapmodify -a -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w -
dn: cn=MarketingSales,ou=marketing,ou=People,dc=example,dc=com
objectclass: top
objectclass: LDAPsubentry
objectclass: nsRoleDefinition
objectclass: nsComplexRoleDefinition
objectclass: nsNestedRoleDefinition
cn: MarketingSales
nsRoleDN: cn=ManagerFilter,ou=sales,ou=People,dc=example,dc=com
nsRoleDN: cn=Marketing,ou=marketing,ou=People,dc=example,dc=com
nsRoleScopeDN: ou=sales,ou=People,dc=example,dc=com

nsNestedRoleDefinition 객체 클래스는 LDAPsubentry, nsRoleDefinition 및 nsComplexRoleDefinition 객체 클래스로부터 상속됩니다. nsRoleDN 속성에는 마케팅 관리된 역할과 영업 책임자 필터링된 역할의 DN이 포함됩니다. 앞의 예에서 설정된 두 사용자 Bob과 Carla는 새 중첩된 역할의 구성원이 됩니다.

이 필터의 범위에는 필터가 있는 하위 트리와 nsRoleScopeDN 속성 값 아래의 하위 트리로 구성된 기본 범위가 포함됩니다. 이 경우 ManagerFilter는 ou=sales,ou=People,dc=example,dc=com 하위 트리에 있습니다. 이 하위 트리를 범위에 추가해야 합니다.

역할 범위 확장

디렉토리 서버는 역할 정의 항목의 하위 트리를 벗어나 역할 범위를 확장하도록 허용하는 속성을 제공합니다. 이 단일 값 속성 nsRoleScopeDN에는 기존 역할에 추가할 범위의 DN이 포함됩니다. nsRoleScopeDN 속성은 중첩된 역할에만 추가할 수 있습니다. 중첩된 역할 정의 예를 참조하십시오.

역할 범위를 확장하는 방법

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

nsRoleScopeDN 속성을 사용하면 다른 하위 트리의 항목을 포함하도록 하위 트리의 역할 범위를 확장할 수 있습니다. 예를 들어 example.com 디렉토리 트리에 o=eng,dc=example,dc=com(엔지니어링 하위 트리) 및 o=sales,dc=example,dc=com(영업 하위 트리)의 두 개의 기본 하위 트리가 있다고 가정합니다.엔지니어링 하위 트리의 사용자는 영업 하위 트리의 역할(SalesAppManagedRole)을 따르는 영업 응용 프로그램에 액세스해야 합니다. 역할 범위를 확장하려면 다음을 수행합니다.

엔지니어링 하위 트리에 있는 사용자에 대한 역할을 만듭니다.

예를 들어 EngineerManagedRole 역할을 만듭니다. 이 예에서는 관리된 역할을 사용하지만 필터링된 역할이나 중첩된 역할을 사용할 수도 있습니다.

예를 들어 영업 하위 트리에서 중첩된 역할 SalesAppPlusEngNestedRole을 사용하여 새로 만든 EngineerManagedRole과 초기 SalesAppManagedRole을 수용합니다.

추가할 엔지니어링 하위 트리 범위의 DN(이 경우 o=eng,dc=example,dc=com)을 사용하여 nsRoleScopeDN 속성을 SalesAppPlusEngNestedRole에 추가합니다.

엔지니어링 사용자가 SalesAppPlusEngNestedRole 역할과 영업 응용 프로그램에 차례로 액세스할 수 있도록 필요한 권한을 부여해야 합니다. 또한, 역할의 전체 범위를 복제해야 합니다.

주 –
확장된 범위를 중첩된 역할로 제한하면 한 도메인에서 이전에 역할을 관리한 관리자는 다른 도메인에 이미 있는 역할에 대한 사용 권한만 가집니다. 관리자는 다른 도메인에서 임의의 역할을 만들 수 없습니다.

서비스 클래스

서비스 클래스(CoS) 메커니즘은 클라이언트 응용 프로그램에 대해 항목이 검색되면서 계산된 속성을 생성하여 항목 관리를 간소화하고 필요한 저장 공간을 줄여줍니다. CoS 메커니즘을 사용하면 항목 간에 속성을 공유할 수 있습니다. 또한 그룹 및 역할과 마찬가지로 CoS는 도우미 항목을 사용합니다.

배포 시 CoS를 사용하는 방법에 대한 자세한 내용은 Sun Java System Directory Server Enterprise Edition 6.2 Deployment Planning Guide의 Managing Attributes With Class of Service를 참조하십시오.

디렉토리 서버에서 CoS가 구현되는 방법에 대한 자세한 내용은 Sun Java System Directory Server Enterprise Edition 6.2 Reference의 9 장, Directory Server Class of Service를 참조하십시오.

주 –

모든 검색 작업으로 CoS에서 생성된 속성의 존재 여부를 테스트하거나 속성 값을 비교할 수 있습니다. 계산된 속성의 이름은 필터링된 역할에 사용된 내부 필터를 제외하고 클라이언트 검색 작업의 모든 필터 문자열에 사용할 수 있습니다.

안전하게 CoS 사용

다음 절에서는 각 CoS 항목의 데이터 읽기 및 쓰기 보호에 대한 일반 원칙에 대해 설명합니다. 개별 액세스 제어 지침(ACI)을 정의하는 자세한 절차는 6 장, 디렉토리 서버 액세스 제어를 참조하십시오.

CoS 정의 항목 보호

CoS 정의 항목에는 생성된 속성 값이 포함되어 있지 않지만 해당 값을 찾을 수 있는 정보를 제공합니다. CoS 정의 항목 읽기는 값이 포함된 템플리트 항목을 찾는 방법을 보여줍니다. 이 항목에 대한 쓰기는 계산된 속성이 생성되는 방법을 수정합니다.

따라서 CoS 정의 항목에 대한 읽기 ACI와 쓰기 ACI를 모두 정의해야 합니다.

CoS 템플리트 항목 보호

CoS 템플리트 항목에는 생성된 CoS 속성 값이 포함되어 있습니다. 따라서 최소한 읽기와 업데이트 모두에 대해 ACI로 템플리트의 CoS 속성을 보호해야 합니다.

포인터 CoS의 경우 단일 템플리트 항목의 이름을 바꾸면 안 됩니다. 대부분의 경우 전체 템플리트 항목을 보호하는 것이 가장 간단합니다.
클래식 CoS의 경우 모든 템플리트 항목은 공통 부모가 정의 항목에 지정되어 있습니다. 이 부모 항목에 템플리트만 저장된 경우 부모 항목에 대한 액세스 제어를 통해 템플리트를 보호합니다. 그러나 부모 아래의 다른 항목에 액세스해야 하는 경우에는 템플리트 항목을 개별적으로 보호해야 합니다.
간접 CoS의 경우 액세스해야 하는 사용자 항목을 포함하여 디렉토리의 모든 항목이 템플리트가 될 수 있습니다. 필요에 따라 디렉토리를 통해 CoS 속성에 대한 액세스를 제어하거나 템플리트로 사용되는 각 항목에서 CoS 속성이 보안되는지 확인합니다.

CoS의 대상 항목 보호

계산된 CoS 속성이 생성되는 CoS 정의 범위 내의 모든 항목은 값 계산에도 사용됩니다.

CoS 속성이 대상 항목에 이미 있는 경우 CoS 메커니즘에서는 기본적으로 이 값을 무시하지 않습니다. 이 동작을 원하지 않는 경우 CoS를 정의하여 대상 항목을 무시하거나, 잠재적인 모든 대상 항목에서 CoS 속성을 보호합니다.

간접 CoS와 클래식 CoS는 모두 대상 항목의 지정자 속성을 사용합니다. 이 속성은 사용할 템플리트 항목의 DN 또는 RDN을 지정합니다. ACI를 사용하여 CoS 범위 전체에서 이 속성을 전역적으로 보호하거나 각 대상 항목에서 필요에 따라 개별적으로 보호해야 합니다.

기타 종속성 보호

생성된 다른 CoS 속성 및 역할을 기준으로 계산된 CoS 속성을 정의할 수 있습니다. 계산된 CoS 속성을 보호하려면 이러한 종속성을 파악하여 보호해야 합니다.

예를 들어 대상 항목의 CoS 지정자 속성이 nsRole일 수 있습니다. 따라서 ACI를 사용하여 역할 정의도 함께 보호해야 합니다.

일반적으로 계산된 속성 값 계산에 포함되는 모든 속성이나 항목은 읽기 및 쓰기 액세스 제어를 위한 ACI가 있어야 합니다. 따라서 복잡한 종속성을 체계적으로 계획하거나 간소화하여 이후의 액세스 제어 구현 시의 복잡성을 줄여야 합니다. 다른 계산된 속성에 대한 종속성을 최소로 유지하면 디렉토리 성능이 향상되고 유지 관리가 쉬워집니다.

명령줄에서 CoS 관리

모든 구성 정보와 템플리트 데이터는 디렉토리 항목으로 저장되기 때문에 LDAP 명령줄 도구를 사용하여 CoS 정의를 구성 및 관리할 수 있습니다. 이 절에서는 명령줄에서 CoS 정의 항목과 CoS 템플리트 항목을 만드는 방법에 대해 설명합니다.

명령줄에서 CoS 정의 항목 작성

모든 CoS 정의 항목에는 LDAPsubentry 객체 클래스가 있으며 cosSuperDefinition 객체 클래스로부터 상속됩니다. 또한, 각각의 CoS 유형은 특정 객체 클래스로부터 상속되고 해당 속성을 포함합니다. 아래 표에는 CoS 정의 항목의 유형별 객체 클래스와 속성이 나와 있습니다.

표 9–1 CoS 정의 항목의 객체 클래스 및 속성


CoS 유형	CoS 정의 항목
포인터 CoS	`objectclass: top` `objectclass: LDAPsubentry` `objectclass: cosSuperDefinition` `objectclass: cosPointerDefinition` `cosTemplateDN:` `DN` `cosAttribute:` `attributeName` `override` `merge`
간접 CoS	`objectclass: top` `objectclass: LDAPsubentry` `objectclass: cosSuperDefinition` `objectclass: cosIndirectDefinition` `cosIndirectSpecifier:` `attributeName` `cosAttribute:` `attributeName` `override` `merge`
클래식 CoS	`objectclass: top` `objectclass: LDAPsubentry` `objectclass: cosSuperDefinition` `objectclass: cosClassicDefinition` `cosTemplateDN:` `DN` `cosSpecifier:` `attributeName` `cosAttribute:` `attributeName` `override` `merge`

모든 경우에 cosAttribute는 여러 값을 가집니다. 각 값은 CoS 메커니즘으로 생성되는 속성을 정의합니다.

CoS 정의 항목에서 다음 속성을 사용할 수 있습니다. 각 속성에 대한 자세한 내용은 Sun Java System Directory Server Enterprise Edition 6.2 Man Page Reference의 개별 속성을 참조하십시오.

표 9–2 CoS 정의 항목 속성


속성	CoS 정의 항목에서의 용도
`cosAttribute` `attributeName override merge`	값을 생성할 계산된 속성 이름을 정의합니다. 이 속성은 여러 값을 가지며, 각각의 값은 템플리트에서 값이 생성될 속성 이름을 나타냅니다. `override` 및 `merge` 한정자는 표 아래에 설명된 특별한 경우에 CoS 속성 값이 계산되는 방법을 지정합니다. `attributeName`에는 하위 유형이 포함될 수 없습니다. 하위 유형이 있는 속성 이름은 무시되지만 `cosAttribute`의 다른 값은 정상적으로 처리됩니다.
`cosIndirectSpecifier` `attributeName`	간접 CoS에서 값이 사용되어 템플리트 항목을 식별하는 대상 항목의 속성 이름을 정의합니다. 이름이 지정된 속성을 지정자라고 하며 각 대상 항목의 전체 DN 문자열이 포함되어야 합니다. 이 속성은 한 개의 값을 갖지만 `attributeName`은 많은 템플리트를 지정하기 위해 여러 값을 가질 수 있습니다.
`cosSpecifier` `attributeName`	클래식 CoS에서 값이 사용되어 템플리트 항목을 식별하는 대상 항목의 속성 이름을 정의합니다. 이름이 지정된 속성을 지정자라고 하며 템플리트 항목의 RDN에 있는 문자열이 포함되어야 합니다. 이 속성은 한 개의 값을 갖지만 `attributeName`은 많은 템플리트를 지정하기 위해 여러 값을 가질 수 있습니다.
`cosTemplateDN` `DN`	포인터 CoS 정의에 템플리트 항목의 전체 DN을 제공하거나 클래식 CoS 정의에 템플리트 항목의 기본 DN을 제공합니다. 한 개의 값을 갖습니다.

주 –

isMemberOf 속성을 CosSpecifier로 사용하여 정적 그룹의 모든 구성원이 계산된 공통 속성 값으로부터 자동으로 상속되도록 만들 수 없습니다.

cosAttribute 속성은 CoS 속성 이름 뒤에 두 개의 한정자(override 한정자 및 merge 한정자)를 허용합니다.

override 한정자는 CoS에 의해 동적으로 생성되는 속성이 항목에 이미 있는 경우의 동작을 설명합니다. override 한정자는 다음 중 하나입니다.

default(한정자 없음) - 항목에 저장된 실제 속성 값이 계산된 속성과 같은 유형이면 서버에서 실제 속성 값을 무시하지 않음을 나타냅니다.
override - 값이 항목과 함께 저장되더라도 서버는 항상 CoS에 의해 생성된 값을 반환함을 나타냅니다.
operational - 속성이 검색에서 명시적으로 요청되는 경우에만 반환됨을 나타냅니다. 작동 가능 속성은 스키마 검사를 통과하지 않아도 반환될 수 있습니다. operational 한정자는 override 한정자와 동일하게 작동합니다.

스키마에서 작동 가능으로 정의된 속성만 작동 가능으로 설정할 수 있습니다. 예를 들어 CoS에서 description 속성 값을 생성한 경우 description 속성은 스키마에서 작동 가능으로 표시되지 않았으므로 operational 한정자를 사용할 수 없습니다.

merge 한정자가 없거나 merge-schemes입니다. 이 한정자는 계산된 CoS 속성이 여러 템플리트나 여러 CoS 정의에서 여러 값을 가질 수 있도록 허용합니다. 자세한 내용은 여러 값을 갖는 CoS 속성을 참조하십시오.

실제 속성 값 무시

아래 명령을 실행하여 override 한정자가 있는 포인터 CoS 정의 항목을 만들 수 있습니다.

dn: cn=pointerCoS,dc=example,dc=com
objectclass: top
objectclass: LDAPsubentry
objectclass: cosSuperDefinition
objectclass: cosPointerDefinition
cosTemplateDn: cn=exampleUS,cn=data
cosAttribute: postalCode override

이 포인터 CoS 정의 항목은 해당 항목이 postalCode 속성 값을 생성하는 템플리트 항목 cn=exampleUS,cn=data과 관련되어 있음을 나타냅니다. 또한 override 한정자는 해당 속성이 대상 항목에 있는 경우 postalCode 속성 값보다 우선함을 나타냅니다.

주 –

CoS 속성이 operational 또는 override 한정자로 정의되는 경우 CoS 범위 내의 항목에 있는 해당 항목의 "실제" 값에 대해 쓰기 작업을 수행할 수 없습니다.

여러 값을 갖는 CoS 속성

merge-schemes 한정자를 지정하면 생성된 CoS 속성은 다음 두 가지 방법으로 여러 값을 가질 수 있습니다.

간접 CoS나 클래식 CoS에서 대상 항목의 지정자 속성은 여러 값을 가질 수 있습니다. 이 경우, 각각의 값은 템플리트를 지정하고 각 템플리트의 값이 생성된 값에 포함됩니다.
모든 유형에서 cosAttribute에 동일한 속성 이름이 포함된 여러 개의 CoS 정의 항목이 있을 수 있습니다. 이 경우, 모든 정의에 merge-schemes 한정자가 포함되어 있으면 생성된 속성에는 각 정의에서 계산된 값이 모두 포함됩니다.

두 경우가 함께 발생하여 더 많은 값을 정의할 수도 있습니다. 하지만 중복 값은 항상 생성된 속성에 한 번만 반환됩니다.

merge-schemes 한정자가 없는 경우, 템플리트 항목의 cosPriority 속성을 사용하여 생성된 속성에 대해 모든 템플리트에 지정되는 한 개의 값을 결정합니다. 이 시나리오에 대해서는 다음 절에서 설명합니다.

merge-schemes 한정자는 대상에서 정의된 "실제" 값과 템플리트에서 생성된 값을 병합하지 않습니다. merge 한정자는 override 한정자와 별개로 작동하므로 모든 쌍이 가능하며 각 한정자의 동작은 상호 보충됩니다. 또한 순서에 상관 없이 속성 이름 뒤에 한정자를 지정할 수 있습니다.

주 –

한 속성에 여러 개의 CoS 정의가 있는 경우 모두 동일한 override 및 merge 한정자를 사용해야 합니다. CoS 정의에 여러 개의 한정자 쌍이 있으면 한 개의 쌍이 임의로 선택되어 모든 정의에서 사용됩니다.

CoS 속성 우선 순위

여러 CoS 정의가 있거나 여러 값을 가진 한정자가 있지만 merge-schemes 한정자가 없는 경우 디렉토리 서버는 우선 순위 속성을 사용하여 계산된 속성의 단일 값을 정의하는 단일 템플리트를 선택합니다.

cosPriority 속성은 모든 템플리트 중에서 특정 템플리트의 전역 우선 순위를 나타냅니다. 우선 순위 0(제로)이 가장 높은 우선 순위입니다. cosPriority 속성이 없는 템플리트는 가장 낮은 우선 순위로 간주됩니다. 두 개 이상의 템플리트가 속성 값을 제공하지만 우선 순위가 같은 경우(또는 없는 경우)에는 임의로 값이 선택됩니다.

merge-schemes 한정자를 사용하는 경우 템플리트 우선 순위는 고려되지 않습니다. 병합하는 경우에는 정의된 우선 순위에 관계 없이 해당되는 모든 템플리트가 값을 정의합니다. 다음 절에 설명된 것처럼 cosPriority 속성은 CoS 템플리트 항목에 정의됩니다.

주 –

cosPriority 속성에 음수 값은 지정할 수 없습니다. 또한 간접 CoS에서 생성된 속성은 우선 순위를 지원하지 않습니다. 간접 CoS 정의의 템플리트 항목에는 cosPriority를 사용하지 마십시오.

명령줄에서 CoS 템플리트 항목 작성

포인터 CoS 또는 클래식 CoS를 사용할 경우 템플리트 항목에 LDAPsubentry 및 cosTemplate 객체 클래스가 포함되어 있습니다. 이 항목은 특별히 CoS 정의에 대해 작성되어야 합니다. CoS 템플리트 항목을 LDAPsubentry 객체 클래스의 한 인스턴스로 만들면 구성 항목에 영향을 받지 않고 일반 검색을 수행할 수 있습니다.

간접 CoS 기법의 템플리트는 디렉토리에 있는 임의의 기존 항목으로,대상을 미리 식별하거나 LDAPsubentry 객체 클래스를 제공할 필요는 없지만 보조 cosTemplate 객체 클래스가 있어야 합니다. 간접 CoS 템플리트는 계산된 속성과 해당 값을 생성하기 위해 CoS를 평가할 때만 액세스됩니다.

CoS 템플리트에는 대상 항목의 CoS에서 생성된 속성과 값이 항상 포함되어 있어야 합니다. 속성 이름은 CoS 정의 항목의 cosAttribute 속성에 지정됩니다.

아래 예에서는 postalCode 속성을 생성하는 포인터 CoS에 대한 가장 높은 우선 순위의 템플리트 항목을 보여줍니다.

dn: cn=ZipTemplate,ou=People,dc=example,dc=com
objectclass: top
objectclass: LDAPsubentry
objectclass: extensibleobject
objectclass: cosTemplate
postalCode: 95054
cosPriority: 0

다음 절에서는 템플리트 항목 예 및 CoS 정의 항목의 유형별 예를 제공합니다.

포인터 CoS 예

다음 명령은 cosPointerDefinition 객체 클래스를 가진 포인터 CoS 정의 항목을 만듭니다. 이 정의 항목은 이전 절의 예에 설명된 CoS 템플리트 항목을 사용하여 ou=People,dc=example,dc=com 트리의 모든 항목에 대한 공통 우편 번호를 공유합니다.

$ ldapmodify -a -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w -
dn: cn=pointerCoS,ou=People,dc=example,dc=com
objectclass: top
objectclass: LDAPsubentry
objectclass: cosSuperDefinition
objectclass: cosPointerDefinition
cosTemplateDn: cn=ZipTemplate,ou=People,dc=example,dc=com
cosAttribute: postalCode

CoS 템플리트 항목(cn=ZipTemplate,ou=People,dc=example,dc=com)은 postalCode 속성에 저장된 값을 ou=People,dc=example,dc=com 접미어에 있는 모든 항목에 제공합니다. 아래 명령을 실행하여 같은 하위 트리에서 우편 번호가 없는 항목을 검색하면 생성된 속성 값이 표시됩니다.

$ ldapsearch -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - \
 -b "ou=People,dc=example,dc=com" -s sub "(cn=*Jensen)"
dn: cn=Babs Jensen,ou=People,dc=example,dc=com
cn: Babs Jensen
...
postalCode: 95054

간접 CoS 예

간접 CoS는 cosIndirectSpecifier 속성의 속성 이름을 지정하여 각 대상에 고유한 템플리트를 찾습니다. 간접 CoS의 템플리트 항목은 다른 사용자 항목을 포함하여 디렉토리에 있는 모든 항목이 될 수 있습니다. 이 예에서 간접 CoS는 대상 항목의 manager 속성을 사용하여 CoS 템플리트 항목을 식별합니다. 템플리트 항목은 관리자의 사용자 항목입니다. 관리자의 사용자 항목은 생성할 속성 값을 포함합니다. 이 경우 값은 departmentNumber의 값입니다.

다음 명령은 cosIndirectDefinition 객체 클래스를 포함하는 간접 CoS 정의 항목을 만듭니다.

$ ldapmodify -a -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w -
dn: cn=generateDeptNum,ou=People,dc=example,dc=com
objectclass: top
objectclass: LDAPsubentry
objectclass: cosSuperDefinition
objectclass: cosIndirectDefinition
cosIndirectSpecifier: manager
cosAttribute: departmentNumber

그런 다음, cosTemplate 객체 클래스를 템플리트 항목에 추가하고 이 항목이 생성될 속성을 정의하는지 확인합니다. 이 예에서는 모든 관리자 항목이 템플리트입니다.

$ ldapmodify -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w -
dn: cn=Carla Fuentes,ou=People,dc=example,dc=com
changetype: modify
add: objectclass
objectclass: cosTemplate
-
add: departmentNumber
departmentNumber: 318842

이 CoS를 사용하면 manager 속성이 포함된 대상 항목(ou=People,dc=example,dc=com 아래의 항목)에 자동으로 해당 관리자의 부서 번호가 지정됩니다. departmentNumber 속성은 서버에 없기 때문에 대상 항목에 대해 계산됩니다. 그러나 departmentNumber 속성은 대상 항목의 일부로 반환됩니다. 예를 들어 Babs Jensen의 관리자가 Carla Fuentes로 정의된 경우 해당 부서 번호는 다음과 같습니다.

$ ldapsearch -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - \
 -b "ou=People,dc=example,dc=com" -s sub "(cn=*Jensen)"
dn: cn=Babs Jensen,ou=People,dc=example,dc=com
cn: Babs Jensen
...
manager: cn=Carla Fuentes,ou=People,dc=example,dc=com
departmentNumber: 318842

클래식 CoS 예

이 예에서는 클래식 CoS로 우편 주소를 생성하는 방법을 보여줍니다. 생성된 값은 CoS 정의의 cosTemplateDN 및 cosSpecifier 속성 값 조합으로 배치되는 템플리트 항목에 지정됩니다. 다음 명령은 cosClassicDefinition 객체 클래스를 사용하여 정의 항목을 만듭니다.

$ ldapmodify -a -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w -
dn: cn=classicCoS,dc=example,dc=com
objectclass: top
objectclass: LDAPsubentry
objectclass: cosSuperDefinition
objectclass: cosClassicDefinition
cosTemplateDn: ou=People,dc=example,dc=com
cosSpecifier: building
cosAttribute: postalAddress

같은 명령을 실행하여 각 건물의 우편 주소를 제공하는 템플리트 항목을 만듭니다.

dn: cn=B07,ou=People,dc=example,dc=com
objectclass: top
objectclass: LDAPsubentry
objectclass: extensibleobject
objectclass: cosTemplate
postalAddres: 7 Old Oak Street, Anytown, CA 95054

이 CoS를 사용하면 building 속성이 포함된 대상 항목(ou=People,dc=example,dc=com 아래의 항목)에 자동으로 해당 우편 주소가 지정됩니다. CoS 기법은 RDN에 지정자 속성 값이 있는 템플리트 항목을 검색합니다. 이 예에서 Babs Jensen이 건물 B07에 지정되어 있으면 우편 주소는 다음과 같이 생성됩니다.

$ ldapsearch -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - \
 -b "ou=People,dc=example,dc=com" -s sub "(cn=*Jensen)"
dn: cn=Babs Jensen,ou=People,dc=example,dc=com
cn: Babs Jensen
...
building: B07
postalAddress: 7 Old Oak Street, Anytown, CA 95054

역할 기반의 속성 작성

항목의 역할을 기반으로 항목에 대한 속성 값을 생성하는 클래식 CoS 체계를 만들 수 있습니다. 예를 들어 역할 기반의 속성을 사용하여 서버에서 항목별 제한을 조회하도록 설정할 수 있습니다.

역할 기반의 속성을 만들려면 nsRole 속성을 클래식 CoS의 CoS 정의 항목에 있는 cosSpecifier로 사용합니다. nsRole 속성은 여러 값을 가질 수 있으므로 두 개 이상의 템플리트 항목이 있는 CoS 체계를 정의할 수 있습니다. 사용할 템플리트 항목을 명확히 지정하기 위해 CoS 템플리트 항목에 cosPriority 속성을 추가할 수 있습니다.

예를 들어 관리자 역할의 구성원이 표준 메일함 할당량을 초과할 수 있도록 허용하는 CoS를 작성할 수 있습니다. 관리자 역할은 다음과 같습니다.

dn: cn=ManagerRole,ou=People,dc=example,dc=com
objectclass: top
objectclass: LDAPsubentry
objectclass: nsRoleDefinition
objectclass: nsComplexRoleDefinition
objectclass: nsFilteredRoleDefinition
cn: ManagerRole
nsRoleFilter: (isManager=True)
Description: filtered role for managers

클래식 CoS 정의 항목은 다음과 같이 만들어집니다.

dn: cn=generateManagerQuota,ou=People,dc=example,dc=com
objectclass: top
objectclass: LDAPsubentry
objectclass: cosSuperDefinition
objectclass: cosClassicDefinition
cosTemplateDn: cn=managerCOS,ou=People,dc=example,dc=com
cosSpecifier: nsRole
cosAttribute: mailboxquota override

CoS 템플리트 이름은 cosTemplateDn과 nsRole 값(역할 DN)의 조합이어야 합니다. 예를 들면 다음과 같습니다.

dn:cn="cn=ManagerRole,ou=People,dc=example,dc=com",\
 cn=managerCOS,ou=People,dc=example,dc=com
objectclass: top
objectclass: LDAPsubentry
objectclass: extensibleobject
objectclass: cosTemplate
mailboxquota: 1000000

CoS 템플리트 항목은 mailboxquota 속성 값을 제공합니다. override 한정자를 추가하면 CoS는 대상 항목에 있는 기존의 mailboxquota 속성 값을 모두 무시합니다. 역할 구성원인 대상 항목에는 다음과 같이 역할 및 CoS에서 생성된 계산된 속성이 지정됩니다.

$ ldapsearch -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w -\
 -b "ou=People,dc=example,dc=com" -s sub "(cn=*Fuentes)"
dn: cn=Carla Fuentes,ou=People,dc=example,dc=comcn: Carla Fuentes
isManager: TRUE...nsRole: cn=ManagerRole,ou=People,dc=example,dc=com
mailboxquota: 1000000

주 –

역할 항목과 CoS 정의 항목은 해당 범위에 동일한 대상 항목이 포함되도록 디렉토리 트리에서 같은 위치에 있어야 합니다. CoS 대상 항목도 같은 위치에 있어야만 검색 및 유지 관리가 용이합니다.

CoS 플러그인 모니터

디렉토리 서버에서는 CoS 플러그인의 특정 특성을 모니터할 수 있습니다. CoS 모니터링 속성은 cn=monitor,cn=Class of Service,cn=plugins,cn=config 항목 아래에 저장됩니다. 이 항목 아래의 각 속성과 해당 속성이 제공하는 정보에 대한 자세한 내용은 Sun Java System Directory Server Enterprise Edition 6.2 Man Page Reference를 참조하십시오.

CoS 로깅 설정

디렉토리 서버는 해당하는 여러 정의 항목을 임의로 구별할 경우 경고 메시지를 기록합니다. 경고 메시지의 형식은 다음과 같습니다.

Definition /defDN1/ and definition /defDN2/ compete to provide attribute
 '/type/' at priority /level/

서버에서 해당하는 여러 정의 항목을 임의로 구별하려는 경우 정보 메시지를 기록하도록 디렉토리 서버를 구성할 수도 있습니다. 이렇게 하려면 플러그인의 메시지를 포함할 오류 로그를 설정합니다.

주 –

추가 로그 수준을 설정하면 로깅 부하가 높아질 수 있으므로 생산 서버에서는 로깅을 설정하지 않을 수 있습니다.

정보 메시지의 내용은 다음과 같습니다.

Definition /defDN1/ and definition /defDN2/ potentially compete 
to provide attribute '/type/' at priority /level/

그런 다음, 정의 항목에서 CoS 우선 순위를 적절하게 설정하여 해당 CoS의 모호성을 해결할지를 선택할 수 있습니다.

참조 무결성 유지

참조 무결성은 항목 간의 관계가 유지되는지를 확인하는 플러그인 메커니즘입니다. 그룹 구성원의 속성과 같은 일부 속성 유형에는 다른 항목의 DN이 포함되어 있습니다. 참조 무결성을 사용하면 항목을 제거할 때 해당 DN이 포함된 모든 속성도 함께 제거됩니다.

예를 들어 사용자 항목을 디렉토리에서 제거하고 참조 무결성을 사용 가능하게 하면 사용자가 구성원인 모든 그룹에서 해당 사용자가 제거됩니다. 참조 무결성을 사용하지 않으면 관리자가 수동으로 이 사용자를 그룹에서 제거해야 합니다. 이 기능은 사용자 및 그룹 관리를 위해 디렉토리를 사용하는 디렉토리 서버와 다른 Sun Java System 제품을 통합하는 경우에 유용합니다.

참조 무결성 작동 방식

활성화된 참조 무결성 플러그인은 삭제, 이름 바꾸기 또는 이동 작업 후 즉시 지정된 속성에 대해 무결성 업데이트를 수행합니다. 기본적으로 참조 무결성 플러그인은 사용되지 않습니다.

디렉토리에서 사용자 또는 그룹 항목을 삭제하거나 이름을 바꾸거나 이동할 때마다 작업이 참조 무결성 로그 파일에 기록됩니다.

instance-path/logs/referint

업데이트 간격이라는 지정된 시간 후에 서버는 참조 무결성이 활성화된 모든 속성에 대해 검색을 수행하고 검색 결과에 표시된 항목과 로그 파일에 있는 삭제 또는 수정된 항목의 DN을 비교합니다. 로그 파일에 항목이 삭제되었다고 표시되면 해당 속성은 삭제됩니다. 로그 파일에 항목이 변경되었다고 표시되면 해당 속성 값도 이에 따라서 수정됩니다.

참조 무결성 플러그인의 기본 구성이 활성화되면 삭제, 이름 바꾸기 또는 이동 작업을 수행한 후에 즉시 member, uniquemember, owner, seeAlso 및 nsroledn 속성에 대한 무결성 업데이트를 수행합니다. 하지만 사용자 요구에 맞게 참조 무결성 플러그인의 동작을 구성할 수 있습니다. 다음 동작을 구성할 수 있습니다.

참조 무결성 업데이트를 다른 파일에 기록합니다.
업데이트 간격을 수정합니다.

참조 무결성 업데이트로 인한 시스템 영향을 줄이려면 업데이트 간격을 늘리는 것이 좋습니다.
참조 무결성을 적용할 속성을 선택합니다.

DN 값이 포함된 속성을 사용하거나 정의하는 경우 참조 무결성 플러그인에서 이러한 속성을 모니터하도록 설정하는 것이 좋습니다.

참조 무결성 플러그인을 구성하는 방법

주 –

참조 무결성 플러그인에 사용되는 모든 데이터베이스의 모든 속성을 색인화해야 합니다. 모든 데이터베이스 구성에 색인을 만들어야 합니다. 레트로 변경 로그가 활성화되면 cn=changelog 접미어를 색인화해야 합니다. 자세한 내용은 12 장, 디렉토리 서버 색인화를 참조하십시오.

복제 환경에서 참조 무결성 플러그인을 사용하는 경우 다음과 같은 몇 가지 제한 사항이 있습니다. 제한 목록은 복제 및 참조 무결성을 참조하십시오.

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

모든 복제본이 구성되고 모든 복제 계약이 정의되어 있는지 확인합니다.

참조 무결성을 유지할 속성 집합과 마스터 서버에서 사용할 업데이트 간격을 결정합니다.

모든 마스터 서버에서 동일한 속성 집합과 업데이트 간격을 사용하여 참조 무결성 플러그인을 활성화합니다.
- 참조 무결성을 위한 속성을 정의하려면 다음 명령을 사용합니다.
  $ dsconf set-server-prop -h host -p port ref-integrity-attr:attribute-name \ ref-integrity-attr:attribute-name
- 참조 무결성 속성을 기존 속성 목록에 추가하려면 이 명령을 사용합니다.
  $ dsconf set-server-prop -h host -p port ref-integrity-attr+:attribute-name
- 참조 무결성 업데이트 간격을 정의하려면 다음 명령을 사용합니다.
  $ dsconf set-server-prop -h host -p port ref-integrity-check-delay:duration
- 참조 무결성을 활성화하려면 다음 명령을 사용합니다.
  $ dsconf set-server-prop -h host -p port ref-integrity-enabled:on

모든 사용자 서버에서 참조 무결성 플러그인을 비활성화합니다.