Azure AD Domain Services の構築

Azure AD Domain Services Azure AD Domain Services
Azure AD Domain Services
Pocket

Azure AD Domain Services (以下、Azure AD DS) について、自身の理解を整理をするためにも、まずは Azure AD DS の概要を前半にまとめてみました。

後半は、実際の Contoso Corp という架空組織のシステム構成をもとに、デプロイ~ドメイン参加までを紹介しているので、興味がありましたら併せてご覧ください。

Azure AD Domain Services とは?

Azure AD DS の概要は、公開情報にも詳しく解説されています。が、やはり読んでもいまいちイメージが湧かないのが公開情報ですね。情報はすごく豊富なのですが…、ひとまず、おおざっぱなイメージを持つために最低限以下の抜粋部分が読めればよいと思います。

Azure Active Directory Domain Services (Azure AD DS) では、Windows Server Active Directory と完全に互換性のあるマネージド ドメイン サービス (ドメイン参加、グループ ポリシー、ライトウェイト ディレクトリ アクセス プロトコル (LDAP)、Kerberos 認証、NTLM 認証など) が提供されます。 クラウドでドメイン コントローラーのデプロイ、管理、および修正プログラムの適用を行わなくても、これらのドメイン サービスを使用することができます。 Azure AD DS は既存の Azure AD テナントと統合されるので、ユーザーは既存の資格情報を使用してサインインできるようになります。 さらに、既存のグループおよびユーザー アカウントを使用してリソースへのアクセスをセキュリティで保護することができます。このため、リフト アンド シフト方式でオンプレミスのリソースをよりスムーズに Azure に移行できます。

Azure Active Directory Domain Services とは
https://docs.microsoft.com/ja-jp/azure/active-directory-domain-services/overview

たまに、オンプレミスからの移行を目的とした「Active Directory のクラウド版」という位置づけで紹介された記事も見つかりますが、Active Directory の機能を完全に網羅するわけではないため、「Active Directory が提供していた一部の機能を Azure に拡張する手段の一つ」ぐらいの解釈を私はしています。

機能ベースで考えてもイメージがつきにくいので、シナリオ ベースに落とし込んで考えていきます。

「Azure にデプロイした Virtual Machine (VM) を Active Directory にドメイン参加させたい。」といった要件が在るとします。Azure AD DS が存在しない世界では、システム管理者は以下の手段から選択する必要あります。

  1. VPN (S2S) 接続を用意して、オンプレミス AD にドメイン参加させる。
  2. Exress Route を用意して、オンプレミス AD にドメイン参加させる。
  3. 別途、スタンドアロンな Active Directory を Azure に構築して、ドメイン参加させる。


しかしながら、いずれの手段も導入・運用コストは安くありませんし、手段 3. に関してはあまり合理的なものとは言えません。

そんな時、手段 4. として登場するのが Azure AD DS です。Azure AD DS は、Active Directory の一部の機能 (ドメイン参加、グループ ポリシー、LDAP、NTLM/Kerberos 認証など) を提供しています。そのため、システム管理者はネットワークを整備せずとも、VM を Azure AD DS ドメイン (マネージド ドメイン) に参加させることができます。

また、Azure AD のユーザー・グループ オブジェクトと、パスワード ハッシュ値が、Azure AD DS に同期される仕組みのため、利用者は同じ資格情報でアクセス可能というのが特徴です。

Azure AD Domain Services が必要なシナリオ

下記に紹介しておりますブログ記事では、Azure AD DS に適したシナリオ および 適さないシナリオが的確に区分けまとめられています。是非、こちらの記事を読んでみてください。

利用パターン 1: Azure 上にクラウド化したサービスに Kerberos/NTLM を用いて SSO したい
利用パターン 2: Azure AD アカウントに対する LDAPS 接続を提供したい – 注意: 読み取り専用
利用パターン 3: パスワードハッシュが同期できないなど特別なセキュリティ要件のある組織において、Azure 上にクラウド化したサービスに Kerberos/NTLM を用いて SSO したい

Azure AD Domain Services の利用シナリオ
https://docs.microsoft.com/ja-jp/azure/active-directory-domain-services/tutorial-configure-ldaps


本記事では、架空組織 Contoso Corp の既存システムと、要件を例に考えます。

Contoso Corp では、オンプレミス ネットワークに Active Directory および LDAP 連携するアプリケーション サーバーをホストしています。Contoso Corp では、アプリケーション サーバーの次期基盤として、 Azure VM への移行を検討しています。

