AWSのマネージドADでOffice365と連携する

構成概要

• プライベートサブネット
  • マネージドAD として Microsoft AD をMulti-AZで配置します。
  • ADおよびDNSの管理サーバとしてEC2のWindowsサーバを1台配置します。
• パブリックサブネット
  • Azure ADへのディレクトリ連携ツールとして Azure AD ConnectをEC2として配置します。
  • Azure AD Connectの冗長化コンポーネントであるAzure AD Connect認証エージェントを異なるサブネットにEC2として配置します。
• ネットワーク
  • AD参加経路
    • Windows端末からのAD参加はKerberos認証となるため、セキュアな経路が必要になります。
      • この例ではWANが提供するDirectConnect接続サービスの利用を想定しています。
  • AzureADへの同期処理
    • 異なるパブリッククラウドとなるためインターネット経由になります。
      • Azure AD Connectの仕様により主としてHTTPSが用いられます。
• 認証処理
  • Office365(Azure AD)へのログイン時に、内部ではAzure AD Connectのパススルー認証機能を経由してMicrosoft ADへ問合せに行きます。
  • このときOffice365に入力するものは、ADログオン時に用いているのと同じアカウント名です。社内などAD参加済み端末の場合はパスワード入力は不要で、社外の場合はパスワード入力も必要になります。

今回の構成に必要なOffice365の知識を整理します。

• Office365アカウントの実体はAzure ADです。
  • Office365をサインアップすると自動的にAzure ADのFreeエディションが構成されます。
  • Microsoft AD アカウントの同期先はAzure ADがターゲットになります。
  • Office365を利用するには、Azure ADに同期されたユーザにライセンスを割り当てる必要があります。
• Azure ADのエディションにより、アカウント同期の機能が変わります。
  • Free版：下記機能が不可
  • Basic版：セルフパスワードリセットが可能
  • PremiumP1以上：パスワード書き戻しが可能
  • つまり、有償版を利用することで逆方向(Azure AD -> Microsoft AD)の更新が一部可能になるということです。
• Azure ADにおけるドメイン
  • 既定のドメインとカスタムドメイン
    • 既定のドメイン
      • デフォルトで用意されるドメインです。onmicrosoft.comのサブドメインという扱いになります。
        • (任意).onmicrosoft.com
    • カスタムドメイン
      • 既定のドメインから変更したい場合は、ドメイン名とDNSゾーンを別途取得した上で作成することができます。
  • プライマリとフェデレーション
    • AzureADのドメインには2つの扱いが存在します。
    • プライマリ
      • 主として利用するドメインです。outlookのメールアドレス名やログインアカウントになります。
    • フェデレーション
      • フェデレーション型のシングルサインオン(SSO)を利用する場合はチェックが付きます。
      • AzureADの仕様上、プライマリに設定しているドメインをフェデレーションすることはできません。(プライマリディレクトリとして扱われるため)
        • 一般的にはOffice365導入時にカスタムドメインを登録し、それをプライマリドメインに設定する形になるかと思います。ただしSSO導入などでフェデレーションを行おうとすると、上記制限が障壁になります。
        • 今回の構成ではフェデレーションを用いないため、詳細は割愛します。
  • アカウント同期におけるドメイン一致について
    • 今回の構成ではMicrosoft ADとAzure ADのアカウント同期にAzure AD Connect(AADC)というソフトウェアを利用します。
      • AADCでは異なるドメイン同士でのアカウント同期も可能ですが、そのために必要な設定はドメインに対する影響が大きいため、同一ドメインでアカウント同期を行うことをお勧めします。

今回の構成に必要なAWS Microsoft AD(MSAD)の知識を整理します。

• MSADとは
  • AWSのマネージドディレクトリサービスの１つです。
  • 他のディレクトリサービスとの比較は割愛します。
