Windows Administration

Active Directory 스키마 확장

Vikas Malhotra

한 눈에 보기:

• 기본 Active Directory 스키마 이해
• classSchema 또는 attributeSchema 개체 추가
• 개체 ID 가져오기 및 사용
• .ldif 파일을 사용하여 스키마 확장

이 기사의 코드 다운로드: Schema2008_05.exe (151KB)

Windows 2000 릴리스와 함께 Active Directory를 소개하면서 Microsoft는 고객에게 Active Directory 구현에 대한 기본 스키마 정의를 제공해 왔습니다.

Active Directory®는 Windows®에서 많은 응용 프로그램이 작성되고 구현되는 방식이 변화했음을 의미하기도 합니다. 이전에는 Microsoft® Exchange 5.5와 같은 응용 프로그램이 자체 디렉터리 구조를 가지도록 빌드되었습니다. Active Directory를 사용할 수 있게 되면서 Microsoft 및 다른 회사의 여러 응용 프로그램에서는 처음부터 자체 스키마를 빌드하는 대신 Active Directory에서 제공하는 기본 구조의 이점을 이용하기 시작했습니다.

이러한 응용 프로그램은 Active Directory에서 제공하는 기본 아키텍처로 시작하여 필요에 따라 이를 확장했습니다. 예를 들어 Microsoft Exchange 2000은 메시징 구현을 위해 Active Directory를 이용함으로써 Microsoft 메시징 아키텍처의 미래를 정의합니다.

현재 Active Directory 환경에서 작동하도록 작성된 많은 응용 프로그램이 기본 스키마를 사용하여 작동하며 필요에 따라 자체 변경 내용을 스키마로 정의하는 경우도 많습니다. 물론 이렇게 하려면 확장 가능한 스키마가 필요하며 이 기사에서는 이러한 스키마에 대해 다룹니다. 또한 많은 응용 프로그램이 Active Directory의 기본 정의에 종속되기 때문에 핵심 스키마의 지속적인 안정성은 매우 중요합니다. 응용 프로그램 대부분은 같은 Active Directory의 다른 응용 프로그램과 함께 작동해야 하므로 한 응용 프로그램에 대한 변경이 다른 응용 프로그램에 영향을 미치지 않아야 합니다.

스키마란?

Active Directory 스키마의 개념을 정확히 모르는 경우가 종종 있을 수 있으며 스키마를 직접 수정하는 작업이 어려워 보일 수도 있습니다. 물론 Active Directory 스키마를 확장하는 작업을 자주 해야 하는 것은 아니지만 특정 응용 프로그램이나 비즈니스 필요에 따라 자주 확장해야 할 수도 있습니다. 따라서 Active Directory는 많은 조직에 있어 핵심 자산이며 잘못된 업데이트로 오작동이 발생하면 심각한 영향을 미칠 수 있기 때문에 스키마가 무엇이며 여기에 무엇이 포함되는지 정확하게 이해하는 것이 매우 중요합니다.

Active Directory 스키마를 확장하는 대신 사용자 지정된 스키마 정의를 직접 테스트하거나 구현하는 작업에 대한 대안으로 Windows Server® 2008의 ADLDS(Active Directory Lightweight Directory Service) 또는 Windows Server 2003의 ADAM(Active Directory Application Mode)의 사용을 고려하는 조직이 많습니다.

스키마는 디렉터리 서비스에 대한 형식을 제공하는 기본 구조입니다. Active Directory 스키마는 ADDS(Active Directory Domain Services)에서 사용되는 개체 클래스 및 특성을 정의합니다. 핵심 스키마는 잘 알려진 다양한 클래스(예: 사용자, 컴퓨터 및 organizationalUnit) 및 특성(예; telephoneNumber 및 objectSID)에 대한 정의를 제공합니다. 핵심 스키마 정의의 개체를 범주 1 개체라고 하며 추가되는 개체를 범주 2 개체라고 합니다.

