Windows の管理

Active Directory スキーマを拡張する

Vikas Malhotra

概要:

• 既定の Active Directory スキーマを理解する
• classSchema または attributeSchema オブジェクトを追加する
• オブジェクト識別子を取得して使用する
• .ldif ファイルを使用してスキーマを拡張する

この記事で使用しているコードのダウンロード: Schema2008_05.exe (151KB)

Windows 2000 のリリースで Active Directory が導入されて以来、マイクロソフトでは、Active Directory を実装するための基本的なスキーマ定義を提供しています。

Active Directory® によって、Windows® を基盤とする多くのアプリケーションの作成および実装方法も転換を遂げました。Active Directory が導入されるまで、Microsoft® Exchange 5.5 などのアプリケーションを構築する際は、独自のディレクトリ構造が実装されていました。Active Directory を利用できるようになったことで、開発者は、多くのアプリケーション (マイクロソフト製および他社製) の開発時に、独自のスキーマをゼロから構築するのではなく、Active Directory によって提供される構造を基盤として活用するようになりました。

このようなアプリケーションを開発する際は、まず Active Directory によって提供される基本的なアーキテクチャを使用し、必要に応じてそれを拡張しました。たとえば、Microsoft Exchange 2000 では、メッセージングの実装に Active Directory が利用され、この実装によって、その後のマイクロソフトのメッセージング アーキテクチャが定義されました。

現在、Active Directory 環境で動作するように作成された多くのアプリケーションでは、Active Directory のスキーマが基盤として使用されており、そこに追加する形で、要件に応じた独自の変更がスキーマに定義されています。後述しますが、当然この変更を実装するには、拡張可能なスキーマが必要です。さらに、非常に多くのアプリケーションが Active Directory の基本的な定義に依存しているので、コア スキーマの継続的な安定性が提供されることは非常に重要です。また、多くのアプリケーションを同じ Active Directory 内で同時に実行する必要があるので、いずれかのアプリケーションが変更されたときに、他のアプリケーションにその影響が及ばないようにする必要があります。

スキーマとは

多くのユーザーにとって、Active Directory スキーマはブラック ボックスのようなものなので、スキーマを独自に変更するという考えには抵抗があるかもしれません。もちろん、Active Directory スキーマの拡張は、毎日発生する作業ではありませんが、特定のアプリケーションやビジネスで必要になる場合があります。したがって、スキーマの定義と内容を理解することは非常に重要です。Active Directory は、多くの組織にとって重要な資産なので、不適切な更新が原因で Active Directory が正常に機能しなくなった場合、重大な影響が発生する可能性があります。

多くの組織では、1 つの戦略として、Active Directory スキーマを拡張するのではなく、Windows Server® 2008 の Active Directory ライトウェイト ディレクトリ サービス (ADLDS) や Windows Server 2003 の Active Directory Application Mode (ADAM) を使用してテストを実行したり、カスタマイズされたスキーマ定義を直接実装したりすることが検討されています。

スキーマは、ディレクトリ サービスの構成を提供する、基盤となる構造です。Active Directory スキーマでは、Active Directory ドメイン サービス (ADDS) で使用されるオブジェクトのクラスと属性が定義されます。コア スキーマでは、多くの既知のクラス (user、computer、organizationalUnit など) と属性 (telephoneNumber、objectSID など) の定義が提供されます。コア スキーマ定義に含まれているオブジェクトはカテゴリ 1 のオブジェクトと呼ばれ、追加されるオブジェクトはカテゴリ 2 のオブジェクトと呼ばれます。

Active Directory スキーマは、cn=Schema, cn=Configuration,dc=X (X は Active Directory フォレストの名前空間です) というパスに定義されたコンテナに格納されています。Active Directory フォレストに格納されるスキーマは 1 つであることに注意してください。フォレスト内のスキーマ定義に変更を加えると、そのフォレスト内のすべてのドメインが変更の影響を受けます。図 1 は、Windows Server の各バージョンの Active Directory スキーマで追加されるクラスと属性の数を示しています。

Figure 1 クラスと属性の数

各バージョンでスキーマの更新を行う際は、Adprep という名前のユーティリティを使用します。Windows Server 2003 R2 で更新を行うと、スキーマのバージョンは 31 に変更され、Windows Server 2008 で更新を行うと、スキーマのバージョンは 44 に変更されます。