• 特徴
  • Kerberos認証対応のため、企業端末のWindowsログオン認証に利用可能です。
  • 独立したADとして構築することができ、他のADとの信頼関係構築が可能です。
  • 自動的な冗長化(Multi-AZ)による高い耐障害性があります。
  • WindowsServer2012R2をベースにしているため、操作ノウハウがWebに豊富です。
  • マネージドADのためサーバ管理が不要で自動スナップショットによるバックアップが可能です。
• 注意点
  • 別途管理用OSが必要になります。
    • MSADへのリモートデスクトップ接続はできません。
    • MSADのドメインに参加できる位置にあるWindowsOS(オンプレorクラウド問わず)を用意し、Windows標準のAD管理ツール、DNS管理ツールをインストールしそのUI上で管理します。
  • 操作権限が限定されています。
    • 従来の管理者権限(EnterpriseAdmins, DomainAdmins)は付与されません。
    • 管理対象ドメインのOUにたいする権限は一通り委譲されているため一般的なユーザ/GPO管理に問題はありませんが、ドメインユーザのパスワードポリシー変更手段(※)やSSOにおけるユーザプロビジョニングに影響することがあります。
      • ※一般的な方法(DefaultDomainPolicy)ではなくファイングレインパスワードポリシーから設定できます。
  • 既存ADのアカウントデータを自動で移行することができません。
    • 従来のオンプレでは新規サーバを既存ドメインに参加させドメインコントローラに昇格させることでアカウントデータをコピーできましたが、MSADでは既存ドメインに参加することができないためそのような手段が取れません。
    • したがって既存ADのアカウントデータは手動もしくはエクスポート/インポート(※)で登録することになります。
      • ※csvdeコマンドを利用します。ただしパスワードは移行できないため再登録が必要になります。
      • 既存ADを将来的に残すのであれば信頼関係を確立するという手段も選択肢に入ります。
• その他仕様
  • DNS機能について
    • MSADをプライベートサブネットに設置した場合でも外部の名前解決はできます。ただしAmazonProvidedDNSにフォワードされるわけではありません。
    • そのためVPC内インスタンス/エンドポイントの名前解決を行う場合や、Route53のプライベートホストゾーンを参照したい場合は、DNSフォワーダ先としてAmazonProvidedDNSを指定する必要があります。
  • 耐障害性について
    • 提供される2つのADのうち、どちらかがFSMOとして機能します。
      • FSMOの確認は以下コマンドで行うことができます。
        • netdom /query fsmo
    • 障害発生時は最新バックアップを元に自動的に元のIPで復旧します。
    • FSMO側で障害がおきた場合、復旧するまでの間は従来のオンプレのFSMO障害と同様の影響(※)が発生します。
      • ※ADユーザパスワード変更不可等

今回の構成に必要なAzure AD Connect(AADC)の知識を整理します。

• AADCとは
  • Microsoftが提供する、AzureADと一方のディレクトリを統合してくれるツールです。
  • WindowsServer上にインストールするソフトウェアで、数分程度で簡単に導入できます。
  • インストール要件は用いる同期機能によって異なります。
    • パスワード同期の場合： WindowsServer 2008 R2 SP1以降
    • パススルー認証の場合： WindowsServer 2012 R2以降
  • 導入により、ADFSとWAP(AD FS Proxy)が不要になるケースがあります。
    • 従来、ADのアカウント機能を外部サービスと連携させるにはADFSとWAPが必要でした。さらにそれぞれ冗長化がほぼ必須という重厚長大なインフラが必要でした。AADC導入により例えば以下のようなケースでADFS+WAPが不要になりえます。
      • アカウント同期先がAzureADだけである。
      • アカウント同期だけができればよい。
