グループポリシーでユーザー毎にプログラムの実行を制御したい

昨今の情勢の影響か、「グループポリシーでリモートデスクトップ接続を制限する」 という記事¹が多く読まれているようで、テレワークやリモートワークの導入を、必要にかられていろいろ調べている人が多いんでしょうね。

 

 

というわけで、私の所属している会社ももしもの場合に備えて、社員の自宅から会社のPCに接続できる方法を検討してほしいということでいろいろと考えているわけです。

リモート接続ということで言えば、TeamViewer や AnyDesk などのリモート接続系のアプリケーションがあるのはわかっていますが、問題はユーザーごとに実行できる、できないを制御したいということなんですよね。

 

ゴール

そこで、ここでは次のようなことを想定して話を進めていきます。

• リモート接続ソフトウェア AnyDesk を使用したい
• インストール先は %ProgramFiles% (または、%ProgramFiles(x86)%)
• でもすべてのユーザーではなくて、一部のユーザーのみ実行できるように構成したい。

というもの。

また、前提条件については以下の通り。

• Active Directory が構築済み
• マシンもユーザーも Active Directory に参加している。
• 管理用のマシンに、リモートサーバー管理ツール (RSAT) が導入されていること。
• AnyDesk が管理者によって全てのマシンに導入済み。

 

ソフトウェア制限ポリシー (SRP)

Active Directory といえば、グループポリシー。そこで、グループポリシーを使って色々とやってみました。例えば、

• AnyDesk のサービスを停止してみる
  → 可能だが、動作がまるで バグ のようだ。
• AnyDesk に関するファイアウォールを無効にしてみる
  → インストール時に作成されるファイアウォールを全て無効にして、グループポリシーでカスタムのルールを作成してみたが、サービスが起動する度に新たにルールが登録されてしまうみたいで、これはまったく意味がなかった。

結局上記の方法ではどれもしっくりとこず、結局は以下の方法しかないな、と思いました。

• ソフトウェア制限ポリシー (SRP²)
• アプリケーション制限ポリシー (Applocker)

の２種類。

これもまたいろいろ試してみたところ、Windows 7 Pro では AppLocker は使えない みたいで、ちなみに言うと、Windows 10 Pro バージョン 1809 でも、ログに次のようなエラーが出てて使えないことがわかりました。

appidsvc.dll: このエディションでは AppLocker コンポーネントを利用できません

・・って、なんやそれ・・。

ちなみに、AppLocker の使用条件は こちら (英語) に書いてあります。

・・というわけで、SRP を使ってプログラムの実行を制御しようと思ったわけですが、これがまた結構 ハマり ました。

 

SRP でプログラム実行を禁止することは簡単

 

グループポリシーオブジェクト (GPO) の作成

まず RSAT の「管理ツール」 から、「グループポリシーの管理」を開き、左側のディレクトリツリーの自ドメイン名を右クリックして、「GPO を作成してリンク」 させていることとしています。

GPO の名称は、例えばここでは、

anydesk_disabled_policy

とでもしておきましょう。

この GPO を右クリックで 「編集」、とすると、「グループポリシー管理エディタ (GPMC³) 」が開きます。

GPMC 左側のツリーを、

コンピュータの構成 » ポリシー » Windows の設定 » セキュリティの設定

とたどり、「ソフトウェアの制限のポリシー」を右クリックして、

「 » 新しいソフトウェアの制限のポリシー」

をクリックします。

すると、その下に 「追加の規則」というフォルダができて、すでに次のような2つのルールが登録されていると思います。

• %HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionSystemRoot%
• %HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionProgramFilesDir%

これは、%SystemRoot% (既定では、C:Windows) と、%ProgramFilesDir% (同じく C:Program Files) の配下にあるプログラムの実行は制限されないという意味になります。

ちなみに、「セキュリティレベル」というフォルダもありますが、これはこの GPO でのソフトウェア制限ポリシーの既定値を指定できます。

• 許可しない
• 基本ユーザー
• 制限しない

ここで、「許可しない」とすると、場合によってはログオンすらできなくなる場合もあるとのことなので、今回はこちらは指定しません。

また、「強制」という項目もあると思いますが、こちらは任意で設定しても OK です。

「強制」を右クリックして「プロパティ」で「強制のプロパティ」を開きます。

通常はこのままでも大丈夫なのですが、必要に応じて「ソフトウェアの制限のポリシーの適用ユーザー」を、「ローカルの管理者を除くすべてのユーザー」としておくといいかもしれません。

 

新しい追加の規則を作成する

このままだと、Program Files 配下にある AnyDesk のプログラムは実行されてしまうので、新たにルールを作成することにします。

