Active Directory （AD）は、組織内のユーザー権限の管理をネットワーク管理者が支援するために設計されたマイクロソフト製品です。Windows Serverにインストールされ、エンタープライズ環境の管理や、すべての権限の保存などのアクションを実行するドメインコントローラーとして機能します。 ユーザーアカウントパスワードと権限、およびユーザー認証の管理。
時が経つにつれ、世界はますますクラウド導入へと向かっており、マイクロソフトもまた、より効率的で現代的なクラウドベースの環境への移行を組織に促している。 アイデンティティ管理マイクロソフトのクラウドベースのドメイン環境向けソリューションは Entra IDオンプレミスの AD の機能をクラウドに拡張し、クラウドベースのアプリケーションの ID とアクセスを管理するための堅牢なソリューションを提供します。サポートするレガシーシステムとのシームレスな統合を可能にするために、マイクロソフトは Entra ID 接続。このツールを使用すると、組織はオンプレミスの Active Directory （AD）環境 Entra IDそれによって「ハイブリッドな結合環境」が構築される。
介して Entra ID Connectを使用すると、組織はオンプレミスのActive Directoryからクラウドにユーザーとディレクトリデータを同期できます。これにより、ユーザーはオンプレミスシステムと同じ認証情報を使用してクラウドサービスにアクセスできます。興味深い機能の1つは、 Entra ID Connectはパスワードライトバックをサポートしており、クラウドで行われたパスワード変更がオンプレミスのActive Directoryに同期されるため、両方の環境間で一貫したID管理が保証されます。このハイブリッドモデルにより、組織はクラウドとオンプレミスの両方のインフラストラクチャで運用しながら、統一されたIDシステムを維持できます。
従来の権限管理と従来の権限管理の違い Active Directory (NAIST) と Entra ID これは、2つの製品間の同期プロセスにおいてセキュリティ上の脆弱性につながる可能性があります。
権限管理の詳細解説
権限管理 Active Directory は、各環境に、変更を行うための高い権限を持つデフォルトの特権セキュリティグループが複数存在するように動作します。特定のユーザーにこれらの権限を付与したい場合は、そのユーザーをグループに追加するだけです。たとえば、「ドメイン管理者」グループは、そのグループ内のすべてのユーザーに権限を付与します。ユーザーまたはグループの権限を定義するもう1つの方法は、ACL（アクセス制御リスト）を使用することです。このリストは、AD内の各オブジェクトに存在し、各エンティティの権限を指定します。このメカニズムにより、ドメイン管理者などの高レベルの権限を持つユーザーに属するオブジェクトであっても、一般ユーザーに変更を行う権限を割り当てることができます。
しかし、 Entra ID (旧称 Azure AD) では、デフォルトではセキュリティ グループはありません。代わりに、RBAC (ロール ベース アクセス制御) メカニズムを使用します。つまり、さまざまなタイプのロールがあり、それぞれ異なるユーザー権限を定義します。グループにロールを割り当てることもでき、そのグループのすべてのメンバーは同じ権限を継承します。ただし、このオプションには、デフォルトで定義されているグループ (例: Active Directory.
では、2 つのメカニズムの違いは何でしょうか? Entra では、ユーザーが役割またはグループの割り当てによって特権権限を受け取ったときに、変更保護が提供されます。従来の AD では、すべての機密グループが変更から保護されているわけではないことがわかりました。実際、特定の機密グループは、 Entra ID 接続同期を行います。
Entraでは、ユーザーに特権ロールが付与されると、自動的に変更保護が付与されます。より高いレベルの特権または同等のロールレベルを持つユーザーのみが変更を実行でき、より低いロールレベルの他のユーザーは変更できません。つまり、ユーザーはセキュリティグループのメンバーである必要はなく、ADとは異なり、特権ロールを割り当てるだけで一定レベルの保護が提供されます。
例えば、階層構造において 管理者ロール 以内 Entra ID パスワード管理者 このロールは、ユーザーにパスワードのリセット権限を与えます。ただし、管理者として分類されているにもかかわらず、このロールは管理者階層の中で最も低いロールの1つとみなされます。そのため、パスワード管理者は、以下のパスワードのみをリセットできます。 一般ユーザー または同じ管理者ロールを持つユーザー。上位レベルのユーザーのパスワードをリセットする権限はありません。 管理者ロールグローバル管理者やその他の 特権アカウント異なる管理者ロール間で明確なセキュリティ境界を維持します。この階層構造により、より機密性の高いロールが不正なパスワード変更から保護されます。
同期はどのように起こるのか？
オンプレミス AD と Entra ID 2つの主な部分に分けられます。
- オンプレミスからIDを同期して Entra ID
- パスワードライトバック Entra ID オンプレミスへ
パート 1: オンプレミスから同期 Entra ID
Entra ID Connect は サービスアカウント インストール識別子の最初の 8 バイトに続くユーザーは MSOL と呼ばれます。このユーザーは、ドメイン コントローラーと同等の強力な機能を持っています。「ディレクトリ変更のすべてを複製する」権限により、ユーザーは DC 同期を実行し、クライアントの資格情報（つまり、NT ハッシュ）を含むオブジェクトのすべての属性を抽出できます。ディレクトリ全体でこのユーザーに付与された広範な権限により、保護されたグループのユーザーに関する情報にアクセスして読み取ることができます。これは、提供された権限により、ユーザーがドメイン コントローラーのような権限で操作できるためです。したがって、ユーザーがグループの ACL に明示的にリストされていなくても、グループ メンバーの NT ハッシュを取得する機能は保持されます。この権限は、同期プロセスのオンプレミス側を許可し、RPC トランスポート上で動作するディレクトリ レプリケーション サービス リモート プロトコルを使用して管理されます。同じプロトコルが DCSync 攻撃の実行にも使用されます。オンプレミスの同期エージェントは、すべてのユーザー情報と属性を次の場所に送信します。 Entra ID ポート443経由で送信されます。Entraはこのデータを受信すると、処理を行い、必要な詳細情報を環境内に入力することで、初期同期プロセスを完了します。
パート2：パスワードライトバック Entra ID オンプレミスへ
同期プロセスの2番目のステップは、Entra AD Connectでパスワードライトバックが有効になっている場合に実行されます。この機能により、クラウドからオンプレミス環境へのパスワード同期が可能になるため、ユーザーがクラウドでパスワードを変更すると、その変更がオンプレミス環境にも反映されます。これにより、2つの環境間で正確な同期が保証されます。これは、組織内のすべてのアプリケーションと環境でユーザーが同じパスワードでログインできるようにするという、両環境を接続する主な理由の1つです。
ユーザーに対してパスワードリセットアクションが開始されると、 Entra IDシステムはまずユーザー名を検索して、それが存在するかどうかを確認します Entra IDユーザーが検出された場合、パスワードリセットを試みている人物にこの操作を実行できる役割があるかどうかを確認するために権限チェックが実行されます。ユーザーに必要な権限がある場合、 Entra ID ユーザー名と新しいパスワードをEntraサービスバスに送信します。
オンプレミスで実行されている同期エージェントがこの情報を取得します。Entra Connect によって作成された MSOL ユーザーには DS 同期権限がありますが、読み取りのみであるため、RPC プロトコルを使用してパスワードをリセットしません。代わりに、LDAP リクエストを実行して、対応するユーザーを検索します。 Active Directory そして、「IADsUser.ChangePassword」操作を使用して、リクエストでパスワードを更新しようとします。
この段階で重要なセキュリティチェックが実行されます。LDAPリクエストがドメインコントローラー（DC）によって受信されると、 Active Directory 権限システムは、パスワード変更を試みるユーザーが対象ユーザーのパスワードをリセットするために必要な権限を持っているかどうかを確認します。これは、対象ユーザーのACLを調べることによって行われます。MSOLユーザーがエンティティに対して「パスワードのリセット」権限を持っていない場合、エラーが返されます。 Entra IDパスワードの更新が権限不足のため失敗したことを示します。「パスワードのリセット」権限があれば、パスワードの変更は正常に完了します。
セキュリティギャップ
同期処理中に、特権グループに属するユーザーやより高い権限を持つユーザーを完全に把握できていないことに気づきました。そのため、Entra 環境では、これらのユーザーはオンプレミス環境と同じ特権ステータスを自動的に取得しません。デフォルトでは、ハイブリッドユーザーは、ネットワーク管理者がこれらの特権と保護を手動で割り当てない限り、初期同期時に Entra の特権ロールと同じ保護を受けません。 Entra ID.
2つの環境間の同期機能と、Entraからオンプレミス環境に認証情報を同期させる機能について理解すると、次のような疑問が生じます。潜在的なリスクは何でしょうか？
主なリスクは、Entraの脆弱な管理者ロールを通じてオンプレミスのActive Directoryで高い権限を取得することです。Active Directoryでは、ユーザーは特権権限を取得できますが、必ずしも保護されたグループに属しているとは限らないため、攻撃にさらされる可能性があります。この攻撃フローにも同様のリスクが存在します。
攻撃者が一度制御権を得ると Entra ID パスワード管理者ロールが割り当てられたユーザーは、オンプレミスのユーザーアカウントを持っていなくても、そのパスワードリセット権限を利用して権限を昇格させることができます。DNS管理者グループなどの、Active Directoryの権限が昇格されたユーザーのパスワードをリセットすることで、アカウントの制御権を取得し、オンプレミスドメイン内で権限を昇格させる可能性があります。
攻撃者が行う必要があるのは、少なくともパスワード管理者ロールを持つ適切なユーザーアカウントでログインすることだけです。 Entra ID彼らがインターフェースを使用するかどうかは関係ありません https://entra.microsoft.com or https://portal.azure.comログイン後、攻撃者は標的となるオンプレミスユーザーを選択し、パスワードをリセットするだけです。これにより、攻撃者はパスワードを変更したアカウントでオンプレミス環境にログインできるようになります。
重要な点として、標的となるユーザーがオンプレミス環境の保護されたグループに属している場合、攻撃は失敗します。
これは、オンプレミスの保護されたユーザーの権限管理が、 Entra ID アカウントをこれらの保護グループのユーザーに接続します。オンプレミス環境では、保護グループは、 adminCount グループの属性。 adminCount 属性が「1」に設定されている場合、そのグループは保護されているとみなされます。これらの保護されたグループは、定期的に適用される固定のアクセス許可テンプレートに従います。1 時間ごとに、保護メカニズムが Active Directory グループの権限をチェックするプロセスを実行します。 ACL テンプレートで定義されている権限と一致させます。不一致がある場合は、プロセスによって権限がリセットされ、テンプレートに一致するように調整されます。
このプロセスは、 SDProp （セキュリティ記述子伝播器）であり、権限テンプレートは AdminSDHolder.
この脆弱性を悪用する攻撃シナリオ
シャドウ管理者
シャドウ管理者 管理者のパスワードをリセットできるが、どの管理者グループにも属していないユーザーです。オンプレミスと Active Directory (NAIST) と Entra ID これらのシャドウ管理者を（特権ユーザーグループによる特別な保護なしに）通常のユーザーとして扱うと、攻撃者はEntraで特権ユーザーのパスワードをリセットする権限を悪用する可能性があります。つまり、攻撃者はオンプレミス環境でもそのユーザーのパスワードをリセットできてしまうということです。
このシナリオでは、攻撃者は侵害されたユーザーの昇格された権限を利用して、権限を昇格させ、ネットワーク全体にわたって制御を拡大するための明確な道筋を得ることができます。
DNS管理者グループ
もう一つの例は、DNS管理者グループです。DNS管理者は、DNSサーバーをはじめとする重要なネットワークインフラストラクチャコンポーネントを管理します。DNS管理者グループは、オンプレミス環境で追加の保護対策が施されていない特権グループとして設定されているため、攻撃者はEntraを介してDNS管理者グループメンバーのパスワードを簡単にリセットできてしまいます。これにより、攻撃者はオンプレミス環境におけるそのアカウントを完全に制御できるようになります。
DNS 管理者アカウントを制御すれば、攻撃者はネットワーク運用を著しく妨害する可能性があります。内部ネットワークトラフィックをリダイレクトするために DNS レコードを変更したり、 中間者攻撃（MITM） 攻撃は、自身が管理するサーバーを経由してトラフィックを迂回させたり、DNS設定を変更してユーザーを悪意のあるウェブサイトに誘導したりすることによって行われる。
グループ ポリシー作成者の所有者
グループ ポリシー作成者所有者も、追加の保護がなければ特権グループになり得るグループの一例です。このグループのメンバーは、自身が作成したグループ ポリシー オブジェクト (GPO) を変更できます。攻撃者がこのグループのアカウントにアクセスした場合、その権限を悪用して、既存の適用済み GPO を変更する可能性があります。変更された GPO には、認証情報を盗んだりマルウェアをインストールしたりするスクリプトなど、有害なスクリプトや設定が含まれている場合があります。
サート・パブリッシャーズ・グループ
認定発行者 グループは、セキュリティに関して常に必要な注意が払われているとは限らない特権グループのもう 1 つの例です。このグループのメンバーには、証明書を公開する権限が与えられています。 Active Directory組織の 公開鍵基盤 (PKI)攻撃者がアカウントにアクセスした場合、 認定発行者 これらのグループに所属する者は、証明書を発行または改ざんすることができ、深刻なセキュリティリスクにつながる可能性があります。
例えば、攻撃者は 悪意のある証明書または不正な証明書 信頼できるユーザーやサービスになりすまし、中間者攻撃を実行したり、安全な通信を解読したり、セキュリティ対策を回避したりすることを可能にする。 認証 制御機能。攻撃者は、ドメイン管理者などの高権限アカウントに証明書を発行することで権限を昇格させ、ドメイン全体を侵害する可能性もあります。
攻撃の緩和
1. ハイブリッド型のID統合設定を使用する場合は、オンプレミス環境とEntraの権限を必ず比較してください。また、Entraにのみ存在し、オンプレミス環境に対応するアカウントを持たない特権ユーザーには、パスワードリセット権限を与えないようにしてください。これにより、外部からの不正アクセスや環境への不正制御を防ぐことができます。
2. オンプレミス環境と同期を設定する場合 Active Directory （AD）と Entra IDそのため、オンプレミス環境において特権グループに割り当てられている権限を常に確認することが不可欠です。特に、これらのグループに不要なパスワード変更権限が付与されていないことを確認する必要があります。
特権グループのメンバーがパスワードを変更できることに気づいた場合、対処方法は2つあります。
- 権限を手動で削除する：各特権グループの権限を手動で調整して、パスワードを変更する機能を削除できます。
- AdminSDHolder テンプレートを活用する: または、 adminCount 特権グループの属性を「1」に設定することで、彼らを保護する。
AdminSDHolder はセキュリティ テンプレートです Active Directory これは、保護対象グループのメンバーに対するセキュリティ権限を定義し、適用するものです。特権グループをこのテンプレートに追加することで、パスワード変更権限を自動的に削除できます。
