一部のActive Directory (AD)統合アプリケーションは、ディレクトリスキーマのカスタム変更が必要です。本日、管理者がAWS Directory Service for Microsoft Active Directory (Enterprise Edition)、またはMicrosoft ADのスキーマを拡張する機能を追加しました。具体的には、ADスキーマを修正してより多くのアプリケーションを有効にすることができます。また、この機能を使用すると、アプリケーションに必要でコアのADクラスと属性にはないあたらしい属性とオブジェクトクラスをADに追加することができます。最後に、作成した属性の変更や無効化ができます。
スキーマをアップデートするには、互換性のあるLightweight Directory Access Protocol Data Interchange Format (LDIF)ファイルをDirectory Service consoleまたはAWS SDKを使用してアップロードします。LDIFは、ADなどのLightweight Directory Access Protocol (LDAP)サーバー用にデータを交換し、スキーマを更新するように設計された書式付きテキストの標準です。エンタープライズ管理者やドメイン管理者など、権限の昇格が必要なアプリケーションはサポートされていない可能性があります。
このブログ記事では、スキーマ属性とクラスについて説明し、LDIFファイルとフォーマットの概要を示します。次に、Microsoft ADドメインに参加しているEC2インスタンスのAmazon EC2インスタンス識別子を格納するコンピュータクラスオブジェクトに新しい属性を追加するユースケースを3つの主なステップで説明します：
- LDIFファイルを作成します。
- LDIFファイルをインポートします。
- スキーマの更新を検証します。
また新しい属性に値を追加する方法について示します。
スキーマの概念
スキーマはディレクトリの構造を定義し、オブジェクト識別子によって一意に参照できる属性を含むオブジェクトクラスで構成されます。スキーマを変更する前に、スキーマの定義方法を知っておくと便利です。このセクションでは、ADスキーマについて知っておくべき重要な概念について説明します。既にADスキーマとLDIFファイルに精通している場合は、先に進むことができます。注：このセクションのすべてのリンクは、Microsoft Developer Network（MSDN）のWebサイトにアクセスします。
スキーマクラス：それぞれのスキーマクラスには、データベース内のテーブルのように、クラスカテゴリを定義するobjectClassCategoryなどのいくつかのプロパティがあります。Characteristics of Object Classesに移動して、クラスの特性の完全なリストを確認し、Defining a New Classで新しいクラスを作成する方法について学んでください。
スキーマ属性：それぞれのスキーマ属性には、データベース内のフィールドのように、その特性を定義するいくつかのプロパティがあります。たとえば、属性を読み書きするためにLDAPクライアントによって使用されるプロパティはIDAPDDisplayNameプロパティです。IDAPDDisplayNameプロパティは、すべての属性およびクラスにわたってユニークでなければなりません。Characteristics of Attributesには、属性特性の完全なリストがあります。新しい属性の定義に関する追加のガイダンスはDefining a New Attributeで見つけることができます。
スキーマリンク属性：いくつかの属性は、フォワードリンクとバックリンクによって2つのクラス間でリンクされています。たとえば、ユーザーをグループに追加すると、ADはそのグループへのフォワードリンクを作成し、ADはそのグループのバックリンクをユーザーに追加します。リンクされる属性を作成するときは、固有のlinkIDを生成する必要があります。
オブジェクト識別子（OID）：各クラスおよび属性には、すべてのオブジェクトにユニークなOIDが必要です。ソフトウェアベンダーは、複数のアプリケーションが同じ属性を異なる目的で使用している場合に競合を避けるための一意性を保証するため、独自にユニークなOIDを取得する必要があります。一意性を保証するために、ISO名登録機関からルートOIDを取得することができます。または、Microsoftから基本OIDを取得することもできます。 OIDの詳細と取得方法については、Object Identifiersを参照してください。
LDIFファイルとフォーマット
LDIFファイルは、ADなどのLDAPディレクトリ内のオブジェクトおよびスキーマを変更するために使用できる、フォーマットされたテキストファイルです。 LDIFファイルには、ディレクトリに格納されているオブジェクトのクラスと属性を定義するための指示が含まれています。クラスまたは属性を定義する命令は、複数の行で構成され、それぞれがクラスまたは属性の異なるプロパティを指定します。 LDIFファイルの形式は、Request for Comments (RFC) 2849で定義されているIETF（Internet Engineering Task Force）標準です。
Microsoft ADディレクトリ内のスキーマを変更するには、まずLDIFファイルを取得または作成する必要があります。また、Microsoft AD管理アカウントが制御するために委任された組織単位（OU）内に保持されているオブジェクトを変更する権限も必要です。また、既存のディレクトリからLDIFファイルをエクスポートすることで、LDIFファイルを取得することもできます。ソフトウェアメーカがあらかじめ作成されたLDIFファイルを製品に提供していることがあります。 LDIFファイルがある場合は、LDIFファイルを送信して既存のスキーマを拡張します。
LDAPディレクトリはLDIFファイルを読み込みません。むしろ、プログラム（たとえばLdifde.exe）がLDIFファイルを解釈します。プログラムはLDIF命令を、LDAPプロトコルを使用してディレクトリに送信する一連のLDAPコマンドに変換します。 Microsoft ADの場合、LDIFファイルはDirectory ServiceコンソールまたはAWS SDKによって送信されます。 Amazon VPCで実行されているLDAPツールまたはアプリケーションから直接スキーマに変更を加える権限はありません。
重要：スキーマの変更は非常に重要な操作であり、非常に注意して実行する必要があります。 LDIFファイルのエラーによりアプリケーションが壊れる可能性があります。エラーから回復するには、別の変更を適用して変更を無効にするか、ディレクトリ全体を以前の状態に復元するため、ディレクトリのダウンタイムが発生することになります。まず、テスト環境ですべてのスキーマの変更を慎重に計画、承認、テストします。AWS Shared Responsibility Modelを確認してください。
はじめからLDIFファイルを作成する場合でも、別のADスキーマからLDIFファイルをエクスポートする場合も、ソフトウェアベンダーが提供するLDIFファイルを使用する場合も、いくつかの重要なLDIFファイルフォーマット規則を理解する必要があります。どのような場合でも、必要に応じてファイルを変更するための標準を熟知している必要があります。たとえば、LDIFファイルの各変更の前には、スキーマ内で変更するオブジェクトを一意に識別する識別名（DN）が付いています。 LDIFファイルのDNは、ディレクトリのDNと完全に一致する必要があります。別のディレクトリからLDIFをインポートする場合は、LDIFファイル全体でDNを編集する必要があります。 Extending Your Microsoft AD SchemaのLDIFフォーマットルールを参照してください。
ADは、ディスクに格納されたディレクトリから読み込んだキャッシュに格納されたディレクトリスキーマから動作します。 ADは5分ごとにキャッシュをリフレッシュし、スキーマの変更が行われると、ディスクに保存されているディレクトリにのみ適用されます。ディスクに格納されているスキーマの変更をすぐに反映させる必要がある場合は、変更を加えた後にスキーマキャッシュを更新するコマンドを発行する必要があります。
Microsoft ADディレクトリスキーマを拡張する方法
このブログ記事の残りの部分では、EC2インスタンス識別子を格納するためにコンピュータオブジェクトクラスに新しい属性を追加することによって、Microsoft ADディレクトリスキーマを拡張する方法を示します。このチュートリアルは、1）LDIFファイルの作成、2）LDIFファイルのインポート、および3）スキーマ更新の検証の3つの主要な手順にしたがっています。このデモでは、私の会社名はExample, Inc.で、私のディレクトリはexample.comというドメイン名を使用しています。
ステップ 1: LDIFファイルを作成する
独自のLDIFファイルを作成するには：
- 新しいスキーマ属性を定義します。
- 新しいスキーマクラスオブジェクトを定義します。
- LDIFファイルを作成します。
A. 新しいスキーマ属性を定義する
この例では、新しい属性の名前はEC2InstanceIDです。属性名をスキーマ内でユニークにするために、プレフィックスとしてexample-を追加します。プレフィックスと名前は、管理者がディレクトリスキーマを参照しているときに、オブジェクトの作成者と目的に関するドキュメントの形式として機能します。この場合、共通名（CN）とIDAPDisplayNameは同じです：example-EC2InstanceID。スキーマの変更に独自の接頭辞を定義するには、DNS、略語、または会社固有の別の文字列を使用できます。ここでは、ステップ3でLDIFファイルを作成するときに使用する属性とプロパティの値を定義しています。
以下の表は、新しい属性を作成するためのプロパティの完全なセットを示しています。属性とプロパティの詳細については、「Defining a New AttributeおよびSystem Checks and Restrictions Imposed on Schema Additions and Modificationsを参照してください。
| Property |
Property Value for My Attribute |
Description |
| CN |
example-EC2InstanceID |
Attribute common name |
| lDAPDisplayName |
example-EC2InstanceID |
Name used by LDAP clients |
| adminDisplayName |
example-EC2InstanceID |
Name used by admin tools |
| attributeSyntax |
2.5.5.12 |
OID for string (Unicode) |
| oMSyntax |
64 |
oMSyntax for string (Unicode) |
| objectClass |
top,attributeSchema |
Is instance of this objectClass |
| attributeID |
1.2.840.113556.8000.9999.2.1 |
The OID for this attribute |
| isSingleValued |
TRUE |
Attribute has unique value |
| searchFlags |
1 |
Attribute is indexed for search |
| isMemberOfPartialAttributeSet |
TRUE |
Replicated to the global catalog |
注：この例では、この属性はoMSyntaxが127ではないため、oMObjectClassは呼び出されません。
B. 新しいスキーマオブジェクトクラスを定義する
ADには、Windowsオペレーティングシステムや多くのAD統合アプリケーションで使用されるオブジェクトを定義するコアスキーマが付属しています。カテゴリ1オブジェクトとも呼ばれるADのコアスキーマ定義は変更しないでください。代わりに、新しい補助クラスを作成し、この新しい補助クラスに新しい属性を追加する必要があります。次に、新しい補助クラスで定義されている属性をコアクラスに追加して、ディレクトリがコアスキーマに依存するアプリケーションとの互換性を保つようにスキーマを拡張します。
この例では、ゴールはコンピュータクラスにexample-EC2InstanceID属性を追加することです。これを行うために、example-Computerという名前の新しい補助クラスを作成し、この新しい補助クラスにexample-EC2InstanceID属性を追加します。後で、example-Computer補助クラスで定義されたexample-EC2InstanceID属性をComputerコアクラスに追加します。ここでは、ステップ3でLDIF命令に変換するexample-Computerクラスのみを定義します。
以下の表は、新しい補助クラスを作成するためのプロパティの完全なセットを示しています。クラスとプロパティの詳細については、Defining a New Classを参照してください。
| Property |
Property Value for My New Auxiliary Class |
Description |
| Cn |
example-Computer |
Class Common Name |
| lDAPDisplayName |
example-Computer |
Name used by LDA Clients |
| adminDisplayName |
example-Computer |
Name used by admin tools |
| governsID |
1.2.840.113556.8000.9999.1.1 |
The OID for the auxiliary class |
| mayContain |
example-EC2InstanceID |
Class optionally contains this attribute |
| possSuperiors |
organizationalUnit, container |
This auxiliary class can be a child of organizationalUnit or container |
| objectClassCategory |
3 |
Auxiliary class |
C. LDIFファイルを作成する
これで、新しいEC2InstanceID属性とexample-Computer補助クラスを定義したので、すべてをまとめて1つのLDIFファイルにします。この例でスキーマを拡張するLDIF命令のシーケンスは以下のとおりです。
- example-EC2InstanceIDを定義します。
- スキーマキャッシュを更新します。
- example-Computer補助クラスを定義します。
- スキーマキャッシュを更新します。
- example-Computer補助クラスで定義された属性をコンピュータに追加します。
- スキーマキャッシュを更新します。
LDIFファイルの新しい命令ごとに、識別名（DN）を命令の最初の行として定義する必要があります。 DNは、ADオブジェクトのツリー内のADオブジェクトを識別し、そのディレクトリのドメインコンポーネントを含む必要があります。この例では、ディレクトリのドメインコンポーネントはDC = example、DC = comです。
DNには、ADオブジェクトの共通名（CN）も含める必要があります。最初のCNエントリは、属性またはクラス名です。次に、CN = Schema、CN = Configurationを使用する必要があります。このCNは、ADスキーマを拡張できることを保証します。前述のとおり、ADオブジェクトのコンテンツを追加または変更することはできません。
注意：新しいファイルを作成する場合、アプリケーションプロバイダによって作成されたファイルを使用する場合、または別のドメインからエクスポートされたファイルを使用する場合は、ディレクトリの命名規則に一致するようにLDIFファイル全体のDNを更新する必要があります。 DNの一般的な形式は次のとおりです。
dn: CN=[attribute or class name],CN=Schema,CN=Configuration,DC=[domain_name]
この例では、新しい属性の例 - EC2InstanceIDのDNが続きます。
dn: CN=example-EC2InstanceID,CN=Schema,CN=Configuration,DC=example,DC=com
以前に作成した6つの手順の手順を使用して、新しいスキーマを定義してADスキーマに追加して、LDIFファイルを作成します。 LDIFファイルの名前をschema_EC2InstanceID.ldifとします。こちらはダウンロード可能です。ファイルを使用してテストを実行したい場合は、dnエントリを変更して自分のドメイン名を指定することを忘れないでください。 LDIFファイルのコードは以下のとおりです。
# 1 – Define the example-EC2InstanceID attribute
dn: CN=example-EC2InstanceID,CN=Schema,CN=Configuration,DC=example,DC=com
changetype: add
objectClass: top
objectClass: attributeSchema
cn: example-EC2InstanceID
attributeID: 1.2.840.113556.1.8000.9999.2.1
attributeSyntax: 2.5.5.12
isSingleValued: TRUE
adminDisplayName: example-EC2InstanceID
adminDescription: EC2 Instance ID
oMSyntax: 64
searchFlags: 1
lDAPDisplayName: example-EC2InstanceID
systemOnly: FALSE
# 2 – Update the schema cache
dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-
# 3 – Define the example-Computer auxiliary class
dn: CN=example-Computer,CN=Schema,CN=Configuration,DC=example,DC=com
changetype: add
objectClass: top
objectClass: classSchema
cn: example-Computer
governsID: 1.2.840.113556.1.8000.9999.1.1
mayContain: example-EC2InstanceID
rDNAttID: cn
adminDisplayName: example-Computer
adminDescription: Example Computer Class
objectClassCategory: 3
lDAPDisplayName: example-Computer
name: example-Computer
systemOnly: FALSE
# 4 – Update the schema cache
dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-
# 5 – Add the attributes defined in the example-Computer auxiliary class to the
# Computer class
dn: CN=Computer,CN=Schema,CN=Configuration,DC=example,DC=com
changetype: modify
add: auxiliaryClass
auxiliaryClass: example-Computer
-
# 6 – Update the schema cache
dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
LDIFファイルを注意深く見直して保存したあと、すぐにアップロードして自分のディレクトリに適用できるようになります：
- AWS Management Consoleを開き、Directory Serviceを選択し、Microsoft ADのDirectory IDリンクを選択します（以下のスクリーンショットを参照）。
- Schema extensionsタブを選択します。ここでは、自分が実行した更新のStart Time、End Time、およびDescription、そしてStatusを使用して、ディレクトリに対するすべてのスキーマ変更試行の履歴を確認できます。
- Upload and update schemaを選択してLDIFファイルをアップロードします。
- Upload LDIF file and update schemaページで、Browseを選択してLDIFファイルを選択します。スキーマ更新の説明を入力して、スキーマを更新した理由をドキュメント化し、Update Schemaを選択します。
Update Schemaを選択すると、Microsoft ADはLDIFファイルの初期構文検証を実行します。
注意：最も一般的な構文検証エラーは、ディレクトリの命名規則に一致するためのLDIFファイル内のDNの更新に失敗することです。
最初のLDIFファイルの構文検証後、以下のの3つのアクションが自動的に実行されます：
- Microsoft ADはスナップショットを作成します。スナップショットを使用すると、スキーマの更新後にアプリケーションで問題が発生した場合にディレクトリを復元することができます。スナップショットの作成には約40分かかります。手動スナップショットの制限に達している場合、続行する前に、手動スナップショットの1つを削除するように指示するメッセージが表示されます。
- LDIFファイルはディレクトリに対して孤立したドメインコントローラに適用されます。 Microsoft ADは、自分のDCの1つをスキーママスターに選択します。ディレクトリ複製からそのDCを削除し、Ldifde.exeを使用してLDIFファイルを適用します。この操作には通常1分もかかりません。
- スキーマの更新は、すべてのドメインコントローラに複製されます。孤立したドメインコントローラに対してLDIFファイルを正常に適用すると、変更されたDCがレプリケーションに追加され、スキーマの更新がすべてのドメインコントローラに複製されます。
これらの手順が進行中のあいだに、ディレクトリはアプリケーションとユーザーの要求に応答することができます。ただし、信頼の作成やIPルートの追加などのディレクトリメンテナンス操作は実行できません。以下のスクリーンショットに示すように、スキーマ更新履歴の進捗状況を監視できます。
注：更新中にエラーが発生すると、詳細なエラーメッセージが表示され、可能であれば、LDIFファイルでエラーが発生した場所を示す行番号が表示されます。エラーが発生した場合、Microsoft ADスキーマは変更されません。
ステップ 3: スキーマの更新を検証する
最後のステップは、スキーマの更新がディレクトリに適用されているかどうかを検証することです。これは、スキーマの更新に依存するアプリケーションを移行または更新する前の重要なステップです。さまざまなLDAPツールを使用するか、または適切なLDAPコマンドを発行するテストツールを作成して、これを実現できます。これを行うために、ADスキーマスナップインとWindows PowerShellを使用する2つの方法を示します。
スキーマ更新が存在するかどうかを確認するには、Microsoft ADドメインに参加しているコンピュータからADツールを実行する必要があります。これは、仮想プライベートネットワーク（VPN）接続を介してAmazon Virtual Private Cloud（VPC）にアクセスできる、オンプレミスネットワーク上で実行されているWindowsサーバーでおこなうことができます。また、Amazon EC2 Windowsインスタンスでこれを実行することもできます（Joining a Domain Using the Amazon EC2 Launch Wizard)を参照）。
ADスキーマスナップインを使用するには：
- こちらの手順を実行して、ADスキーマスナップインをインストールします。
- Microsoft管理コンソール（MMC）を開き、ディレクトリのActive Directory Schemaツリーを展開します。クラスと属性を見ることができます。以下のスクリーンショットは、EC2InstanceID属性の例を示しています。
Windows PowerShellを使用する場合は、Get-ADObjectコマンドレットを使用してスキーマ更新がディレクトリに適用されているかどうかを確認することができます。以下のコードは、この例の構文を示しています。
# New attribute EC2InstanceID
PS C:\> get-adobject -Identity 'CN= EC2InstanceID,CN=Schema,CN=Configuration,DC=example,DC=com' -Properties * <Enter>
adminDescription: EC2 instance ID
adminDisplayName: example-EC2InstanceID
attributeID : 1.2.840.113556.1.8000.9999.2.1
attributeSyntax : 2.5.5.12
CanonicalName : example.com/Configuration/Schema/example-EC2InstanceID
CN : example-EC2InstanceID
...
# New auxiliary class example-computer
PS C:\> get-adobject -Identity 'CN=example-Computer,CN=Schema,CN=Configuration,DC=example,DC=com' -Properties * <Enter>
adminDescription: example computer class
adminDisplayName: example-Computer
CanonicalName : example.com/Configuration/Schema/example-Computer
CN : example-Computer
...
# New auxiliary class example-computer added to the computer class
PS C:\> get-adobject -Identity 'CN=computer,CN=Schema,CN=Configuration,DC=example,DC=com' -Properties auxiliaryClass | select -ExpandProperty auxiliaryClass <Enter>
example-Computer
ipHost
オプション: 新しい属性に値を追加する
新しい属性を作成したので、Microsoft ADディレクトリ内のコンピュータの属性に新しい値を追加しましょう。Windows PowerShellを開き、以下のコマンドを使用して新しい属性を設定します。
PS C:\> set-adcomputer -Identity <computer name> -add @{example-EC2InstanceID = '<EC2 instance ID>'}
次に、前のコマンドでコンピュータオブジェクトに追加されたEC2InstanceID値がMicrosoft ADディレクトリに存在するかどうかを検証します：
PS C:\> get-adcomputer -Identity <computer name> –Property example-EC2InstanceID
DistinguishedName : CN=<computer name>,OU=Computers,DC=example,DC=com
DNSHostName : <computer name>.example.com
Enabled : True
example-EC2InstanceID : <EC2 instance ID>
Name : <computer name>
ObjectClass : computer
ObjectGUID : e7c2f596-4f8c-4084-a124-6fc6babaf3c8
SamAccountName : <computer name>
SID : S-1-5-21-3794764471-3203795520-307520662-1104
まとめ
このブログ記事では、LDIFファイルをフォーマットする方法や、Directory Serviceコンソールを使用してMicrosoft ADディレクトリに対してLDIFファイルを適用する方法など、Microsoft ADスキーマの拡張に関する重要な概念、用語、および手順の概要を説明しました。別のドメインまたはアプリケーションからLDIFファイルをインポートする場合でも、これらの手順はディレクトリへの影響を理解する上で重要となります。スキーマの拡張は重要な操作ですので、まず、開発環境でアプリケーションでテストしてから本番環境でスキーマ更新を適用するようにしてください。
スキーマ拡張、LDIFファイルの作成方法、一般的なエラーの詳細については、AWS Directory Service documentationを参照してください。
AWS Directory Serviceの詳細については、AWS Directory Serviceのホームページを参照してください。質問がある場合は、Directory Service forumに投稿してください。
– Peter（日本語訳はSA渡邉（@gentaw0）が担当しました。原文はHow to Add More Application Support to Your Microsoft AD Directory by Extending the Schema）
