SSSDでLinuxをActive Directoryに統合する｜オフライン認証と権限管理の設定確認手順

LinuxとActive Directory統合が現場で選ばれる理由

企業環境でLinuxサーバーを運用する場合、認証基盤をWindows Active Directory（AD）に統合する構成は今や標準的な選択肢になっています。管理者アカウントの個別管理をやめ、AD上のユーザー・グループをそのままLinuxログインに使える状態にすることで、アカウントのライフサイクル管理や監査ログの一元化が実現します。

この統合を担うコンポーネントが SSSD（System Security Services Daemon） です。かつてはWindows統合に winbind が多く使われてきましたが、現在のRHEL 9・Ubuntu 22.04以降のディストリビューションでは、realmd と SSSD の組み合わせが推奨構成として前面に出ています。sssdはKerberosチケットのキャッシュやオフライン認証にも対応しており、ネットワーク断時の業務継続という観点でも優れています。

本記事では、ゼロから AD 統合を行う際の手順を「目的ベース」で整理し、特にオフライン認証の設定確認と sudo 権限管理の実装まで一通り完結させます。

事前準備：前提条件とパッケージの確認

作業を始める前に、以下の点を確認しておく必要があります。

• Linuxサーバーと ADドメインコントローラー間でDNSが正しく解決できること（nslookup で ADのSRVレコードが引ける状態）
• NTPによる時刻同期が済んでいること（Kerberos認証は5分以内の時刻差を要求する）
• AD上にドメイン参加用アカウントが準備されていること
• Linux側のホスト名がFQDNで設定されていること（hostnamectl set-hostname で確認・設定）

パッケージのインストールは、ディストリビューションによって次のように異なります。RHEL 9系（Rocky Linux 9・AlmaLinux 9を含む）では以下を実行します。

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

Ubuntu 22.04・24.04 では次のコマンドになります。

sudo apt install -y realmd sssd sssd-tools libnss-sss libpam-sss adcli packagekit

realmd はドメイン探索とSSSD設定ファイルの自動生成を担う補助ツールです。手動で sssd.conf を一から書くことも可能ですが、realmd を経由すると初期設定の抜け漏れが防ぎやすくなります。

ドメイン参加とSSSD設定ファイルの確認

ドメイン探索が成功することをまず確認します。

realm discover example.com

ドメイン情報とKerberosレルムが表示されれば、DNSとネットワーク疎通は問題ありません。続いてドメイン参加を実行します。

sudo realm join --user=domain_admin example.com

参加が成功すると、/etc/sssd/sssd.conf が自動生成されます。このファイルの権限は 0600・所有者 root でなければSSSDが起動しないため、手動編集後は必ずパーミッションを確認してください。

自動生成された sssd.conf のうち、運用上特に注意が必要な設定項目を確認します。

[domain/example.com]
ad_domain = example.com
krb5_realm = EXAMPLE.COM
realmd_tags = manages-system joined-with-adcli
cache_credentials = true          ← オフライン認証に必須
id_provider = ad
access_provider = ad
auth_provider = krb5
krb5_store_password_if_offline = true   ← オフライン時にもPW認証を許可
default_shell = /bin/bash
use_fully_qualified_names = False ← ドメイン名省略ログインを許可する場合

cache_credentials = true と krb5_store_password_if_offline = true はオフライン認証の核心です。前者はKerberosチケット取得後に認証情報をローカルキャッシュへ保存し、後者はパスワード認証もオフライン時に通すよう設定します。ネットワークが断絶した環境での緊急ログインが必要な運用現場では、この2行の設定漏れが問題になるケースが多く報告されています。

use_fully_qualified_names = False にした場合、同名ユーザーが複数ドメインに存在するマルチドメイン環境では競合が発生しうるため、シングルドメイン環境に限定して使用するのが安全です。

オフライン認証の動作検証手順

設定後、実際にオフライン認証が機能しているかを確認する手順を以下に示します。

まずオンライン状態でADユーザーとして一度ログインし、認証情報をキャッシュに入れます。その後、ネットワークインターフェースを意図的に無効化してオフライン状態をシミュレートします。

# ネットワーク切断（テスト環境のみで実施）
sudo ip link set eth0 down

# SSSDのオフライン状態を確認
sudo sssctl domain-status example.com

Online status: Offline と表示された状態でSSHログインを試みて認証が通ることを確認します。キャッシュのTTLは sssd.conf の offline_credentials_expiration で制御でき、デフォルトは0（無期限）です。セキュリティポリシーに応じて日数を設定することを推奨します。

