クラウドエンジニアブログ

Active Directory の PaaS 版「Azure AD Domain Services」まとめ

新井

新井

はじめに

9月には Microsoft Ignite もありましたが、Azure がますます便利になるにつれてオンプレミス環境からの移行を考える機会も増えると言えます。

オンプレミスからの移行となった場合に切っても切り離せないのが ID の移行です。
LDAP や Windows 統合認証、グループポリシーなど昔からある Windows Server Active Directory (以下、WSAD) の機能をクラウド上でも実装する事が肝要になります。

「WSAD の機能」で直ぐに思いつく実装手法と言えば下記です。

  • オンプレミスと Azure 間を接続し、Azure 仮想マシンで WSAD のレプリカを作成
  • Azure 上にシステム用の WSAD を新規に作成

これらが間違っているわけではないのですが、管理コストや仮想マシン費用など実装した分だけ各種コストが純増する仕組みであり、IT 管理者としては手放しでは喜べないかもしれません。

そこで生まれたのが Azure AD Domain Services (以下、AADDS) です。今回は、本機能の仕組みを簡単に説明してみたいと思います。

しくみ

AADDS は、一言で表すと Azure AD の情報を基にドメインコントローラー (以下、DC)を PaaS として提供するサービスになります。そのため、ドメイン参加やグループ ポリシー、各種認証機能と言った WSAD の機能を提供しつつも DC の構築や修正プログラムの適用と言った従来の作業を行う必要はありません。

Azure AD の情報を基に展開されるサービスとなるためシナリオは以下の二つです。

シナリオ 1:Azure 上で完結する WSAD 代替

Azure 上で完結する WSAD 代替

このシナリオでは WSAD との連携はありません。ユーザーが Azure AD 上のユーザーをメンテナンスするとその情報が AADDS に連携され、仮想マシンが参照 (利用) 可能になります。

クラウドユーザー (xxxx@contoso.onmicrosoft.com) ⇒ Azure AD のメンテナンス

WSAD との連携が無いため、AADDS では「クラウドユーザー」のみが利用可能になります。

シナリオ 2:シナリオ 1 + WSAD 連携

シナリオ 1 + WSAD 連携

このシナリオでは、更に Azure AD を介して WSAD と連携することも可能になります。ユーザーがオンプレミス上の WSAD をメンテナンスすると 最終的にはユーザー情報が AADDS まで連携されます。

クラウドユーザー (xxxx@contoso.onmicrosoft.com) ⇒ Azure AD のメンテナンス
同期ユーザー (xxx@contoso.local) ⇒ WSAD のメンテナンス

AADDS では、「クラウドユーザー」「同期ユーザー」二種類が利用可能になりますが、ユーザーの種別によりメンテナンスを行う箇所が分かれます。

いずれのシナリオにおいても、管理者は AADDS で生成される DC の修正プログラムの適用作業やレプリケーショントポロジの設計などを考慮する必要は無く、サービス提供されるのです。

考慮点

AADDS は DC を自社で保持することなく WSAD の機能を享受できる素晴らしいサービスではありますが、考慮点も存在します。AADDS の実体は、WSAD の純粋なレプリカではなく、Azure AD を媒介とした全く別の AD だからです。以下は代表的な考慮点です。

  1. ドメインまたはエンタープライズ管理者の特権
    サービスを利用するに当たって必要な特権はもちろん支給されますが、ドメインやエンタープライズの管理者特権は利用できません。
  2. スキーマの拡張機能
    スキーマの拡張は行えません。
  3. AD ドメイン/フォレストの信頼
    他のドメインとの信頼関係を結ぶ事は出来ません。
  4. WSAD からの同期
    前項の「シナリオ 2」においては、Azure AD にパスワード同期を行う事が必須です。また、WSAD に設定していた以下のよくあるデータは同期されません。
  5. 同期方向
    原則的に、AADDS から Azure AD に何かの情報を書き戻すことは出来ません。従って、AADDS 側からパスワードやグループ メンバーシップ、グループ属性の変更を行う事は出来ず、Azure AD や WSAD からの変更を必要とします。
  6. LDAP 書き込み
    LDAP の参照は可能ですが、書き込みを行う事は出来ません。
  7. 地理的に分散したデプロイ
    展開できる Azure の仮想ネットワークは常に一つです。即ちジオ分散は出来ません。
  8. Azure AD 一つに対して AADDS 一つ
    同じ Azure AD の情報を持つ AADDS は常に一つだけなので、SI などにおける「別プロジェクト用 AADDS」といった 1 対 N の関係は成立しません。

このように WSAD とは異なるため考慮する点は存在しますが、管理者の負担を増やすことなく WSAD 準拠の環境を構成できるのが AADDS の強みです。

