DHCPサーバー・PAM認証基盤とOpenLDAPディレクトリ構築【202試験 主題2.07】



LinuCレベル2の第2関門である「202試験」では、ネットワーククライアントを統合管理・認証するためのコア技術が出題されます。その筆頭となるのが、主題2.07「ネットワーククライアントの管理」で問われる DHCPサーバーの設定と管理（2.07.1）、PAM認証スタック（2.07.2）、および LDAPクライアントとOpenLDAPサーバー（2.07.3 / 2.07.4） です。

クライアント端末へ動的にIPやゲートウェイ、DNS情報を配付するDHCPサーバー、Linuxアプリケーションと各種認証方式を疎結合に仲介するPAM、そして全社規模でアカウントや権限を一元管理するLDAPディレクトリサービスは、現代のネットワークインフラの根幹を支える3大基盤です。本記事では、AlmaLinux 9.8の実機環境に isc-dhcpd 4.4、OpenLDAP 2.6、SSSD を導入し、dhcpd.conf の主要パラメータから PAM コントロールフラグの評価順序、LDAP階層構造（DIT）の検索までを実機検証ログとともに体系的に解説します。

1. DHCPサーバーの構築・管理とIPv6ルーター広告#

ネットワークに参加するPCやサーバーに対して、IPアドレス、サブネットマスク、デフォルトゲートウェイ、DNSサーバーアドレスを自動配布するプロトコルが DHCP（Dynamic Host Configuration Protocol） です。

1.1 DHCPの4段階ハンドシェイク（DORA）と動作原理#

クライアントが起動してからIPアドレスを取得するまで、以下の4つのブロードキャスト／ユニキャストパケット（DORA）がやり取りされます。

1.2 /etc/dhcp/dhcpd.conf の設定構文と固定IP割り当て#

ISC DHCPサーバーの主設定ファイルは /etc/dhcp/dhcpd.conf です。subnet 宣言でネットワーク範囲を定義し、スコープ内で各種オプションを指定します。

# サブネット宣言と動的IPプール
subnet 192.168.2.0 netmask 255.255.255.0 {
    range 192.168.2.150 192.168.2.200;           # 動的配布IP範囲
    option routers 192.168.2.1;                  # デフォルトゲートウェイ
    option domain-name-servers 192.168.1.137, 8.8.8.8; # DNSサーバー
    option domain-name "localdomain";            # 検索ドメイン名
    default-lease-time 600;                      # デフォルトリース時間（秒）
    max-lease-time 7200;                         # 最大リース時間（秒）

    # 特定端末（MACアドレス）への固定IP割り当て
    host printer01 {
        hardware ethernet 00:11:22:33:44:55;     # 端末の物理MACアドレス
        fixed-address 192.168.2.210;             # 固定割り当てIPアドレス
    }
}

1.3 リース管理ファイルとDHCPリレーエージェント（dhcrelay）#

DHCPサーバーが現在クライアントへ貸し出しているIPアドレスや有効期限、MACアドレス情報は、/var/lib/dhcpd/dhcpd.leases に随時記録・更新されます。

また、DHCPの要求パケット（DHCPDISCOVER）はL2ブロードキャストであるため、ルーターを超えて別セグメントへ届きません。ルーターをまたいだ拠点や別VLANの端末に単一のDHCPサーバーからIPを配付する場合、ルーターまたは中継サーバー上で DHCPリレーエージェント（dhcrelay） を動作させます。dhcrelay はブロードキャストを受信するとユニキャストパケットに変換して指定のDHCPサーバーへ転送します。

1.4 IPv6自動構成（SLAACとradvd）#

IPv6環境では、DHCPv6サーバーを使用する方式のほかに、ルーターがプレフィックス情報を定期ブロードキャストする SLAAC（Stateless Address Autoconfiguration: ステートレスアドレス自動設定） が広く使われます。LinuxマシンをIPv6ルーターとして動作させ、クライアントへプレフィックスを広告するデーモンが radvd（Router Advertisement Daemon） であり、設定ファイルは /etc/radvd.conf です。