追加の規則の何もないところを右クリックして、「新しいパスの規則」 で、「新しいパスの規則」を開いて、パスに

%ProgramFiles%AnyDeskAnyDesk.exe

を指定します。

そして「セキュリティレベル」 を 「許可しない」にして、「適用」してください。

同様に、もう一つ 「新しいパスの規則」 を追加して、

%ProgramFiles(x86)%AnyDeskAnyDesk.exe

も追加します。

 

規則が適用されているか確認

次に、規則が適用されているか確認します。

任意のマシンに、任意のユーザーでログオンして、スタートメニューやデスクトップのアイコンからAnyDesk を実行してみると、

とか

とアラートが出れば正解。

 

SRP で「特定のユーザー」をどのように指定するか

実は、ここからがハマってしまった部分で、色々試行錯誤するわけですが・・・

結論からいうと・・

 

セキュリティフィルターを使用

そう。

結論から言うと、「セキュリティフィルター」を使用します。

要約すると、

• 上記とは別にセキュリティフィルターを適用した GPO を作成
• なおかつ、「ユーザーの構成」で SRP を構成する

が最終的な答えになりました。

 

セキュリティグループを作成

「特定のユーザー」というのは、「特定のセキュリティグループに属しているユーザー」と読み替えることも可能なので、ここでは AnyDesk を使用して良いユーザーということで、

AnyDeskUsers

というセキュリティグループを作成することにします。

まず、RSAT の 「Active Directory ユーザーとコンピューター (ADUC)」 を開いて、左側のディレクトリツリーの Users を右クリックし、

新規作成 » グループ

として作成します。

内容は、以下の通りでよいでしょう。

• グループ名： AnyDeskUsers
• グループのスコープ： グローバル
• グループの種類： セキュリテイ

 

もう一つのグループポリシーオブジェクト (GPO) の作成

次に、再び「グループポリシーの管理」を開いて、新しい GPO を作成します。

ここでは、

anydesk_enabled_policy として、GPO を作成し「編集」することとします。

GPO の内容ですが、今度は先程と違って、ユーザーの構成 » ポリシー » Windows の設定 » セキュリティの設定 とたどり、「ソフトウェアの制限のポリシー」を右クリックして、

「新しいソフトウェアの制限のポリシー」

をクリックします。

次に、「追加の規則」を右クリックし、「新しいハッシュの規則」をクリックします。

ここで、実行させたいファイルのハッシュを指定します。

「参照」をクリックしてフォルダツリーをたどって C:Program FilesAnyDeskAnyDesk.exe (あるいは C:Program Files (x86)AnyDeskAnyDesk.exe) を選択し 「開く」とすることで、次のようにハッシュの内容が表示されますので、「OK」します。

ここまで設定ができたら、一旦 「グループポリシー管理エディタ (GPMC) 」を閉じます。

 

セキュリティフィルタの設定

次に、GPE のグループポリシーオブジェクトの一覧から、anydesk_enabled_policy を選択して、メインウィンドウの「スコープ」タブ内の「セキュリティフィルター処理」の内容を確認します。

通常、Authenticated Users が指定されていると思いますが、これを選択して「削除」します。

次に、「追加」をクリックして、先ほど作成したセキュリティグループ、AnyDeskUsers を指定して追加します。

「セキュリティフィルター処理」の内容が、AnyDeskUsers だけになっていることを確認した上で、次は「委任」タブに移動します。

「グループとユーザー」の一覧の中に、AnyDeskUsers があり、なおかつ Authenticated Users が存在しないのを確認し、「追加」をクリックし、Domain Computers を一覧に追加します。

アクセス許可は「読み取り」のみで OK です。

ここの Domain Computers を指定する部分は 必須 なので忘れないようにしてください。

 

動作確認

ここまで来たら、今回作成した GPO を適当な OU もしくは、ドメインに直接リンクさせます (2つとも同じ場所にリンクしても大丈夫です)。

また、ユーザーとコンピューターも、この GPO を参照できるロケーションに配置してください。

また、セキュリティグループ AnyDeskUsers に、プログラムを実行しても良いユーザを参加させることも忘れずにしてください。

いよいよ、準備が整ったので、それぞれログオンして AnyDesk が実行できるかどうか試してみてください。

うまくいかない場合は、パソコンの再起動、もしくはコマンドプロンプトで、

GPUPDATE /FORCE

を実行することで、GPO が適用されるはずです。

 

動かない OR ハマりどころ

 

GPO の配置と、ユーザー、コンピューターの配置

一応今回の内容は、ドメインに直接リンクさせることを想定しているので、いずれかの 組織単位 (OU) にユーザーとコンピューターを配置していれば GPO が適用されますが、 Users のようなコンテナの中に配置したままだと、GPO が適用されません。

 