Azure AD Domain Services
Contoso Corp のシステム環境


まず、Azure AD では LDAP に対応していません。そのため、システム管理者は VPN (S2S) もしくは、Express Route で通信経路を確保し、オンプレミスの ネットワーク範囲を Azure にまで拡張する必要があります。

Azure AD Domain Services
Contoso Corp シナリオ 1


そこで、Azure AD DS を導入する手段で考えてみます。Azure AD DS は LDAP に対応しているため、アプリケーション サーバーは Azure に移行後も引き続き LDAP 連携が行えます。また、システム管理者はネットワークなどのインフラ整備をする必要がありません。

Azure AD Domain Services
Contoso Corp シナリオ 2


さて、Azure AD DS に適さないシナリオがあります。冒頭でも触れましたが、Azure AD DS は「Active Directory のクラウド版」ではないため、それを前提としたシナリオにはもちろん適しません。

公開情報に Azure AD DS と Active Directory の機能を比較した表がありました。(とてもいい資料ですが、自動翻訳がイケていないため、英語ページを転記しています。)

表を見ると、意外と Active Directory と Azure AD DS の間に差異がないように見えますが、Azure AD DS では、特権ロール (Domain/Enterprise Admin) がないことから、限定的な管理操作しか行えません。

FeatureAzure AD DSSelf-managed AD DS
Managed service
Secure deploymentsAdministrator secures the deployment
DNS server (managed service)
Domain or Enterprise administrator privileges
Domain join
Domain authentication using NTLM and Kerberos
Kerberos constrained delegationResource-basedResource-based & account-based
Custom OU structure
Group Policy
Schema extensions
AD domain / forest trusts (one-way outbound forest trusts only)
Secure LDAP (LDAPS)
LDAP read
LDAP write (within the managed domain)
Geo-distributed deployments


このため、「オンプレミス Active Directory を将来的に廃止するため」もしくは、「オンプレミス Active Directory と同じように管理したい」といった要件に合わないこと、予め理解しておく必要があります。

また、特権ロールの有無に限らず、Azure AD DS ではシステム管理者が編集できない設定 (ReadOnly) も多くあるため、こういったギャップは認識しておく必要があります。

まとめますと、ドメイン参加、グループ ポリシーなど、従来のサービスを Azure リソースに対して “簡単” に提供できる一方で、制限事項が多いことから、オンプレミス Active Directory のような 設計・運用 は実現できない可能性が極めて高いです。

Azure AD Domain Services のメリット

まず、なんといってもマネージド サービスであることです。オンプレミスの Active Directory では一般的な非機能部分 (ハード管理、監視、可用性、性能性、バックアップ など) を設計、運用する必要があるわけですが、Azure AD DS ではそれらの部分が完全にマネージドであるために、管理者はここに工数を浪費する必要がありません。

また、Azure AD Domain Services はエディションによって従量課金額が異なりますが、際立って高額でないので、コスト面でもその他の手段と比較して優位かと思いました。(エディションによりますが、月額およそ数万円程度です。)

STANDARDENTERPRISEPREMIUM
AAD DS コア サービス
提案された認証負荷 (ピーク、時間別)10 ~ 3,0003,000 ~ 10,00010,000 ~ 70,000
提案されたオブジェクト数20 ~ 25,00025,000 ~ 100,000100,000 ~500,000
バックアップ頻度5 日ごと3 日ごと毎日3
リソース フォレストの信頼利用不可510
インスタンス
ユーザー フォレスト4¥16.80/時間/セット¥44.80/時間/セット10¥179.20/時間/セット
リソース フォレスト (プレビュー)4該当なし¥22.40/時間¥89.60/時間


個人的に推したいのは、Secure LDAP です。Internet を経由して Azure AD DS に LDAPS 接続する機能ですが、これは Azure AD DS ならでは、な機能ですね。

Secure LDAP

Active Directory では、例えば、 DMZ セグメントに配置して Internet から LDAP 接続させる、といった用途に適しません。(技術的には可能ですが、そういったシナリオは想定されておらず、且つ RODC であろうがセキュリティ的に一般的ではない構成です。)

気になった方は下記の公開情報からその詳細を確認してみてください。



