次の方法で共有

グループ メンバーシップの変更が一部の VPN 接続で更新されない

この記事では、VPN ユーザーがグループ メンバーシップの変更後にリソース アクセスまたは構成の問題が発生する可能性がある状況について説明します。

適用対象: サポートされているすべてのバージョンの Windows クライアント

現象

Covid-19のパンデミックに対応して、現在、自宅で働き、学び、交流するユーザーが増えています。 VPN 接続を使用して職場に接続します。 これらの VPN ユーザーは、セキュリティ グループに追加またはセキュリティ グループから削除されると、変更が期待どおりに有効にならない可能性があることを報告します。 次のような症状が報告されます。

  • ネットワーク リソース アクセスに対する変更は有効になりません。
  • 特定のセキュリティ グループを対象とするグループ ポリシー オブジェクト (GPO) が正しく適用されません。
  • フォルダー リダイレクト ポリシーが正しく適用されていません。
  • 特定のセキュリティ グループを対象とする Applocker 規則は機能しません。
  • ユーザー ホーム フォルダーや GPP ドライブ マップなど、マップされたドライブを作成するログオン スクリプトは機能しません。
  • whoami /groups コマンド (コマンド プロンプトで実行) は、ユーザーのローカル セキュリティ コンテキストのグループ メンバーシップの古い一覧を報告します。
  • gpresult /r コマンド (コマンド プロンプトで実行) は、グループ メンバーシップの古いリストを報告します。

クライアントが VPN に接続されている間にユーザーが Windows をロックしてからロックを解除すると、これらの症状の一部が解決されます。 たとえば、一部のリソース アクセスの変更が有効になります。 その後、ユーザーが Windows からサインアウトしてからサインインし直した場合 (ネットワーク リソースを使用するすべてのセッションを閉じる)、より多くの現象が解決します。 ただし、ログオン スクリプトが正しく機能せず、 gpresult /r コマンドにグループ メンバーシップの変更が反映されない場合があります。 runas コマンドを使用してクライアントで新しい Windows セッションを開始すると、ユーザーは問題を回避できません。 このコマンドは、同じ資格情報を使用して新しいセッションを開始するだけです。

この記事の範囲には、ドメインに認証メカニズム アシュアランス (AMA) を実装し、ユーザーがネットワーク リソースにアクセスするためにスマート カードを使用して認証する必要がある環境が含まれます。 詳細については、「 Windows での対話型ログオン シナリオでの AMA の使用の説明を参照してください。

原因

オフィス環境では、ユーザーが稼働日の終わりに Windows からサインアウトするのが一般的です。 ユーザーが翌日にサインインすると、クライアントは既にネットワークに接続されており、ドメイン コントローラーに直接アクセスできます。 このような状況では、グループ メンバーシップの変更がすぐに有効になります。 ユーザーは、次の日 (次回ユーザーがサインインした場合) に適切なアクセス レベルを持ちます。 同様に、グループ ポリシーの変更は 1 日または 2 日以内に有効になります (適用がスケジュールされているポリシーに応じて、ユーザーが 1 回または 2 回サインインした後)。

ホーム環境では、ユーザーは稼働日の終了時に VPN から切断し、Windows をロックする可能性があります。 サインアウトしない可能性があります。ユーザーが次の朝に Windows のロックを解除 (またはサインイン) すると、ユーザーが Windows のロックを解除するかサインインするまで、クライアントは VPN に接続しません (ドメイン コントローラーにアクセスすることはできません)。 クライアントは、新しい資格情報をドメイン コントローラーに接続するのではなく、キャッシュされた資格情報を使用して Windows にユーザーをサインインさせます。 Windows は、キャッシュされた情報に基づくユーザーのセキュリティ コンテキストを構築します。 Windows では、ローカルのグループ ポリシー キャッシュに基づいて、グループ ポリシーも非同期的に適用されます。 このキャッシュされた情報を使用すると、次の動作が発生する可能性があります。

  • ユーザーは、持つべきではないリソースにアクセスでき、必要なリソースにアクセスできない可能性があります。
  • グループ ポリシー設定が想定どおりに適用されないか、グループ ポリシー設定が古くなっている可能性があります。

この動作は、ユーザーがサインインするときに Windows がキャッシュされた情報を使用してパフォーマンスを向上させるために発生します。 Windows では、キャッシュされた情報を使用して、ネットワークに接続されていないドメインに参加しているクライアントでユーザーをサインインさせます。 クライアントが VPN を排他的に使用してネットワークに接続し、ユーザーがサインインするまでクライアントが VPN 接続を確立できない場合、予期しない結果が発生します。

重要