Active Directory 스키마는 경로 cn=Schema,cn=Configuration,dc=X에 정의된 컨테이너에서 찾을 수 있습니다. 여기서 X는 Active Directory 포리스트의 네임스페이스입니다. Active Directory 포리스트에는 하나의 스키마만 포함됩니다. 포리스트에서 스키마 정의를 변경하면 해당 포리스트의 모든 도메인에 영향을 미칩니다. 그림 1은 여러 버전의 Windows Server에서 Active Directory 스키마에 추가되는 클래스 및 특성의 수를 보여 줍니다.

Figure 1 클래스 및 특성 수

여러 Windows Server 버전에 대한 스키마 업데이트는 Adprep라는 유틸리티를 사용하여 수행합니다. Windows Server 2003 R2 업데이트에서 스키마 버전은 31로 업데이트되며 Windows Server 2008에서는 44로 변경됩니다.

ADSIEdit와 같은 도구를 사용하여 Active Directory에서 cn=Schema,cn=Configuration,dc=X의 objectVersion 특성 값을 검사하면 버전을 확인할 수 있습니다. Exchange Server, SMS(System Management Server) 또는 Active Directory에 종속적인 기타 응용 프로그램에서는 응용 프로그램 필요에 따라 스키마를 수정할 수 있습니다.

기본 구성 요소

Active Directory는 classSchema(줄여서 클래스)와 attributeSchema(줄여서 특성)의 두 종류의 개체로 구성됩니다. 일반적으로 조직에서는 기존 스키마에서 사용할 수 없는 특정 특성으로 데이터를 저장하려고 할 때 Active Directory 스키마의 확장을 고려합니다. 먼저 스키마 컨테이너에 attributeSchema 개체를 지정한 다음 새 개체에 필요한 속성을 정의하여 Active Directory 스키마에 특성을 만들 수 있습니다.

attributeSchema 개체의 속성 목록과 이에 대한 정보를 보려면 go.microsoft.com/fwlink/?LinkId=110445를 참조하십시오. 여기서 볼 수 있듯이 attributeSchema 개체에 대해 정의할 수 있는 속성은 여러 가지이며 이들 속성 중 대부분이 필수입니다.

일반적인 특성 이외에도 정방향 링크 및 역방향 링크를 제공하여 한 쌍으로 구현되는 Linked라는 특수한 특성도 스키마 내에 있습니다. Active Directory의 그룹 구성원을 예로 들 수 있습니다. 그룹의 구성원 특성(예를 들어 John Doe라는 구성원이 있는 ContosoEmployees 그룹)은 정방향 링크이며 구성원 개체의 해당 memberOf 특성은 역방향 링크입니다. 예를 들어 John Doe의 memberOf 특성을 쿼리하면 ContosoEmployees 그룹의 고유 이름(DN)이 계산됩니다.

정방향 링크는 다른 특성과 매우 비슷하게 동작합니다. 그룹 구성원으로 여러 개체가 포함될 수 있는 구성원 특성과 마찬가지로, 값은 단일 값이거나 다중 값일 수 있으며 디렉터리에 부모 개체와 함께 저장됩니다.

반면에 역방향 링크는 참조 무결성을 보장하기 위해 시스템에서 유지됩니다. 역방향 링크 특성의 값을 쿼리하면 결과는 일치하는 모든 정방향 링크 값에서 계산됩니다. 역방향 링크는 항상 다중 값입니다.

ADDS의 각 개체 클래스는 스키마 컨테이너의 classSchema 개체로 정의됩니다. classSchema 개체를 정의하는 데 필수적인 특성 목록은 go.microsoft.com/fwlink/?LinkId=110445에서 확인할 수 있습니다.