まとめますと、主に下記の点が Azure AD DS の主な利点といえます。

  • インフラの整備を必要とせずに、NTLM/Kerberos、グループ ポリシー、LDAP などのサービスが Azure リソースに提供できる。
  • その他の手段と比べると、導入 および 運用コストが安い。と思う。
  • マネージドなサービスであるため、システム管理者の運用工数が削減できる。
  • Secure LDAP を使ってディレクトリを安全に公開できる。


一方で、オンプレミスのように細かな管理ができないというデメリット (というよりかはクラウドの制限) がありますが、これはクラウドの特徴の話であって、これをデメリットとして扱うのはもはやナンセンスな気がします。

さて、Azure AD DS の概要についてはこれぐらいにしておき、以降では実際に Azure AD DS のデプロイに焦点向けていきます。

Azure AD Domain Services の同期について

Azure AD DS では、ドメイン内にユーザー オブジェクトを作成する方法として、以下の2つがあります。本章では、方法 2. の同期処理に関する内容について説明します。デプロイするにあたって、この同期処理を理解しておかないと、恐らくハマります。

  1. [Active Directory ユーザーとコンピューター] を使用してマネージド ドメインに直接作成する。
  2. Azure AD → Azure AD DS の同期処理によって作成する。


Azure AD DS では、Azure AD のユーザー・グループ オブジェクト および パスワード ハッシュ値が同期されるため、管理者はアカウントの二重管理をする必要はなく、利用者はオンプレミス または Azure AD と同じ資格情報でリソースにアクセスできます。

同期処理は、Azure AD → Azure AD DS への一方向であるため、同期処理によって生成されるユーザー オブジェクトは読み取り専用になります。加えて、パスワードも Azure AD の管轄であるため、Azure AD DS からパスワード リセットも行えません。

Azure AD Domain Services – 同期のしくみ


この同期プロセスは自動で行われるため、システム管理者が操作する必要はありません。また、デプロイ直後の初回同期には、Azure AD のオブジェクト数によっては数時間~数日ほど要するとのことですが、その後の同期サイクルに関しては 20 ~ 30 分に 1 回程度のサイクルで実行されているように見えます。
※ あくまで私個人の体感なので、参考程度にしてください。

なお、Azure AD → Azure AD DS に同期されるユーザー・グループ オブジェクトの属性は公開情報にまとまっています。


次に、Azure AD DS のパスワード ハッシュ同期について触れます。Azure AD のユーザー オブジェクトには、下記 の 2 つの種別に分けることができます。

  1. クラウド ID:Azure AD で直接作成したユーザーのこと。
  2. ハイブリッド ID:Azure AD Connect によって同期されたユーザーのこと。

まず、上記の1. 2. いずれのユーザー種別であっても、既定では Azure AD DS (Active Directory) で扱うことのできる NT LAN Manager (NTLM) および Kerberos のパスワード ハッシュ値を保持していません。

また、 Azure AD ではセキュリティの観点からユーザーのパスワードをクリア テキスト形式で保存していないため、既存のユーザー オブジェクトに対して、NTLM/Kerberos のパスワード ハッシュ値を生成する方法がありません。

パスワード ハッシュ値を同期するためには、システム管理者 および 利用者は、ユーザー種別に応じて下記のタスクを遂行する必要があります。

実行者タスク
クラウド ID利用者 または システム管理者パスワード のリセット または 変更
ハイブリッド IDシステム管理者パスワード ハッシュ同期の有効化


クラウド ID の場合

クラウド ID の場合、Azure AD DS をデプロイする以前に存在していたユーザーは、NTLM/Kerberos 認証用のパスワード ハッシュ値を持っていません。

このため、パスワードのリセット または 変更を実施すると同時に、NTLM/Kerberos 認証用のパスワード ハッシュ値を生成して、それを Azure AD DS に同期します。

つまり、既存のユーザーが Azure AD DS にログオンするには、パスワード リセット もしくは 変更しておき、Azure AD DS に同期しておく必要があります。

なお、デプロイ後に作成したクラウド ID のユーザーは、初回のパスワード生成のタイミングで、パスワード ハッシュ値の生成および同期行われるため、パスワード変更の必要はありません。

ハイブリッド ID の場合

次に、ハイブリッド ID の場合、Azure AD Connect のパスワード ハッシュ同期を有効にすることで、NTLM/Kerberos 認証用のパスワード ハッシュ値を Azure AD に同期できます。すでに有効になっている場合、下記のリンク先にある Re-enable 処理を、コマンドで実行するだけです。


