9月には Microsoft Ignite もありましたが、Azure がますます便利になるにつれてオンプレミス環境からの移行を考える機会も増えると言えます。
オンプレミスからの移行となった場合に切っても切り離せないのが ID の移行です。
LDAP や Windows 統合認証、グループポリシーなど昔からある Windows Server Active Directory (以下、WSAD) の機能をクラウド上でも実装する事が肝要になります。
「WSAD の機能」で直ぐに思いつく実装手法と言えば下記です。
これらが間違っているわけではないのですが、管理コストや仮想マシン費用など実装した分だけ各種コストが純増する仕組みであり、IT 管理者としては手放しでは喜べないかもしれません。
そこで生まれたのが Azure AD Domain Services (以下、AADDS) です。今回は、本機能の仕組みを簡単に説明してみたいと思います。
AADDS は、一言で表すと Azure AD の情報を基にドメインコントローラー (以下、DC)を PaaS として提供するサービスになります。そのため、ドメイン参加やグループ ポリシー、各種認証機能と言った WSAD の機能を提供しつつも DC の構築や修正プログラムの適用と言った従来の作業を行う必要はありません。
Azure AD の情報を基に展開されるサービスとなるためシナリオは以下の二つです。
シナリオ 1：Azure 上で完結する WSAD 代替
このシナリオでは WSAD との連携はありません。ユーザーが Azure AD 上のユーザーをメンテナンスするとその情報が AADDS に連携され、仮想マシンが参照 (利用) 可能になります。
クラウドユーザー (xxxx@contoso.onmicrosoft.com) ⇒ Azure AD のメンテナンス
WSAD との連携が無いため、AADDS では「クラウドユーザー」のみが利用可能になります。
シナリオ 2：シナリオ 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 だからです。以下は代表的な考慮点です。
このように WSAD とは異なるため考慮する点は存在しますが、管理者の負担を増やすことなく WSAD 準拠の環境を構成できるのが AADDS の強みです。
それでは、前項の「シナリオ 1」を目指して流れで見てみましょう。なお、本手順においては、事前に以下のオブジェクトを作成しておきます。
「その他のサービス」-「その他」-「Azure AD Domain Services」と移動します。
画面中央から「＋追加」を押下します。
基本パネルを全て入力します。なお、DNS ドメイン名は任意の名称が可能ですが、プレフィクス部分のみで 15 文字以内にする必要があります。また、名称は接続される予定のネットワークのいずれにおいても利用されていない必要があります。
ネットワークパネルにおいて、AADDS を展開する仮想ネットワークとサブネットを選択します。なお、AADDS を展開する仮想ネットワークの要件 (推奨) は以下の通りです。
管理者とグループパネルにおいて、ユーザーを選択します。「AAD DC Administrators」グループに所属するユーザーは、各コンピューターやサーバー上でローカル管理者に指定される他、グループポリシーの構成などの AADDS の管理者タスクを実行する事ができます。
この次の概要パネルでは内容を確認して「OK」を押下します。
1 時間ほどすると AADDS が構成されますので、これで AADDS 自体の設定は完了です。
次は、各仮想マシンにてドメインに参加するために DNS サーバーの値を変更します。DNS サーバーの値の変更手段は複数用意されていますので、適切な手法を選択ください。以下は、AADDS の概要ページから行える仮想ネットワーク全体での DNS サーバーの変更手順となります。
作成した AADDS の DNS ドメイン名を押下します。
概要ページの中央に表示されている二つの IP アドレスが DC の IP アドレスとなりますので、控えた上で「DNS サーバーの構成」を押下します。
DNS サーバーページにおいて「カスタム」を選択し、入力フィールドに先ほど控えた二つの IP アドレスを入力し、最後に「保存」を押下します。
構成が完了したら、新しい DNS サーバーの値を各仮想マシンに反映させるために、仮想マシンを再起動してください。
作成しておいた仮想マシンにリモートデスクトップにてログインし、コマンドプロンプトを起動します。その後、作成した AADDS の DNS ドメイン名を解決すると応答が有る事がわかります。
通常の WSAD 参加の手法でドメインに参加する事が出来ました。
もちろん、OS の再起動後も正しくドメイン参加をしている事がわかります。
構成された AADDS において、管理者のタスク (e.g. OU 作成等) をするためには以下の二つが必要です。
AADDS ドメイン参加済み仮想マシンに AAD DC Administrators グループ所属ユーザーにてリモートデスクトップを用いてログインします。その後、サーバーマネージャーを起動し、「役割と機能の追加ウィザード」を起動します。
その後、「機能」ページにて以下のコンポ―ネントをインストールします。
コンポーネントのインストール後は WSAD と同様の管理が可能です。
ただし、Domain Admins グループへの追加など、サービスとして不可となっているものはやはり行えません。
WSAD のレプリカではないため、すべての管理者タスクが行えるわけではありませんが、新たに Active Directory を構成する必要が無い分、管理者の負担は大幅に軽減されるはずです。加えて、DC の管理を Microsoft が行ってくれるというのは非常に助かります。
管理者としてのタスクの在り方がまた一つ変わろうとしているようです。
次回予告
関連ページ
Microsoft Azure 導入・運用支援サービス 詳細 |