클래스에는 Structural, Abstract 및 Auxiliary의 세 가지 형식이 있습니다. 이 형식은 objectClassCategory 특성 값으로 정의됩니다. 88이라는 네 번째 범주에는 X.500 1993 표준 이전에 정의된 클래스가 포함됩니다. 이러한 클래스 형식은 objectClassCategory 특성에서 0 값으로 지정됩니다. 이 클래스 형식은 더 이상 정의되지 않아야 합니다.

ID 가져오기 및 사용

디렉터리의 각 classSchema 및 attributeSchema 개체 ID는 classSchema 개체의 governsID와 attributeSchema 개체의 attributeID에 대해 정의되는 필수 OID(개체 ID)를 사용하여 정의됩니다. 이 ID는 특정 발행 기관에서 개체 식별을 위해 제공하는 고유한 숫자 값입니다. 숫자 지정은 LDAP 프로토콜의 정의(RFC 2251)에 의해 구성됩니다. Active Directory 스키마의 일부 OID는 ISO(국제 표준화 기구)에서 발행하며 나머지 일부 OID는 Microsoft에서 발행합니다. OID는 디렉터리 내의 개체에 대해 고유해야 합니다.

OID는 그림 2에서처럼 1.2.840.113556.1.y.z와 같은 숫자 문자열입니다. 예를 들어 사용자 classSchema 개체의 OID는 1.2.840.113556.1.5.9입니다.

Figure 2 사용자 개체에 대한 ID

조직에서는 스키마를 확장하려고 할 때 자체 OID 루트 번호를 가져와서 OID가 고유한지 확인합니다. 이 루트 번호에서 분기하여 조직에서 만드는 새 개체 클래스와 특성에 고유한 ID를 제공합니다. OID 루트는 ISO NRA(National Registration Authority)에서 직접 가져올 수 있습니다. 미국의 경우 NRA는 ANSI(American National Standards Institute)입니다.

ansi.org에서 루트 OID를 가져오기 위한 절차와 비용 일정을 참조할 수 있습니다. 다른 지역의 경우는 해당 ISO 회원 조직에 문의하십시오. ISO에서 제공하는 목록은 iso.org/iso/about/iso_members.htm에서 확인할 수 있습니다.

이전에는 조직에서 schemreg@microsoft.com으로 전자 메일을 보내 Microsoft로부터 OID를 얻을 수 있었습니다. 하지만 이제는 go.microsoft.com/fwlink/?LinkId=110453에서 VBScript를 다운로드하여 실행하도록 요청자를 안내하는 자동 회신이 전송됩니다.

Microsoft에서 발행하는 OID의 경우에는 Microsoft OID 번호 공간인 1.2.840.113556.1.8000.x 아래에 번호가 할당됩니다. 여기서 x는 조직에 할당된 고유한 번호입니다. 조직에서는 이 OID를 추가 분할하여 개체를 지정할 수 있습니다. 따라서 조직에서는 새 classSchema 개체에 1.2.840.113556.1.8000.x.1.y를 사용하고 attributeSchema 개체에 1.2.840.113556.1.8000.x.2.z를 사용할 수 있습니다. 여기서 x는 조직의 고유 번호를 나타내며 y와 z는 각각 특정 classSchema 및 attributeSchema 개체에 할당된 번호입니다. 이들 개체의 이름에는 서로 구분할 수 있도록 조직 고유의 접두사를 사용하는 것이 좋습니다.

연결된 특성 정의

정방향 링크의 attributeSyntax 값은 2.5.5.1, 2.5.5.7 또는 2.5.5.14가 되어야 합니다. 이들 값은 Object (DS-DN) 구문과 같은 고유 이름이 포함된 구문에 해당합니다.

역방향 링크의 attributeSyntax 값은 Object (DS-DN) 구문인 2.5.5.1이어야 합니다. 관례에 따라 역방향 링크 특성은 최상위 추상 클래스의 mayContain 값에 추가됩니다. 이렇게 하면 역방향 링크 특성이 실제로 개체와 함께 저장되지 않고 정방향 링크 값을 기반으로 계산되기 때문에 모든 클래스의 개체에서 역방향 링크 특성을 읽을 수 있습니다.

