LinuxサーバーをActive Directoryで管理してみる

はじめに

プログデンスの佐藤です。

今回は、自宅ラボで複数のLinuxサーバーとWindowsサーバーを運用していて

• 「このサーバーに作ったユーザーって何だっけ？」
• 「またパスワード管理か...」
  といった悩みが日常茶飯事になってきたため、Active DirectoryでLinux環境も含めて統合認証を実現し、ユーザー/パスワード管理の煩雑さから解放された話をお届けします。

背景・課題

上述の通り、自宅ラボにLinux/Windows混在でサーバーが多く、構築時や運用時のユーザー管理が悩ましくなってきます。
推奨できるやり方ではありませんが、検証用途であると割り切って、パスワードを簡単なものにして使い回すという方法もありますが、
困ったことにそれでもパスワードを忘れます。

もはや課題は別のところにある気もしていますが、Active DirectoryでLinux環境も含めて統合認証を実現できたことを書いていきたいと思います。

今回の環境について

今回の舞台である自宅ラボの環境は以下のようになっています。

LinuxサーバーをActive Directoryに参加させるために、いくつかの技術要素を理解する必要があります。
なお、本記事ではLinuxのディストリビューションにAlmaLinuxを使用しています。

AD(Active Directory)とは

ADはMicrosoftがWindowsサーバーで提供するコンピューター、ユーザー、プリンター、アプリケーション等のリソースを一元的に管理するディレクトリサービス機能です。
そのため、多くの企業では社内でよく利用されています。最近ではリモートワークの普及とも相まって、パブリッククラウドのAzure Active Directoryも利用されていますが、そのオンプレミス版となります。

SSSD(System Security Services Daemon)によるAD参加の仕組み

今回はWinbindは使用せず、SSSDを使用して、直接ADに参加させています。
そのため、AD参加にあたり、下記の要素が存在します。

1. SSSD
2. AD/Kerberos認証

SSSDが担う役割

1. プロトコル変換

LinuxとADではプロトコルが異なるため、以下サービスの間で仲介役としてSSSDが動作します：

• Linux: NSS(Name Service Switch)、PAM(Pluggable Authentication Modules)
• Active Directory: LDAP、Kerberos

2. システムサービスとの連携

Linuxのシステム内部において、NSSやPAMを統合し、システム間の連携を担います：

• NSS: id user01 コマンドでADユーザー情報を表示
• PAM: ログイン時のパスワード認証をADに転送

3. 認証情報の取得とキャッシュ

SSSDは認証した情報のキャッシュも行います：

[初回アクセス時]
Linux → SSSD → Active Directory(LDAP検索)
「user01の情報を教えて」→「UID:10001, GID:10001, ホームディレクトリ:/home/user01」
[2回目以降]  
Linux → SSSD(キャッシュから即座に回答)
「user01の情報を教えて」→「UID:10001, GID:10001...(キャッシュより)」

Kerberos認証の役割

AD環境において、Kerberos認証は認証基盤として動作します。

Kerberos認証の基本的な仕組み

Kerberos認証は「チケット」という概念を使った認証方式で、一度認証を通せば、複数のサービスにパスワードを入力せずにアクセスできる、いわゆる SSO(Single Sign-On) を実現することができます。

Kerberos認証では以下2つの「チケット」を使用して認証を行います：

• TGT(Ticket Granting Ticket)：
  初回の認証が成功した際に受け取るチケットであり、このチケットが無いとAD環境内の他サービス（ファイルサーバー等）にアクセスすることができません。

• TGS(Ticket Granting Service)：
  TGTを持つクライアントが他サービスにアクセスし、アクセス許可を得られた際に受け取るチケットになります。ここでの動作が実質的にSSOとなります。

身近な例で例えると、以下のような流れになります：

[1] TGT取得フェーズ

Linux Client → KDC(AD): 「user01でログインしたい」
KDC → Linux Client: 「TGT(認証済み証明書)を発行するよ」

[2] サービス利用フェーズ

Linux Client → KDC: 「ファイルサーバーにアクセスしたい(TGT提示)」
KDC → Linux Client: 「TGS(サービス利用券)を発行するよ」
Linux Client → File Server: 「アクセスします(TGS提示)」
File Server: 「どうぞ！」

実際の認証フロー

AD参加前後の認証の流れの違い

まず、AD参加前後で認証の流れが以下のように変わります。

参加前（ローカル認証）
ユーザーログイン：SSH → ローカル認証（/etc/passwd確認 → /etc/shadow確認） → 認証OK/NG

参加後（AD統合認証）
ユーザーログイン：SSH → SSSD → AD → Kerberos認証 → 認証OK/NG
↓
SSSDがキャッシュに保存（次回高速化）

realmとSSSDによるADへの参加

SSSDを使用してのADに参加しますが、実際にはrealmを使用します。
realmを利用することで、AD参加に必要な/etc/sssd/sssd.conf等の設定情報も自動生成されます。

周辺環境は下記を前提としています。

• ADは構築済み
• DNSによる正引きと逆引きが可能

realmとSSSDを使用して、ADに参加する手順は以下のようになります。

① 必要パッケージのインストール

> sudo dnf -y install realmd sssd oddjob oddjob-mkhomedir adcli samba-common-tools krb5-workstation
(snip)
>

② ADへ参加

$ realm discover example.localdomain
  example.localdomain
    type: kerberos
    realm-name: EXAMPLE.LOCALDOMAIN
    domain-name: example.localdomain
    configured: no
    server-software: active-directory
    client-software: sssd
    required-package: oddjob
    required-package: oddjob-mkhomedir
    required-package: sssd
    required-package: adcli
    required-package: samba-common-tools
    login-formats: [e-mail]
    login-policy: allow-realm-logins