Azure AD に格納されるパスワード ハッシュ値は、Azure AD テナントごとに一意で生成されるキーで暗号され、安全に格納されます。このあたりのメカニズムが気になる方は以下を参考にしてください。



Azure AD Domain Services のデプロイ

それでは、Azure AD DS のデプロイをしていきましょう。本記事では、下図の青枠内のシナリオを前提に進めます。

Azure AD Domain Services
Contoro Corp – Azure AD DS デプロイ シナリオ例


Azure AD DS のデプロイは非常に簡単且つシンプルです。基本的にチュートリアルに沿って進めればとくにつまづくポイントもありません。



前提条件

まずは、前提条件から確認していきます。

このチュートリアルを完了するには、以下のリソースと特権が必要です。
・有効な Azure サブスクリプション
・Azure サブスクリプションをお持ちでない場合は、アカウントを作成してください。
・ご利用のサブスクリプションに関連付けられた Azure Active Directory テナント (オンプレミス ディレクトリまたはクラウド専用ディレクトリと同期されていること)。
・必要に応じて、Azure Active Directory テナントを作成するか、ご利用のアカウントに Azure サブスクリプションを関連付けます。
・Azure AD DS を有効にするには、Azure AD テナントに “全体管理者” 特権が必要です。
・必要な Azure AD DS リソースを作成するためには、ご利用の Azure サブスクリプションに “共同作成者” 特権が必要です。

Azure AD DS では必須ではありませんが、Azure AD テナントには、SSPR (Self-Service Password Reset: セルフサービス パスワード リセット ) を構成することをお勧めします。 SSPR がなくても、ユーザーは自分のパスワードを変更できます。しかし、ユーザーがパスワードを紛失してしまってリセットする必要が生じた場合には SSPR が役立ちます。

チュートリアル:Azure Active Directory Domain Services インスタンスを作成して構成する
https://docs.microsoft.com/ja-jp/azure/active-directory-domain-services/tutorial-create-instance#prerequisites


一点、注意があるとすれば、Azure AD DS をデプロイ後、そのインスタンスを別のリソース グループ、仮想ネットワーク、サブスクリプションなどに移動することはできません。
仮に上記のような要件でてきた場合、Azure AD DS を再作成するしか手段はなく、且つデータはすべて削除されますので、注意が必要です。

仮想ネットワークの計画

Azure AD DS のデプロイ時に計画することがあるとすれば、仮想ネットワークです。


基本的には、Azure AD DS をデプロイすると同時に生成される仮想ネットワークを使用しましょう。なのですが、既存の仮想ネットワークを選択することも可能です。
デプロイする仮想ネットワークにおける考慮点はいくつかあるため、ここは計画的に設計しましょう。

  • Azure AD DS がサポートされるリージョンの仮想ネットワークを選択する必要がある。
  • Azure AD DS と クライアント間の遅延を最小限にするため、物理的に近いリージョンが推奨されている。
  • 既存のサブネットにデプロイしてはいけないため、独自サブネットを定義する必要がある。
  • Azure AD DS および 既存システムがお互い影響し合わないよう、Azure AD DS 専用の仮想ネットワークを用意するのが理想的である。
  • 同時に生成される ネットワーク セキュリティ グループ (NSG) は、Azure AD DS の要件を満たす必要がある。
  • クライアントがマネージド ドメインを名前解決できるよう、DNS の参照先を Azure AD DS が提供する DNS (Windows Server DNS) に設定する必要がある。(ほかの DNS から条件付きフォワーダー経由で名前解決させる構成でもサポートされていそう。)
  • マネージド ドメインの通信を妨げる恐れがあるため、不要なユーザー定義ルートは作成しないようにする。
  • クライアントが異なるVirtual Network (Vnet) にいる場合、ピアリング接続する必要がある。

デプロイによって生成される Azure LoadBalancer や Network Security Group のルールに対する編集や削除などは控えることを推奨しています。仮にルールを変更したことで Azure AD DS の要件を満たしていない場合、SLA の対象外と判断されます。

Azure AD Domain Services インスタンスを作成する

Azure AD DS インスタンスは Azure Portal または Azure Powershell から作成いただけます。本記事では、Azure Portal の流れを掲載していますが、Powershell で有効化する手順は公開情報に紹介されているので、こちらを参考にしてください。



Azure AD Domain Services

