当社には、図書館などをサポートする AD ドメイン (オンプレミス) があります。この図書館には多数の公共コンピューターがあり、これらの公共コンピューターは Active Directory 内の独自の OU にあります。また、public当社の司書が外部のゲストにマシンへのアクセスを許可するために使用できる汎用ゲスト ログインもあります。
このアカウントだけを制限して、PublicComputersOU 内のコンピューターにのみアクセスできるようにします。
これらのコンピューターや他のコンピューターに引き続きログインできるユーザーは他にも多数います。
AD のユーザー オブジェクトのボタンについては承知していますLog On To...が、これらのコンピューターは移動したり入ったりするため、これは適していません。OU メンバーシップは他の理由で維持されますが、コンピューターが移動するたびにそのボタンを使用する必要がある場合、すぐに古くなります。
AD 階層の関連部分は次のようになります。
Domain Root > InstitutionComputers > Library > PublicComputers
> ServiceAccounts > public
> Users (group) > {ManyOtherUsers}
> OtherOU > {ManyOtherUsers}
これどうやってするの？
パブリック アカウントを含めるようにドメイン レベルでログオン拒否ポリシーを設定し、次にアカウントを含まないより具体的な OU レベルで別のログオン拒否ポリシーを設定してみました。
テストでは、一部のマシンではこれが機能しますが、他のマシンではパブリック ユーザーのログインがブロックされます。機能していないマシンのローカル セキュリティ ポリシーを確認すると、OU レベルではなくドメイン レベルの完全なポリシーが適用されていることがわかりますが、マシンが正しい OU のメンバーであることを確認しました。さらに、両方のポリシーが表示されます。(この情報も質問に追加しています)。そのため、より具体的なポリシーがこれらのコンピューターと一致していることがわかります。コンピューターをgpresult実行して再起動した後でも、この状態が続きます。gpupdate /force
グループ ポリシーでの「強制」の動作について誤解していたことが判明しました。これは、CSS の !important と有効/無効の違いのようなものです。「強制」のマークを外すと、すべてのポリシーを適用しながら、文書化された優先順位ルールが機能するようになりました。
答え1
2 つの GPO を作成します。
- ドメイン レベルの GPO。
publicローカル ログオンを拒否するセキュリティ ポリシーにユーザーを追加する - OU レベルの GPO (コンピュータ オブジェクトを持つ OU)。ローカルでのログオン拒否を空 (または、ブロックする必要がある他のユーザーがいる場合は、必要な値) に設定します。
詳細については、Microsoft のドキュメントを参照してください。https://learn.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/deny-log-on-locally
通常の適用順序と比較して、強制優先順位は逆になります。
階層の 2 つのレベルで適用される GPO に競合する設定がある場合、クライアントから最も遠い設定が優先されます。これは、最も近いリンクの GPO の設定が優先される通常のルールとは逆です。