このバージョンを確認するには、ADSIEdit などのツールを使用して、Active Directory の cn=Schema,cn=Configuration,dc=X に格納されている objectVersion 属性の値を調べます。Exchange Server や System Management Server (SMS) など、Active Directory に依存する一部のアプリケーションは、必要に応じてスキーマを変更する場合があることに注意してください。

基盤となる要素

Active Directory は、classSchema (略してクラス) と attributeSchema (略して属性) という 2 種類のオブジェクトから構成されます。通常、Active Directory スキーマの拡張が組織で検討されるのは、既存のスキーマで提供されていない特定の属性にデータを格納する必要がある場合です。Active Directory スキーマの属性を作成するには、まずスキーマ コンテナ内の attributeSchema オブジェクトを指定してから、その新しいオブジェクトに必要なプロパティを定義します。

attributeSchema オブジェクトのプロパティの一覧と、これらのプロパティの詳細については、go.microsoft.com/fwlink/?LinkId=110445 を参照してください。ご覧になっていただければわかりますが、attributeSchema オブジェクトに定義できるプロパティは多数あります。これらの多くは必須のプロパティです。

スキーマには、通常の属性以外にも、ペアで実装され、前方リンクと後方リンクを提供する、リンクされた属性が含まれています。例として、Active Directory のグループ メンバシップについて考えてみましょう。グループ (たとえば、John Doe という名前のメンバを含む ContosoEmployees という名前のグループ) の member 属性は前方リンクで、対応するメンバ オブジェクトの memberOf 属性は後方リンクです (つまり、John Doe の memberOf 属性が照会されると、ContosoEmployees グループの識別名 (DN) が算出されます)。

前方リンクの機能は、他の属性とほぼ同じで、1 つ以上の値を指定できます (member 属性と同様、グループのメンバとして複数のオブジェクトを含めることができます)。これらの値は、親オブジェクトと共にディレクトリに格納されます。

一方、後方リンクは、参照整合性を維持するために、システムによって管理されます。後方リンク属性の値を照会すると、対応するすべての前方リンクの値から結果が算出されます。後方リンクでは、常に複数の値が保持されます。

ADDS の各オブジェクト クラスは、スキーマ コンテナ内の classSchema オブジェクトによって定義されます。classSchema オブジェクトを正しく定義するうえで重要な属性の一覧については、go.microsoft.com/fwlink/?LinkId=110445 を参照してください。

指定できるクラスは、構造型、抽象型、および補助型の 3 種類です。これらのクラスは、objectClassCategory 属性の値によって定義されます (88 と呼ばれる 4 番目のカテゴリには、X.500 1993 規格よりも前に定義されたクラスが含まれます。この種類のクラスを定義するには、objectClassCategory 属性に 0 を指定します。ただし、この種類のクラスは、今後定義しないことをお勧めします)。

識別子を取得して使用する

ディレクトリの classSchema オブジェクトと attributeSchema オブジェクトの ID は、必須のオブジェクト識別子 (OID) を使用して定義されます。classSchema オブジェクトの OID は governsID に対して定義され、attributeSchema オブジェクトの OID は attributeID に対して定義されます。これらの ID は、オブジェクトを識別するために、特定の発行機関によって提供される一意の数値です。数値の形式は、LDAP プロトコルの定義 (RFC 2251) で規定されています。Active Directory スキーマの OID には、国際標準化機構 (ISO) によって発行されるものや、マイクロソフトによって発行されるものがあります。OID は、ディレクトリ内のオブジェクトごとに一意である必要があります。

OID は、1.2.840.113556.1.y.z などの一連の数値です (図 2 参照)。たとえば、ユーザーの classSchema オブジェクトの場合は 1.2.840.113556.1.5.9 です。

Figure 2 ユーザー オブジェクトの識別子

組織でスキーマを拡張する際は、一意の OID を使用できるように、独自の OID ルート番号を取得します。その後、取得した番号を枝分けして、組織でオブジェクトの新しいクラスと属性を作成したときに、一意の ID を提供します。OID ルート番号は、ISO の National Registration Authority (NRA) から直接取得できます。米国の NRA は米国規格協会 (ANSI) です。

OID ルート番号の取得手順とその料金体系については、ansi.org を参照してください。米国以外の地域については、該当する ISO の加盟組織にお問い合わせください。ISO から加盟組織の一覧が提供されています (iso.org/iso/about/iso_members.htm)。

