컨테이너 및 나뭇잎

Active Directory Domain Services 디렉터리 계층의 루트를 제외한 모든 개체가 instance 다른 개체에 포함된 개체의 계층 구조를 포함합니다. 이 계층 구조는 디렉터리 및 파일의 파일 시스템보다 더 유연합니다. 대신 , Active Directory 스키마의 규칙은 다른 개체 클래스의 인스턴스를 포함할 수 있는 개체 클래스를 결정합니다. 예를 들어 User 개체 클래스의 기본 스키마 정의에는 가능한 상사로 Organizational-Unit 및 Container 개체 클래스가 포함됩니다. 즉, User 개체의 가능한 부모 개체 또는 컨테이너 instance. 즉, Organizational-Unit 개체는 User 개체를 포함할 수 있지만 User 클래스의 스키마 정의가 변경되지 않는 한 User 개체는 다른 User 개체를 포함할 수 없습니다.

스키마 개체, 즉 서버 포리스트에 존재할 수 있는 클래스 및 특성을 정의하는 classSchema 또는 attributeSchema 개체를 제외하고 Active Directory Domain Services 모든 개체는 컨테이너일 수 있습니다. 특히 개체 클래스 정의의 possSuperiors 또는 systemPossSuperiors 특성에 표시되는 모든 개체 클래스는 잠재적으로 컨테이너입니다. 미리 정의된 개체 클래스의 컨테이너에 대한 자세한 내용은 Active Directory Domain Services 참조를 참조하세요. 추상 스키마에 프로그래밍 방식으로 바인딩하고 IADsClass::get_Containment 또는 IADsClass::get_PossibleSuperiors 메서드를 사용하여 지정된 클래스가 포함하거나 포함할 수 있는 클래스를 가져올 수 있습니다. 자세한 내용은 추상 스키마 읽기를 참조하세요. 개체 instance 모든 개체의 possibleInferiors 특성을 읽고 개체에 포함될 수 있는 개체 클래스를 확인할 수도 있습니다. possibleInferiors는 생성된 특성입니다. 즉, 다른 클래스 정의의 possSuperiors/systemPossSuperiors 값에서 계산되며 실제로 디렉터리에 저장되지 않습니다.

Active Directory 스키마는 Container 클래스를 정의합니다. 앞에서 설명한 대로 개체가 컨테이너로 컨테이너 클래스의 instance 필요가 없습니다. Leaf 클래스도 있으며 이 클래스의 하위 클래스는 일반적으로 컨테이너가 아니지만 사용할 수 없는 이유가 없습니다.

마지막으로 개체 클래스와 연결된 표시 지정자에 플래그를 설정하여 사용자 인터페이스가 항상 클래스의 인스턴스를 컨테이너가 아닌 리프로 표시해야 함을 나타낼 수 있습니다. 이렇게 하면 사용자 인터페이스가 너무 많은 컨테이너로 인해 복잡해지는 것을 방지할 수 있습니다. 자세한 내용은 컨테이너를 리프 노드로 보기를 참조하세요.