realmdとSSSDを使用してFedora ServerをMicrosoft Active Directoryに参加させる方法 - ITFROMZERO - Share tobe shared! realmdとSSSDを使用してFedora ServerをMicrosoft Active Directoryに統合するための詳細なステップバイステップガイド。各ソリューションのメリット・デメリット比較、ホームディレクトリの自動作成、ADグループへのsudo権限の付与、オフライン認証のテストまで網羅しています。

Table of Contents

LinuxをActive Directoryに統合するソリューションの比較

数十台にも及ぶ個別のLinuxサーバー上でローカルアカウントを管理していると、権限の削除漏れが発生しやすくなります。従業員の退職時に各サーバーへ個別にログインしてローカルアカウントを削除するのは、時間がかかるだけでなく、重大なセキュリティリスクを伴います。既存のActive Directory (AD) インフラストラクチャを活用してID管理を一元化することが、最も合理的な解決策です。

Fedora ServerをWindowsドメインに接続する際、管理者は通常次の3つの選択肢を検討します。

Winbind (Sambaスタック) の使用: Sambaに深く関連する従来の手法です。WinbindはMSRPCおよびNTLMを介してDomain Controller (DC) と通信するため、CIFS/SMBプロトコルによるファイル共有が必須のサーバーに最適です。
OpenLDAP + Kerberos (krb5) + PAMの手動統合: 各コンポーネントを手動で構築します。Kerberosが本人認証 (authentication) を担当し、LDAPがユーザー/グループ一覧の照会 (authorization) を行い、これらをPAMおよびNSSを介してLinuxに統合します。
realmdとSSSD (System Security Services Daemon) の組み合わせ: Red Hatによって標準化された最新のソリューションです。realmdツールがドメインの検出から参加までのプロセス全体を自動化します。バックグラウンドではsssdデーモンがセッションの維持、ID情報の照会、およびローカルキャッシュの作成を担います。

各方式のメリット・デメリット

1. Winbind

メリット: 複雑なSambaファイル共有や、NTLMv2を使用するレガシーシステムとの互換性に非常に優れています。

デメリット: 設定ファイルsmb.confが肥大化し複雑になります。ドメイン内のオブジェクトが10,000個を超えると、Winbind経由でのユーザー名前解決速度が著しく低下することがよくあります。

2. OpenLDAPとKerberosの手動設定

メリット: 固有の要件に合わせて、スキーマ属性ごとに詳細な制御が可能です。

デメリット: 設定ミスのリスクが非常に高くなります。/etc/krb5.confや/etc/nsswitch.conf、/etc/pam.d/ディレクトリ配下の多数のファイルを編集する必要があります。PAMの構文を1つ間違えただけで、サーバーへのすべてのSSH接続が即座にロックアウトされる恐れがあります。

3. realmdとSSSDの組み合わせ

メリット: 手順が極めてシンプルです。コマンドを1つ実行するだけでドメイン参加が完了します。KerberosおよびSSSDの設定ファイルがすべて自動的かつ正確に生成されます。最も重要な点として、SSSDは優れたオフラインキャッシュ機能を備えています。Domain Controllerへのネットワーク接続が切断された場合でも、通常どおりドメインアカウントでログインを継続できます。

デメリット: 内部DNSシステム、特にDomain Controllerを指すSRVレコードに完全に依存します。

Fedora ServerにrealmdとSSSDが最適な理由

FedoraはRed Hat Enterprise Linux (RHEL) の直接のアップストリームとして機能します。そのため、authselectやsssdといったコアID管理ツールはこのディストリビューションに深く統合され、入念にテストされています。realmd経由でドメインに参加すると、システムのPAMプロファイルはデフォルトのSELinuxポリシーと競合することなくauthselectによって自動更新されます。

FedoraをCI/CDランナー、ステージング環境、社内データベースのいずれとして運用する場合でも、realmd + SSSDの組み合わせは最も安定し、安全で、メンテナンスの手間が少ない選択肢です。

Fedora ServerをActive Directoryに参加させる手順

ステップ1: DNSと時刻同期 (NTP) の設定

KerberosはActive Directoryの主要な認証プロトコルです。このプロトコルでは、Fedora ServerとDomain Controller間の時刻のずれが300秒（5分）以内でなければなりません。この許容範囲を超えると、Kerberosチケットの発行に失敗します。

まず、サーバーが正しい内部DNSを参照し、ドメイン（例: corp.local）のSRVレコードを解決できるか確認します。

# 使用中のDNSサーバーを確認
resolvectl status

# LDAPおよびKerberosのSRVレコードを照会
host -t srv _ldap._tcp.corp.local
host -t srv _kerberos._tcp.corp.local