Windows Server 2003에는 조직이 스키마의 두 개체를 연결하는 데 사용할 수 있는 기능인 linkID 자동 생성이 추가되었습니다. 특성의 linkID 특성이 1.2.840.113556.1.2.50으로 설정될 경우 시스템에서는 이 기능을 통해 자동으로 새로 연결된 특성의 linkID를 생성합니다. 해당 역방향 링크는 linkID를 정방향 링크의 attributeId 또는 ldapDisplayName으로 설정하여 생성됩니다. 정방향 링크를 만든 후와 역방향 링크를 만들기 전에 스키마 캐시를 다시 로드해야 합니다. 그렇지 않으면 역방향 링크가 만들어질 때 정방향 링크의 attributeId 또는 ldapDisplayName을 찾을 수 없습니다. 스키마 캐시는 필요할 때, 즉 스키마가 변경되고 몇 분 후 또는 도메인 컨트롤러가 다시 부팅되었을 때 다시 로드됩니다.

Active Directory가 Windows 2000 수준에 있는 경우에는 schemreg@microsoft.com으로 전자 메일을 보내 Microsoft에 linkID를 요청해야 합니다. 자동 회신 안에는 "E-mails sent to schemreg@microsoft.com will be processed only if they are related to linkID registrations for legacy environments"라는 줄이 있습니다. 여기서 전자 메일에는 회사 이름, 연락처 이름, 전자 메일 주소, 전화 번호, 등록된 접두사(적용 가능한 경우), 등록된 OID(적용 가능한 경우) 등의 정보가 포함됩니다.

스키마 확장 준비

Active Directory 스키마를 확장하기로 결정했다고 가정하겠습니다. 이 분석에서는 ADLDS(또는 Windows Server 2003에서는 ADAM)를 사용하여 구현되는 대체 디렉터리가 요구 사항에 맞지 않음을 확인한 후 그 사용을 고려하지 않을 수 있습니다. 다음 단계에서는 스키마에 추가할 새 attributeSchema 개체를 식별하고 이 과정에서 이 새 개체를 지정하는 모든 필수 값(예: cn, ldapDisplayName 등)을 정의합니다. 개체의 특성 값을 정의하면서 Microsoft 또는 다른 소스에서 OID를 받습니다. 기본적으로 위 내용을 비즈니스 요구 사항 및 기술 사양으로 문서화했습니다. 또한 실제 Active Directory와 비슷한 랩 환경을 구현하고 테스트할 준비를 완료했습니다.

실제로 많은 조직에서는 이러한 변경을 승인하거나 거부하고 이를 구현하기 위한 프로세스를 수립하는 위원회를 구성하고 있습니다. Active Directory는 많은 조직에서 권한 정보 소스로 사용되며 변경을 적용한 후에도 지속적으로 정상 작동해야 하기 때문에 이러한 검사와 조정 절차는 필수입니다.

조직에서 변경을 진행하기로 결정한 경우에는 이 프로젝트에 대한 테스트 및 구현 계획을 정의해야 합니다. MMC(Microsoft Management Console) 내에서 Active Directory 스키마 스냅인을 사용하거나 프로그래밍 방식 또는 준프로그래밍 방식을 사용하여 새 개체를 추가함으로써 스키마를 확장할 수 있습니다. LDIFDE를 사용하여 .ldif 형식 파일을 가져오거나, CSVDE를 사용하여 .csv 형식 파일을 가져오거나, Active Directory Service Interfaces, ADSI, 스크립팅을 사용하는 경우를 예로 들 수 있습니다.