• ディレクトリ同期
  • 基本的に一方向同期です。
    • 同期元AD(今回はMSAD)からAzure ADへの一方向同期になります。
    • 上述したようにAzure ADの有償エディションを利用することによりAzure ADからMSADへパスワードのリセットや変更の更新をかけることもできますが、アカウントの登録などはMSAD側で行う必要があるため主たる管理AD(プライマリディレクトリ)はAzure ADではなくMSADになります。
  • シングルサインオンオプション
    • AADCではシームレスシングルサインオン(sSSO)という聞き慣れない名前のSSOができます。
      • sSSOはいわゆるフェデレーションを用いません。リダイレクトをするのではなく同期元ADとAzureADが「同じデータを保つ(パスワード同期)」もしくは「常につながっている(パススルー認証)」のいずれかの振る舞いを行うことで、同期元ADのアカウントでAzureADにログインできるという機能です。
      • パスワード同期+sSSO
        • アカウント名とパスワードをAzureADに定期的に同期する方式です。
        • 同期元をMSADにするとMSAD側の権限不足によりアカウント名しか同期できません。つまりパスワード情報がAzureAD側にないためOffice365へログインできなくなります。そのため今回の構成では採用しません。
          • 余談ですがonelogin のAD connectorではonelogin側へパスワード同期ができるので、権限不足というより仕様というべきでしょうか。
      • パススルー認証+sSSO
        • ログイン時に毎回同期元に問合せする方式です。AADCは同期元ADへのプロキシのような動きをします。
        • パスワードを別クラウドに保存しなくていいのでセキュアであるという利点がありますが、AADCに障害が起きるとOffice365にログインできなくなるためパススルー認証ではAADCを冗長化する必要があります。
        • 同期元をMSADとした場合でも利用可能なため今回はパススルー認証を採用します。
• 冗長化
  • 上述したようにパススルー認証の場合、AADCの冗長化が必須になります。
    • 冗長化は簡単です。別途用意したWindowsサーバをAD参加させ「パススルー認証エージェント」というAADCのライト版のようなものを入れるだけです。
      • 今回の構成図では「AADC認証エージェント」と呼称しています。
    • 冗長化はクラスタを組む必要はありません。インストールするだけでAzureADへの接続を行いAzureAD側で複数のAADCを認識し冗長性(Act/Stb)を管理してくれます。
  • ファイアウォール設定
    • パススルー認証は「常につながっている」と前述しましたが通信方向としてはAADC -> AzureADとなります。そのためAADC側ではインターネット向けのアウトバウンドを空けておけばOKです。冗長サーバを増やしてもFW設定への影響が少ない、親切なネットワーク仕様になっています。

• 管理者によるアカウント管理は以下の流れになります。
  • RDPで管理サーバにログインします。
  • AD管理ツールでアカウントの追加/削除等を行います。
  • アカウント(ユーザ名のみ)は定期的(※)にAzureADに同期されます。
    • ※30分間隔です(変更可能)。
  • Office365に管理者がログインしOffice365用ライセンスを割り当てます。※
    • ※Office利用ユーザのみ

いかがでしたでしょうか。

極力マネージドでクラウドADを構成してみましたが、この構成は現時点では様々な課題があります。

• アカウント移行のコスト
  • MSADを新規構築する場合、アカウント登録にユーザ数に応じたコストがかかります。
    • 数百人を超える規模のユーザ数だと大きな問題になります。
    • AWSに(ADパスワードも含めた)自動移行ツールの提供を期待します。
• 限定された連携先
  • 連携先はAzure ADのみです。
  • 他のSaaSサービスとのSSOは外部IDaaSの契約が必要です。
    • IDaaSはたいていユーザ単位の課金となるためユーザ数が多い場合は費用対効果を考え直す必要があります。
  • AWS SSOが東京リージョンに提供されれば、この問題は解決するのではと思います。
    • AWS SSOはMicrosoft ADもしくはAD Connectorに対応しており、連携先はOffice365をはじめ様々なサービスが事前登録されています。
    • しかも驚くべきことにAWS SSOの利用は追加料金が必要ありません。
    • 現時点では今回のような構成にとどめておき、AWS SSOが日本にローンチされたらAADCを撤廃する、というような戦術もありかと思います。

もし支援のご要望があればお問い合わせください。 最後までお読み頂きありがとうございました。