LinuxをActive Directoryに参加させる：SSSDとRealmdによる実践ガイド

Table of Contents

サーバーごとの個別アカウント管理を卒業する

50台以上のLinuxサーバーでローカルユーザーアカウントを手動で管理するのは、最悪な週末への入り口です。それは退屈で、かつセキュリティ上も好ましくありません。すでにWindows環境を運用しているなら、Active Directory（AD）ドメインはLinuxのアイデンティティを一元化するのに最適な場所です。このガイドを読み終える頃には、ADの資格情報を使用してLinuxマシンにログインできるようになります。また、グループベースのアクセス制限やsudo権限の管理も、ドメインコントローラーから直接行えるようになります。

クイックスタート（5分）

まずはクリーンな状態から始めることをお勧めします。コマンドを入力する前に、Linuxサーバーがポート389（LDAP）、445（SMB）、88（Kerberos）経由でドメインコントローラー（DC）に到達できることを確認してください。また、DNS設定はADのDNSサーバーを指している必要があります。これが最も多い失敗の原因です。

1. 必要なパッケージのインストール

まず、実際の処理を担うツールをインストールします。ドメインの検出にはrealmdを、認証 and キャッシュの処理にはsssdを使用します。

sudo apt update
sudo apt install -y realmd sssd sssd-tools libnss-sss libpam-sss adcli samba-common-bin packagekit krb5-user

krb5-userのインストール中に、デフォルトのKerberosレルム（realm）の入力を求められます。ドメイン名をすべて大文字で入力してください（例：EXAMPLE.COM）。Kerberosは大文字と小文字を厳密に区別するため注意が必要です。

2. ドメインの検出と参加

サーバーが実際にドメインを認識できるか確認します。realm discoverコマンドを使用します。

realm discover example.com

出力内容が正しければ、マシンをドメインに参加させます。コンピューターを参加させる権限を持つADアカウント（サービスアカウントや管理者アカウントなど）の資格情報が必要です。

sudo realm join --user=Administrator example.com

3. 接続の確認

連携を確認します。既存のADユーザーの情報を取得してみましょう。

id [email protected]

舞台裏：SSSDとRealmdの違い

私がrealmdを好む理由は、KerberosやSSSDの複雑な設定を自動化してくれるからです。以前は、管理者がkrb5.confやsmb.confを手動で編集する必要がありました。そこでタイプミスが1つあるだけで、すべてが動かなくなってしまいます。realmdは、これらのサービスの賢いコーディネーターとして機能します。

SSSDの威力

System Security Services Daemon（SSSD）は、この構成を堅牢にします。単にパスワードをチェックするだけでなく、資格情報をキャッシュします。これは、DCへのネットワーク接続が一時的に途切れた場合に非常に役立ちます。接続が復旧するまで、ユーザーはキャッシュされたデータを使用してログインし続けることができます。

4GBのRAMを搭載した本番環境のUbuntu 22.04ノードでは、SSSDは何百もの同時認証リクエストを余裕で処理しています。Winbindのような古い手法よりも大幅に効率的です。

DNS：すべての基盤

DNSの問題は、realm discoverの失敗の原因の99%を占めます。ADはLDAPやKerberosサービスを特定するためにSRVレコードに大きく依存しています。Linuxサーバーは、ADドメインコントローラーをプライマリDNSとして使用する必要があります。次のコマンドでレコードを確認してください。

host -t SRV _kerberos._udp.example.com

SSSDのチューニング

realmdは機能する設定を作成してくれますが、おそらく/etc/sssd/sssd.confを微調整したくなるでしょう。よくある変更は、ユーザー名からドメインサフィックスを削除することです。これにより、長い[email protected]ではなく、単にusernameとしてログインできるようになります。

[sssd]
domains = example.com
config_file_version = 2
services = nss, pam

[domain/example.com]
ad_domain = example.com
krb5_realm = EXAMPLE.COM
realmd_tags = manages-system joined-with-adcli 
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = False
fallback_homedir = /home/%u

変更後はサービスを再起動してください：sudo systemctl restart sssd

高度な制御：Sudoとアクセスグループ

ドメインに参加したら、実際にサーバーにアクセスできるユーザーを制限する必要があります。すべてのドメインユーザーがデータベースサーバーにログインできる状態は望ましくないでしょう。

ログインアクセスの制限

私は通常、まず全員を拒否し、それから特定のADグループを選択的に許可するようにしています。

sudo realm deny --all
sudo realm permit -g "Linux Admins"

このコマンドにより、”Linux Admins”セキュリティグループのメンバーのみがそのマシンにSSH接続できるようになります。

ホームディレクトリの自動作成

ADユーザーが初めてログインするとき、ファイルを保存する場所が必要です。このプロセスを自動化するためにpam_mkhomedirモジュールを有効にします。これにより、新入社員ごとに手動でフォルダーを作成する手間が省けます。

sudo pam-auth-update --enable mkhomedir

Sudo権限の付与

ADグループをroot権限にマッピングできます。設定を綺麗に保つために、/etc/sudoers.d/に専用のファイルを作成します。

sudo nano /etc/sudoers.d/ad-admins

次の行を追加します。ADグループ名に含まれるスペースはバックスラッシュでエスケープする必要があることに注意してください。

%Linux\ Admins ALL=(ALL) ALL

実践的なトラブルシューティングのヒント

LinuxをADに参加させる作業は、常にスムーズにいくとは限りません。現場で学んだヒントをいくつか紹介します。

時刻同期が不可欠： サーバーの時刻がDCから300秒（5分）以上ずれていると、Kerberos認証は失敗します。常にchronyなどを使用してドメインコントローラーと同期させてください。
キャッシュのクリア： ADでユーザーのグループを更新してもLinux側で反映されない場合は、キャッシュをフラッシュしてください：sudo sss_cache -E
ログの確認： 問題が発生したときは、journalctl -u sssdが頼りになります。詳細なデバッグが必要な場合は、sssd.confでdebug_level = 9を設定してください。
ホスト名の一致： ローカルのホスト名は、AD内のコンピューターオブジェクト名と一致している必要があります。参加させる前に、hostnamectl set-hostname myserver.example.comを使用して設定しておきましょう。

アイデンティティをActive Directoryに統合することは、セキュリティ面で非常に大きなメリットがあります。1つのADアカウントを無効にするだけで、Linuxフリート全体のアクセス権が即座に剥奪されるのは、管理上の大きな安心感に繋がります。