キャッシュの状態確認には sssctl コマンドが便利です。

# ユーザー情報の解決確認
id aduser@example.com

# SSSDキャッシュのユーザー一覧
sudo sssctl user-show aduser

# キャッシュ全体の状態確認
sudo sssctl cache-expire -u aduser

認証が通らない場合は、/var/log/sssd/sssd_example.com.log を確認します。ログレベルは sssd.conf の debug_level を一時的に 7 まで上げることで詳細ログが取得できます。確認後は debug_level をデフォルト（0）に戻すことを忘れずに行ってください。

ADグループによるsudo権限管理の実装

AD統合後の権限管理で最も実用的な構成は、ADのセキュリティグループを使ってsudoを制御することです。特定のADグループに所属しているユーザーだけにsudo権限を与える設定を行います。

方法は2つあります。/etc/sudoers.d/ に直接グループを指定する方法と、SSSDの sudo_provider を使ってAD（またはLDAP/IPA）からsudoルールを取得する方法です。シンプルな構成では前者が管理しやすく、大規模環境では後者が適しています。

前者（sudoersファイルへの直接記述）の例を示します。

# /etc/sudoers.d/ad_sudo_rules として作成（visudo -f で編集を推奨）
%linux_admins@example.com ALL=(ALL) ALL
%linux_operators@example.com ALL=(ALL) /usr/bin/systemctl, /usr/sbin/journalctl

グループ名にスペースが含まれる場合（ADでは珍しくない）は、スペースをアンダースコアまたはバックスラッシュでエスケープする必要があります。use_fully_qualified_names = False の場合はドメイン部分を省略できますが、マルチドメイン構成では明示的にドメイン名を付けることを推奨します。

設定後は sudo の動作を実際に確認します。

# ADユーザーとしてsudo権限を確認
sudo -l -U aduser

# グループ所属の確認
id aduser

ホームディレクトリの自動作成は pam_mkhomedir によって処理されます。RHEL 9 では oddjob-mkhomedir がこれを担います。realm join 時に --home-dir /home/%u オプションを渡すことで、ホームディレクトリのパステンプレートを統一しておくと後の管理が楽になります。

切り戻し手順と2026年環境での注意点

ドメイン参加を解除してローカル認証に戻す場合は、以下の手順で実施します。

sudo realm leave example.com

realm leave を実行すると、sssd.conf のドメイン設定が削除され、SSSDが停止します。/etc/nsswitch.conf のSSSD参照エントリも自動的に削除されるため、完了後にローカルユーザーでのログインが正常に機能することを確認してください。なおAD側にはコンピュータオブジェクトが残るため、AD管理者に削除を依頼するか --remove-computer オプションを使います。

sssd.conf の手動誤編集によりSSSDが起動しなくなった場合は、バックアップから復元してサービスを再起動します。

sudo systemctl restart sssd
sudo systemctl status sssd

2026年時点での現行環境差分として、いくつかの点を整理しておきます。

RHEL 9.4以降では authselect が SSSD プロファイル管理の標準ツールとなっており、authconfig は完全に廃止されています。realm join が自動的に authselect select sssd with-mkhomedir を呼び出すため、通常は手動操作不要ですが、既存環境を移行する際は authselect current で現在のプロファイルを確認してから作業を進めることを推奨します。

Ubuntu 24.04（Noble Numbat）では、sssd パッケージが標準で sssd-ad バックエンドを含むようになり、追加インストールが不要になりました。また同バージョンから systemd-resolved がデフォルトの DNS リゾルバーになっているため、AD の SRV レコード解決に問題が発生する場合は /etc/systemd/resolved.conf の Domains= 行に AD ドメインを追記する対応が有効です。

Kerberos の暗号スイートについては、Windows Server 2025 以降で RC4（ARCFOUR-HMAC）が既定で無効化される方向にあります。Linux 側の /etc/krb5.conf で allow_weak_crypto = false を明示し、AES256-CTS が優先されるよう設定しておくことが、今後の互換性維持の観点から重要です。古い AD 環境との接続でのみ RC4 が必要な場合は、AD 側の設定変更を先行させるのが適切な対処順序です。

SSSD を使った AD 統合は一度稼働すれば安定していますが、AD 側のパスワードポリシー変更・ドメイン構成変更・Kerberos ポリシー改定が Linux 側の認証に予期せず影響するケースがあります。定期的に sssctl domain-status とログ監視を組み合わせ、オフライン状態が長引いていないかを確認する運用フローを組み込んでおくことが、安定した統合環境の維持につながります。