Latest / M365.FM – Microsoft 365・Copilot・AI ポッドキャスト（日本語） / Microsoft Entra Domain Services をやさしく解説：自前のドメインコントローラーなしでレガシーアプリを Azure へ（AI吹き替え）

Transcript

Microsoft Entra Domain Services をやさしく解説：自前のドメインコントローラーなしでレガシーアプリを Azure へ（AI吹き替え） · M365.FM – Microsoft 365・Copilot・AI ポッドキャスト（日本語）

0:00
マイクロソフト365、コパイロット、AI、Azure、そして働き方の未来を築く人々が集う10日間への準備はできていますか?
0:07
この1月、M365カンファレンスがさらに規模を拡大して帰ってきます。
0:12
世界中のMVPや業界エキスパートによるライブセッション、実践的なデモ、役立つ知識をぜひ体験してください。
0:18
ありきたりなスライドは一切ありません。
0:20
無意味な専門用語の羅列もありません。
0:22
コパイロットスタジオ、AIエージェント、ファブリック、セキュリティ、ガバナンス、自動化など、現実の課題に取り組みます。
0:30
プロフェッショナル、開発者、ビジネスリーダーの皆様、それぞれに最適なセッションをご用意しています。
0:35
10日間の充実した期間で、多様な技術を探求し、世界中のコミュニティとつながりましょう。
0:40
ライブ配信で学び、実践的な知見を組織に持ち帰ってください。
0:44
2027年1月開催、10日間、一つのマイクロソフトコミュニティ。
0:49
現在、参加登録受付中です。
0:51
m365コン.NETにアクセスして、今すぐ参加枠を確保してください。
0:56
繰り返します。m365コン.NETです。
0:59
m365コン.NETから今すぐ登録を、1月のライブでお会いしましょう。
1:05
皆さん、こんにちは。
1:06
M365FMがお届けするマイクロソフト知識の断片、新エピソードへようこそ。
1:10
ミルコピーターズです。
1:11
社内サーバーにある古いビジネスアプリを、Azure仮想マシンに移行するところを想像してみてください。
1:16
アプリはクラウドに移動しましたが、依然としてWindowsドメインを要求します。
1:19
ドメインへの参加、LDAPによるユーザー検索、ケルベロスによるサインイン、グループポリシーの適用が必要なのです。
1:24
多くの人は、EntraIDがアクティブディレクトリのすべての役割を代替すると考えています。
1:28
実際は違います。
1:29
最新のクラウドアプリはEntraIDでサインインできますが、古いWindowsアプリはサーバー室にあった頃と同じドメインを期待するのです。
1:36
このエピソードの終わりには、EntraID、アクティブディレクトリ、Entraドメインサービスがそれぞれどう適合するのか、そして管理方法を変える一つの重要な詳細が理解できるはずです。
1:44
ID情報は一方向にしか流れません。
1:47
なぜEntraIDだけでは、すべてのレガシーアプリを動かせないのか。
1:50
まずは、EntraIDが得意とすることから始めましょう。
1:53
それは、クラウドサービスへの受付窓口のようなものです。
1:55
あなたが誰であるかを認識し、サインインを確認し、Microsoft 365のチーム、シェアポイント、またはクラウド上のビジネスアプリへのアクセスを許可するかを判断します。
2:02
一度サインインすればパスワードを何度も入力することなく、サービス間を移動できます。
2:06
それがシングルサインオンです。
2:07
EntraIDは、多要素認証による2段階のチェックや、使用しているデバイス、サインイン場所、会社が定めるアクセスルールに基づいた判断も可能です。
2:17
最新のアプリにとって、このパターンは非常にうまく機能します。
2:20
ブラウザを開くとアプリがあなたをEntraIDへ誘導し、サインインしてスマホで承認を行うと、裏側でEntraIDがアプリに安全なサインインメッセージを送信します。
2:28
アプリはそのメッセージを読み取り、あなたにアクセスを許可するのです。
2:30
このパターンでは、ドメイン参加は不要で、古いWindowsサーバーも関係なく、アプリが従来の社内ディレクトリを検索する必要もありません。
2:37
しかし、古いアプリは異なる世界で育ちました。
2:40
長年Windowsサーバーで動作し、ユーザーがドメイン参加済みのPCからサインインする財務アプリを想像してみてください。
2:45
そのアプリは、古いソフトウェアが社内ディレクトリを検索する一般的な方法であるLDAPを通じて従業員情報を参照します。
2:50
システム間の信頼関係を確立する古いWindowsのサインイン方式、ケルベロスを使用しているかもしれません。
2:55
Windowsコンピューターの設定を制御する一連の社内ルールであるグループポリシーに依存している可能性もあります。
3:00
そのアプリは、現代のクラウドのサインインメッセージの読み方を知りません。
3:03
ネットワーク越しに呼び出しを行い、従来のWindowsドメインを見つけることを前提としています。
3:07
もし見つからない場合、アプリはユーザーのサインインに失敗したり、サービスアカウントが見つからなかったり、あるいは単に起動を拒否したりします。
3:12
このようなパターンは、IT以外の分野でも見かけたことがあるでしょう。
3:15
古い機器のプラグが合わないとき、新しい電源コンセントは何の役にも立ちません。
3:18
電気は来ていても、接続が間違っているのです。
3:20
ここで、その財務アプリとそのデータベースをAzure仮想マシンに移行する会社を想像してみてください。
3:24
サーバーは移動しましたが、古い要件は変わっていません。
3:27
オフィスにアクティブディレクトリを残し、VPNというプライベートなネットワークトンネル経由でAzureと接続する方法もあります。
3:32
つまり、Azure上のアプリはドメインが必要なときに、その接続を通じてリクエストを送信するのです。
3:37
それは機能しますが、アプリはネットワークリンクとオンプレミスのドメインコントローラーが利用可能であることに依存してしまいます。
3:42
そして、その接続に問題があれば、クラウドアプリも同様に問題を抱える可能性があります。
3:46
もう一つの選択肢は、Azure内に独自のドメインコントローラー仮想マシンを作成することです。
3:50
ドメインコントローラーとは、従来のアクティブディレクトリドメインを実行し、ディレクトリやサインイン、その他のドメイン業務を処理するサーバーのことです。
3:55
これも機能しますが、今度はチームが管理すべきサーバーが増えることになります。
3:58
誰かがそれらにパッチを適用し、監視する必要があります。
4:01
バックアップや復旧計画、ドメインコントローラーを同期させるための計画が必要であり、ドメインを制御する強力な管理者アカウントを保護する必要もあります。
4:07
一部の企業にとっては、その管理が理にかなっています。
4:09
しかし他の企業にとっては、古いアプリを維持するためだけの余分な作業となります。
4:12
つまり、そのギャップは非常に狭いものですが、現実に存在します。
4:15
アプリはAzureに存在しながら、今もなお古いアクティブディレクトリの言語を話しているのです。
4:19
Microsoft Entra Domain Serviceとは何か?
4:22
これは、Azureネットワーク内で動作するマネージド型のWindowsドメインです。
4:26
それが分かりやすい定義です。
4:28
ドメインコントローラーは舞台裏で完全にMicrosoftによって管理され、Azure仮想マシンや従来のアプリはこれまで通り使い慣れたドメインサービスを利用できます。
4:36
クラウド環境をオフィスビルだと考えてみてください。
4:38
Entra IDは正面の受付デスクです。
4:41
Microsoft 365やその他のクラウドアプリへのサインイン時に本人確認を行い、そのサインインに関する社内ルールを適用します。
4:46
Entra Domain Serviceは鍵のかかったバックオフィスにあります。
4:49
古いシステムは現代のクラウドアプリのように受付デスクを訪れる必要はありません。
4:53
彼らに必要なのは自分たちの言語を理解し、要求に応えてくれる昔ながらのディレクトリが近くにあることです。
4:57
そのバックオフィスこそがマネージドドメインです。
4:59
重要な点はドメインコントローラーを自分で構築する必要がないということです。
5:03
リモートデスクトップでそれらにサインインすることもありません。
5:05
何台稼働させるか、Windowsのパッチ適用、相互接続の管理なども行う必要はありません。
5:08
それらすべてをマイクロソフトが管理します。
5:10
あなたの仕事は、適切なAzure仮想マシンやアプリをマネージドドメインに接続することです。
5:14
接続さえすれば、使い慣れたアクティブディレクトリサービスを利用できます。
5:17
Windows VMはドメインに参加でき、古いアプリはLDAPを使って人、グループ、ディレクトリの詳細を検索できます。
5:23
サーバー間の信頼関係が必要な古いビジネスアプリでよく求められるサインイン方式、ケルベロスも利用可能です。
5:29
また、一部のアプリで今も必要なWindowsの古いサインイン方式であるNTLMも利用できます。
5:34
マネージドドメインはDNSも提供するため、数値の羅列ではなく名前で正しいサーバーを見つけることができます。
5:39
さらにグループポリシーもサポートしているため、マネージドドメイン内のコンピューターやユーザーに特定のWindows設定を適用できます。
5:44
専門的な用語が並んでしまいましたね。
5:46
翻訳デスクだと考えてみてください。
5:48
あなたのアプリが昔ながらのWindows言語で、このユーザーは誰?と尋ねます。
5:52
このサーバーはそのサーバーを信頼できるか?
5:54
データベースはどこにある?
5:55
このコンピューターにはどの設定を適用すべきか?
5:58
エントラドメインサービスはそれらの質問を理解し、アプリが期待する形式で回答しますが、従業員のリストを二重に作成することはありません。
6:04
IDのマスター記録はエントラIDに残ります。
6:07
エントラIDのユーザーとグループがマネージドドメインにコピーされるため、古いアプリも理解できる形式でそれらを参照、利用できます。
6:13
社内にオンプレミスのアクティブディレクトリがある場合、IDはそこからエントラIDに同期され、その後ドメインサービスにコピーされることになります。
6:18
ここでは方向性が重要です。
6:20
ID情報はエントラドメインサービスへと流れます。
6:23
逆方向には流れません。
6:24
したがって、ユーザーがエントラID由来であれば、そのユーザーはエントラIDで管理します。
6:28
ユーザーが元々オンプレミスのアクティブディレクトリ由来であれば、その場所でユーザーを管理します。
6:33
ドメインサービスをメインの従業員レコードを編集する場所として扱うことはありません。
6:37
そうすることで、マネージドドメインが同じ人物の異なるバージョンを持つ、第二のファイルキャビネットになることを防ぎます。
6:41
さて、セットアップ時に多くの人がつまずくポイントが一つあります。
6:44
それはパスワードです。
6:45
現代のクラウドサインインと従来のWindowsサインインでは、裏側でのパスワードの扱いが正確には同じではありません。
6:50
ケルベロスやNTLMが機能するためには、ドメインサービスはそれらの古い方式をサポートする保護された形式のパスワードデータを必要とします。
6:55
マイクロソフトは、あなたのパスワードをプレーンテキストで保持することはありません。
6:58
その代わり、ユーザーがドメイン参加済みのVMや古いアプリにマネージドドメイン経由でサインインするには、正しい保護済みパスワード情報が必要になります。
7:06
クラウド専用ユーザーの場合、ドメインサービスが有効になった後にパスワードを変更しなければならないことがよくあります。
7:12
そのパスワード変更によって、マネージドドメインに必要な保護された形式が作成されるからです。
7:15
それが完了するまで、ユーザーはMicrosoft 365には問題なくサインインできても、旧式のドメインを利用しようとすると失敗する場合があります。
7:22
最初は奇妙に感じるかもしれません。
7:24
ユーザーにはすでにアカウントがあり、パスワードも機能しているのに、レガシーアプリではまだ使えないのです。
7:29
欠けているのはユーザーアカウントではありません。
7:31
古いサインイン方式で必要とされる、保護されたパスワード形式なのです。
7:34
ドメインサービスには、それが機能する範囲に関する明確な境界線もあります。
7:37
これはVNETと呼ばれることが多い、Azure仮想ネットワーク内で実行されます。
7:41
Azure VMはそのVNETにネットワークアクセスできる必要があり、マネージドドメインを見つけられるようにそのDNS設定を使う必要があります。
7:47
これはインターネット上のあらゆるデバイスが接続できる公開ディレクトリではありません。
7:50
適切なAzureネットワークに接続されたワークロードのためのプライベートなドメインサービスです。
7:54
つまり、アプリがAzure上で古いアクティブディレクトリの動作を必要とする場合、ドメインサービスがその動作を提供するための管理された場所となります。
8:00
そこで次の疑問が生じます。
8:02
これはエントラーIDや既存のアクティブディレクトリドメインとどのように共存するのでしょうか?
8:06
名前は似ていますが、その役割は大きく異なります。
8:09
エントラーID、アクティブディレクトリ、そしてドメインサービス、それぞれ役割が異なります。
8:13
名前が近いため、これらを同じ製品の異なるバージョンとして扱いがちです。
8:17
実際は違います。
8:18
それぞれが会社ID情報の異なる部分を担っており、それぞれの役割を理解すれば選択はずっと明確になります。
8:24
エントラーIDはクラウドIDを扱います。
8:26
マイクロソフト365、チームズ、シェアポイント、あるいは現代のビジネスアプリを開くと、エントラーIDがサインインをチェックし、アクセス権を制御します。
8:38
最新のアプリはウェブベースのサインイン方式を利用するため、エントラーIDと同じネットワーク上にある必要はありません。
8:47
ブラウザーやアプリからサインインすると、エントラーIDが本人確認を行い、アプリがアクセス許可の証明を受け取ります。
8:52
これが新しいクラウドアプリの標準的なパターンです。
8:55
アクティブディレクトリドメインサービス、アクティブディレクトリと略されることが多い、は別の役割を担います。
9:00
これは、多くの企業が自社のオフィス、データセンター、サーバー室で運用している従来のWindowsドメインです。
9:05
企業がドメインコントローラーを所有し、設定方法を選択し、ドメイン全体を完全に管理します。
9:10
Windows PCの管理、ローカルサーバーのサポート、そして長年利用されている業務アプリが求める古いサインイン方式を提供できます。
9:16
そのレベルの制御には責任が伴います。
9:19
ITチームがドメインを運用し、サーバーを監視し、会社にとってディレクトリがどうあるべきかを決定します。
9:24
エントラドメインサービスは、これら2つの世界の仲間に位置します。
9:27
Azureのワークロードに対して、古いアクティブディレクトリの動作が必要な場合に管理されたWindowsドメインを提供しますが、
9:32
ドメインコントローラー側はMicrosoftが運用します。
9:34
従来のアクティブディレクトリドメインを自前で完全に運用する手間をかけずに、Azure VMや古いアプリでドメインを利用できます。
9:40
これはファイリングキャビネットのシステムだと考えてください。
9:42
エントラIDには、クラウド作業のための主要な従業員記録が保持されています。
9:46
ここには、Microsoft 365や現代的なクラウドサインインに使用される作業用レコードが保管されています。
9:50
ドメインサービスは、古いAzureアプリが必要とするレコードの互換性のあるコピーを提供します。
9:55
これらのアプリは、使い慣れたファイリングキャビネットを開き、ユーザー、グループ、サインインの詳細を理解できる古い形式で見つけることができます。
10:01
アプリをAzureに移行したからといって、再構築する必要はありません。
10:04
クラウドのみの企業でも、この設定を利用できます。
10:07
ローカルのドメインコントローラーを運用したことがない企業を想像してみてください。
10:10
全員がエントラIDを通じてMicrosoft 365にサインインしており、ビジネスで古いWindowsアプリのためにAzure VMの使用を開始します。
10:16
その会社は、そのアプリのためだけにオンプレミスのアクティブディレクトリドメインを構築する必要はありません。
10:21
代わりに、ドメイン動作を必要とするAzure VMにはエントラドメインサービスを使用し、それ以外の社内業務は引き続きエントラIDを利用できます。
10:28
ハイブリッド構成の企業では、出発点が異なります。
10:31
すでにオフィスでアクティブディレクトリを運用し、ユーザーとグループをエントラIDに同期しているかもしれません。
10:35
それらのユーザーは、Azureで実行されるワークロードのためにエントラドメインサービスに表示させることができます。
10:39
フローは次のようになります。
10:41
企業の既存のアクティブディレクトリがIDの詳細をエントラIDに送信し、エントラIDが互換性のあるコピーをドメインサービスに提供します。
10:48
これは、ドメインサービスが元のオンプレミスのドメインを置き換えるという意味ではありません。
10:52
オフィスでは、ローカルPCやサーバー、工場システム、あるいはオンプレミスのアプリケーションのために、独自のアクティブディレクトリドメインが必要な場合があります。
10:59
ドメインサービスは、従来の管理されたドメイン機能がワークロードに適したAzure上の領域のみを処理します。
11:04
また、これによってエントラIDが完全なアクティブディレクトリに変わるわけでもありません。
11:07
エントラIDは、引き続きクラウドIDサービスとしての役割を担います。
11:10
ドメインサービスは特定の古いニーズに対して管理ドメインを追加するものですが、自身でアクティブディレクトリを運用する場合のような、あらゆるオプションや制御レベルを提供するわけではありません。
11:18
つまり、3つの異なる役割を思い浮かべてください。
11:21
エントラIDは、モダンなクラウドサインインを処理します。
11:23
アクティブディレクトリは、記者自身で運用するWindowsドメインを処理します。
11:26
エントラドメインサービスは、ドメインコントローラーを自身で運用することなく、Windowsドメインを必要とするAzure上のレガシーなワークロードを処理します。
11:34
もっと良い質問ができます。
11:35
ドメインサービスはいつワークロードに適し、いつ別の手段を選ぶべきでしょうか。
11:39
ドメインサービスが適している場合と、そうでない場合についてです。
11:42
製品名からではなく、アプリケーションから考えてください。
11:45
古いアプリがLDAP、ユーザー名とパスワードを称号するための古い言語を使用しており、それをAzureに移行する場合、ドメインサービスは非常に適しています。
11:52
アプリは全面的に書き直すことなく、すでに理解している仕組みを使い続けることができます。
11:56
これは、アプリが現在も動作しており、ビジネスに必要で、かつサインインコードの書き換えに多大な時間やコストがかかる場合に重要です。
12:01
もう一つの一般的なシナリオは、Azure仮想マシンのグループが通常のドメインコンピューターとして動作する必要がある場合です。
12:06
スタッフが職場の仕事用アカウントでWindowsにサインインする必要があるかもしれません。
12:10
サービスは、アプリがデータベースなどの別のシステムに接続するために使用するサービスアカウントを必要とする場合があります。
12:14
仮想マシンに企業設定を適用するために、グループポリシーが必要になることもあるでしょう。
12:18
そのような場合、ドメインサービスはAzureのマシンに期待通りのドメイン動作を提供します。
12:23
リモートデスクトップサービスもここに当てはまります。
12:25
従業員がAzure上の共有Windowsデスクトップやアプリに接続する様子を想像してください。
12:29
それらのシステムは、ユーザーのサインインやコンピューター管理のためにWindowsドメインに依存することがよくあります。
12:33
ドメインサービスは、チームがドメインコントローラーの仮想マシンを一から構築することなく、そのドメイン層を提供します。
12:39
古いアプリは、複数のパーツで構成されていることがよくあります。
12:41
フロントにウェブサーバー、中間にアプリサーバー、バックにデータベースがあるかもしれません。
12:45
アプリサーバーは、データベースが接続を受け入れる前に、そのIDを証明する必要があります。
12:50
その信頼関係がWindowsサービスアカウントに依存している場合、ドメインサービスは移行後もそれらの接続を維持します。
12:55
重要なのは、チームはワークロードに必要な従来のドメイン動作を得ることができ、本来ならサーバーリストに乗るはずのドメインコントローラーの運用はマイクロソフトが代行してくれるという点です。
13:04
ただし、単にAzureを利用しているという理由だけでドメインサービスを選んではいけません。
13:07
新しいクラウドアプリは、エントラIDを通じて直接サインインさせるべきです。
13:10
最新のサインイン方式に対応していれば、ユーザーをエントラIDに誘導し、サインインの証明を受け取ることで、クラウドのアクセスルールや多要素認証の恩恵を得られます。
13:18
それが新しいソフトウェアにとって、よりクリーンな道筋となります。
13:21
ドメインサービスは、古いプロトコルを使用するアプリを支援するものです。
13:24
新しいアプリに古いプロトコルを覚えさせる理由にはなりません。
13:27
事前に確認しておくべき厳格な制限事項もあります。
13:29
アクティブディレクトリから読み取るだけでなく、書き込みを行うアプリも存在します。
13:33
例えば、アプリが通常の業務の一環としてディレクトリ内のエントリを作成または変更したい場合などです。
13:37
アプリがLDAP書き込みアクセスを必要とする場合、ドメインサービスは適していません。
13:42
ディレクトリの格納内容を定義する一連のフィールドである、アクティブディレクトリスキーマを変更する必要があるアプリについても同様の警告が当てはまります。
13:48
一部の古いソフトウェアでは、実行前に独自のフィールドを追加するよう求められることがあります。
13:52
マネージドドメインでは、その基盤となる設計を変更することはできません。
13:54
また、チームがドメイン自体に対して完全な制御を必要とする場合も、一度立ち止まる必要があります。
13:58
ドメインコントローラーへの直接アクセスが必要な場合があるかもしれません。
14:01
非常に広範な制御権限を与えるドメイン管理者の権限が必要な場合もあるでしょう。
14:04
あるいは、独自のやり方で構築運用したい複雑なディレクトリ設計が必要な場合もあるかもしれません。
14:08
その場合は、オンプレミスまたはAzure上の仮想マシンでアクティブディレクトリを自分で実行する方向に向かうことになります。
14:14
ドメインサービスは、マイクロソフトが中核となるドメインサービスを運用するため、意図的に制御権を制限しています。
14:18
ですから、進む道を決める前に、シンプルに自問してみてください。
14:21
このワークロードは古いアクティブディレクトリの言語が必要か、それとも最新のエントラーIDに対応できるか。
14:26
最新のエントラーIDが使えるなら、そこから始めましょう。
14:28
古いドメインの動作が必要だが、ドメインのあらゆる部分を所有する必要はないのであれば、ドメインサービスが非常によく適合する可能性があります。
14:34
もしアプリがディレクトリの書き換えやスキーマの変更を必要としたり、チームに完全なドメイン制御権を求めるなら、別の場所が必要になります。
14:40
マネージドドメインを選択するということは、トレードオフを受け入れるということです。
14:43
マイクロソフトがドメインコントローラーを管理する代わりに、自分で運用する場合に伴う制御権の一部を手放すことになります。
14:48
知っておくべきマネージドサービスのトレードオフです。
14:50
そのマネージドのアプローチは作業を軽減しますが、ITチームが制御できる範囲も変わります。
14:55
マイクロソフトがドメインコントローラーを運用し、同期の維持パッチの適用、可用性の確保を舞台裏で行います。
15:00
各ドメインコントローラーの配置を計画したり、サーバー障害後に復旧させたりする必要はありません。
15:05
それが多くのチームが選択する理由ですが、ドメインコントローラーにリモートデスクトップ接続することはできず、ドメイン管理者やエンタープライズ管理者の権限も得られません。
15:11
なぜなら、それらの権限はマイクロソフトが管理する部分への制御を可能にしてしまうからです。
15:15
その代わりに、マイクロソフトは、Entra Domain Service Administratorsというグループを提供しています。
15:19
ドメイン管理が必要なユーザーをそのグループに入れ、マネージドドメインに参加させた管理用仮想マシンを使用します。
15:25
そのマシンから、使い慣れたアクティブディレクトリツールを使用して、マイクロソフトが許可する範囲内で管理を行えます。
15:30
例えば、独自の組織単位、Oを作成することができます。
15:33
これらは、コンピュータやサービスアカウントといったドメインオブジェクトを入れるフォルダだと考えてください。
15:37
DNSレコードの管理や、サポートされている設定に対するグループポリシーの作成、適用が可能です。
15:41
また、ドメインに参加するコンピュータを管理することもできますが、これがサービスを利用する主な理由であることが多いです。
15:45
これらの制限には意図があります。
15:47
ドメインコントローラーの追加やアクティブディレクトリスキーマの変更はできませんし、マネージドドメインへの変更がEntra IDに反映されることもありません。
15:53
そのため、ユーザーとグループの管理はソースディレクトリで行うようにしてください。
15:57
クラウドのみの企業であれば、そのソースはEntra IDです。
16:00
ハイブリッド構成の企業であれば、Entra IDと同期するオンプレミスのアクティブディレクトリがそれに当たります。
16:04
このルールは、よくあるミスを防ぐためのものです。
16:07
マネージドドメイン上のユーザーを確認し、そこでの変更が永続的だと思い込んで編集してしまうケースです。
16:11
しかし、その変更はEntra IDやオンプレミスのアクティブディレクトリの社内記録には反映されません。
16:16
マネージドドメインは、Azureネットワーク内でプライベートに持ってください。
16:19
一般的な社内ディレクトリにするのではなく、必要なワークロードのみをサポートするようにしましょう。
16:23
ネットワークアクセスを制限し、管理用マシンを保護し、管理権限は必要な人にのみ付与してください。
16:28
あなたはガードレール付きのサービスを選択しているのです。
16:31
それらのガードレールは作業を削減する一方で、マイクロソフトが所有する部分の変更を制限します。
16:35
シンプルなAzure以降のストーリーをご紹介します。
16:38
オフィス内のサーバーで古いアプリを実行している金融企業を想像してみてください。
16:42
そのアプリは、従業員を見つけるためにLDAPに依存しています。
16:44
ユーザーのサインイン時にはケルベロスを使用しています。
16:46
そしてサーバーは、サービスアカウントを使って認証を行い、財務データベースにアクセスします。
16:50
この企業は、アプリとデータベースの両方をAzure仮想マシンへ移行したいと考えています。
16:54
一つの選択肢はVPN経由でオフィスドメインに接続し続けることですが、
16:57
そうなるとAzure上のアプリは毎日そのネットワーク接続とローカルのドメインコントローラーに依存することになります。
17:02
別の選択肢は、Azure内に新しいドメインコントローラー仮想マシンを構築することです。
17:06
これによりトラフィックの多くをAzure内で完結できますが、
17:08
ITチームがパッチ適用、監視、バックアップ、復旧を行うべきWindowsサーバーが増えてしまいます。
17:11
そこでチームは別の方法を取ります。
17:13
彼らのユーザーとグループはすでにエントラIDに同期されています。
17:16
彼らはエントラドメインサービスを有効にし、Azure仮想ネットワークを接続します。