この動作は、対話型ログオン シナリオでのみ関連します。 ネットワーク ログオンではキャッシュされた情報が使用されないため、ネットワーク リソースへのアクセスは期待どおりに機能します。 代わりに、グループ情報はドメイン コントローラー クエリから取得されます。

ユーザー セキュリティ コンテキストとアクセス制御への影響

ユーザーがサインインしたときにクライアントがドメイン コントローラーに接続できない場合、Windows はキャッシュされた情報に基づいてユーザー セキュリティ コンテキストをベースにします。 Windows は、ユーザー セキュリティ コンテキストを作成した後、ユーザーが次回サインインするまでコンテキストを更新しません。

たとえば、ユーザーがオフラインの間に Active Directory のグループに割り当てられているとします。 ユーザーは Windows にサインインし、VPN に接続します。 ユーザーがコマンド プロンプト ウィンドウを開き、 whoami /groups コマンドを実行した場合、グループの一覧には新しいグループは含まれません。 ユーザーは、VPN に接続したまま、デスクトップをロックしてロックを解除します。 whoami /groups コマンドでも同じ結果が生成されます。 最後に、ユーザーは Windows からサインアウトします。 ユーザーが再度サインインすると、 whoami /groups コマンドによって正しい結果が生成されます。

キャッシュされた情報がユーザーのリソースへのアクセスに及ぼす影響は、次の要因によって異なります。

  • リソースがクライアント上にあるか、ネットワーク上にあるか
    ネットワーク上のリソースには、追加の認証手順 (対話型ログオンではなくネットワーク ログオン) が必要です。 この手順は、リソースがアクセスを決定するために使用するグループ情報は、クライアント キャッシュではなく、常にドメイン コントローラーから取得されることを意味します。
  • リソースが Kerberos チケットまたはその他のテクノロジ (NTLM アクセス トークンなど) を使用してユーザーを認証および承認するかどうか
    • キャッシュされた情報が NTLM で保護されたリソースへのユーザー アクセスに与える影響の詳細については、「 NTLM 認証に依存するリソースを参照してください。
    • キャッシュされた情報が Kerberos で保護されたリソースへのユーザー アクセスに与える影響の詳細については、「 Kerberos チケットに依存するリソースを参照してください。
  • ユーザーが既存のリソース セッションを再開しているか、新しいリソース セッションを開始しているか
  • VPN への接続中にユーザーがクライアントをロックおよびロック解除するかどうか
    VPN に接続しているときにユーザーがクライアントをロックし、ロックを解除すると、クライアントはユーザー グループのキャッシュを更新します。 ただし、この変更は、既存のユーザー セキュリティ コンテキストや、ユーザーがクライアントをロックしたときに実行されていたセッションには影響しません。
  • VPN に接続しているときにユーザーがクライアントからサインアウトし、もう一度サインインするかどうか
    サインアウトしてからサインインする効果は、ユーザーが VPN に接続しているときに最初にクライアントをロックおよびロック解除したかどうかによって異なります。 クライアントをロックしてからロックを解除すると、次のサインイン時にクライアントが使用するユーザー情報のキャッシュが更新されます。

NTLM 認証に依存するリソース

このカテゴリのリソースには、次のものが含まれます。

  • クライアント上のユーザー セッション

  • NTLM 認証に依存するクライアント上のすべてのリソース セッション

  • NTLM 認証に依存するネットワーク上のすべてのリソース セッション

    重要

    ユーザーが NTLM 認証を必要とするネットワーク上のリソースにアクセスすると、クライアントはユーザー セキュリティ コンテキストからキャッシュされた資格情報を提示します。 ただし、リソース サーバーは、最新のユーザー情報をドメイン コントローラーに照会します。

これらのリソース セッション (クライアント上のユーザー セッションを含む) は期限切れになりません。 ユーザーが Windows からサインアウトしたときなど、ユーザーがセッションを終了するまで実行を続けます。 クライアントをロックしてからロック解除しても、既存のセッションは終了しません。

Kerberos チケットに依存するリソース

ユーザーが VPN に接続し、Kerberos チケットに依存するネットワーク リソースにアクセスしようとすると、Kerberos キー配布センター (KDC) は Active Directory からユーザーの情報を取得します。 KDC は Active Directory からの情報を使用してユーザーを認証し、チケット許可チケット (TGT) を作成します。 TGT のグループ メンバーシップ情報は、TGT が作成された時点で最新です。

その後、Windows は TGT を使用して、要求されたリソースのセッション チケットを取得します。 セッション チケットでは、TGT からのグループ情報が使用されます。

