Ubuntu 20.04.2 LTS以降ではadsysというツールが提供されており、UbuntuマシンのActive Directory（以下、AD）ドメインへの統合が強化されています。このadsysについて、実例も交えながら複数回に分けて紹介します。

今回は、adsysが解決したい課題とその前提となるADについて簡単にまとめ、AD側の設定までおこないます。

adsysが解決しようとしている課題

adsys自体の紹介に入る前に、本稿に関わる部分に関して簡単にADの基礎[1]を押さえながら、adsysが解決しようとしている課題が何かを説明します。

ADは、組織内にあるコンピューターやユーザーの情報・パスワードといったものを一元的に管理し、認証するための仕組みです。一般的には、数多くの人やコンピューターなどのリソースを管理する必要がある、それなりに規模のある会社や組織で導入されるものでしょう。そのため、読者の皆様の中にもAD自体の利用経験があるかもしれません。

ADにはその論理モデルに示される通り、階層構造があります。規模が大きい順に「フォレスト」「⁠ドメイン」「⁠組織単位（以下OU⁠）⁠」という階層です。この中でも中心になる階層はドメインで、ユーザーやコンピューターといったリソースはドメインに参加し、認証されます。

ドメイン内部を管理する上でリソースのグループ分けが必要となったときにはOUを使います。OUはさらに入れ子構造にもできます。OUに関してはのちに具体的な動作例を示す予定です。

1つ以上のドメインをまとめたものがフォレストですが、adsysの文脈では関係しないため、いったん忘れていただいて構いません[2]。「⁠adsysはドメイン全体やOUと関連して動作する」と覚えておいてください。

会社組織でイメージする場合、一般的にはドメインが「会社全体」に、OUが「部署」に対応するといった形になるでしょう。

このドメインを提供するのがActive Directoryディレクトリサービス（以下、ADDS）で、これはWindows Serverの機能です。ただ、ADDSはLDAP、Kerberos、DNSといったオープン系の要素を統合・実装したものといえ、これら1つ1つの要素はWindows環境以外でも利用できる一般的なものです。そのためこれまでも、一定の「お作法（AD的な手続き⁠）⁠」を守れば、WindowsマシンでなくてもADのドメインに参加することはできるといえる状態でした。実際、adsysを使わなくてもUbuntuマシンをドメインに参加させること自体は可能です[3]。

しかしながら、adsysを使わずにUbuntuマシンがドメインに参加できるからといって、そのマシンを使うユーザーやUbuntuマシンの管理が（Windowsマシンを管理するときと同じようなスキームで）できるかといわれたら答えはノーに近い状態でした。

AD環境には、ドメインやOUに所属するユーザーやコンピューターの設定をADから一元的に管理し、それらに適用するためのグループポリシーとそれを含むグループポリシーオブジェクト（以下、GPO）という機能・仕組みがあります。ADはWindows Serverの機能ですので、このあと具体的にお見せしますようにWindowsマシンに対する管理用テンプレートはデフォルトで用意されています。また、ドメインに参加するWindowsクライアントOS側にもそのGPOを適切に適用するための仕組みがあります。

一方、Ubuntuを含むLinuxマシンに適用できる管理用テンプレートはAD側でデフォルトで用意されておらず、Linuxマシン側にもGPOを適用するための（メジャーな）仕組みがありませんでした。そのため、adsys登場以前はUbuntuマシンがドメインに参加してできることはユーザーの認証（もっとも、これ自体は大きなメリットです）とその認証に関するGPOの適用くらいでした[4]。

このような状況を改善することが今回紹介するadsysの目的です。具体的には、

1. ADドメインで使うためのLinuxマシン用のグループポリシー管理用テンプレート（とその付随コンポーネント）
2. ユーザーやマシンに適用されたGPOを実現するためにLinuxクライアント側で動作するための仕組み・ソフトウェア

の2つを提供することで、LinuxマシンでもGPOを利用できるようにすることを目指しています。

GPOとは

adsysはLinuxマシンでもGPOを使えるようにする仕組みであると述べました。ここではGPOについて確認しておきます。

先ほど簡単に触れましたがGPOはユーザーやコンピューターに適用されるグループポリシーを含む、コレクションと定義されています。グループポリシーにはコンピューターに対して適用するもの（グループポリシー管理エディター上の表記では「コンピューターの構成⁠」⁠）と、ユーザーに対して適用するもの（同「ユーザーの構成⁠」⁠）の2つがあります。

次のスクリーンショットからわかるように、Windowsマシンに対してグループポリシーで設定可能な項目は非常に多岐にわたります。

管理テンプレートを見てみると、Windows Updateの挙動というWindows OSの重要コンポーネントの動作から、「⁠バッテリ使用時に電源ボタンを押したら、スリープするのか、シャットダウンするのか、休止状態にするのか、はたまた何もしないのか」といった細かいものまで設定できます。このスクリーンショットで見えている設定項目はごく一部で、まず、何がどこにあるのかを把握することからして困難です[5]。