1.5 実機での dhcpd 構文検証ログ#

dhcpd.conf を編集した後は、デーモンを起動する前に必ず dhcpd -t -cf /etc/dhcp/dhcpd.conf を実行して構文エラーを検査します。

[user01@linuc-node01 ~]$ sudo dhcpd -t -cf /etc/dhcp/dhcpd.conf
Internet Systems Consortium DHCP Server 4.4.2b1
Config file: /etc/dhcp/dhcpd.conf
Database file: /var/lib/dhcpd/dhcpd.leases
PID file: /var/run/dhcpd.pid
Source compiled to use binary-leases

2. PAM（Pluggable Authentication Modules）のアーキテクチャ#

従来のUNIXシステムでは、各アプリケーション（loginコマンド、ftpデーモン、suコマンド等）が独自に /etc/passwd や /etc/shadow を直接読み込んでパスワード検証を行っていました。この密結合な実装形態では、生体認証やワンタイムパスワード、LDAP連携などの新しい認証方式を導入するたびに、すべてのアプリケーションを再コンパイルしなければならない致命的な欠点が存在しました。

この課題を解決するために考案された共通認証APIが PAM です。アプリケーションはPAMライブラリが提供するAPIを呼び出すだけで認証処理を委譲でき、管理者は設定ファイルを書き換えるだけで認証バックエンドを柔軟に差し替える（Pluggable）ことが可能です。

図1: Linux PAM認証スタックの処理フローとコントロールフラグの評価

2.1 PAMが果たす役割と共通認証API#

