正直なところ、案件にアサインされる前のActive Directory（※以降AD）に対するイメージはシンプルでした。
「社員のアカウントを作って、一元管理するやつ」程度のイメージを持っていました。
実際に触ったことがなかったので調べてみたところ、大きく以下2点のものだと捉えていました。
・ADはオンプレミスのWindows環境でID管理を担う仕組みで、社員がPCにログインできるのも、社内システムにアクセスできるのも、ADがその認証を一手に引き受けている。
・ドメインコントローラーと呼ばれるサーバーが中心に存在し、誰がどのリソースにアクセスできるかを管理している。
なるほど！Entra IDもその流れを汲んだクラウド版でしょ！ってアサインされる前は思っていました笑
ではなぜ、Entra IDというクラウド版が存在するのか。
ADが設計された時代、仕事は基本的に「社内ネットワークの中」で完結していました。
社員は会社のPCから社内サーバーにアクセスし、退勤したらそこで終わり。
その前提があったからこそ、ドメインコントローラーを中心とした管理が機能していました。
ところがクラウドの普及とともに、その前提が崩れ始めます。
SlackやMicrosoft 365、SalesforceといったSaaSをどこからでも使うのが当たり前になり、社員が社外・私用デバイスから業務システムにアクセスする場面が増えました。
オンプレのADは「社内にいること」を前提とした仕組みのため、こうした変化に対応しきれません。
そこで登場したのが、クラウドネイティブなID管理基盤としてのEntra IDです。
「クラウド版ADでしょ」という認識のまま案件にアサインされた僕が最初に担当した業務は、アカウント管理ではありませんでした。
IdP（Identity Provider）としてのアプリケーション連携申請を受け付け、内容を精査して設定する業務です。
正直、最初は「？」でした。IDを管理するんじゃないの？アプリ連携って何？という状態です。
調べていくうちに、Entra IDがただのID管理ツールではなく、以下のような役割を持つことがわかってきました。
ADは「社内のID管理」に特化していましたが、Entra IDはそこに認証基盤としての役割まで担っていたのです。
ここで一度、ADとEntra IDを整理してみます。
名前が似ているので後継製品のように見えますが、実際には別物として捉えたほうがしっくりきます。
項目 | Active Directory | Entra ID |
|---|---|---|
管理場所 | オンプレミス | クラウド（Azure） |
主な認証プロトコル | Kerberos / NTLM | SAML / OAuth / OIDC |
対象環境 | 社内ネットワーク前提 | インターネット前提 |
アプリ連携 | 限定的 | SaaSを含む幅広い連携が可能 |
アクセス制御 | GPO | 条件付きアクセス |
ドメインコントローラー | 必要 | 不要 |
プロトコルも、KerberosやNTLMからSAML・OAuth・OIDCへ。同じ「認証」でも、設計思想がまるで違いました。
なお、最近はMicrosoft Entra Kerberosも登場しており、ハイブリッド環境でのシームレスな認証も実現しつつあります。
クラウドとオンプレの境界がさらに曖昧になってきている印象です。
「Entra IDはID管理ツールでしょ」という認識のまま案件にアサインされた僕が、実際に触れて気づいたことを整理してきました。
なお、Entra IDにはMFAやPIM、Identity Protectionなど今回紹介した以外にも多くの機能があります。
この記事ではその中でも特に「ADとの違い」を理解するうえで押さえておきたい3つに絞って紹介しました。
改めてまとめると、Entra IDは以下の3つの顔を持っています。
ADの「社内ネットワーク前提のID管理」から、クラウド時代の「認証基盤」へ。
同じID管理という言葉でも、その守備範囲は想像以上に広がっていました。
次回は、僕が最初に担当した業務でもあるIdPとしてのアプリ連携について、SAMLやOAuthなどの認証プロトコルを交えながら掘り下げていきます！！