実装

それでは、前項の「シナリオ 1」を目指して流れで見てみましょう。なお、本手順においては、事前に以下のオブジェクトを作成しておきます。

  • AADDS を展開する仮想ネットワーク
  • AAD DC Administrators グループに所属させるクラウドユーザー
  • テスト用の仮想マシン

「その他のサービス」-「その他」-「Azure AD Domain Services」と移動します。

Azure AD Domain Services

画面中央から「+追加」を押下します。

+追加

基本パネルを全て入力します。なお、DNS ドメイン名は任意の名称が可能ですが、プレフィクス部分のみで 15 文字以内にする必要があります。また、名称は接続される予定のネットワークのいずれにおいても利用されていない必要があります。

基本パネルの入力

ネットワークパネルにおいて、AADDS を展開する仮想ネットワークとサブネットを選択します。なお、AADDS を展開する仮想ネットワークの要件 (推奨) は以下の通りです。

  • AADDS の専用サブネットを用意し、このサブネットに他の仮想マシンを展開しない
  • ゲートウェイ サブネットに AADDS を展開しない
  • サブネットに使用可能な IP アドレスが少なくとも 3-5 個あること
ネットワークパネル

管理者とグループパネルにおいて、ユーザーを選択します。「AAD DC Administrators」グループに所属するユーザーは、各コンピューターやサーバー上でローカル管理者に指定される他、グループポリシーの構成などの AADDS の管理者タスクを実行する事ができます。

管理者とグループパネル

この次の概要パネルでは内容を確認して「OK」を押下します。

1 時間ほどすると AADDS が構成されますので、これで AADDS 自体の設定は完了です。

AADDS

次は、各仮想マシンにてドメインに参加するために DNS サーバーの値を変更します。DNS サーバーの値の変更手段は複数用意されていますので、適切な手法を選択ください。以下は、AADDS の概要ページから行える仮想ネットワーク全体での DNS サーバーの変更手順となります。

作成した AADDS の DNS ドメイン名を押下します。

DNS ドメイン名

概要ページの中央に表示されている二つの IP アドレスが DC の IP アドレスとなりますので、控えた上で「DNS サーバーの構成」を押下します。

DNS サーバーの構成

DNS サーバーページにおいて「カスタム」を選択し、入力フィールドに先ほど控えた二つの IP アドレスを入力し、最後に「保存」を押下します。

DNS サーバーページ

構成が完了したら、新しい DNS サーバーの値を各仮想マシンに反映させるために、仮想マシンを再起動してください。

ドメイン参加

作成しておいた仮想マシンにリモートデスクトップにてログインし、コマンドプロンプトを起動します。その後、作成した AADDS の DNS ドメイン名を解決すると応答が有る事がわかります。

コマンドプロンプト

通常の WSAD 参加の手法でドメインに参加する事が出来ました。

コマンドプロンプト

もちろん、OS の再起動後も正しくドメイン参加をしている事がわかります。

DNS サーバーページ

管理者タスク

構成された AADDS において、管理者のタスク (e.g. OU 作成等) をするためには以下の二つが必要です。

  • AADDS のドメイン参加済みのコンピューター (サーバーが楽です)
  • AAD DC Administrators グループに所属するユーザー

AADDS ドメイン参加済み仮想マシンに AAD DC Administrators グループ所属ユーザーにてリモートデスクトップを用いてログインします。その後、サーバーマネージャーを起動し、「役割と機能の追加ウィザード」を起動します。

その後、「機能」ページにて以下のコンポ―ネントをインストールします。

  • 「グループポリシー管理」
  • 「リモートサーバー管理ツール」-「役割管理ツール」-「AD DS および AD LDS ツール」
  • 「リモートサーバー管理ツール」-「役割管理ツール」-「DNS サーバー ツール」
役割と機能の追加ウィザード

コンポーネントのインストール後は WSAD と同様の管理が可能です。

グループポリシーの管理

ただし、Domain Admins グループへの追加など、サービスとして不可となっているものはやはり行えません。

Domain Admins グループへの追加

おわりに

WSAD のレプリカではないため、すべての管理者タスクが行えるわけではありませんが、新たに Active Directory を構成する必要が無い分、管理者の負担は大幅に軽減されるはずです。加えて、DC の管理を Microsoft が行ってくれるというのは非常に助かります。

管理者としてのタスクの在り方がまた一つ変わろうとしているようです。


次回予告

  • RBAC 機能によるリソースアクセス制御

【総合】お問い合わせ

ソリューションに関する全般的なお問い合わせはお気軽にご相談ください。

ピックアップ

セミナー情報
クラウドエンジニアブログ
clouXion
メールマガジン登録