Azure ADとオンプレミスAD(Active Directory)の違い

Azure ADとは

Microsoftの法人(企業・行政機関・教育機関など)向けクラウドサービスでは、Azure Active Directory(Azure AD)の利用が必須です。Azure ADはクラウドサービスを利用するユーザーや、そのユーザーを束ねるグループを管理し、認証を行い、アクセスを制御する仕組み(認証基盤)です。

Azure ADの役割とオンプレミス Active Directoryの役割

Microsoftの製品でユーザーやグループの管理を行う機能と言えば、Windows Server の Active Directory(Active Directory Domain Service - ADDS)を思い浮かべる方も多いでしょう。Active Directory(ADDS)がオンプレミスのLAN内での認証基盤であるのに対して、Azure ADはインターネット上のクラウドサービスでの認証基盤として機能します。
従来の組織のIT環境では、組織の事業所内や事業所間がLAN/WANで結ばれ、そのネットワーク(イントラネット)に業務用アプリケーションサーバーや社内ポータルWebサーバー、グループウエアサーバー、データベース サーバー、さらにクライアントPCやネットワークプリンターなどのデバイスが接続されています。Active Directory(ADDS)はこのようなイントラネット内のデバイスを管理し、そのデバイスを利用したりアクセスしたりするユーザーの管理・認証を行っています。ユーザーは「ドメイン アカウント」を利用し、デバイスは「グループ ポリシー」で制御されます。
しかし組織のIT環境をクラウド化する場合、認証基盤としてActive Directoryをそのまま利用することはできません。これはActive Directoryがイントラネットのように「閉じた」ネットワークで利用することを前提に設計されており、インターネットを介した認証や制御を行うことができないからです。そこでMicrosoftがクラウドサービス用に開発・提供しているのがAzure ADです。Azure ADはインターネットを介して、インターネット上のさまざまなサービスに認証を提供できるように設計・構築されています。

左:オンプレミスのActive Directory

左:オンプレミスのActive Directory

右:Azure AD

右:Azure AD

実際、Azure ADはMicrosoftのクラウドサービス-Microsoft 365、Dynamics 365、Intune、Power Platform、Microsoft Azureで利用されるだけでなく、多くのサードパーティーのSaaS(Software as a Service)のユーザー認証に利用されています。
※Azure ADが利用可能なサードパーティーサービスの一覧はAzure Active Directory アプリケーションギャラリーを参照してください

Azure ADとActive Directoryの相違点

Azure ADとActive Directoryの相違点を見ていきましょう。

実行環境

Azure ADはMicrosoftがクラウド上で提供するSaaSとして利用します。そのため利用者側では実行環境を用意する必要がありません。
Active Directoryは利用者自身がWindows Serverの機能として構築する必要があります。実運用環境であれば、Active Directory Domain Serviceを実行するWindows Serverが少なくとも2インスタンス必要です。

ネットワーク

Azure ADはクラウド上のエンドポイントとして機能し、認証要求とその応答は通常インターネット経由でやりとりされます。
※Microsoft クラウドへの専用線接続(Express Route)を利用すると、イントラネット内からAzure ADへの通信をすべて専用線経由として、インターネットを経由しない構成にできます

Active Directoryはイントラネット内のサーバーとして機能し、認証要求とその応答はイントラネット内で完結します。

認証プロトコル

Azure ADではインターネットで広く使われる多くの認証プロトコルをサポートしています。これらのプロトコルを利用して、Microsoftのクラウドや多くのサードパーティーのSaaSの認証を行っています。ただし Kerberos や NTLM には対応していません。Azure AD でサポートされるプロトコルについては、Azure Active Directory認証と同期プロトコルの概要を参照してください。

Active Directoryでは通常 Kerberos(既定)またはNTLM(Kerberos が利用できない場合のダウングレード先)が認証プロトコルとして利用されます。Active Directory認証を利用するには、デバイスがこれらのプロトコルに対応している必要があります。

コスト

Azure ADは SaaS として提供されているので、利用にはMicrosoftとのサブスクリプション契約が必要です。ただしMicrosoftのクラウドサービス(Microsoft 365、Dynamics 365、Intune、Power Platform、Microsoft Azure)には無料のAzure ADサービスが付属しています。また無償版のAzure ADも提供されています。
有償のサブスクリプションが必要となるのはAzure ADのプレミアム機能を利用する場合のみです。Azure ADの料金についてはAzure Active Directoryの価格を参照してください。

Active DirectoryはWindows Serverに含まれる機能なので、Windows Serverのライセンス(サーバーライセンスとクライアントアクセスライセンス-CAL)の費用が必要です。
ライセンスの費用は、利用するWindows Serverのエディション、インスタンス数、アクセスするクライアント数、ライセンス形態によって決まります。併せて、実行環境(物理マシン、仮想化環境)の費用も必要となります。

その他の相違点

Azure ADとActive Directoryのその他の詳細な相違については、以下の資料を参考にしてください。

Azure ADとActive Directoryの類似点

Azure ADとオンプレミスのActive Directoryは認証基盤として類似の機能を持っています。ただし同じような機能であっても、その中では相違点があります。