$ sudo realm join example.localdomain -U <ADの管理ユーザー>
$
$ realm discover example.localdomain
  example.localdomain
    type: kerberos
    realm-name: EXAMPLE.LOCALDOMAIN
    domain-name: example.localdomain
    configured: kerberos-member　★configuredがno->kerberos-memberに変わる
    server-software: active-directory
    client-software: sssd
    required-package: oddjob
    required-package: oddjob-mkhomedir
    required-package: sssd
    required-package: adcli
    required-package: samba-common-tools
    login-formats: [e-mail]
    login-policy: allow-realm-logins
$
$ id [e-mail]　★ADユーザー情報が取得できる
　 uid=595001000([e-mail]) gid=595000512(domain [e-mail]) 
　 groups=595000512(domain [e-mail]),595000513(domain [e-mail]),
　 595000572(denied rodc password replication [e-mail])
$

③ユーザー名だけでログインできるように設定を変更

$ cat /etc/sssd/sssd.conf

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

[domain/example.localdomain]
default_shell = /bin/bash
krb5_store_password_if_offline = True
cache_credentials = True
krb5_realm = EXAMPLE.LOCALDOMAIN
realmd_tags = manages-system joined-with-adcli
id_provider = ad
fallback_homedir = /home/%u@%d
ad_domain = example.localdomain
use_fully_qualified_names = False　★ここをTrue -> Falseに変更する
ldap_id_mapping = True
access_provider = ad
$
$ systemctl restart sssd
$

④ ログインして、ユーザーディレクトリが作成されることを確認

$ ls -l /home
合計 0
drwxr-xr-x.  3 root   root           35 12月  1  2024 .
dr-xr-xr-x. 19 root   root          247 11月 17  2024 ..
drwx------.  5 user01 domain users  140  7月 21 22:06 [e-mail]

AD参加により可能なこと

ADユーザーとADグループを指定できる

Linux上でADユーザーとADグループを指定できるため、以下のようなことも可能です。

sudo(管理者権限)設定

ADユーザー又はADグループに対しても通常のユーザーやグループ同様にsudoの実行権限を付与することが可能です。
書き方にパターンがいくつかありますが、以下のように/etc/sudoersファイルを編集するか、/etc/sudoers.d/配下に同様の記載をしたファイルを配置します。
① ユーザーに対して権限を付与する場合

[ユーザー名]@[ADドメイン] ALL=(ALL) ALL
[ユーザー名] ALL=(ALL) ALL　★FQDNの使用を無効にしている場合はADドメインは不要

② グループに対して権限を付与する場合

%[ADグループ]@[ADドメイン] ALL=(ALL) ALL

Domain Adminsのようにスペースを挟むグループ名の場合は""(ダブルクォーテーション)で囲みます。

"%Domain Admins@[ADドメイン]" ALL=(ALL) ALL

ディスククォータ

個人で使用する分にはさほど気にすることはないですが、共用サーバーのように複数ユーザーが利用する環境では気づかないうちにディスクやディレクトリを圧迫します。
ディスククォータもsudoers同様にADユーザー又はADグループ単位で指定できるようになります。

$ sudo xfs_quota -x -c 'report -ug /home'
User quota on /home (/dev/mapper/almalinux-home)
                               Blocks
User ID          Used       Soft       Hard    Warn/Grace
---------- --------------------------------------------------
root                0          0          0     00 [--------]
user01             64          0          0     00 [--------]

Group quota on /home (/dev/mapper/almalinux-home)
                               Blocks
Group ID         Used       Soft       Hard    Warn/Grace
---------- --------------------------------------------------
root                0          0          0     00 [--------]
domain admins      64          0          0     00 [--------]

AD参加後のメリット

ここまで記載した内容でLinuxサーバーは晴れて、ADに参加できました。
やや仰々しい書き方になりますが、以降はADに参加することによって、得られるメリットの紹介となります。

運用面での利点

最もわかりやすい点としては、Windows OS同様にユーザーを作成する必要が無くなります。
パスワードもADユーザーのパスワードで認証可能なため、初期パスワードを発行して、初回ログイン時にパスワードを変更…といった手間も不要です。非常に地味なところですが、楽です。

セキュリティ面での利点

ADに参加することで、Linuxにログインする場合はローカルのユーザーではなく、ADユーザーとなります。その結果、ユーザーが乗っ取られることはなくなります。
/etc/passwdにも/etc/groupにもADユーザーやADグループは存在していません。

$ sudo cat /etc/passwd | grep -i "user01"
$
$ sudo cat /etc/group | grep -i "domain"
$

もちろん、SSSDは認証情報を一時的にキャッシュしていますし、ユーザーディレクトリに保存されているような情報は除きます。

まとめ

冒頭で書いていたように、LinuxサーバーをADで管理できないかという思いに至ったのは、パスワードを忘れたり、ユーザーを忘れたりして、サーバーの作り直しを繰り返していた状況をどうにかしたかった、という非常に片付けができないものぐさな理由でした。

そんな出だしだったため、以下のような頭を悩ませるトラブルを人知れず繰り返していました：

• およそ時刻同期されているのに、AD参加を拒否される（実はDNSの逆引き設定も抜けていた）
• Kerberos認証の暗号化方式の違いで、AD参加を拒否される（ある時突然、参加できた）
• straceの結果と睨み合い（AI頼み）

ただ、結果的に思っていた以上にサーバーの管理は楽になっています。
加えて、トラブルシュートの中で多少なりともLinuxにおける認証やAD…特にKerberos認証については理解が深まりました。

次回は、上記トラブルの詳細とAD管理での利点をサーバーの半自動デプロイを絡めた内容を書いてみようと思っています。

末筆ですが、最後までお読みいただき、ありがとうございました。