こんにちは、IDチームのすかんくです。
今回は「Azure AD Connect」と「オンプレ AD の廃止」について考えてみました。
執筆の背景
日々お客様と会話する中でこんな悩みが多くあるということに気付きました。
「将来的にはオンプレ AD を廃止して、Azure AD（またはその他 IDaaS）に寄せたいと思ってる」
「一方で、現状はオンプレ AD でユーザーやデバイス管理しているので、Azure AD Connect の導入を検討している」
「しかし Azure AD Connect を導入したら、オンプレ AD の廃止に逆行していそうで躊躇している」
オンプレ AD に関連するコンポーネントを追加することで、よりオンプレ AD 依存度が高まるのでは？という疑問は至極当然のものだと思います。
しかしながら Azure AD Connect に関しては寧ろその逆で、周辺機能も含め上手に活用することでオンプレ AD への依存度を下げていくことが可能です。詳しくは本記事内で解説していきたいと思います。
Azure AD Connect を導入するメリット
本題に入る前に、そもそもの Azure AD Connect 導入のメリットについて振り返っておきたいと思います。
一般的に、Azure AD Connect を導入するメリットについて調べるとこんなことが書いてあるかと思います。
- オンプレ AD のユーザーやデバイスを Azure AD に同期することで、ディレクトリの二重管理から開放される
- デバイスを Hybrid Azure AD Join させることで、Azure AD 条件付きアクセスの認証要素として扱えるようになるため、デバイストラストな環境をエコに構築できる
- Hybrid Azure AD Join したデバイスは PRT(Primary Refresh Token) を取得できるため、PC ログイン後に Azure AD へ再認証が不要となりユーザー体験が高まる
- 併せて Intune にも登録することで、デバイス管理がインターネット経由で可能になりテレワーク環境下における GPO 更新問題などにも対応可能となる
こんなところでしょうか？
参考までに導入時点でのイメージ図を書いてみました↓※細かなコンテキスト等は省いてます
まず AD と Azure AD の両方を利用している環境においては、とりあえず Azure AD Connect の導入を検討するのは悪くない選択肢（Not 盲目的）ですし、書いてある通りのメリットは得られるかと思います。
一方、メリットに記載した通りではあるものの、Azure AD Connect はオンプレ AD と Azure AD を密に結合させることで幾つかのメリットを提供するコンポーネントでもあるため、執筆の背景に記載したような懸念を持たれる方も多いのではないか？と感じました。
ということで、ここからは Azure AD Connect と周辺機能を活用することで何故オンプレ AD への依存度を下げられるのか解説・紹介していきます。
「オンプレ AD への依存」について整理する
そもそも「オンプレ AD に依存する」とはどういう状態なのかについて、整理しておきたいと思います。
本ブログ内では、以下の表に示す状態をオンプレ AD に依存した状態であると定義しておきます。
| 機能 | 依存状態の説明 | 対応例 | 対応のしやすさ |
|---|---|---|---|
| ディレクトリマスタとしての役割 | オンプレ AD から異なるサービスや基盤にユーザーがプロビジョニングされていること | Azure AD のプロビジョニング エージェントやその他サービスを検討 | △ |
| デバイス管理基盤としての役割 | AD 参加や GPO を活用して、デバイスが管理・制御されていること | Intune への GPO 移管 | ○ |
| 認証に利用していること | LDAP や統合 Windows 認証を利用していること | 同期ユーザーでの Azure AD Join によるオンプレミスアプリへのアクセス | ○ |
| 同上 | 認証口の切り替え | △ | |
| その他の役割と機能 | DNS や ADCS などの機能を利用していること | サービスの置き換え | × |
オンプレ AD を廃止するためには、各依存状態に対して個別に対応を考えていく必要があります。
また、対応における制約事項として、エンドユーザー（一般社員・従業員など）の負担を極力避けるといった要件が出てくる場合も多いかと思います。
このように中々に困難が伴いそうな諸条件下において、「Azure AD Connect や Azure AD に関連するサービスを上手に活用することで、オンプレ AD の依存度を段階的に下げていくことが出来ます」というのが本記事内でお伝えしたいアプローチとなります。
比較的容易に対応できる項目
同期ユーザーでの Azure AD Join によるオンプレミスアプリへのアクセス
まず初めに紹介したいのが、Azure AD Connect を用いて Azure AD ヘ同期されたユーザー（以下、同期ユーザー）を使ってデバイスを Azure AD Join させるというケースです。
Azure AD 上に直接されたユーザーとは違い、同期ユーザーで Azure AD Join した場合にはユーザープロファイルのドメインパートが オンプレ AD と同じ形式でプロビジョニングされます。
- Azure ADに直接作成されたユーザーは、AzureAD\user
- Azure AD Connect によって同期されたユーザーは、”ADDomain”\user（例：sukank\user）など
何が言いたいかというと、Azure AD Join した同期ユーザーが AD と連携したシステムへアクセスする際、AD からチケットを交換することが可能になります。
詳細はこちらの公式ドキュメントを確認いただきたいですが、一言で言えば「Azure AD Join した端末でも AD と連携したシステムにアクセスできる」ということになります。
このような機能が Azure AD Connect によって提供されることで、「既存デバイスは Hybrid Azure AD Join で展開しつつ、新規デバイスからは Azure AD Join でセットアップする」といったシナリオが成り立ちます。
そうなれば次に考えることはデバイスのライフサイクルです。デバイス入れ替えのスパンや計画などをベースとして、「既存デバイスがすべて入れ替わるくらいのタイミングで、AD も一緒に止められると良いな～」といった具体的なスケジュールを検討しやすくなります。
この後に紹介する対応策についても、ここで考えたスケジュールに収まりそうか考えつつ、対応の優先度を練るのが良いかなと思います。
Intune への GPO 移管
さて Azure AD Join でデバイス管理をしていこうと言われても、オンプレ AD でデバイス管理をしている場合は GPO を用いてデバイスの制御を実施されている組織がほとんどかと思います。
そのような場合には Intune の GPO 分析機能を試されることをお勧めします。
この機能では、エクスポートした GPO を Intune へアップロードすることで、現在の各種設定をどのように Intune の構成プロファイルに落とし込めばよいかを示してくれます。
このように周辺機能も含めて上手に活用することで、認証やデバイス管理で AD に依存していた領域を少しずつ Azure AD や Intune へ寄せていくというのが基本的なアプローチになります。
ここまでご紹介した内容についてはテスト用のユーザーやデバイスを準備することで比較的容易に試すことが出来る作業かと思います。
現在 Azure AD Connect を利用しており、今後 AD 廃止を検討されている方はこのあたりから手を付けていくのが良いのではないかと考えます。（タイトル回収）
参考までにこの時点でのイメージ図を記載します↓
検討は容易な項目
Azure AD のプロビジョニング エージェントやその他サービスを検討
いつまでに AD を無くしたいというスケジュール感を具体化したら、次に考えたいのは AD を ID マスタとして業務システムにユーザープロビジョニングを行っているシステムへの対応です。このようなケースでは、ID マスタの切り替え手段を検討する必要があります。
まず初めに考えられるのは、ID マスタを Azure AD とする方法です。
Azure AD にもオンプレミス向けのプロビジョニングエージェントが提供されているため、必要に応じて検討いただければと思います。
しかし、上記機能は対応しているプロビジョニング方式が限られていることもあり、（ガチガチの）レガシーシステムではマッチしないことが多いと思います。
このような場合には、利用する形式に対応したサービス（iPaaSなど）を検討したり、システムの保守期間によっては刷新を検討したりと、複数の観点から業務インフラ全体の在り方を検討していく必要があります。
ここまでお伝えした通り、机上で考えたり確認する分には比較的容易ですが、実行には困難を伴うことがほとんどです。
個人的には、実行が難しい場合は AD に依存し続けるという選択も悪くない選択だと思います。
（新しい、モダンな環境も大変魅力的ですが、やはりコストパフォーマンスの観点から難しいケースは多々ありそうです）
認証口の切り替え
プロビジョニングの他にも、認証口としての切り替えも検討する必要があります。
[同期ユーザーでの Azure AD Join によるオンプレミスアプリへのアクセス] で紹介した方法は “AD への認証を Azure AD Join したデバイスでも可能” というだけであり、”認証自体は引き続き AD に依存している” という状況は変わりません。
対応には認証口を切り替える必要がありますが、実施には追加開発が伴うケースがほとんどです。
Azure AD へ OIDC 認証するためのアプリケーション（サービスプリンシパル）を発行して、システム側でアプリケーションへのリダイレクト行って、認証結果を以ってシステム画面に遷移するよう対応するのが一般的だと思います。
ここでは、先に記載した通り追加開発だけでなくシステム刷新など複数の手段を検討いただければと思います。
この際気を付けたいのは、単にコストを比較するだけでなく、組織の要件に合った手段を選ぶことです。
例えば、ファイルサーバーであればクラウドストレージへの移行をするのが一般的な手段だと思いますが、高機密情報を扱うような業種ではオンプレミスにデータを保管する必要があったりと、各組織固有の要件に沿った選択が必要となることがあります。
どうしても複数の観点から取るべき手段を検討してく必要がありますので、検討期間や対応スケジュールに余裕を持たせておくのが良いと思います。
冒頭でイメージした AD 廃止のスケジュールにバッファを積んだり、この時点でスケジュール面でも見直しや調整を行っておくと良いかもしれません。
参考までにこの時点でのイメージ図を記載します↓
検討から困難を伴う項目
サービスの置き換え
また、忘れてはならないのがオンプレ AD 特有の役割や機能についても、もれなく洗い出して置き換えの方針を検討することです。
よくある具体例として、DNS や ADCS（Active Directory 証明書サービス）を挙げておきます。
- 規模や歴史によっては DNS レコードの洗い出し（これ今使ってるの？という確認含む）は大変な作業になります
- ADCS に関しても、Intune と連携して SCEPman から配布するといった代替手段を検討する必要があります
何にせよ、各社のオンプレ AD 上でどのような役割と機能が追加されているかご確認いただき、これまで同じように複数の手段や観点から検討を進め、対応スケジュールを調整していく必要がございます。
参考までにこの時点でのイメージ図を記載します↓
ここまで検討が済んだら
AD 廃止に向けた見通しが立ったと言えるかと思います。（お疲れさまでした！）
ここからは「対応するだけの各種リソースの確保や、関係者への根回し、日々作業の実施」等々、目標に向けやるべきことを1つずつ消化していきましょう！！
検討したあれやこれの対応が完了して、Azure AD Connect を停止したり AD を停止したりすることで、最初に思い描いた AD 廃止という状態が現実となります。
最後に改めて、今回のアプローチにおいて目指す姿のイメージ図を記載します↓
まとめ
いかがだったでしょうか？今回は Azure AD Connect が提供する同期ユーザーでのオンプレミスアクセス機能を足掛かりに、少しずつオンプレ AD 依存を減らしていくアプローチや対応例についてご紹介しました。
デバイスの入れ替えやライフサイクルをベースに大まかな AD 廃止までの期間を算出し、その中で様々な施策をスケジュールとして載せていくのは計画を具体化する上では比較的やりやすい方式かなと思います。
一方で、それぞれ検討を進める中で、やはり廃止期間に調整が必要になる場合はあると思いますので、その辺は柔軟に対応していきたいですね。
勿論、すべての組織でこのアプローチが通用するとは限りませんが、Azure AD Connect を導入している（または検討している）組織におかれましては比較的再現性のあるアプローチではないかと思います。（この記事がどこかで誰かの参考になれば幸いです。）
今回は Microsoft サービス中心で考えてみましたが、Okta を例としたその他 IDaaS でのシナリオを検討してみるのも面白いかもしれませんね。ではまた！