어떤 방식을 사용하든지 이 기능은 Active Directory 포리스트에서 스키마 마스터의 FSMO(신축 단일 마스터 작업) 역할에 연결하거나 이 역할을 저장하는 서버에서 수행되어야 합니다. 또한 스키마 업데이트에 사용하는 계정에는 충분한 관리 권한이 있어야 업데이트를 수행할 수 있으므로 해당 계정을 Schema Administrators 그룹의 구성원으로 지정해야 합니다. 마지막으로 포리스트에 대한 스키마 업데이트를 사용하도록 설정해야 합니다(기본적으로 사용하지 않도록 설정되어 있음).

변경이 매우 단순한 경우 이외에는 테스트 구현 및 프로덕션 구현 단계 사이의 표준화를 향상시키고 단계를 수동으로 수행할 때 발생할 수 있는 유형의 오류를 줄이기 위해 자동화된 방식으로 변경을 수행해야 합니다. 이제 LDIFDE를 사용하여 변경을 구현하기로 결정했다고 가정하겠습니다. 스키마를 확장할 때 업데이트를 적용하려면 새 특성과 클래스를 추가하고 클래스에 새 특성을 추가한 다음 캐시 다시 로드를 트리거합니다. 몇 가지 시나리오를 살펴보겠습니다.

특성 추가

설명을 위해 Contoso라는 조직에서 각 직원의 신발 크기를 식별하는 특성을 Active Directory에 추가하고자 한다고 가정하겠습니다. Active Directory 포리스트에는 contoso.com과 employees.contoso.com의 두 가지 도메인이 있습니다. 여기서 중요한 점은 사용자 지정 클래스 정의를 사용하여 만들어지는 모든 개체에 이 새 특성이 포함되어야 한다는 것입니다.

같은 포리스트에 있기 때문에 스키마 변경은 두 도메인 모두에 영향을 미친다는 점을 염두에 두어야 합니다. Microsoft에서 1.2.840.113556.8000.9999의 OID를 받았으며 이를 Contoso의 classSchema 개체에 대한 1.2.840.113556.8000.9999.1과 attributeSchema 개체에 대한 1.2.840.113556.8000.9999.2로 다시 나누었다고 가정하겠습니다. 이제 그림 3에서처럼 이 새 개체에 대한 모든 특성 값을 정의하려고 합니다.

Figure 3 contosoEmpShoe 특성 정의

또한 contosoEmpShoe 특성은 사용자 클래스 개체로 만들어진 모든 개체에 사용 가능해야 하지만 사용자 클래스의 기본 정의는 수정하지 않는 것이 좋습니다. 대신 그림 4에서처럼 contosoEmpShoe로 지정된 mayContain 값이 있는 contosoUser라는 보조 클래스를 정의해야 합니다. 그런 다음 contosoUser 보조 클래스에 대해 정의된 특성을 사용자 클래스에 추가합니다.

Figure 4 contosoUser 클래스 정의

지금까지 분석을 수행하고 값을 정의했으므로 이제 그림 5의 코드와 비슷한 .ldif 파일을 만들어야 합니다. 그림 5의 내용을 메모장에 복사하고 파일을 contosoUser.ldif로 저장할 수 있습니다. 또는 technetmagazine.com에서 다운로드한 코드에서 사본을 사용할 수도 있습니다.

Figure 5 .스키마를 확장하기 위한 ldif 파일

#Attribute definition for contosoEmpShoe

dn: CN=contosoEmpShoe,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemaadd
objectClass: top
objectClass: attributeSchema
cn: contosoEmpShoe
attributeID: 1.2.840.113556.1.8000.9999.2.1
attributeSyntax: 2.5.5.12
isSingleValued: TRUE
adminDisplayName: contosoEmpShoe
adminDescription: contosoEmpShoe
oMSyntax: 64
searchFlags: 1
lDAPDisplayName: contosoEmpShoe
systemOnly: FALSE

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

# Classes

dn: CN=contosoUser,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemaadd
objectClass: top
objectClass: classSchema
cn: contosoUser
governsID: 1.2.840.113556.1.8000.9999.1.1
mayContain: contosoEmpShoe
rDNAttID: cn
adminDisplayName: contosoUser
adminDescription: contosoUser
objectClassCategory: 3
lDAPDisplayName: contosoUser
name: contosoUser
systemOnly: FALSE

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