PAMは、認証を要求する「サービス（クライアントアプリケーション）」と、実際の検証処理を実行する「PAMモジュール（/lib64/security/*.so）」の間に介在します。

例えば、ユーザーがSSH経由でログインを試みた場合、第15回で堅牢化を解説するOpenSSHデーモン（sshd）は内部で直接パスワード照合を行うのではなく、PAMの pam_authenticate() 関数を呼び出します。PAMは設定ファイルに従って、ローカルの暗号化パスワード検証モジュール（pam_unix.so）やアカウントロックモジュール（pam_faillock.so）を順次実行し、その成否結果を sshd に返します。

2.2 設定ファイル配置（/etc/pam.d/ と /etc/pam.conf）#

PAMの設定方法は歴史的に2通りの形式が存在しますが、現在のLinuxディストリビューションではサービス別のディレクトリ方式が標準です。

• /etc/pam.conf: 単一のファイル内にすべてのサービスの認証設定を列挙する古い形式です。現在では互換性維持のために残されているのみです。
• /etc/pam.d/: サービスごとに独立した設定ファイルを配置する標準形式です（例: /etc/pam.d/sshd、/etc/pam.d/su、/etc/pam.d/system-auth）。ファイル名がサービス名と一致します。

/etc/pam.d/ 配下の各設定ファイルは、1行ごとに以下の基本構文で記述されます。

<モジュールタイプ>   <コントロールフラグ>   <モジュールパス>   [<モジュール引数...>]

2.3 4つのモジュールタイプ（auth, account, password, session）#

PAMモジュールは、実行する処理の目的に応じて以下の4つのグループ（モジュールタイプ）に分類されます。1つの共有ライブラリ（例: pam_unix.so）が複数のモジュールタイプに対応している場合もあります。

2.4 コントロールフラグの評価挙動（required, requisite, sufficient, optional）#

LinuC 202試験において最も出題頻度が高く、合否を分ける重要概念が コントロールフラグ の評価ロジックです。同じモジュールタイプに対して複数のモジュールがスタック（連鎖）されている場合、フラグによって判定継続のルールが異なります。

実機の /etc/pam.d/system-auth から、典型的なスタック構造を確認します。

[user01@linuc-node01 ~]$ head -n 25 /etc/pam.d/system-auth
#%PAM-1.0
# This file is auto-generated.
auth        required      pam_env.so
auth        sufficient    pam_unix.so try_first_pass nullok
auth        required      pam_deny.so

account     required      pam_unix.so

password    requisite     pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=
password    sufficient    pam_unix.so try_first_pass use_authtok nullok sha512 shadow
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
-session     optional      pam_systemd.so
session     required      pam_unix.so

auth スタックにおいて、pam_unix.so が成功した場合は sufficient により直ちに認証成功となり、末尾の pam_deny.so は実行されません。しかしローカルパスワード検証に失敗した場合は、後続の required pam_deny.so が評価され、確実に認証拒否となります。

3. PAMによるセキュリティ制御と実機検証#

PAMは単純なパスワード認証だけでなく、ブルートフォース攻撃防御、特権昇格制限、およびシステムリソース上限の強制など、強固なアクセス制御を提供します。

3.1 pam_faillock（pam_tally2の後継）によるアカウントロック設定#

かつてのCentOS 6/7や古いLinux環境では pam_tally2 モジュールがログイン試行制限に使われていましたが、AlmaLinux 8/9を含む現代のシステムでは pam_faillock モジュールが標準化されています（LinuC試験でも更新された重要な変更点です）。

pam_faillock は、認証失敗回数を記録し、指定回数を超えた場合に一定期間アカウントを一時ロックします。ロック状態の確認や手動解除には faillock コマンドを使用します。

• faillock --user <ユーザー名>: 対象ユーザーの失敗試行ログおよびロック状態を表示します。
• faillock --user <ユーザー名> --reset: 蓄積された失敗カウントをゼロクリアし、ロックを即時解除します。

[user01@linuc-node01 ~]$ sudo faillock --user user01
user01:
When                Type  Source                           Valid
[user01@linuc-node01 ~]$ 

3.2 pam_wheel によるsu実行制限#

su コマンドによる管理者（root）昇格を特定の管理者グループ（wheel グループ）所属ユーザーのみに制限する場合、/etc/pam.d/su 内の pam_wheel.so を有効化します。

# wheelグループに所属しているユーザーのみsuコマンドの実行を許可
auth        required      pam_wheel.so use_uid

use_uid オプションを指定することで、現在実行中の実UID（RUID）がwheelグループに所属しているかを正しく検証します。

3.3 pam_limits によるリソース制限（limits.conf）#

DoS攻撃やプログラミングミスによるメモリ枯渇・ファイルディスクリプタ枯渇を防ぐため、ログインセッション開始時にリソース上限を適用するのが pam_limits.so です。その定義ファイルは /etc/security/limits.conf および /etc/security/limits.d/*.conf に配置されます。

設定行は「ドメイン（対象ユーザー/グループ）」、「タイプ（soft/hard）」、「アイテム（制限項目）」、「値」の4列で記述されます。

[user01@linuc-node01 ~]$ ulimit -a | head -n 10
core file size              (blocks, -c) unlimited
data seg size               (kbytes, -d) unlimited
scheduling priority                 (-e) 0
file size                   (blocks, -f) unlimited
pending signals                     (-i) 14444
max locked memory           (kbytes, -l) 8192
max memory size             (kbytes, -m) unlimited
open files                          (-n) 1024
pipe size                (512 bytes, -p) 8
POSIX message queues         (bytes, -q) 819200

4. OpenLDAPとディレクトリサービスの基礎構造#

企業やデータセンターにおいて多数のLinuxサーバーやクライアントPCが稼働する場合、各端末の /etc/passwd に個別にユーザーアカウントを登録・保守するのは現実的ではありません。これをネットワーク経由で集中管理するための標準技術が LDAP（Lightweight Directory Access Protocol） です。

図2: LDAPディレクトリ情報ツリー（DIT）の階層構造とDNの構成

4.1 RDBMSとディレクトリサービス（LDAP）の決定的な違い#

MySQLやPostgreSQLに代表されるリレーショナルデータベース（RDBMS）と、LDAPディレクトリサービスは、想定される利用パターンが根本的に異なります。

4.2 ディレクトリ情報ツリー（DIT）と識別名（DN / RDN）#

LDAP内のデータは、DNSやファイルシステムと同様に階層構造（ツリー構造）で管理されます。このツリー全体を DIT（Directory Information Tree） と呼びます。

ツリー内の各ノード（データ1件）は「エントリ（Entry）」と呼ばれ、エントリの完全な位置を示す一意の識別名を DN（Distinguished Name） と呼びます。DNは、最下層の相対識別名である RDN（Relative Distinguished Name） と、上位階層のパスをカンマ区切りで結合した文字列で構成されます。

例えば、ドメイン example.com の People 組織に属するユーザー taro の完全なDNは、以下のように表記されます。

dn: uid=taro,ou=People,dc=example,dc=com
    ^^^^^^^^  ^^^^^^^^^ ^^^^^^^^^^^^^^^
      RDN     上位OU       Base DN (ルート)

4.3 オブジェクトクラス（objectClass）と属性（Attribute）#

各エントリがどのような情報（属性: Attribute）を保持できるかは、そのエントリに割り当てられた オブジェクトクラス（objectClass） によって定義されます。LinuC 202試験では以下のスキーマ知識が問われます。

• オブジェクトクラスの種別:
  • structural（構造型）: エントリの根本的な種類を決定します。1つのエントリに構造型クラスは原則1つのみ指定可能です（例: person, inetOrgPerson, posixGroup）。
  • auxiliary（補助型）: 既存のエントリに新たな属性セットを追加するために併用します（例: Linuxアカウント情報を付与する posixAccount, パスワード有効期限情報を付与する shadowAccount）。
• 属性定義の制約:
  • MUST: そのオブジェクトクラスを適用した際に、必ず値を設定しなければならない必須属性です（例: posixAccount における cn, uid, uidNumber, gidNumber, homeDirectory）。
  • MAY: 設定しても省略してもよい任意属性です（例: loginShell, gecos, userPassword）。

5. LDIF形式とLDAPクライアントツールの操作#

LDAPサーバーに対するデータの登録、検索、変更、削除は、標準データ交換フォーマットである LDIF（LDAP Data Interchange Format） と、OpenLDAPクライアントツール群を用いて実行します。

5.1 LDIF（LDAP Data Interchange Format）の記法ルール#

LDIFファイルはプレーンテキストであり、以下の厳格なフォーマット規則を持ちます。

dn: uid=taro,ou=People,dc=example,dc=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
uid: taro
cn: Taro Tanaka
sn: Tanaka
mail: taro@example.com
userPassword: {SSHA}h9s8djK3...
uidNumber: 2001
gidNumber: 2000
homeDirectory: /home/taro
loginShell: /bin/bash

5.2 ldapsearch による検索とフィルタリング構文#

LinuC 202試験の最頻出コマンドが ldapsearch です。構文オプションおよび検索スコープの指定方法は確実に暗記する必要があります。

検索フィルタは、論理演算子（&: AND、|: OR、!: NOT）を前置記法（ポーランド記法）で記述します。

# uidがtaroまたはjiroであり、かつposixAccountクラスを持つエントリを検索
ldapsearch -x -b "dc=example,dc=com" "(&(objectClass=posixAccount)(|(uid=taro)(uid=jiro)))" uid cn mail

5.3 ldapadd, ldapmodify, ldapdelete によるエントリ操作#

エントリの更新系コマンドの基本構文は以下の通りです。

• ldapadd -x -D <BindDN> -W -f <ファイル.ldif>: LDIFファイルから新しいエントリを一括追加します（内部的には ldapmodify -a と同等）。
• ldapmodify -x -D <BindDN> -W -f <変更.ldif>: 既存エントリの属性値の追加（add:）、置換（replace:）、削除（delete:）を実行します。
• ldapdelete -x -D <BindDN> -W "uid=taro,ou=People,dc=example,dc=com": 指定したDNのエントリを削除します。子エントリを持つ親ノードは直接削除できません。
• ldappasswd -x -D <BindDN> -W -S "uid=taro,ou=People,dc=example,dc=com": 指定したユーザーの userPassword 属性を変更します（-S で新パスワードの対話入力プロンプトを表示）。

6. Linuxクライアントの統合認証（SSSD連携）#

LDAPサーバーを導入した後、Linuxクライアント（サーバー群）がそのディレクトリ情報を参照してユーザーログインを処理できるようにするためのクライアント側統合アーキテクチャについて整理します。

6.1 SSSD（System Security Services Daemon）の役割#

かつては nss_ldap や pam_ldap モジュールを用いてLDAPサーバーと直接通信していましたが、ネットワーク遅延やLDAP障害時にシステム全体のログイン処理が停止する問題がありました。現代のLinuxディストリビューションでは、統合認証デーモンである SSSD（System Security Services Daemon） が標準採用されています。

6.2 /etc/nsswitch.conf と authselect による設定適用#

Linuxシステムが「ユーザー名からUIDやGIDを解決する際、どの情報源をどの順序で参照するか」を決定するのが /etc/nsswitch.conf（Name Service Switch設定ファイル）です。

passwd:     files systemd sss
group:      files systemd sss
shadow:     files sss

上記の設定では、まずローカルの files（/etc/passwd）を検索し、存在しない場合に systemd および sss（SSSDデーモン経由でのLDAP検索）を順次参照します。

AlmaLinuxやRHEL系環境では、これらのPAMおよびNSSの設定を手動で直接書き換えるのではなく、プロファイルベースで安全に切り替える authselect コマンドが推奨されています。

# 利用可能なプロファイル一覧の表示
[user01@linuc-node01 ~]$ authselect list
- minimal        ローカルパスワード認証のみを使用する最小構成
- sssd           SSSDデーモンを使用した集中認証構成
- winbind        Samba Winbindを使用したActive Directory連携構成

# SSSDプロファイルの適用と指紋認証等の機能追加
[user01@linuc-node01 ~]$ sudo authselect select sssd with-mkhomedir

with-mkhomedir オプションを指定することで、初回ログイン時に自動的にユーザーのホームディレクトリを生成する pam_mkhomedir.so が有効化されます。

7. LinuC 202試験（主題2.07）重要ポイント総整理#

202試験の主題2.07における記述式問題（コマ問）対策、および引数・判定ロジックの整理を行います。

7.1 記述式（コマ問）頻出コマンド・設定ファイル一覧#

7.2 PAMコントロールフラグの判定テーブル完全整理#

設問で提示されたモジュールスタックの合否シミュレーションにおいて、迷わず正解を導くための判定マトリクスです。

8. まとめと次回予告（第10回：BINDによるDNSサーバー構築）#

本記事では、LinuCレベル2（202試験）の第1弾として、システム認証の共通骨格であるPAMのアーキテクチャ、コントロールフラグの評価論理、pam_limitsによるリソース制御、そして企業ディレクトリサービスの標準であるLDAPのDIT構造、LDIF構文、クライアントツールの操作までを整理しました。

認証とアカウント管理は、あらゆるネットワークサービスを提供する上でのセキュリティ基盤です。PAMのスタック評価順序やLDAPの識別名ルールを確実に身につけておくことで、以降に登場するWebサーバーやメールサーバー、ファイル共有サーバーの認証設定を円滑に理解できるようになります。

次回（第10回）からは、インターネットおよび社内ネットワークの最重要インフラである「名前解決サーバー」を取り上げます。Linuxにおける事実上の業界標準DNSサーバーソフトウェアである BIND（Berkeley Internet Name Domain） を用いた正引き・逆引きゾーン設定、ゾーン転送、セキュリティ機能（TSIG / DNSSEC）の構築と実機検証を体系的に解説します。

リンク