そうしてポリシーを構成したGPOは、ドメイン全体やそのOUごとに「リンク」します。これにより、そのグループポリシーを適用する範囲を指定します。ちなみに、GPOの処理には順番があり、あとに適用されるGPOのポリシーが優先されます。例えば、ドメインにリンクされたGPOのあとにOUにリンクされたGPOが適用されるため、この2つのGPOで異なる設定値を持つポリシーがあった場合、基本的にはOUにリンクされたGPO側の内容が適用されます[6]。

このような「コンピューターの構成」「⁠ユーザーの構成」や「GPOを適用する範囲」を使い分けることで、ドメイン内のユーザーやコンピューターを細かく管理・制御できるようになります。会社を例にすると具体的には次のようなことが可能になります。

• 「開発部」というOUと「営業部」というOUとに、それぞれ異なるGPOをリンクすることで、「⁠開発部」のメンバーと「営業部」のメンバーとに異なるユーザーポリシーを設定する。
• デスクトップPCとノートPCとでコンピューターオブジェクトの所属するOUを分けることで、マシンの特性に合わせたポリシー（例：電源管理ポリシー）を設定する。

ADへのGPOテンプレートの配置

adsysの展開はAD側とUbuntuマシン側の両方の作業が必要です。今回はAD側の設定をおこないます。

Ubuntuマシンにグループポリシー適用するにはグループポリシー管理用テンプレートが必要なため、これをドメインに追加します。

なお、今回はドメインコントローラー（ドメイン機能を提供するサーバー）にはWindows Server 2022 Standard[7]を使用し、example.comというドメインをすでに作成している状態を前提とします。

グループポリシー管理用テンプレートはセントラルストアを作成することで管理できます。セントラルストアはドメインコントローラー間で共有する設定ファイルが置かれるSYSVOLフォルダに配置します。今回のドメインexample.comの場合、セントラルストアのパスは\\example.com\SYSVOL\example.com\policies\PolicyDefinitionsとなります。ちなみに、ドメインを展開したデフォルト状態ではパスの最後にあるPolicyDefinitionsフォルダは存在しませんのでエクスプローラーで\\example.com\SYSVOL\example.com\policies\を開き、手動で作成します[8]。

セントラルストアを用意できたところで、次はUbuntuマシン向けの管理用テンプレートを入手・配置する必要があります。

Ubuntuマシン用のテンプレートにはlts-onlyとallの2種類あります。lts-onlyは文字通りUbuntuのLTS版（記事執筆時点でUbuntu 24.04, 22.04, 20.04）にのみ対応したテンプレートです。これに対し、allはadsysでサポートされているすべてのリリース（記事執筆時点でlts-onlyのリリースにUbuntu 23.10が加わります）向けのテンプレートです。今回はlts-only版のテンプレートを使用することにします。

続いて、管理用テンプレート（ポリシー定義ファイル）の入手方法ですが、次の3つがあります。

1. Ubuntuマシンでadsysctl policy admx lts-onlyコマンドを実行し生成する
2. https://github.com/ubuntu/adsys/tree/main/policies/Ubuntu/lts-onlyからダウンロードする
3. adsys-windowsパッケージから入手する

今後の流れの兼ね合いもあり、今回は3の方法を採ることにします。次はUbuntu 24.04 LTSでのコマンド実行例です。

$ sudo apt install -y adsys-windows
$ dpkg -L adsys-windows
/.
/usr
/usr/share
/usr/share/adsys
/usr/share/adsys/windows
/usr/share/adsys/windows/adwatchd.exe
/usr/share/adsys/windows/policies
/usr/share/adsys/windows/policies/all
/usr/share/adsys/windows/policies/all/Ubuntu.adml
/usr/share/adsys/windows/policies/all/Ubuntu.admx
/usr/share/adsys/windows/policies/lts-only
/usr/share/adsys/windows/policies/lts-only/Ubuntu.adml
/usr/share/adsys/windows/policies/lts-only/Ubuntu.admx
/usr/share/doc
/usr/share/doc/adsys-windows
/usr/share/doc/adsys-windows/changelog.gz
/usr/share/doc/adsys-windows/copyright

このうち目的のテンプレートは/usr/share/adsys/windows/policies/lts-only/Ubuntu.admxと/usr/share/adsys/windows/policies/lts-only/Ubuntu.admlです。Ubuntu.admxファイルは\\example.com\SYSVOL\example.com\policies\PolicyDefinitionsに配置し、Ubuntu.admlファイルは\\example.com\sysvol\example.com\Policies\PolicyDefinitions\en-USに配置します。フォルダパスからお気づきかもしれませんが、.admxファイルはポリシーの構造といったWindows OSの使用言語によらないものを定義し、.admlファイルは各ポリシーの選択肢や説明といったものをOSで使用されている言語で表示するためのファイルです。

セントラルストアを作成し、Ubuntu.admxファイルとUbuntu.admlファイルを適切に配置すると「グループ ポリシー管理エディター」の表示が次のように変わります。

このようにセントラルストアに配置したポリシー定義ファイルが読み込まれ、Ubuntu用のポリシーが設定できるようになったことがわかります。

これでドメインコントローラーにUbuntu用のグループポリシー管理用テンプレートを展開できました。次回はUbuntuマシン上の作業に移ります。