dn: CN=User,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemamodify
add: auxiliaryClass
auxiliaryClass: contosoUser
-

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1

.ldif 파일을 생성한 후에는 랩 환경에서 구현을 완벽하게 테스트하고, 도메인과 포리스트의 종단 간 복제를 확인하며, 포리스트에서 스키마의 업데이트를 사용할 수 있도록 설정할 수 있습니다. 이 단계에서는 Schema Admin 권한이 있는 계정으로 로그인해야 합니다. 변경이 수행될 스키마 마스터에서 아웃바운드 복제를 사용하지 않도록 설정하고 다음 명령을 실행하여 .ldif 파일을 가져올 수 있습니다.

ldifde –i –f <Path>\contosoUser.ldif –b
<username> <domain> <password> -k –j. –c
"CN=schema,CN=Configuration,DC=X"
#schemaNamingContext

변경이 수행되면 스키마 마스터에서 아웃바운드 복제를 사용할 수 있도록 설정하고 모든 도메인 컨트롤러에 대해 복제가 수행되었는지 확인합니다.

이제 모두 마쳤습니다! 사용자 클래스, 즉 사용자 계정을 사용하여 만든 개체와 연결될 새 특성을 스키마에 정의했습니다.

변경을 확인하려면 Active Directory 사용자 및 컴퓨터를 열고 employees.contoso.com 도메인에 연결하여 Users OU(조직 구성 단위)로 이동한 다음 ContosoTestUser라는 새 사용자 계정을 만듭니다. 이제 adsiedit.msc 콘솔을 열고 도메인 파티션 dc=employees,dc=contoso,dc=com에 연결한 다음 Users OU를 확장하고 ContosoTestUser를 마우스 오른쪽 단추로 클릭하여 속성 페이지를 엽니다. contosoEmpShoe 특성을 찾습니다. 이 특성을 편집하여 값을 입력할 수 있습니다. 또한 Ldp.exe 유틸리티를 사용하여 특성을 확인하고 수정할 수 있습니다.

이제 두 특성을 정의하고 연결하는 예제를 살펴보겠습니다. 그리고 Contoso에서 직원의 신발 크기를 중요 요소로 고려하여 회사에서 신발 크기를 재는 사람의 연간 성과를 추적하는 시나리오를 가정해 보겠습니다. 조금 이상한 예제이기는 하지만, Contoso에서 직원의 신발 크기 측정을 담당한 사람과 신발 크기 측정을 마친 사람 및 수를 하나의 특성 쿼리를 통해 추적하고자 한다고 가정하겠습니다. 이러한 유형의 데이터는 데이터베이스 테이블에 저장하는 것이 더 적절하다고 생각할 수 있지만, 여기서는 단지 정방향 링크와 역방향 링크를 설명하기 위한 것입니다.

물론 앞의 예제에서 설명한 것과 같은 종류의 분석을 수행할 수 있습니다. 하지만 여기서는 그림 6에서처럼 .ldif 파일 linkids1.ldif 및 linkids2.ldif를 생성해 보겠습니다. 그런 다음 이 명령을 실행하여 .ldif 파일을 가져옵니다.

Figure 6 정방향 및 역방향 링크 .ldif 파일

 
#linkids1.ldif
#Attribute definition for Forward Link Attribute

dn: CN=ContosoShoeSizeTaker,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemaadd
objectClass: top
objectClass: attributeSchema
cn: ContosoShoeSizeTaker
attributeID: 1.2.840.113556.1.8000.9999.2.2
LinkID: 1.2.840.113556.1.2.50
attributeSyntax: 2.5.5.1
isSingleValued: TRUE
adminDisplayName: ContosoShoeSizeTaker
adminDescription: ContosoShoeSizeTaker
oMSyntax: 64
searchFlags: 1
lDAPDisplayName: ContosoShoeSizeTaker
systemOnly: FALSE

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

