🖥️

【Proxmox VE実践編】UbuntuをActive Directoryドメインに参加させる方法

に公開
初心者
Proxmox
自宅サーバ
ファイル共有
ドメイン参加
tech

【Proxmox VE実践編】UbuntuをActive Directoryドメインに参加させる方法

前回の記事では、Windows ServerでActive Directoryドメイン環境を構築しました。
https://zenn.dev/koikoi_infra/articles/04a50731a0f456
今回はそのADを拡張し、Ubuntu Serverをドメインに参加させることで、WindowsとLinuxが共存する、より実践的なハイブリッド環境を構築します。

1. Phase 1：Ubuntu側の準備（DNSとNTP）

ubuntu-server-01がActive Directoryドメインに参加するためには、まず「ドメインはどこにあるのか？」を見つけられるようにし、「ドメインと同じ時間を刻む」必要があります。ここからの作業は、SSHでUbuntu Server (ubuntu-server-01)に接続して行います。

なぜDNSとNTPの設定が必要なのか？

  • DNS (住所録): ドメインに参加するということは、「koikoi_infra.local市の市役所（ドメインコントローラー）はどこですか？」と尋ね、登録手続きをすることです。そのためには、市役所の場所を知っている正しい住所録（DNSサーバー） を参照する必要があります。
  • NTP (時計): Active Directoryの認証（本人確認）は、Kerberosという非常に厳格な仕組みを使います。この仕組みは、不正アクセスを防ぐために「認証チケット」にタイムスタンプを利用するため、サーバーとクライアントの時計が5分以上ずれていると、認証を拒否してしまいます。そのため、ドメイン内のすべてのコンピューターは、同じ時計（NTPサーバー）に合わせる必要があります。

Step 1: DNS設定の変更

Ubuntuサーバーに、名前解決はドメインコントローラー（ws01）に聞きに行くように教えます。sudo nano /etc/systemd/resolved.confコマンドで設定ファイルを開き、以下のようにDCのIPアドレスとドメイン名を指定します。

[Resolve]
DNS=192.168.3.102
Domains=koikoi_infra.local

設定後、sudo systemctl restart systemd-resolvedでサービスを再起動します。

Step 2: 時刻同期（NTP）の設定

sudo apt install chrony -yで時刻同期ツールをインストール後、sudo nano /etc/chrony/chrony.confで設定ファイルを開き、時刻同期の基準をドメインコントローラーに設定します。

server 192.168.3.102 iburst

sudo systemctl restart chronyでサービスを再起動し、chronyc sourcesで同期状況を確認します。

2. Phase 2：ドメイン参加と統合認証

いよいよ、Ubuntuサーバーをkoikoi_infra.localドメインに参加させます。

ドメイン参加とはそもそも何か？

コンピューターがドメインに参加するとは、そのコンピューターがドメインコントローラーとの間に信頼関係を確立することです。これにより、そのコンピューターはドメインのメンバーとして正式に登録され、Active Directoryのユーザーアカウントでログインしたり、グループポリシーを受け取ったりできるようになります。

Step 3: 必要パッケージのインストールとKerberos設定

Active Directoryとの連携に必要なソフトウェア群をインストールします。

sudo apt install -y realmd sssd sssd-tools libnss-sss libpam-sss adcli krb5-user
  • Kerberos: Active Directoryで使われる、非常に強力な認証プロトコル（本人確認のルール） です。krb5-userは、Ubuntuがそのルールで会話できるようにするためのツールです。
  • SSSD (System Security Services Daemon): LinuxがActive Directoryのような外部の認証サーバーと連携するための仲介役サービスです。ユーザー情報のキャッシュや、オフラインでのログインも可能にする高機能なデーモンです。

krb5-userのインストール中に表示される対話画面で、レルム（KOIKOI_INFRA.LOCAL）やサーバー名（ws01.koikoi_infra.local）を正しく入力します。

Step 4: ドメインへの参加

