Microsoft Entra Private AccessがオンプレミスのActive Directoryに条件付きアクセスをもたらす

攻撃者はクラウドリソースをますます標的にしていますが、だからといってオンプレミスのActive Directoryインストールがネットワークへのアクセスを得るための絶好のターゲットでなくなったわけではありません。例えば、政府機関などは多くのオンプレミスサーバーや従来型デスクトップに依存しており、これらは魅力的な標的となります。

その結果、Microsoftは昨年、Microsoft Entraの強化されたアクセス制御機能をオンプレミスシステムに追加する方法のテストを開始しました。これにより、組織はこれらのリソースに対して条件付きアクセスや多要素認証（MFA）オプションを設定できるようになります。当初の展開には、Entraのアイデンティティ中心のゼロトラストネットワークアクセス（ZTNA）フレームワークを使用してActive Directoryドメインコントローラーなどのリソースに接続するサポートが含まれていました。

7月には、公式のMicrosoftドキュメントに「Active Directoryドメインコントローラー向けEntra Private Access」の設定に関する詳細が追加され、これらの機能が本格的にリリースされ、運用環境で利用可能になったことが示されました。

この機能を展開する前に克服しなければならない大きなハードルが1つあります。それは、ネットワークがNTLMフリーであり、ドメインコントローラーとの認証にKerberosのみをサポートしていることを確認する必要があるという点です。Entra Private Accessの目標は、従来のVPNや内部Active Directoryリソースの代替となることです。

Entra Private Accessのためのシステム準備

Entra Private Accessは2024年11月から一般提供されていますが、Active Directoryドメインコントローラーとの完全な統合とドキュメントは先月から利用可能になりました。

サービスを設定するには、Microsoft Entra IDでグローバルセキュアアクセス管理者ロールが必要です。また、製品にはライセンスが必要ですが、概念実証のためにトライアルライセンスを使用して展開をテストすることができます。

また、クライアントマシンがWindows 10以上であり、Microsoft Entraに参加済みまたはハイブリッド参加済みデバイスであることを確認する必要があります。クライアントマシンはプライベートリソースおよびドメインコントローラーへの到達性（ラインオブサイト）も必要です。つまり、ユーザーは企業ネットワーク内にいて、オンプレミスリソースにアクセスしている必要があります。

ファイアウォールルールとしては、ドメインコントローラーのWindowsファイアウォールでインバウンドTCPポート1337を開放する必要があります。また、保護したいプライベートアプリのサービスプリンシパル名（SPN）を特定し、それらをドメインコントローラーにインストールしたPrivate Access Sensorsポリシーに追加する必要があります。

Microsoftは、まずプライベートアプリでこの機能をテストすることを推奨しています。プライベートアプリのSPNを使用してドメインコントローラーにMFAを強制することができますが、後の段階で実施することで管理者のロックアウト問題を回避できるとMicrosoftは報告しています。

多くの展開と同様に、インストールに必要なさまざまな部分のトラブルシューティングから問題が始まることがよくあります。Global Secure Accessコミュニティリソースハブのリソースを確認し、概念実証をセットアップすることをお勧めします。

現時点で保護可能なクライアントはWindows 10および11、Androidです。Windows on Arm、macOS、iOSは現在プレビュー段階です。

Susan Bradley / CSO

Entra Private Accessの活用

これらの追加セキュリティ設定を展開する前に、ネットワークからNTLMを排除する作業を進めておく必要があります。まず、NTLMがどこで使用されているかを特定するために環境を監査します。

そのためには、[コンピューターの構成]\[ポリシー]\[Windowsの設定]\[セキュリティの設定]\[ローカルポリシー]\[セキュリティオプション]に移動します。

Susan Bradley / CSO

NTLMを使用したワークグループおよびドメイン認証試行を含む最も詳細な監査は、以下の設定で実現できます：

• ネットワークセキュリティ：NTLMの制限：リモートサーバーへの送信NTLMトラフィック＝すべて監査
• ネットワークセキュリティ：NTLMの制限：このドメインでのNTLM認証の監査＝すべて有効
• ネットワークセキュリティ：NTLMの制限：受信NTLMトラフィックの監査＝すべてのアカウントで監査を有効

「このドメインでのNTLM認証の監査」の設定はドメインコントローラーのみに設定する必要がある点に注意してください。「リモートサーバーへの送信NTLMトラフィック」および「受信NTLMトラフィックの監査」の監査はすべてのコンピューターで設定してください。

あとは、イベントビューアー（ローカル）\アプリケーションとサービスログ\Microsoft\Windows\NTLM\Operationalにあるログファイルを確認します。

非常に安全性の低いプロトコルで通信しているアプリケーションやプロセスを特定しましょう。Entra Private Accessを導入しない場合でも、ネットワーク内でNTLMの使用状況を監査しておくことで、ランサムウェア攻撃への防御にも役立ちます。

アプリケーションやプロセスでNTLMの使用を特定したら、NTLM v1をブロックし、以下のポリシー設定でNTLM v2の強制・制限への移行を開始します：

• コンピューターの構成 > ポリシー > Windowsの設定 > セキュリティの設定 > ローカルポリシー > セキュリティオプションに移動します。
• ネットワークセキュリティ：LAN Manager認証レベルを「NTLMv2応答のみ送信。LMおよびNTLMを拒否」に設定します。これによりKerberosの使用が強制され、必要な場合のみNTLMv2がフォールバックとして許可されます。

再度、結果を確認し、どのアプリケーションやネットワークセグメントが影響を受けているかを判断します。大きな影響を受けるアプリケーションについては、NTLMを段階的に廃止するために、アプリケーションの更新や廃止などの選択肢を検討してください。

NTLMに依存しなくなった場合は、ドメイン内でその使用を安全にブロックできます。

そのためには、グループポリシーでネットワークセキュリティの設定を行い、「NTLMの制限：このドメインでのNTLM認証」ポリシーを選択します。「ドメインアカウントによるドメインサーバーへのアクセスを拒否」から「すべて拒否」まで、完全なブロックが選択できます。

ネットワーク内のアプリケーションについては、NTLMがハードコーディングされていないか確認してください。特に以下をチェックします：

• AcquireCredentialsHandle関数への呼び出しで、ハードコーディングされた文字列ntlmを渡している場合——これらはnegotiateに置き換えます
• RpcBindingSetAuthInfo関数への呼び出し——RPC_C_AUTHN_DEFAULTをRPC_C_AUTHN_GSS_NEGOTIATEに置き換えます。

ネットワークからNTLMを排除することは不可能ではありませんが、困難な場合もあります。時間とリソースをかけて選択肢を検討し、より多くのクラウドセキュリティ技術を追加してローカルActive Directoryに組み込めるようにしましょう。