#Reload schema

#linkids2.ldif

#Attribute definition for Backward Link Attribute

dn: CN=ContosoShoeSizesTakenByMe,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemaadd
objectClass: top
objectClass: attributeSchema
cn: ContosoShoeSizesTakenByMe
attributeID: 1.2.840.113556.1.8000.9999.2.3
LinkID: 1.2.840.113556.8000.9999.2.2
attributeSyntax: 2.5.5.1
isSingleValued: FALSE
adminDisplayName: ContosoShoeSizesTakenByMe
adminDescription: ContosoShoeSizesTakenByMe
oMSyntax: 64
searchFlags: 1
lDAPDisplayName: ContosoShoeSizesTakenByMe
systemOnly: FALSE

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

#Add ContosoShoeSizeTaker and ContosoShoeSizesTakenByMe Attribute as MayContain in 
#contosoUser class

dn: CN= contosoUser,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemamodify
add: mayContain
mayContain: ContosoShoeSizeTaker
mayContain: ContosoShoeSizesTakenByMe

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

#Add Backward Link Attribute as MayContain in Top

dn: CN=Top,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemamodify
add: mayContain
mayContain: ContosoShoeSizesTakenByMe

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1

ldifde –i –f <Path>\linkedids<>.ldif –b
<username> <domain> <password> -k –j. –c
"CN=schema,CN=Configuration,DC=X"
#schemaNamingContext

이제 사용자 개체가 만들어지면 해당 개체는 ContosoShoeSizeTaker 및 ContosoShoeSizesTakenByMe의 특성을 가집니다. John이라는 사용자의 사용자 개체를 만들 때는 ContosoShoeSizeTaker 특성이 신발 크기를 잰 Frank라는 사람의 DN으로 채워집니다. Frank의 사용자 개체의 속성에서 ContosoShoeSizesTakenByMe 특성을 쿼리하면 결과에는 John의 DN 및 Frank가 신발 크기를 잰 다른 사람이 포함됩니다. 경영진은 Frank의 사용자 계정의 ContosoShoeSizesTakenByMe 특성에 있는 DN 수에 따라 Frank에게 포상할 수 있습니다.

시스템 검사 및 조정

스키마 수정과 같은 중요한 업데이트는 아키텍처 요구 사항에 대한 검사 없이 수행할 수 없습니다. Active Directory에서는 이러한 일관성 검사와 안전 검사를 통해 Active Directory 스키마에 추가나 수정이 이루어질 때마다 해당 변경으로 인한 불일치 또는 기타 문제가 발생하지 않는지 확인합니다.

먼저 각 클래스에 대한 governsID의 값은 스키마 내에서 고유해야 합니다. schemaClass 개체를 정의할 경우 systemMayContain, mayContain, systemMustContain 및 mustContain 목록에 정의되는 모든 특성은 미리 존재해야 합니다. 동시에 subClassOf, systemAuxiliaryClass, auxiliaryClass, systemPossSuperiors 및 possSuperiors 목록에 정의되는 모든 클래스도 미리 존재해야 합니다.

또한 systemAuxiliaryClass 및 auxiliaryClass 목록에서 모든 클래스의 objectClassCategory는 88 클래스 또는 Auxiliary 클래스여야 합니다. 마찬가지로 systemPossSuperiors 및 possSuperiors 목록에서 모든 클래스의 objectClassCategory는 88 클래스 또는 Structural 클래스로 지정되어야 합니다.

여러 클래스를 정의할 때, Abstract 클래스는 다른 Abstract 클래스에서만 상속할 수 있으며 Auxiliary 클래스는 Structural 클래스에서 상속할 수 없고 Structural 클래스는 Auxiliary 클래스에서 상속할 수 없습니다. 또한 rDNAttID 특성에 지정된 특성에는 유니코드 문자열이 구문으로 있어야 하며 단일 값이어야 합니다.