realmコマンドを使い、Ubuntuサーバーをドメインに参加させます。

sudo realm join --user=Administrator koikoi_infra.local

Step 5: SSSDの最適化とsudo権限の付与

ドメインユーザーでのログインを快適にし、管理者権限を与えます。
sudo nano /etc/sssd/sssd.confで設定ファイルを編集します。

補足：sssd.confの各設定の意味
  • use_fully_qualified_names = False: ログイン名をadm-labuserのように短縮できるようにします。（設定しないとadm-labuser@koikoi_infra.localと毎回入力する必要がある）
  • fallback_homedir = /home/%u: ドメインユーザーが初めてログインした際に、/home/ユーザー名という形式でホームディレクトリを自動作成します。
  • default_shell = /bin/bash: ログイン時の標準シェルをbashに指定します。

sudo visudoコマンドで設定ファイルを開き、ADのセキュリティグループ（例: %IT-Administrators@koikoi_infra.local）に対してsudoの実行権限を付与します。

3. Phase 3：統合ファイル共有

最後に、Windows Server上の共有フォルダに、ADのユーザー認証を使ってUbuntu Serverからアクセスします。

Step 6: Windows側での共有フォルダ作成と権限設定

リモートデスクトップでWindows Server (ws01)に接続し、C:\ShareDataのようなフォルダを作成します。
フォルダのプロパティで、**「共有」と「セキュリティ」**の2つのタブを使ってアクセス権を設定します。

  • 「共有」タブでは、「詳細な共有」から共有アクセス許可を設定します。ここではEveryoneに「フルコントロール」を与え、実際の制御は次のNTFSに任せます。
  • 「セキュリティ」タブで、NTFSアクセス許可を設定します。まず「詳細設定」から**「継承の無効化」**をクリックします。
補足：なぜ「継承の無効化」が必要か？

Windowsのフォルダは、デフォルトで親フォルダのアクセス許可設定（C:ドライブの設定など）を自動的に引き継ぎ（継承し）ます。ShareDataフォルダに独自の厳密な権限を設定したい場合、この継承を無効化して、意図しないユーザー（例: Usersグループ）からのアクセス許可を一度リセットする必要があります。これにより、これから設定するADグループの権限だけが、このフォルダの唯一のルールとなります。

継承を無効化したら、Usersなどの不要なアクセス許可を削除し、「追加」ボタンからADのグループ（例: IT-Administrators）に対してフルコントロールなどの細かい権限を設定します。

Step 7: Ubuntu側でのアクセスとマウント

補足：共有フォルダのマウントとは？

マウントとは、ネットワーク上にあるリモートの共有フォルダを、あたかもローカルのディレクトリの一部であるかのようにOSに認識させる操作です。//ws01/ShareDataというネットワーク上の場所を、Linuxの/mnt/sharedataというローカルの場所に「接続」することで、普通のフォルダとしてファイルにアクセスできるようになります。

SSHでUbuntu Serverに接続し、sudo apt install -y cifs-utilsで接続ツールをインストールします。
サーバーを再起動しても自動で接続されるように、/etc/fstabファイルを編集して永続的なマウントを設定します。

sudo nano /etc/fstab

ファイルの一番最後に、以下の行を追記します。

//ws01.koikoi_infra.local/ShareData /mnt/sharedata cifs _netdev,vers=3.0,sec=krb5,multiuser 0 0
fstabの各項目の意味
  • //ws01.koikoi_infra.local/ShareData: 接続先の共有フォルダ（UNCパス）です。
  • /mnt/sharedata: 接続するローカルの場所（マウントポイント）です。
  • cifs: ファイルシステムの種類（Windows共有）を指定します。
  • _netdev: ネットワークが利用可能になってからマウント処理を開始します。
  • vers=3.0: より安全で高機能なSMBプロトコルバージョン3.0を指定します。
  • sec=krb5: 認証方式に、パスワードを使わない安全なKerberos認証を指定します。
  • multiuser: **（最重要）**これにより、アクセスするユーザー個人の資格情報（Kerberosチケット）で認証が行われ、Windowsサーバー側で設定したアクセス権が正しく適用されるようになります。
  • 0 0: バックアップ(dump)と起動時のチェック(fsck)に関する設定です（通常はこの値で問題ありません）。