クライアントは TGT をキャッシュし、ローカルかネットワーク上かにかかわらず、ユーザーが新しいリソース セッションを開始するたびに TGT を使用し続けます。 また、クライアントはセッション チケットをキャッシュして、リソースへの接続を続行できるようにします (リソース セッションの有効期限が切れた場合など)。 セッション チケットの有効期限が切れると、クライアントは新しいセッション チケットの TGT を再送信します。

重要

ユーザーがリソース セッションを開始した後にユーザーのグループ メンバーシップが変更された場合、変更がユーザーのリソース アクセスに実際に影響を与えるタイミングは、次の要因によって制御されます。

  • グループ メンバーシップの変更は、既存のセッションには影響しません。
    既存のセッションは、ユーザーがサインアウトするか、セッションを終了するか、セッションの有効期限が切れるまで続行されます。 セッションの有効期限が切れると、次のいずれかが発生します。
    • クライアントはセッション チケットを再送信するか、新しいセッション チケットを送信します。 この操作により、セッションが更新されます。
    • クライアントはもう一度接続を試みません。 セッションは更新されません。
  • グループ メンバーシップの変更は、現在の TGT や、その TGT を使用して作成されたセッション チケットには影響しません。
    チケット付与サービス (TGS) は、Active Directory 自体にクエリを実行するのではなく、TGT からのグループ情報を使用してセッション チケットを作成します。 TGT は、ユーザーがクライアントをロックするかサインアウトするまで、または TGT の有効期限が切れるまで (通常は 10 時間) 更新されません。 TGT は 10 日間更新できます。

klist コマンドを使用して、クライアントのチケット キャッシュを手動で消去できます。

Note

チケット キャッシュには、コンピューター上のすべてのユーザー セッションのチケットが格納されます。 klistコマンド ライン オプションを使用して、特定のユーザーまたはチケットにコマンドをターゲットにすることができます。

起動プロセスとサインイン プロセスに対する影響

グループ ポリシー サービスは、グループ ポリシーの適用を高速化し、クライアントのパフォーマンスへの悪影響を軽減するために最適化されています。 詳細については、「 グループ ポリシーに対する高速ログオンの最適化と高速起動の効果を理解するを参照してください。 この記事では、グループ ポリシーとスタートアップ プロセスとサインイン プロセスの対話方法について詳しく説明します。 グループ ポリシー サービスは、フォアグラウンド (起動時またはサインイン時) またはバックグラウンド (ユーザー セッション中) で実行できます。 このサービスは、次の方法でグループ ポリシーを処理します。

  • 非同期処理 は、他のプロセスの結果に依存しないプロセスを指します。
  • 同期処理 は、互いの結果に依存するプロセスを指します。 そのため、同期処理では、前の処理が完了して次の処理が開始できるようになるまで待つ必要があります。

次の表は、フォアグラウンド処理またはバックグラウンド処理をトリガーするイベントと、処理が同期または非同期のどちらであるかをまとめたものです。

トリガー 同期または非同期 前景または背景
コンピューターの起動またはシャットダウン 同期または非同期 前景
ユーザーのサインインまたはサインアウト 同期または非同期 前景
スケジュール済み (ユーザー セッション中) 非同期 背景
ユーザー アクション (gpupdate /force) 非同期 背景

構成の変更を適用するために、一部のクライアント側拡張機能 (CSEs) には同期処理が必要です (ユーザーのサインイン時またはコンピューターの起動時)。 このような場合、CSE はバックグラウンド処理中に変更の必要性を識別します。 ユーザーが次回サインインするか、コンピューターを起動すると、CSE は同期処理フェーズの一部として変更を完了します。

これらの CSP の中には、同期処理の実行中にドメイン コントローラーやその他のネットワーク サーバーに接続する必要があります。 フォルダー リダイレクトとスクリプト CSEs は、このカテゴリの 2 つの CSEs です。

この設計はオフィス環境で効果的に機能します。 ただし、自宅での作業環境では、ユーザーがドメインに接続している間にサインアウトして再びサインインしないことがあります。 クライアントがドメイン コントローラーまたはその他のサーバーに接続する前に、同期処理を完了する必要があります。 そのため、一部のポリシーを正しく適用または更新できません。

たとえば、フォルダー リダイレクトを変更するには、次のものが必要です。

  • フォアグラウンド同期処理 (ユーザー サインイン中)。
  • ドメイン コントローラーへの接続。 処理の実行中は、接続を使用できる必要があります。
  • リダイレクト ターゲット フォルダーをホストするファイル サーバーへの接続。 処理の実行中は、接続を使用できる必要があります。