다음은 classSchema 개체와 관련된 몇 가지 규칙입니다. attributeSchema 개체의 경우는 어떻습니까? 클래스의 governsID 값과 마찬가지로 attributeID 값은 고유해야 합니다. 또한 mAPIID 값은 있는 경우 반드시 고유해야 합니다. rangeLower 및 rangeUpper가 있는 경우 rangeLower는 rangeUpper보다 작아야 합니다. attributeSyntax 및 oMSyntax의 값은 일치해야 합니다. 특성이 개체 구문인 경우(oMSyntax =127) 올바른 oMObjectClass가 있어야 합니다. linkID는 있는 경우 반드시 고유해야 합니다. 또한 역방향 링크에는 해당하는 정방향 링크가 있어야 합니다.

실수한 경우

스키마가 새 개체(클래스 및 특성)로 확장된 경우에는 삭제할 수 없습니다. 하지만 스키마 개체에서 특성 isDefunct를 TRUE로 설정하여 클래스나 특성을 비활성화할 수 있습니다. Active Directory와 함께 제공되는 기본 스키마의 일부인 스키마 개체(범주 1 개체)는 비활성화할 수 없습니다. 기본 스키마에 추가된 개체만 비활성화할 수 있습니다. 즉, 범주 2 개체만 비활성화할 수 있으며 Active Directory에서 클래스가 기존의 모든 존재하는 클래스의 subClassOf, auxiliaryClass 또는 possSuperiors 목록에서 사용되지 않음을 확인한 경우에만 비활성화할 수 있습니다.

특성을 비활성화하려는 시도를 통해 Active Directory는 특성이 기존의 존재하는 클래스의 mustContain 또는 mayContain에 사용되지 않는지 확인합니다. 비활성화된 개체는 특성 isDefunct를 FALSE로 설정하여 다시 활성화할 수 있습니다. Active Directory가 Windows Server 2003 수준에 있는 경우에는 비활성화된 개체의 ldapDisplayName, schemaIdGuid, OID 및 mapiID 값을 재사용할 수 있습니다.

결론

스키마의 클래스 또는 특성 정의를 추가하거나 수정하려면 해당 classSchema 개체 또는 attributeSchema 개체를 추가하거나 수정해야 합니다. 이 프로세스는 해당 변경으로 인해 나중에 스키마에서 불일치나 문제가 발생하지 않음을 확인하기 위한 추가적인 검사가 수행된다는 점을 제외하면 Active Directory에서 개체를 추가하거나 수정하는 것과 비슷합니다.

Active Directory 스키마는 쉽게 수정할 수 있지만 스키마의 구조 및 이러한 변경을 구현하기 위해 스키마가 어떻게 작동하는지 이해하는 것이 좋습니다. 프로덕션 Active Directory 스키마를 변경하려면 많은 계획이 필요하며 신중하게 수행해야 합니다. 새 개체에 대한 비즈니스 요구 사항과 기술 사양을 정의하고 철저한 랩 테스트를 수행하는 것이 중요합니다. 변경으로 인해 심각한 영향을 미칠 수 있으므로 꼭 필요한 경우에만 Active Directory 스키마를 확장하는 것이 좋습니다.

Vikas Malhotra는 뉴욕의 Microsoft Consulting Services에서 근무하고 있으며 12년 동안 크고 작은 규모의 여러 IT 조직에서 디렉터리, 메시징, 보안 및 데이터 네트워킹과 같은 인프라 아키텍처 업무를 담당해 왔습니다. Vikas는 전자 통신 공학 학사 학위와 통신 기술 관리 석사 학위를 보유하고 있으며 vikasmal@microsoft.com으로 연락할 수 있습니다.

© 2008 Microsoft Corporation 및 CMP Media, LLC. All rights reserved. 이 문서의 전부 또는 일부를 무단으로 복제하는 행위는 금지됩니다..