翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# AWS Managed Microsoft AD の主な概念
<a name="ms_ad_key_concepts"></a>

以下の主要な概念に精通していれば、 AWS Managed Microsoft AD をさらに活用できます。

**Topics**
+ [Active Directory スキーマ](#ms_ad_key_concepts_schema)
+ [AWS Managed Microsoft AD のパッチ適用とメンテナンス](#ms_ad_key_concepts_maintenance)
+ [グループ管理サービスアカウント](#ms_ad_key_concepts_gmsa)
+ [Kerberos の制約付き委任](#ms_ad_key_concepts_kerberos)

## Active Directory スキーマ
<a name="ms_ad_key_concepts_schema"></a>

スキーマとは、分散ディレクトリの一部をなしている属性とクラスの定義のことであり、データベースにおけるフィールドとテーブルに類似しています。スキーマには、データベースに追加または含めることができるデータの型や形式を決定する、一連のルールが含まれています。User クラスは、データベースに保存される *クラス* の一例です。例として、User クラスの属性には、ユーザーの姓、名、電話番号などを含めることができます。

### スキーマの要素
<a name="ms_ad_schema_elements"></a>

属性、クラス、オブジェクトは、スキーマのオブジェクト定義を作成するために使用される基本要素です。Managed AWS Microsoft AD スキーマを拡張するプロセスを開始する前に知っておくべきスキーマ要素の詳細を以下に示します。

**属性**  
各スキーマ属性は、データベース内のフィールドと類似しており、それ自体の特性を定義するためのプロパティをいくつか含んでいます。例えば、`LDAPDisplayName` は属性を読み書きするために LDAP クライアントで使用されるプロパティです。`LDAPDisplayName` プロパティは、すべての属性とクラスにおいて一意である必要があります。属性の特性に関する詳細な一覧については、MSDN ウェブサイトの「[Characteristics of Attributes](https://msdn.microsoft.com/en-us/library/ms675578(v=vs.85).aspx)」(属性の特性) を参照してください。新しい属性の作成方法に関する詳細なガイダンスについては、MSDN ウェブサイトの「[Defining a New Attribute](https://msdn.microsoft.com/en-us/library/ms675883(v=vs.85).aspx)」(新しい属性の定義) を参照してください。

**クラス**  
クラスは、データベースにおけるテーブルに相当するもので、複数のプロパティを定義することができます。例えば、`objectClassCategory` は、クラスのカテゴリを定義します。クラスの特性の詳細なリストについては、MSDN ウェブサイトの「[Characteristics of Object Classes](https://msdn.microsoft.com/en-us/library/ms675579(v=vs.85).aspx)」(オブジェクトクラスの特性) を参照してください。新しいクラスの作成方法に関する詳細については、MSDN ウェブサイトの「[Defining a New Class](https://msdn.microsoft.com/en-us/library/ms675884(v=vs.85).aspx)」(新しいクラスの定義) を参照してください。

**オブジェクト識別子 (OID)**  
各クラスおよび属性には、オブジェクトの全体で一意である OID を含める必要があります。ソフトウェアベンダーは、独自の OID を取得して、一意性を確保する必要があります。一意性を確保することで、複数のアプリケーションにおいて同一の属性が異なる目的で使用された場合の競合が回避されます。一意性を確保するには、ISO Name Registration Authority (ISO 名前登録機関) からルート OID を取得します。あるいは、Microsoft から基本 OID を取得することも可能です。OID および OID の取得方法に関する詳細については、MSDN ウェブサイトの「[Object Identifiers](https://msdn.microsoft.com/en-us/library/ms677614(v=vs.85).aspx)」(オブジェクト識別子) を参照してください。

**スキーマとリンクした属性**  
一部の属性は、2 つのクラス間で、前後の双方向でリンクされています。この最も適切な例としてはグループがあります。グループを調べると、そのグループのメンバーを確認でき、ユーザーを見た場合は、それが所属するグループを確認できます。ユーザーをグループに追加すると、Active Directory によってグループに対する前方リンクが作成されます。次に Active Directory は、グループからユーザーへの後方リンクを追加します。リンクされる属性が作成される際には、一意のリンク ID も生成される必要があります。詳細については、MSDN ウェブサイトの「[Linked Attributes](https://msdn.microsoft.com/en-us/library/ms677270(v=vs.85).aspx)」(リンク属性) を参照してください。

#### 関連トピック
<a name="schemaelements_related"></a>
+ [AWS Managed Microsoft AD スキーマを拡張するタイミング](ms_ad_schema_extensions.md#ms_ad_schema_when_to_extend)
+ [チュートリアル: AWS Managed Microsoft AD スキーマの拡張](ms_ad_tutorial_extend_schema.md)

## AWS Managed Microsoft AD のパッチ適用とメンテナンス
<a name="ms_ad_key_concepts_maintenance"></a>

AWS Directory Service for Microsoft Active Directory は、DS for AWS Managed Microsoft AD AWS とも呼ばれ、実際には Microsoft Active Directory Domain Services (AD DS) であり、マネージドサービスとして提供されます。システムはドメインコントローラー (DCs) に Microsoft Windows Server 2019 を使用し、サービス管理の目的でソフトウェアを DCs AWS に追加します。 は DC AWS を更新 (パッチ適用) して新機能を追加し、Microsoft Windows Server ソフトウェアを最新の状態に保ちます。 DCs パッチ適用プロセス中も、ディレクトリは引き続き使用可能な状態を維持します。

### 可用性の確保
<a name="ensuringavailability"></a>

デフォルトでは、各ディレクトリは 2 つの DC で構成され、それぞれが異なるアベイラビリティーゾーンにインストールされています。お客様の選択により、DC を追加して可用性をさらに高めることができます。高可用性と耐障害性を必要とする重要な環境では、追加の DCsをデプロイすることをお勧めします。パッチ適用中の AWS DCs AWS は使用できなくなります。1 つ以上の DCs が一時的に停止している場合、 は、ディレクトリに少なくとも 2 つの運用 DC があるまでパッチ適用を AWS 延期します。 DCs これにより、パッチ処理中であっても、ユーザーには運用可能な他の DC を提供することができます。通常、パッチには DC ごとに 30〜45 分を要しますが、この時間は変動する可能性があります。パッチを含む何らかの理由で 1 つ以上の DC が利用できない場合に、アプリケーションが動作中の DC にアクセスできるようにするには、静的な DC アドレスではなく Windows DC ロケーターサービスを使用するように、そのアプリケーションを設定します。

### パッチ適用のスケジュールを理解する
<a name="understandingpatching"></a>

DC で Microsoft Windows Server ソフトウェアを最新の状態に保つために DCs 、 は Microsoft の更新 AWS を使用します。Microsoft が毎月のロールアップパッチを Windows Server で使用できるように AWS するため、 は、3 暦週間以内にロールアップをテストしてすべてのカスタマー DCs に適用するために最善を尽くします。さらに、 は、DCs への適用性と緊急性に基づいて、Microsoft が毎月のロールアップ外でリリースする更新 AWS を確認します。Microsoft により*クリティカル*または*重要*と評価され、DC に関連性のあるセキュリティパッチについて、 AWS は、5 日間以内にそのパッチをテストしデプロイするための最大限の努力を払います。

## グループ管理サービスアカウント
<a name="ms_ad_key_concepts_gmsa"></a>

Microsoft は、グループ管理サービスアカウント (gMSA) と呼ばれる (サービス用の) アカウントを、管理者が管理するための新たな手法を Windows Server 2012 に導入しました。gMSA を使用することで、サービス管理者はサービスインスタンス間のパスワードを手動で同期させる必要がなくなります。代わりに、管理者は Active Directory 内に単一の gMSA を作成し、この gMSA を複数のサービスインスタンスで使用するように設定します。

 AWS Managed Microsoft AD のユーザーが gMSA を作成できるようにするには、*AWS 委任 Managed Service アカウント管理者*セキュリティグループのメンバーとしてアカウントを追加する必要があります。管理者アカウントは、デフォルトでこのグループのメンバーになっています。gMSA の詳細については、Microsoft TechNet ウェブサイトの「[Group Managed Service Accounts Overview](https://technet.microsoft.com/en-us/library/hh831782(v=ws.11).aspx)」(グループ管理サービスアカウントの概要) を参照してください。

**関連する AWS セキュリティブログの投稿**
+ [AWS Managed Microsoft AD が Active Directory 統合 .NET アプリケーションのデプロイを簡素化し、セキュリティを向上させる方法](https://aws.amazon.com/blogs/security/how-aws-managed-microsoft-ad-helps-to-simplify-the-deployment-and-improve-the-security-of-active-directory-integrated-net-applications/)

## Kerberos の制約付き委任
<a name="ms_ad_key_concepts_kerberos"></a>

Kerberos の制約付き委任は、Windows Server の機能の 1 つです。この機能を使用するサービス管理者は、アプリケーションサービスがユーザーの代わりに行う処理の範囲を制限することで、アプリケーションの信頼の境界を指定し適用できます。これは、バックエンドサービスに委任できるフロントエンドサービスアカウントを指定する際の役に立ちます。Kerberos の制約付き委任は、任意あるいはすべてのサービスに、gMSA が Active Directory ユーザーに代わり接続することを防止し、承認されていない開発者による不正使用の可能性を排除します。

例えば、ユーザー jsmith が HR アプリケーションにログインする場合を考えます。この時、SQL Server で jsmith のデータベースへのアクセス許可を適用する必要があります。ただし、SQL Server のデフォルトでは、データベース接続を開く際に jsmith で設定済みのアクセス許可を使用せず、hr-app-service のアクセス許可を適用するサービスアカウントの認証情報を使用します。HR 給与アプリケーションが SQL Server データベースにアクセスするために、jsmith の認証情報を使用できるように設定する必要があります。そのためには、 AWS内にある AWS Managed Microsoft AD ディレクトリの hr-app-service サービスアカウントに対して Kerberos の制約付き委任を有効にします。jsmith がログオンすると、このユーザー がネットワークの他のサービスへのアクセスを試みた場合に Windows が自動的に使用する Kerberos チケットが、Active Directory から提供されます。Kerberos の委任により、hr-app-service アカウントは jsmith の Kerberos チケットを再利用してデータベースにアクセスできます。つまり、jsmith に固有のアクセス許可を適用してデータベース接続を開くことが可能です。

 AWS Managed Microsoft AD のユーザーに Kerberos 制約付き委任の設定を許可するアクセス許可を付与するには、委任 *AWS Kerberos 委任管理者*セキュリティグループのメンバーとしてアカウントを追加する必要があります。管理者アカウントは、デフォルトでこのグループのメンバーになっています。Kerberos の制約付き委任の詳細については、Microsoft TechNet ウェブサイトの「[Kerberos Constrained Delegation Overview](https://technet.microsoft.com/en-us/library/jj553400(v=ws.11).aspx)」(Kerberos の制約付き委任の概要) を参照してください。

[リソースベースの制約付き委任](https://docs.microsoft.com/en-us/windows-server/security/kerberos/kerberos-constrained-delegation-overview#resource-based-constrained-delegation-across-domains)が、Windows Server 2012 に導入されました。これを使用することで、バックエンドサービス管理者は、サービスのために制約付き委任を設定できます。