実際、この変更には 2 つのサインインが含まれる場合があります。最初のサインイン時に、クライアントのフォルダー リダイレクト CSE が変更の必要性を検出し、フォアグラウンド同期処理の実行を要求します。 次のサインイン時に、CSE によってポリシーの変更が実装されます。

グループ ポリシーレポートへの影響

グループ ポリシー サービスは、クライアント、Windows Management Instrumentation (WMI)、およびレジストリのグループ メンバーシップ情報を保持します。 WMI ストアは、ポリシーの結果セット レポートで使用されます ( gpresult /rを実行して生成されます)。 どの GPO が適用されるかを決定するために使用されません。

Note

ポリシー ログの結果セットを無効にするポリシーを有効にすると、ポリシーレポート機能の結果セットをオフにすることができます。

次の状況では、グループ ポリシー サービスは WMI のグループ情報を更新しません。

  • グループ ポリシーはバックグラウンドで実行されています。 たとえば、コンピューターが起動した後、またはユーザーがサインインした後の定期的な更新中、またはユーザーがグループ ポリシーを更新するために gpupdate /force コマンドを実行したときなどです。
  • グループ ポリシーは、グループ ポリシー キャッシュから実行されています。 たとえば、クライアントがドメイン コントローラーにアクセスできないときにユーザーがサインインした場合などです。

この動作は、ユーザーのサインイン中にグループ ポリシー サービスがネットワークに接続できないため、VPN 専用クライアントのグループ リストが常に古くなっている可能性があることを意味します。 グループ ポリシーが実行され、WMI のグループ情報が更新されない場合、グループ ポリシー サービスは次のようなイベントを記録する可能性があります。

GPSVC(231c.2d14) 11:56:10:651 CSessionLogger::Log: restoring old security grps

調べているアカウントのグループ ポリシー サービス ログに次の行が表示される場合にのみ、WMI と gpresult /r の出力が更新されることを確認できます。

GPSVC(231c.2d14) 11:56:10:651 CSessionLogger::Log: 新しいセキュリティ grps のログ記録

解決方法

この記事で説明する問題を解決するには、ユーザーがサインインする前にクライアントへの VPN 接続を確立できる VPN ソリューションを使用します。

対処方法

ユーザーがサインインする前にクライアント接続を確立する VPN を使用できない場合は、この記事で説明する問題を軽減できます。

ユーザー セキュリティ コンテキストとアクセス制御の回避策

ユーザーをグループに追加した後、またはグループからユーザーを削除した後、ユーザーに次の手順を指定します。 この手順では、ユーザーがサインインする前に VPN に接続しないクライアントのユーザー セキュリティ コンテキストを更新する、サポートされている唯一の回避策を提供します。

重要

ユーザーがこの手順を開始する前に、メンバーシップの変更がドメイン コントローラー間でレプリケートされるのに十分な時間を割きます。

  1. クライアント コンピューターにサインインし、通常どおり VPN に接続します。
  2. クライアント コンピューターが VPN に接続されていることを確認したら、Windows をロックします。
  3. クライアント コンピューターのロックを解除し、Windows からサインアウトします。
  4. Windows にもう一度サインインします。

グループ メンバーシップ情報 (およびリソース アクセス) が最新の状態になりました。

コマンド プロンプト ウィンドウを開き、 whoami /allを実行することで、グループ メンバーシップ情報を確認できます。

Note

次の Windows PowerShell スクリプトを使用して、この手順のロックとロック解除の手順を自動化できます。 このプロセスでは、ユーザーは Windows にサインインし、スクリプトの実行後に Windows からサインアウトする必要があります。

$fullname = $env:userdnsdomain + "\" + "$env:username" 
$MyCred = Get-Credential -Username $fullname -Message "Update Logon Credentials"
Start-Process C:\Windows\System32\cmd.exe -ArgumentList ("/C", "exit 0") -Credential $MyCred -WindowStyle Hidden -PassThru -Wait

グループ ポリシーを含むサインイン プロセスの回避策

構成を手動で変更したり、ユーザーがサインインした後にスクリプトを実行したり、ユーザーが VPN に接続して Windows からサインアウトしたりすることで、いくつかの問題を軽減できます。 これらのアプローチを組み合わせる必要がある場合があります。 グループ ポリシーの場合、特に重要なのは、グループ ポリシーが機能するタイミングと方法を理解することです。

Note

マップされたドライブ接続とログオン スクリプトには、フォルダー リダイレクトと同じフォアグラウンド同期処理要件はありませんが、ドメイン コントローラーとリソース サーバーの接続が必要です。

グループ ポリシー CSEs の処理要件の詳細な一覧については、「 グループ ポリシーに対する高速ログオンの最適化と高速起動の効果の理解を参照してください。