以前は、組織から schemreg@microsoft.com (英語のみ) に電子メールを送信することで、マイクロソフトから OID を取得できましたが、現在は、電子メールを送信すると、VBScript (go.microsoft.com/fwlink/?LinkId=110453) をダウンロードして実行するよう依頼者に要求するメッセージが自動的に返信されます。

マイクロソフトによって発行される OID には、1.2.840.113556.1.8000.x など、マイクロソフトの OID 番号空間に属する番号が割り当てられます (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 の値は、2.5.5.1 である必要があります。この値は Object (DS-DN) 構文に対応しています。原則として、後方リンク属性は、top 抽象型クラスの mayContain の値に追加されます。これにより、後方リンク属性をあらゆるクラスのオブジェクトから読み取ることができるようになります。この理由は、後方リンク属性は、実際にはオブジェクトと共に格納されているのではなく、前方リンクの値に基づいて計算されるからです。

Windows Server 2003 では、組織でスキーマ内の 2 つのオブジェクトをリンクさせるために使用できる、linkID の自動生成という機能が導入されました。この機能によって、新しくリンクされた属性の linkID 属性が 1.2.840.113556.1.2.50 に設定されたときに、その属性の linkID がシステムによって自動的に生成されるようになりました。対応する後方リンクを作成するには、linkID を前方リンクの attributeId または ldapDisplayName に設定します。前方リンクが作成された後、後方リンクが作成される前に、スキーマ キャッシュを再度読み込む必要があります。このタイミングでスキーマ キャッシュが読み込まれなかった場合、後方リンクの作成時に、前方リンクの attributeId または ldapDisplayName が見つからなくなります。スキーマ キャッシュは、スキーマが変更されてから数分後、またはドメイン コントローラの再起動時に、要求に応じて再度読み込まれます。

Active Directory のレベルが Windows 2000 の場合は、schemreg@microsoft.com (英語のみ) に電子メールを送信してマイクロソフトに linkID を要求する必要があります。自動的に返信されるメッセージには、schemreg@microsoft.com に送信された電子メールが処理されるのは、古い環境用の linkID の登録に関連している場合のみであることが記載されています。このため、電子メールには会社名、連絡先、電子メール アドレス、電話番号、登録したプレフィックス (該当する場合)、登録した OID (該当する場合) などの情報を記入するようにしてください。

スキーマを拡張する準備を行う

Active Directory スキーマを拡張することになったとします。分析の結果、ADLDS (または Windows Server 2003 の ADAM) を使用して実装された代替のディレクトリでは要件を満たすことができず、この方法の使用を断念した結果、スキーマの拡張が選択されたものと思われます。次に、スキーマに追加する新しい attributeSchema オブジェクトを決定し、これらの新しいオブジェクトを指定するために必要な値 (cn や ldapDisplayName など) をすべて定義しました。さらに、オブジェクトの属性値を定義するときに、マイクロソフトまたは別の機関から OID を取得しました。これらの情報は重要なので、ビジネス要件と技術仕様として文書化しました。そして、現在の Active Directory を再現したテスト用のラボ環境も実装しました。

実際に、多くの組織では、このような変更を承認し、変更の実装手順を決定するための委員会が設置されます。Active Directory は、信頼できる情報源として多くの組織で使用されるので、このような抑制と均衡を図ることは不可欠です。また、変更後も Active Directory を継続的に稼動させることが非常に重要です。

変更作業を進めていくことが決定したら、このプロジェクトのテストと実装の計画を定義する必要があります。スキーマを拡張するには、Microsoft 管理コンソール (MMC) 内で Active Directory スキーマ スナップインを使用して新しいオブジェクトを追加するか、スキーマを拡張するためのプログラム (またはそれに近い方法) を使用します。たとえば、LDIFDE による .ldif ファイルのインポート、CSVDE による .csv ファイルのインポート、Active Directory サービス インターフェイス (ADSI) スクリプトの使用などが考えられます。

どの方法を使用する場合でも、スキーマの拡張は、Active Directory フォレスト内に存在するスキーマ マスタのフレキシブル シングル マスタ操作 (FSMO) の役割が割り当てられているサーバー、またはそのサーバーに接続されているサーバーで行う必要があります。また、スキーマの更新に使用するアカウントには、更新を行うための管理者特権が与えられている必要があるので、そのアカウントを Schema Administrators グループに追加します。最後に、フォレストのスキーマを更新する操作を有効にする必要があります (既定では無効になっています)。

変更は、非常に簡単なものでない限り、自動化された方法で行う必要があります。これにより、テスト環境と実稼動環境を同じ方法で実装し、手動で手順を実行した場合に発生する可能性のある問題を回避できます。たとえば、LDIFDE を使用して変更を実装するとします。スキーマの拡張時に更新を適用するには、新しい属性とクラスを追加し、新しい属性をクラスに追加した後、キャッシュを再度読み込みます。では、いくつかのシナリオについて考えてみましょう。

属性を追加する

これは説明のみを目的としたシナリオですが、たとえば Contoso という名前の組織で、各従業員の靴のサイズを識別する属性を Active Directory に追加するとします。Active Directory フォレスト内には、contoso.com と employees.contoso.com という 2 つのドメインが存在します。ユーザー クラス定義を使用して作成されたすべてのオブジェクトに、この新しい属性が含まれるようにする必要があります。

2 つのドメインは同じフォレスト内に存在するので、スキーマの変更が両方のドメインに影響を与えることを考慮する必要があります。この例では、マイクロソフトから 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 属性は、ユーザー クラス オブジェクトとして作成されたすべてのオブジェクトに含まれる必要があるので、ユーザー クラスの既定の定義は変更しないことをお勧めします。その代わりに、contosoUser という名前の補助型クラスを定義し、mayContain の値に contosoEmpShoe を指定します (図 4 参照)。その後、contosoUser 補助型クラス用に定義された属性を、ユーザー クラスに追加します。

Figure 4 contosoUser クラスの定義

分析を行い、値を定義したところで、次は .ldif ファイルを作成します。図 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 ファイルを生成したら、ラボ環境で実装を徹底的にテストし、ドメインとフォレストのエンド ツー エンドのレプリケーションを検証した後、フォレスト内のスキーマの更新を有効にします。その後、スキーマ管理者の特権が与えられたアカウントを使用してログインします。スキーマ マスタ (変更を実行するサーバー) で出力方向のレプリケーションを無効にしてから、次のコマンドを実行して .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 ユーティリティを使用して、これらの属性を確認および変更することもできます。

次に、2 つの属性を定義し、リンクさせる例を見てみましょう。Contoso で従業員の靴のサイズが重要視され、社内で靴のサイズを測定する人物の年間の実績を追跡する必要があるとします。なんだか妙な感じがしますね。さらに、Contoso では、1 つの属性を照会するだけで、従業員の靴のサイズを測定した人物の名前だけでなく、その人物がサイズを測定した従業員の名前と人数を把握できるようにする必要があります (このデータはデータベース テーブルに格納した方が適切であると思われたかもしれませんが、ここでの目的は単に前方リンクと後方リンクの機能を説明することです)。

当然、まずは前述の例のように、分析を行います。ただし、ここでは説明を省略して先に進み、linkids1.ldif と linkids2.ldif という .ldif ファイルを生成します (図 6 参照)。その後、次のコマンドを実行して .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 というユーザー オブジェクトを作成すると、靴のサイズを測った Frank という人物の DN が ContosoShoeSizeTaker 属性に格納されます。次に、Frank のユーザー オブジェクトのプロパティにアクセスし、ContosoShoeSizesTakenByMe 属性を照会すると、John の DN と、Frank が靴のサイズを測定した他のすべての従業員の DN を確認できます。これで、たとえば経営管理者は、Frank のユーザー アカウントの ContosoShoeSizesTakenByMe 属性に格納されている DN の数に基づいて、Frank に報酬を与えることができます。

システムの抑制と均衡

スキーマの変更などの重要な更新を行う場合は、必ずその変更がアーキテクチャの要件を満たしているかどうかを確認する必要があります。Active Directory では、このような整合性と安全性の確認が実行され、Active Directory スキーマに対する追加や変更が発生するたびに、それらの変更が原因で不整合などの問題が発生しないかどうかが検証されます。

まず、各クラスの governsID の値は、スキーマ内で一意である必要があります。また、schemaClass オブジェクトを定義する場合、systemMayContain、mayContain、systemMustContain、および mustContain のリストで定義されているすべての属性が既に存在している必要があります。同時に、subClassOf、systemAuxiliaryClass、auxiliaryClass、systemPossSuperiors、および possSuperiors のリストで定義されているすべてのクラスも既に存在している必要があります。

さらに、systemAuxiliaryClass と auxiliaryClass のリストに含まれているすべてのクラスの objectClassCategory に、88 クラスまたは補助型クラスを示す値が指定されている必要があります。同様に、systemPossSuperiors と possSuperiors のリストに含まれているすべてのクラスの objectClassCategory には、88 クラスまたは構造型クラスを示す値が指定されている必要があります。

さまざまなクラスが定義されていますが、抽象型クラスは他の抽象型クラスのみを継承できます。また、補助型クラスは構造型クラスを継承できず、構造型クラスは補助型クラスを継承できません。さらに、rDNAttID 属性に指定される属性には、Unicode 文字列から成る 1 つの値が指定されている必要があります。

以上が classSchema オブジェクトに関連するいくつかの規則です。では、attributeSchema オブジェクトについてはどうでしょうか。クラスの governsID の値と同様、attributeID の値は一意である必要があります。また、mAPIID (存在する場合) の値も一意である必要があります。さらに、rangeLower と rangeUpper が存在する場合、rangeLower には rangeUpper よりも小さい値が指定されている必要があります。attributeSyntax の値と oMSyntax の値は一致している必要があります。属性にオブジェクト構文が使用される場合 (oMSyntax = 127) は、この属性に適切な oMObjectClass が指定されている必要があります。linkID (存在する場合) は一意である必要があります。また、後方リンクに対応する前方リンクが存在する必要があります。

失敗したときの対策

新しいオブジェクト (クラスと属性) を使用してスキーマを拡張した後、それらのオブジェクトを削除することはできません。ただし、スキーマ オブジェクトの属性 isDefunct を TRUE に設定することによって、クラスまたは属性を非アクティブにすることができます。Active Directory に付属している既定のスキーマの一部であるスキーマ オブジェクト (カテゴリ 1 のオブジェクト) を非アクティブにすることはできません。非アクティブにすることができるのは、既定のスキーマに追加されたオブジェクトのみです。つまり、カテゴリ 2 のオブジェクトのみを無効にすることができます。また、既存のアクティブなクラスの subClassOf、auxiliaryClass、または possSuperiors のリストで使用されていないことが Active Directory によって確認されているクラスのみを無効にすることができます。

属性の非アクティブ化を試行すると、Active Directory によって、その属性が既存のアクティブなクラスの mustContain または mayContain で使用されていないかどうかが確認されます。無効になったオブジェクトは、属性 isDefunct を FALSE に設定することで再度有効にすることができます。Active Directory が Windows Server 2003 レベルの場合は、無効になったオブジェクトの ldapDisplayName、schemaIdGuid、OID、および mapiID の値を再利用できます。

まとめ

スキーマ内のクラスまたは属性の定義を追加または変更する場合、対応する classSchema オブジェクトまたは attributeSchema オブジェクトも追加または変更する必要があります。このプロセスは、Active Directory のオブジェクトを追加または変更する場合と同様です。ただし異なる点が 1 つあり、実装した変更が原因で、後から不整合などの問題がスキーマで発生しないように、追加で確認処理が実行されます。

Active Directory スキーマの変更作業は単純ですが、変更を実装する場合は、スキーマの構造と機能を理解することが重要です。運用環境の Active Directory スキーマを変更する場合は、綿密な計画を立て、慎重に実装する必要があります。また、新しいオブジェクト用のビジネス要件と技術仕様を定義し、ラボで徹底的にテストすることが重要です。変更によって大きな影響がもたらされる可能性があるので、絶対に必要な場合のみ Active Directory スキーマを拡張することをお勧めします。

Vikas Malhotra は、Microsoft Consulting Services (ニューヨーク) に勤務しています。12 年間にわたる在籍期間の中で、多くの大規模および中規模企業内の IT 組織と関わり、それらの企業のインフラストラクチャで使用されるアーキテクチャの要件 (ディレクトリ、メッセージング、セキュリティ、データ ネットワークなど) に対処する業務に従事してきました。彼は、電子工学と電気通信の工学士号、および電気通信 (技術) 管理の理学修士号を取得しています。連絡先は、vikasmal@microsoft.com (英語のみ) です。

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; 許可なしに一部または全体を複製することは禁止されています.