グループポリシーの適用はこまめに

GPO を編集しても、それがクライアントに適用されるまで時間がかかることがありますので、細かに

GPUPDATE /FORCE

して、GPO の適用を強制的に行いましょう。

 

セキュリティフィルター と Domain Computers

セキュリティフィルターを書ける場合に、「スコープ」タブの「セキュリティー処理」のリストに、フィルタを適用したいセキュリティグループを設定する際に、Authenticated Users を削除し忘れないようにすることと、「委任」タブの「グループとユーザー」に Domain Computers を追加し忘れないようにしてください。

前者はすべてのユーザーにセキュリティフィルターが適用されるようになり、逆に後者はいずれのユーザーもセキュリティフィルターが適用されなくなります。

また後者は、次のようにシステムイベントログにイベントID 1096 のイベントログが残ります。

グループポリシーの処理に失敗しました。・・(中略)・・このイベントが解決されるまで、グループポリシー設定は解決されません。エラーの原因となったファイル名及びパスの情報についてはイベントの詳細を参照してください。

とあります (コマンドプロンプトで GPUPDATE /FORCE したときも、同様のメッセージが出力されます) 。

イベントの詳細を、XML で確認すると、

<Data Name="ErrorDescription">アクセスが拒否されました</Data>

となっており、なにかの権限が不足していて、アクセスが拒否させられたことが伺えます。

こういうときは、Domein Computers を追加し忘れていないか確認しましょう。

 

同じ実行ファイルでもハッシュは一つとは限らない

例えば、Windows に標準でインストールされている「メモ帳」のプログラムを例にとってみると、OS 単位でバージョンが違います⁴。

この場合、ハッシュが違ってくるのでそれぞれのハッシュでルールを作成する必要があります。

また、Firefox のように、32 ビット版と64 ビット版でバイナリ (プログラム) が違う場合も同様です。この場合、バージョンがまったく同じだとハッシュも同様に同じように表示されるので勘違いしてしまいそうですが、内部のハッシュはまったく別物のようです (まあ、当たり前といえば当たり前ですが)。

よって、こういう場合もそれぞれのバイナリのハッシュをルールとして登録する必要があります。

さらに、ブラウザのような頻繁にアップデートの繰り返されるプログラムの場合は、バージョンアップのある度にハッシュを追加登録しなければいけない部分にも留意してください。

 

ルールには優先順位がある

今回の例では、

• 全体のルールとして、パス AnyDesk.exe を実行できないように構成。
• ユーザーが、AnyDeskUsers の場合、AnyDesk.exe のハッシュが一致する場合は実行を制限しないように構成

しました。

ここで一つ疑問。

前者は、「パスの規則」を使って構成したのに、なぜ後者のルールは、「ハッシュの規則」だったのか。

答えは簡単で、前者後者ともに「パスの規則」でルールを作成すると、プログラムの実行を「拒否する」 ほうが優先されるからです (参考： Software Restriction Policies — Rule ordering (英語))。

ルールを判定する順番はどうなのかというと、以下の通りになります。

1. ファイルがデジタル署名されていて、証明書が明示的に許可されていない場合は、ブロック。
2. ファイルがデジタル署名されていて、証明書が明示的に許可されている場合は、実行。
3. ファイルハッシュが明示的に禁止されている場合は、ブロック。
4. ファイルハッシュが明示的に許可されている場合は、実行。
5. MSIパッケージが明示的に許可されていないネットワークゾーンから起動された場合は、インストールがブロック。
6. MSIパッケージが明示的に許可されたネットワークゾーンから起動された倍は、インストールが実行。
7. 最後にパスのルールが処理。

パスのルールについては、複数のパスのルールが競合する場合があるのですが、要は実行しようとするファイルの絶対パスに最も近いものが優先されます。

原則拒否が優先され、許可 (制限なし) はその後になるため、まったく同じパスのルールが存在している場合は、拒否がある場合はプログラムの実行がブロックされます。

 

まとめ

本来であれば、AppLocker を利用した、「アプリケーションの制限のポリシー」を使用できればいいんですが、それは叶わず今回のような流れとなりました。

ただ、暗黙の了解 (？) が多すぎて Active Directory 初心者にはとてもハードルが高いな、とも感じました。

色々設定値を試しているうちに、どんどん沼の深みにハマってしまうような感覚といえばいいのでしょうか。Windows の、特にグループポリシー周りではそういったことがよくありますね。Microsoft のドキュメントも大概わかりにくく書いてますしね。

でも結局最終的には動いたのでよかったですが・・

そもそもなんで、AppLocker が動かないのかが気になります。今後の課題としたいと思います。