デバイスの管理

Azure ADにデバイス(PC やモバイル デバイス)を登録/参加させることができます。Azure AD 参加したPCはAzure ADアカウントでWindowsにサインインできます。これはPCをActive Directoryドメインに参加させるのに似ていますが、Active Directoryと異なりデバイスはAzure ADとインターネット経由で接続できますので、デバイスの場所に関わらずAzure ADからデバイスが参照できます。
Azure AD自体にはデバイス管理の機能はありませんが、Microsoft IntuneなどのMDMソリューションと連携して、アプリケーションの管理やポリシーの適用、リモート ワイプ(デバイス内のデータ削除)などがインターネット経由で行えます。これはリモートワーク/テレワークに適した機能です。

Active DirectoryでもPCをドメインに参加させることができ、ドメインに参加したPCではドメインユーザーアカウントでWindowsにサインインできます。
ただしPCを完全に管理できるのはPCがActive Directoryのあるイントラネットに接続されている場合だけです。インターネット経由でデバイスのポリシーを変更したり、リモート ワイプを行うことはできません。Active Directoryではリモートワーク/テレワークで利用するデバイスの管理に課題が残ります。

ユーザー管理

Azure ADでは管理者があらかじめアカウントを作成し、それを実際のユーザーに割り当てて利用させます。アカウントの情報は管理者が一元管理できます。
ユーザーは割り当てられたアカウントを使ってMicrosoft 365などのクラウドサービスにアクセスできるほか、Azure AD参加したWindows PCにサインインすることができます。またMicrosoft 365 グループやセキュリティ グループなどのグループを作り、グループ単位でユーザーを管理することもできます。
Azure ADはクラウド上のサービスなので、ユーザーはインターネットに接続していればどこからでもAzure ADにサインインすることができます。

Active Directoryでも同様に管理者があらかじめアカウントを作成し、それを実際のユーザーに割り当てて利用させます。アカウントの情報は管理者が一元管理できます。
ユーザーは割り当てられたアカウントを使ってActive Directory ドメインに参加したWindows PCにサインインでき、同じアカウントを使ってActive Directoryで管理されているさまざまなオンプレミスのリソース(オンプレミスのアプリケーション、ファイルサーバー、プリンターなど)にアクセスできます。また組織単位(OU)やセキュリティグループを作り、OU 単位・グループ単位でユーザーを管理することもできます。
Active Directoryはオンプレミスの環境なので、ユーザーがActive Directoryでサインインできるのはオンプレミスのネットワークに接続している場合のみです。Windows PCの場合オンプレミスのネットワークに接続していない場合でも「キャッシュ ログオン」できますが、リソースへのアクセスはできません。

ポリシー(デバイス/ユーザー)

Azure AD自体にはデバイスやユーザーに対するポリシー適用の機能はありませんが、Microsoft 365に含まれるデバイス管理機能やIntune、サードパーティー製のMDMソリューションと連携して、デバイスやユーザーに管理者が構成したポリシーを適用できます。
サポートされているバージョンのWindowsにはこのようなMDMで構成可能な数多くのCSP(構成サービス プロバイダー)が含まれており、十分な管理を行うことができます。グループポリシーの管理用テンプレート(ADMX ファイル)を処理するCSPも含まれていますので、IntuneなどのMDMを通じてActive Directoryのグループポリシーと同様のポリシーをデバイス単位・ユーザー単位で適用可能です。
MDM による管理はインターネット経由で行われるため、デバイスやユーザーの場所を問わず常時管理可能です。

Active Directoryにはグループポリシーの管理が標準の機能として備わっています。Active Directory ドメインに参加したコンピューターとユーザーには、ドメインで構成されているポリシーが自動的に適用されます。
コンピューターやユーザーに対するグループポリシーの更新は、コンピューターがオンプレミスのネットワークに接続している場合にのみ行われます。そのためリモートワーク・テレワークの環境では、管理者がポリシーを変更しても、コンピューターやユーザーに変更がすぐに適用されない場合があります。

Azure ADとActive Directoryの同期

Azure ADとオンプレミスのActive Directoryはこのように異なる目的の別の製品(サービス)であっても同じ「認証基盤」という機能のため、いずれもユーザー管理・認証のためのユーザー情報のフォーマットとして LDAP スキーマが利用されています。スキーマが同じなのでユーザーの名前(アカウント名)や表示名、メール アドレスなどの属性情報は共通で利用できる形式になっています。
そのため、オンプレミスの既存のActive Directoryの情報をクラウド上のAzure ADに同期させることができます。これはAzure AD Connectという機能です。Azure AD Connectを利用すると、オンプレミスの既存のActive Directoryのユーザー、グループ、およびその他のオブジェクトがAzure ADにも作成され、クラウド側のユーザーやグループのID情報がオンプレミスと一致したものになります。

さらにパスワードも同期が可能です(実際に同期されるのはパスワードのハッシュで、平文のパスワードそのものはクラウドには保存されません)。これにより、ユーザーは同じアカウント名とパスワードを使って、オンプレミスのActive DirectoryとAzure ADの両方にサインインできるようになります。
Azure AD Connectについて詳しくはAzure AD ConnectおよびConnect Healthとは を参照してください。