sudo mount -aコマンドでマウントを実行し、ls -la /mnt/sharedataなどで中身が見えることを確認します。

Step 8: AD認証によるアクセス制御の最終確認

これまでの設定が正しく機能しているか、いよいよ最終確認です。ADユーザーでログインし、Windows側で設定したアクセス権が正しく反映されているかをテストします。

Kerberos認証：sshとsuでの挙動の違い

fstabで設定したsec=krb5は、「Kerberos認証」で本人確認を行うという宣言です。この認証には「チケット」と呼ばれる一時的な身分証明書が必要ですが、その取得方法はログインの仕方によって異なります。

  • sshでの直接ログイン（推奨）:
    ドメインユーザーで直接SSH接続すると、ログインと同時にKerberosチケットが自動的に発行されます。そのため、ユーザーは特に意識することなく共有フォルダにアクセスできます。

  • suでのユーザー切り替え:
    ローカルユーザーからsuコマンドで切り替えた場合、Kerberosチケットは自動発行されません。そのため、kinitコマンドを使って手動でチケットを取得する必要があります。

【実践】アクセス許可・拒否テスト

権限を持つユーザー(adm-labuser)と、持たないユーザー(it-user01)の両方でテストします。

  1. アクセスが許可されるケースの確認 (adm-labuser)
    クライアントPCから、adm-labuserで直接Ubuntu ServerにSSH接続します。
ssh adm-labuser@ubuntu-server-01.koikoi_infra.local

Adminフォルダにファイルを作成してみましょう。問題なく成功するはずです。

touch /mnt/sharedata/Admin/test_by_adm.txt
echo "OK" # -> エラーが出なければ成功
  1. アクセスが拒否されるケースの確認 (it-user01)
    次に、Adminフォルダへの書き込み権限を持たないit-user01でテストします。
ssh it-user01@ubuntu-server-01.koikoi_infra.local

同じようにAdminフォルダにファイルを作成しようとすると、今度は正しくエラーになるはずです。

touch /mnt/sharedata/Admin/test_by_ituser.txt
# => touch: cannot touch '...': Permission denied

この「Permission denied」というエラーは、設定ミスではなく、意図した通りのアクセス制御が成功している証拠です。

  1. suコマンド利用時の注意点とkinitの実行
    最後に、ローカルユーザーからsuコマンドでadm-labuserに切り替えて、共有フォルダへのアクセスを試してみましょう。
# 例えばローカルユーザーlabuserでログインしているセッションから切り替える
su - adm-labuser

この状態でファイルを作成しようとすると、sshで直接ログインした場合とは異なり、権限エラーが発生します。これはsuコマンドではKerberosチケットが自動取得されないためです。

touch /mnt/sharedata/Admin/test_by_su_fail.txt
# => touch: cannot touch '...': Permission denied

この問題を解決するには、kinitコマンドを手動で実行し、Kerberosチケットを取得します。

# kinitコマンドで認証チケットを要求
kinit
# => adm-labuserのパスワードを入力

# チケットが取得できたか確認
klist

# 再度ファイル作成を試す
touch /mnt/sharedata/Admin/test_by_su_success.txt
echo "OK" # -> 今度は成功するはず

この挙動から、suコマンドでADユーザ―に切り替えた場合は、共有フォルダへアクセスする前にkinitの実行が必要であることがわかります。

まとめ

これで、認証もファイルアクセスも統合された、本格的なハイブリッド環境が完成しました。これは、実際の企業システムで広く使われている、非常に価値の高い技術です。

Discussion