1. Azure AD のグローバル管理者 且つ サブスクリプションに所有者ロールを持つアカウントで、Azure Portal にサインインします。

2.上部の検索バーに「Azure AD Domain Services」と入力し、メニュー画面へ移動します。

3. [Azure AD Domain Services の作成] をクリックします。

Azure AD Domain Services の作成 – 基本

4. 各種入力します。マネージド ドメイン名については、以下の補足を参考にしてください。
※ [フォレストの種類] は “ユーザー” を選択します。リソース フォレストはまたの機会に。

[補足] Azure AD DS のマネージド ドメイン名について

以下の3つのドメイン種別から選択可能です。

  • 組み込みドメイン … ***.onmicrosoft.com
  • カスタム ドメイン … itbeginner.tech など、インターネット上でルーティング可能なドメイン
  • ルーティング不可能なドメイン … hoge.local など、インターネット上でルーティング不可能なドメイン

既定では、組み込みドメインが選択されていますが、Secure LDAP を使用してインターネット経由でのアクセスが発生する場合、カスタム ドメインを選択しましょう。Secure LDAP では、当然ですがインターネット上でルーティングが可能なドメイン 且つ SSL 証明書が発行可能なドメインが必要なためです。

Secure LDAP を使用しないのであれば、組み込みドメインやルーティング不可能なドメインを選択しても構いません。

Azure AD Domain Services の作成 – ネットワーク

5. 今回のシナリオでは、仮想ネットワークおよび サブネットを新規作成します。

Azure AD Domain Services の作成 – 管理

6. Azure AD DS を管理できるユーザー および 通知先を設定します。

AAD DC Administrators というセキュリティ グループのメンバーが Azure AD DS を管理できます。Azure AD DS の管理ユーザーになる Azure AD ユーザーをメンバーシップに入れておきましょう。

Azure AD Domain Services の作成 – 同期

7. Azure AD → Azure AD DS に同期するユーザーの範囲を指定します。範囲を限定する場合はグループ単位でスコープを設定いただけます。

Azure AD Domain Services の作成 – 確認および作成

8. あとは [作成] するだけです。本当に簡単ですね…。

デプロイには最大で 1 時間程度を要することもあるため、気長に待ちましょう。
デプロイ および その後の同期状況については、[Azure AD Domain Services] – [概要] 、[正常性] から確認いただけけます。

デプロイ および 初回の同期が完了しますと、[正常性] メニューからご確認いただけます。

Azure AD Domain Services – 正常性

いろいろと準備

本記事の環境では、ドメイン参加するために以下のタスクを完了させる必要があります。いずれも本筋の話ではないため、公開情報の紹介程度とさせてください。

  1. DNS の設定
  2. 仮想ネットワーク ピアリング

まず、図中の VM がドメイン参加できるようにするには、マネージ ドメイン名 を解決できるように参照先 DNS を変更する必要があります。


本当は条件付きフォワーダーとか設定して試したかったのですが、VM にアタッチされた NIC の [カスタム DNS サーバー] から、Azure AD DS の IP アドレスを指定しました。
※ OS に反映させるには、VM の再起動が必要です。

カスタム DNS サーバー


次に、VM と Azure AD DS の各仮想ネットワーク間に接続を確立するために、仮想ネットワーク ピアリングを構成しました。公開情報の通りにすれば問題なく構成できます。



マネージド ドメイン に ドメイン参加

VM からマネージド ドメインに参加するには、AAD DC Administrators グループ メンバーの資格情報が必要です。加えて、クラウド ID の場合は事前にパスワード変更しておき、Azure AD DS に同期しておきます。

準備が整えば、あとは通常の Windows Server 通りにドメイン参加すれば OK です。入力する資格情報は AAD DC Administrators メンバーの資格情報を入力します。

マネージド ドメインへのドメイン参加

再起動後、VM にドメイン ユーザーとして VM にログオンいただけます。

おわりに

さて、Azure AD DS の概要に加えて、デプロイ~ドメイン参加までのシナリオを通しましたが、いかがでしたでしょうか。

本来は、設計や運用の話に焦点を置いて記事を書こうかと思ったのですが、まずは自身の理解を整理するためにも概要部分をまとめました。

本記事をご覧になった方々に、Azure AD DS の理解が少しでも深まれば幸いです。

それでは、よい Azure AD ライフをっ♪

Pocket

コメント

タイトルとURLをコピーしました