前書き
ドメイン環境の一般ユーザにローカル管理者の権限を与え、PCのキッティングを行ってもらうための設定手順を書こうと思います。
ドメイン環境で、ユーザにローカル管理者のIDとパスワードを与えなくても、ユーザ側でアプリケーションのインストールなどセットアップができるようになります。また、ローカル管理者の権限のみのため、ファイルサーバのアクセス権には影響を与えないものとなります。
ネット上に有益な情報は掲載されていましたが、検証してみるとうまくいかないところもあり、また新しい発見もあったので備忘録として残したいと思います。
以下の記事は大変参考になりました。ありがとうございました。
https://sys-guard.com/post-12704/
https://soma-engineering.com/server/activedirectory/gpo-user-localadministrator/2018/07/22/
検証環境と目的
検証環境は以下の通りです。
サーバOS ドメイン機能レベル フォレスト機能レベル |
Windows Server 2016 |
クライアントOS | Windows 10 Pro 64bit |
ドメイン名 | Kensho.local |
また、本手順の目的は「Default Domain Policyは変更せず、ドメインの特定のOUに入ったPCに対してローカル管理者権限を与えること」としています。
Default Domain Policyを変更しても問題ないという場合は、本手順のグループポリシーの編集部分だけをDefault Domain Policyに対して行っていただければと思います。(手順⑦~⑰です)
手順
- まず、ローカル管理者権限を与えるPCを格納するOUを作成します。ADサーバにログインし[Active Directoryユーザーとコンピュータ]を開きます。
- ドメイン名を右クリックし、[新規作成]⇒[組織単位(OU)]をクリックします。
- ここでは「AdminComputers」という名前でOUを作成します。
- 「AdminComputers」という名前のOUが作成されたことを確認します。
- 新しいGPOを作成します。
ADサーバ上で[グループポリシーの管理]を開き、[グループポリシーオブジェクト]を右クリック⇒[新規]をクリックします。
- 「LocalAdminGPO」という名前で新規のGPOを作成しました。
- 作成された「LocalAdminGPO」を右クリックして[編集]をクリックします。
- [グループポリシー管理エディター]が起動しますので、[コンピュータの構成]⇒[ポリシー]⇒[Windowsの設定]⇒[セキュリティの設定]⇒[制限されたグループ]を右クリックし、[グループの追加]をクリックします。
- [参照]ボタンをクリックします。
- 「Domain Users」と入力し、[名前の確認]をクリックします。「Domain Users」の存在がドメイン上で確認できるとアンダーバーが入るので、その後[OK]をクリックします。
- [OK]をクリックします。
- [Domain Usersのプロパティ]ウィンドウが開くので、[このグループの所属]の[追加]ボタンをクリックします。
- [参照]ボタンをクリックします。
- 「Administrators」と入力して[名前の確認]をクリックし、Administratorsグループの存在を確認してから[OK]をクリックします。
- [OK]をクリックします。
- [このグループの所属]に「Administrators」が入ったことを確認し、[適用]⇒[OK]をクリックします。
- [制限されたグループ]に「Domain Users」が入り、所属グループに「Administrators」が入っていることを確認します。
- [グループポリシーの管理]に戻り、ポリシーを適用するOU(ここでは「AdminComputers」)を右クリックし、[既存のGPOのリンク]をクリックします。
- 作成した「LocalAdminGPO」を選択して、[OK]をクリックします。
- 「AdminComputers」にポリシーを強制的に適用させるため、リンクさせた「LocalAdminGPO」をクリックし、画面右側の「AdminComputers」を右クリック⇒[強制]をクリックします。
※ここが自分の検証で躓いた個所で、ポリシーの適用を強制にしないと、うまくPCにポリシーが適用されませんでした。
- 「AdminComputers」に対するポリシーの適用が強制になったことを確認します。
- ローカル管理者権限を与えたいPCを、「AdminComputers」のOUに移動します。
※PCはドメインに参加すると、デフォルトで「Computers」というOUに所属されますので移動が必要です。
※ここも検証で躓いた個所で、コンピュータオブジェクトに対してポリシーが適用されるので、コンピュータオブジェクトをしかるべきOUに移動させることが必要です。ユーザオブジェクトに適用されるわけではありません。
- GPOのリンクを貼ったOU(ここでは「AdminComputers」)に移動が完了したことを確認します。
- コマンドプロンプトを起動し、”gpupdate /force”コマンドを実行して、ポリシーのアップデートを行います。
ADサーバでの作業は以上で完了です。
- クライアントマシンで動作確認を行います。
ログインしている場合は一度サインアウトし、再度サインインします。(ログオフ⇒ログイン)
※再ログインする前に、クライアントでも”gpupdate /force”コマンドを実行した方がベターです。
- 何でもよいので、アプリを[管理者として実行]してみます。
そうすると、[ユーザアカウント制御]でパスワードが聞かれないはずです。
以上で作業は完了です。
補足
ポリシーを適用する前と後での、クライアントの動きの違いを補足したいと思います。また、設定が反映が確認できる場所も書いておきます。
クライアントの動作の変化
前述しましたが、アプリを[管理者として実行]したとき、ローカル管理者のパスワードを聞かれなくなります。
《適用前》
《適用後》
設定の確認箇所
クライアントマシンで[コンピュータの管理]を開きます。
[ローカルユーザーとグループ]の中の[グループ]をクリックし、「Administrators」グループをダブルクリックします。
適用前では「Administrator」「ローカルユーザー(任意)」「Domain Admins」のみですが、適用後には「Domain Users」が加わります。
《適用前》
《適用後》
「Domain Users」というのはドメイン上のユーザーは必ず所属しているグループとなるため、「Domain Users」を指定してGPOを作成することで、すべてのドメインユーザに対してローカル管理者の権限を与えられるということになります。(コンピュータオブジェクトの移動は必要ですが。。)
最後までお読みいただき、ありがとうございました。
コメント