Azure ADでのみ利用可能な機能

Azure ADでは可能ですが、Active Directoryでは行えないこととして、以下のような機能があります。

クラウドサービスへのサインインとアクセス制御

Azure ADアカウントは前述のようにクラウドベースで多くの認証プロトコルをサポートしているため、Microsoftのクラウド サービスやサードパーティーのクラウドサービスへのサインインと、そのサービス内でのリソースへのアクセス制御に利用できます。ユーザーアカウント単位だけでなく、グループ単位でのアクセス制御も可能です。
Active Directory はオンプレミスの仕組みであるため、クラウドサービスへのサインインには直接利用できません。Active Directoryアカウントでクラウドサービスを利用するには、別途ADFS(Active Directory フェデレーション サービス)を構成する必要があります。

セルフサービス パスワード リセット

アカウントのパスワードを忘れた場合、ユーザーが管理者に依頼せず自分自身でパスワードをリセットして新しいパスワードに変更する機能です。

Azure AD ではユーザーがあらかじめセキュリティ情報(SMS を送信する電話番号や Authenticator アプリなど)を登録しておくことで、パスワード忘却時でも本人確認を行い、パスワードリセットが可能となるように構成できます。
Active Directoryにはこの機能はありません。サードパーティー製品でActive Directoryにセルフサービスパスワードリセットを追加するものがあります。

多要素認証

Azure ADへのサインイン時にパスワードやスマートカードなどの1つの認証情報だけでなく、複数の認証要素を求める機能です。多要素認証を有効にすると、例えばパスワードの他に、SMSで送信されるコードの入力、Authenticatorアプリでの承認、生体認証など、別の認証要素を提供しないとサインインできません。この機能でより高いセキュリティが実現されます。
Active Directoryにはこの機能はありません。

条件付きアクセス

Azure ADへのサインイン時に、接続に利用しているデバイスの状態(更新状態やポリシーの適用状態など)、デバイスが接続しているネットワーク、アクセスしようとしているリソースなどの組み合わせの条件により、サインインを許可/拒否したり、多要素認証を求めたりする機能です。

例えば会社内のネットワークから会社で管理しているデバイスでAzure ADにサインインする場合はパスワードのみで許可、会社外のネットワークに接続している会社管理デバイスからの場合は多要素認証を要求、それ以外はサインインを拒否するというような構成が可能です。
Active Directoryにはこの機能はありません。

外部ユーザーのゲスト招待

Azure ADには組織外のユーザーを「ゲスト」として招待し、組織のリソース(Microsoft 365 の SharePoint Online や Teams、組織の独自アプリケーションなど)へのアクセスを許可する機能があります。これにより組織内外のユーザーのコラボレーションを効率的に行うことができます。ゲストとして招待されたユーザーは招待元のAzure ADで管理され、アクセス権限を制御することができます。
Active Directoryで組織外のユーザーに組織内のリソースへのアクセス権を与えることは困難です。フォレスト内に外部ユーザー専用のドメインを作り、そのドメインのユーザーとして管理するなどの工夫が必要になり、仕組みや運用が複雑化します。

Active Directoryでのみ利用可能な機能

Azure ADでは行えない機能もあります。

オンプレミスリソースへのアクセス制御

Windows 環境のオンプレミスのリソースはアクセス制御リスト(ACL)に基づいてアクセスの許可/制限を制御しています。ユーザーはアカウントACLに(直接または参加しているグループを通じて)登録されることで、リソースへのアクセスが許可されます。ACLに登録できるアカウント(ユーザー アカウントやグループ)はオンプレミスのアカウント(ドメイン アカウントまたはローカル アカウント)のみで、Azure AD ユーザーのアカウントやAzure ADのグループを登録することはできません。
そのためAzure ADアカウントを利用して、オンプレミスのリソースへのアクセス制御を行うことはできません。オンプレミスアカウントの資格情報を要求する社内Webアプリケーションへのアクセスには、Azure ADアプリケーション プロキシを構成する必要があります。その他のファイルサーバーなどのオンプレミスのリソースへのアクセス制御を行うには、別途オンプレミスのアカウント(資格情報)を用意することになります。

まとめ

Azure ADはクラウドベースの認証とアクセス制御の仕組み、Active Directory(ADDS)はオンプレミスの認証とアクセス制御の仕組みです。Microsoft 365やMicrosoft AzureなどのMicrosoftのクラウドサービスの利用にはAzure ADが必須です。またAzure ADのアカウントを利用して、多くのサードパーティーのクラウドサービスでの認証を行うことができます。
まったく新しい組織でクラウド上にすべての業務の基盤を構築する場合はAzure ADのみを利用してすべてのユーザーやデバイスを管理することが可能でしょう。しかし既存のオンプレミスのリソースをActive Directoryで管理している組織の場合、Azure ADでその機能をすべて置き換えることは困難です。こうした既存の組織では、クラウド用のAzure ADとオンプレミスのActive DirectoryをAzure AD Connectで同期させて利用することが望ましい利用形態です。

マルチクラウドの記事