Simple AD新規受付終了で考える、軽量ディレクトリ設計の見直し

Simple ADが担っていた役割

まずは、Simple ADがどのような役割を担ってきていたかを振り返りたいと思います。Simple ADはSamba 4互換のマネージドディレクトリであり、ユーザーアカウントの管理やグループメンバーシップ、グループポリシーの管理、KerberosベースのシングルサインオンなどのActive Directoryの一部の機能を、ドメインコントローラー用EC2を自分で構築・管理することなく提供していました。一方でMFAやスキーマ拡張といった機能は有しておらず、その分コストを抑えやすい、といったメリットもありました。簡単に比較するとこのような形です。

Simple ADの代替検討やActive Directory環境の見直しをご検討中の方は、NTT東日本までお気軽にご相談ください。現状環境の整理から移行方針の検討、AWS・ネットワークを含めた認証基盤の設計・運用についてトータルでご支援します。

Simple ADが使えないことで困るケース

Simple ADが利用できなくなることで困るケースを具体的に考えたいと思います。例えば、次のようなケースが考えられます。

小規模なAmazon WorkSpaces での利用

Simple ADを活用していた代表的なユースケースの一つで、過去クラソルでも多くの記事があり、NTT東日本としてもかつて”おまかせクラウドVDI”というサービスを提供しておりました。(参考：https://business.ntt-east.co.jp/content/cloudsolution/column_cloud_vdi.html)

小規模なAmazon WorkSpaces環境では、既存ADを持たないお客さまがSimple ADを使ってスタンドアロンのディレクトリを用意する構成が選択肢になっていました。

今後の新規構築ではSimple ADを前提にした軽量構成が取れなくなるため、AWS Directory Service for Microsoft Active Directory、AD Connectorでの利用またはWorkSpaces の導入方式自体を再検討する必要があります。

Amazon EC2上のWindows/Linuxアプリの軽量なディレクトリ利用

EC2上のWindows ServerやLinuxワークロードで、ドメイン参加、LDAP、KerberosベースのSSO、基本的なグループポリシーを利用するためにSimple ADを使っていたケースでは、今後の新規案件では代替策を検討する必要があります。

検証・開発環境

Samba 4と互換性のあるAD対応アプリケーションの検証、LDAP/Kerberos認証の確認、小規模なディレクトリ要件のPoCや検証案件では、Simple ADは小規模かつ低コストで実現できる選択肢でした。

今後は、この検証用途でもAWS Directory Service for Microsoft Active Directoryを使うのか、自前Samba ADを立てるのか、あるいはAD前提の設計自体を見直すのかを判断する必要があります。

Simple ADの代替検討やActive Directory環境の見直しをご検討中の方は、NTT東日本までお気軽にご相談ください。現状環境の整理から移行方針の検討、AWS・ネットワークを含めた認証基盤の設計・運用についてトータルでご支援します。

代替案の検討

ここからは、代替案を検討していきたいと思います。公式ページでの代替ソリューションはAWS Directory Service for Microsoft Active DirectoryとAD Connectorの2つになりますが（https://docs.aws.amazon.com/ja_jp/directoryservice/latest/admin-guide/simple-ad-availability-change.html）、そもそも自身/対象のワークロードにおいてSimple ADがどんな役割を担っていたのかを考える必要があります。

Simple ADで何をしていたのかの棚卸

Simple ADに限らず、ディレクトリサービスを利用する際に整理しておきたい項目をまとめておきます。

• 何のためにディレクトリが必要なのか
• ドメイン管理が必要なのか
• 認証方式でLDAP/Kerberosが必要なのか
• グループポリシーで制御する必要があるか
• 既存ADとの連携が必要なのか
• ユーザー数・コンピューター数はどの程度か
• 停止時の業務影響はどの程度か
• 運用担当者はAD/Sambaを運用できるのか

これらを踏まえて、代替策を検討していきたいと思います。

代替案①：AWS Directory Service for Microsoft Active Directory

機能面でドメイン管理やグループポリシーが引き続き必要な場合、可用性も踏まえると多くの課題は解決できますが、一方で冒頭の比較表にもあるように、機能面では過剰なうえ、コスト面は上昇します。下記のような構想や将来の拡張性を持っているようでしたら、こちらに移行してしまうことも考えられます。

• Microsoft ADとの高い互換性が必要
• Group Policy、信頼関係、スキーマ拡張、PowerShell管理が必要
• Amazon RDS for SQL Server, FSx for Windows File Server、Amazon EC2 for Windows Server、WorkSpaces DaaSなどと本格的に連携したい
• 複数AWSアカウントでディレクトリを共有したい
• 監査・セキュリティログ連携が必要

Simple ADからAWS Directory Service for Microsoft Active Directoryへインプレース変換する手順や、Simple ADからの直接移行ツールは公式には案内されていないため、新規にAWS Directory Service for Microsoft Active Directoryでディレクトリを作成した後、CSVエクスポートなどでユーザー・グループを移行する形になります。また、ドメインの再参加や、アプリケーション連携の設定変更も必要となります。

代替案②：AD Connector

AD Connectorは、AWSサービスからの認証要求を、オンプレミスまたはクラウド上のセルフマネージドADへプロキシするサービスです。ディレクトリデータをAWS側に複製せず、接続先ADのパスワードポリシーやアカウントロックアウトポリシーを利用します。移行できるケースはすでにオンプレミスや自前運用のADを持っている場合です。

移行については、AD Connector自体にはデータベースを持たないため、Simple ADのユーザー・グループ情報を接続先ADにインポートし、AWS側の認証先をAD Connectorに切り替える形をとります。

代替案③：EC2上のSamba運用

本案はSimple ADがSambaベースであることから一見すると自然な流れに見えます。

しかし、これはSimple ADの代替サービスを選ぶというよりはディレクトリ基盤を自前で運用する判断となるため、AWSのサービス側で担ってきた可用性、バックアップ、監視、パッチ適用、セキュリティ維持まで含めて自前で行うということになります。

可用性を踏まえると、単に1台のEC2にSambaをインストールすればよいわけではありません。複数AZにSamba AD DCを配置し、ADレプリケーション、DNS冗長化、バックアップ、監視、障害時の復旧手順まで設計する必要があります。Sambaの運用がしたい、という方はこちらでもよいと思いますが、多くの場合はアプリケーションを使いたい、ということになるのでここに大きな時間を割くのは本質的ではありません。NTT東日本のクラウド導入・運用サービスではこれらのEC2の構築・監視・保守を担うことはできますが、Simple ADの代替のマネージドサービスを選ぶというよりは、ディレクトリ基盤を自前でどう運用するかの判断になります。

代替案④：そもそもAD自体をやめる

「そもそもADによる管理を続ける必要があるのか」がこの代替案の論点です。

SaaSやWebアプリケーション中心の環境であれば、IDaaSを中心にSAML/OIDC、MFA、条件付きアクセス、SCIMによるユーザーライフサイクル管理へ移行することで、ADドメインを前提にしない認証基盤へ寄せていくことができます。

すぐにWindowsドメイン参加、Group Policy、Kerberos認証、LDAP依存アプリケーションを全廃止できるわけではないと思いますが、徐々にこれらに依存しない認証方式に移行することもできます。

そのため、単にADを置き換えるのではなく、ADが必要な領域とIDaaSへ移行できる領域を分けて整理することが重要です。

IDaaSによる移行を検討する場合は、次のようなポイントを検討します。

• 認証対象はWindows端末/サーバーなのか、SaaS/Webアプリなのか
• ドメイン参加、LDAP/Kerberos認証、グループポリシーが本当に必要なのか
• IDaaSのSAML/OIDC/SCIMで代替できる範囲はどこまでか
• MFA、条件付きアクセス、デバイス信頼、監査ログをどこで管理するか
• AWS利用者の認証をIAM Identity Centerと外部IdP連携に寄せられるか
• 既存ADを残す場合、IDaaSとの同期元として使うのか、段階的に縮小するのか
• レガシーLDAP/Kerberos依存アプリケーションをどう扱うか

Simple ADの代替検討やActive Directory環境の見直しをご検討中の方は、NTT東日本までお気軽にご相談ください。現状環境の整理から移行方針の検討、AWS・ネットワークを含めた認証基盤の設計・運用についてトータルでご支援します。

まとめ

Simple ADの新規受付終了は単なる代替サービスの検討にとどまらず、軽量ディレクトリの再設計、アプリケーションの認証・認可の仕組みの見直しという根本からの見直しとなります。移行先の検討についてはそもそもADを何のために利用していたか、という点を改めて整理したうえで進めていくことをおすすめします。

NTT 東日本では、AWSの構築保守だけではなく、ネットワーク設計なども含めたエンドツーエンドでのソリューション提供を行っております。

経験値豊かなメンバーがご担当させていただきますので、是非お気軽にお問い合わせください！

Simple ADの代替検討やActive Directory環境の見直しをご検討中の方は、NTT東日本までお気軽にご相談ください。現状環境の整理から移行方針の検討、AWS・ネットワークを含めた認証基盤の設計・運用についてトータルでご支援します。

本コラムに記載されてる会社名、サービス名、商品名は、各社の商標または登録商標です。