次に、chronydによる時刻同期を有効にします。

# NTPプロトコルによる時刻同期を有効化
sudo timedatectl set-ntp true

# 同期ステータスを確認
timedatectl status

ステップ2: 必要なパッケージのインストール

Fedoraの公式リポジトリに必要なすべてのパッケージが揃っています。次のコマンドを実行してインストールします。

sudo dnf install -y realmd sssd oddjob oddjob-mkhomedir adcli samba-common-tools krb5-workstation

主要パッケージの役割:

realmd: ドメインの検出と参加処理を調整・実行します。
sssd: 認証、キャッシュ管理、PAM/NSSとの通信を担当するデーモンです。
oddjob-mkhomedir: ADユーザーの初回ログイン時に/home/usernameディレクトリを自動生成します。
adcli: Active Directoryに対する直接の管理操作を実行する低レベルライブラリです。

ステップ3: ドメインの検出と参加

接続前に、次のコマンドを実行してサーバーがADを認識できるかテストします。

sudo realm discover corp.local

出力結果にドメイン名、レルム名、必要なパッケージ情報が詳細に表示されます。問題なく情報が表示されたら、ドメインに参加します。

sudo realm join -U Administrator corp.local

組織の管理構造に従ってサーバーを特定の組織単位 (OU) に配置したい場合は、追加パラメータを指定できます。

sudo realm join -U Administrator corp.local --computer-ou="OU=Linux Servers,DC=corp,DC=local"

プロンプトが表示されたら、ドメイン管理者アカウントのパスワードを入力します。警告なしでコマンドが終了すれば、サーバーはActive Directory内にコンピューターオブジェクトとして正常に登録されています。

ステップ4: ホームディレクトリの自動生成を有効化

ADユーザーがSSHで初回ログインする際、個人プロファイルを保存するための専用ディレクトリが必要です。Fedoraでは、authselectを使用してこのモジュールを安全に有効化します。

# sssdプロファイルでmkhomedir機能を有効化
sudo authselect select sssd with-mkhomedir --force

# システム起動時にoddjobdサービスが動作するよう有効化して起動
sudo systemctl enable --now oddjobd.service

ステップ5: sssd.confの最適化とsudo権限の割り当て

デフォルトでは、ログイン時に[email protected]のようにフルネームを入力する必要があります。これを短縮してuserだけでログインできるようにするには、SSSDの設定ファイルを編集します。

sudo nano /etc/sssd/sssd.conf

[domain/corp.local]セクション内の次の2つのパラメータを調整します。

# 短縮ユーザー名でのログインを許可
use_fully_qualified_names = False

# 一貫性のあるホームディレクトリのパスを指定
fallback_homedir = /home/%u

SSSDは、設定ファイルのパーミッションが緩い場合、起動を拒否します。適切なパーミッションを設定し、サービスを再起動します。

sudo chmod 600 /etc/sssd/sssd.conf
sudo systemctl restart sssd

次に、AD内の特定のグループ（例: Linux Adminsグループ）にsudo管理者権限を付与します。メインの/etc/sudoersファイルを直接変更するのではなく、/etc/sudoers.d/配下に個別ファイルを作成します。

sudo visudo -f /etc/sudoers.d/domain_admins

以下の行を追加します（グループ名に含まれるスペースはバックスラッシュ\でエスケープします）。

%Linux\ Admins ALL=(ALL) ALL

作成したsudo設定ファイルの構文を検証します。

sudo visudo -c -f /etc/sudoers.d/domain_admins
sudo chmod 440 /etc/sudoers.d/domain_admins

ステップ6: 認証の確認とオフラインキャッシュのテスト

Active Directoryからアカウント情報が正しく取得できているか確認します。

id devops_user

このコマンドにより、UID、GID、およびユーザーが所属するADグループの全リストが返されます。

次に、確認したドメインアカウントを使用してサーバーへSSH接続してみます。

ssh devops_user@<IP_FEDORA_SERVER>

初回アクセス時にはCreating directory '/home/devops_user'.というメッセージが表示されます。続けてsudo -iを実行し、root権限がスムーズに利用できることを確認します。

オフラインキャッシュ機能をテストするには、ファイアウォールを使用してDomain ControllerへのLDAP通信ポートを一時的に遮断します。

sudo iptables -A OUTPUT -p tcp --dport 389 -j DROP

ドメインアカウントで新しいSSHセッションを開いてみます。認証情報は/var/lib/sss/db/配下のSSSDデータベースにキャッシュされているため、問題なくログインが成功します。テスト完了後は、作成したファイアウォールの遮断ルールを必ず削除してください。