#564 FreeIPAサーバー構築からクライアント参加まで：Rocky Linux実践チュートリアル

2025年11月4日 00:13

Rocky Linux BastionホストをFreeIPAドメインに参加させる – ステップバイステップガイド

環境概要

今回のラボ環境では、RHELベースのKVMホスト上で複数のRocky Linux 9仮想マシンをKVM/QEMUで実行しています。ホスト（RHEL）は「freeipa」（FreeIPAサーバー）や「bastion」（ドメインに参加させるクライアント）といったVMを管理しています。FreeIPAサーバーはDNSドメインlab.localで構成されており、アイデンティティ管理サーバー（Kerberos/LDAPによる認証集中管理、DNSサービス等）として機能します。bastion VMはlab.localドメインのFreeIPAクライアントとして登録される予定です。

ネットワーク構成:
仮想マシン同士は仮想ネットワークで接続されています。今回のケースでは、FreeIPAサーバーおよびそのクライアント用に内部ネットワーク10.10.0.0/24を使用しています。FreeIPAサーバーにはIPアドレス10.10.0.2、bastionホストには10.10.0.3を割り当てています。また、このネットワーク上にゲートウェイ10.10.0.254を設定し、KVMホストを介したインターネットアクセスを提供します。KVMホストは外部接続用にNATネットワーキング（192.168.122.0/24）も提供します。FreeIPAサーバーとbastionはそれぞれホスト名をfreeipa.lab.localおよびbastion.lab.local（完全修飾ドメイン名）に設定済みです。DNSの設定前に基本的な名前解決ができるよう、両マシンの/etc/hostsにこれらの名前をあらかじめ記載しています[1]。

例えば:

10.10.0.2 freeipa.lab.local freeipa
10.10.0.3 bastion.lab.local bastion

KVMホスト上では、「freeipa」や「bastion」を含む仮想マシンが実行中であることを確認できます[2]:

$ sudo virsh list --all
Id Name State
----------------------------
7 rocky9 running
8 bastion running
10 freeipa running
...

上記の出力: KVMホスト上でFreeIPAサーバーVM（freeipa）とbastion VMが稼働している様子を示しています[2]。

注: FreeIPA (Free Identity, Policy, Audit) はLinux向けのアイデンティティ管理サーバーです（概念的にはWindowsのActive Directoryに類似）。Kerberosによる集中認証、LDAPによるアカウント管理、DNSサービスなどを提供します。ここではサーバーVMにFreeIPAをインストールし、Rocky Linux上のbastion VMをクライアントとしてドメインに参加させ、bastionホストのDNS正引き（A）レコードおよび逆引き（PTR）レコードを設定することを目標とします。

ネットワーク設定 (FreeIPAサーバーおよびBastion)

FreeIPAをインストールしたりクライアントをドメインに参加させたりする前に、両VMの適切なネットワーク設定を行う必要があります。

静的IPとホスト名の設定:
FreeIPAサーバーVMには静的IP10.10.0.2/24を、bastion VMには10.10.0.3/24を設定します。両マシンがお互いのホスト名を認識できるようにしておくことも重要です。各VMのホスト名を正しく設定します（例: サーバー側ではhostnamectl set-hostname freeipa.lab.local、クライアント側ではhostnamectl set-hostname bastion.lab.localを実行）。また、DNSが利用可能になるまでは（上記のように）各VM（少なくともクライアント側）の/etc/hostsに双方の名前を追記しておきます。これにより、初期セットアップ中にbastionからfreeipa.lab.localを名前解決できるようにしておきます。

Network Manager (nmcli):
Red Hat系ディストリビューションではnmcliを用いてネットワークインターフェースを設定すると便利です。今回のシナリオでは両VMに10.10.0.0/24ネットワークのインターフェースがあります（この接続を便宜上、サーバー側はnet10-freeipa、クライアント側はnet10-bastionと呼びます）。それぞれに対し以下のようにIPアドレス、DNS、ゲートウェイを設定します。まずFreeIPAサーバー側では、自身のIPを設定し、（DNSサービス起動後に）自分自身をDNSとして使うよう設定しておきます:

# On FreeIPA server VM:
sudo nmcli connection modify net10-freeipa \
ipv4.addresses "10.10.0.2/24" \
ipv4.gateway "10.10.0.254" \
ipv4.dns "10.10.0.2" \
ipv4.dns-search "lab.local" \
ipv4.method manual \
ipv4.never-default no
sudo nmcli connection down net10-freeipa && sudo nmcli connection up net10-freeipa

bastionクライアント側では、静的IPを割り当て、DNSサーバーとしてFreeIPAサーバー（10.10.0.2）を指すよう設定します。内部ネットワーク側のipv4.never-defaultをyesに設定し、デフォルトルートを上書きしないようにしています（NAT用のインターフェースがデフォルトゲートウェイになります）。必要に応じて後でデフォルトルートの調整も行います。例えば[3]:

On Bastion VM:
sudo nmcli connection modify net10-bastion \
ipv4.addresses "10.10.0.3/24" \
ipv4.gateway "10.10.0.254" \
ipv4.dns "10.10.0.2" \
ipv4.dns-search "lab.local" \
ipv4.method manual \
ipv4.never-default yes
sudo nmcli connection down net10-bastion && sudo nmcli connection up net10-bastion

これらのコマンドによりbastionのIPを10.10.0.3に設定し、DNSサーバーとしてFreeIPAホストを指定し、検索ドメインをlab.localに設定します[3][4]。ipv4.never-default yesにより、bastionに別のインターフェース（例: NATによるDHCPインターフェースenp1s0でインターネット接続）がある場合でも、そちらを引き続きデフォルトルートとして利用するようになります。（今回のケースでは、NATネットワークがenp1s0経由でゲートウェイ192.168.122.1を提供しています。）

ネットワーク接続の確認:
設定適用後、FreeIPAサーバーとbastionがお互い通信できることを確認します。例えば、bastion側からFreeIPAサーバーにIPまたは名前でpingを実行します:

ping -c 3 freeipa.lab.local

このコマンドによりfreeipa.lab.localが10.10.0.2に解決され、応答が返ってくるはずです。実際、本環境でbastionからfreeipaへのpingは正常に通り、基本的な接続性が確認できました[5]:

$ ping -c3 freeipa.lab.local
PING freeipa.lab.local (10.10.0.2) ...
64 bytes from freeipa.lab.local: icmp_seq=1 ttl=64 time=0.378 ms
64 bytes from freeipa.lab.local: icmp_seq=2 ttl=64 time=0.527 ms
64 bytes from freeipa.lab.local: icmp_seq=3 ttl=64 time=0.530 ms

--- freeipa.lab.local ping statistics ---
3 packets transmitted, 3 received, 0% packet loss ...[5]

インターネット接続の確認（ゲートウェイ設定）:
これらのVMでインターネットアクセス（パッケージのインストールやNTP）の必要がある場合、正しいデフォルトルートが設定されていることを確認します。今回のラボでは、通常NATインターフェースによってデフォルトルート（例: 192.168.122.1）が提供されます。しかし当初、VMに適切なデフォルトゲートウェイが設定されておらず外部に到達できない状態でした。KVMホスト側でIP転送を有効にし、内部ネットワークインターフェースにゲートウェイ10.10.0.254を追加することで、この問題を解決しています。上記のnmcli設定でipv4.gateway 10.10.0.254（およびFreeIPA側でipv4.never-default no）を指定したことで、VMはインターネットに接続できるようになりました。この修正後、bastionから外部への疎通（例えばパッケージリポジトリへのアクセス）も確認できました。

FreeIPAサーバーのインストール (サーバーのセットアップと初期設定)

次に、FreeIPAサーバーをfreeipa.lab.local VM上にインストール・設定します。

FreeIPAパッケージのインストール: サーバーVM（freeipa）上でFreeIPAサーバー関連パッケージをインストールします。Rocky Linuxの場合、パッケージ名はipa-server（統合DNSを使う場合はipa-server-dnsも）です。dnf（またはyum）コマンドでインストールします:

sudo dnf install -y ipa-server ipa-server-dns

これによりディレクトリサーバー（389 Directory Server）、Kerberos KDC、Apache、Dogtag証明書局など多数の依存関係が自動的にインストールされます。実行ログには大量のパッケージが列挙されますが、ここでは詳細を省略しました[25]。

FreeIPAサーバーのインストーラ実行:
パッケージの準備ができたら、ipa-server-installコマンドを実行し、ドメインコントローラーのセットアップを行います。このインストーラは対話的なスクリプトで、ドメインやレルムの設定を進めます。今回は主要なパラメーターを予め指定して自動インストールしました。例えば、以下のコマンドを実行しました:

    sudo ipa-server-install \
--hostname=freeipa.lab.local \
--domain=lab.local \
--realm=LAB.LOCAL \
--ds-password 'admin123!' \
--admin-password 'admin123!' \
--no-ntp \
--setup-dns \
--forwarder 168.63.129.16

           （実行したコマンド内のパスワードadmin123!は例です。）主要なオプションを示します:

o   --hostname=freeipa.lab.local – IPAサーバーのホスト名（FQDN）を設定します。システムに設定済みのホスト名と一致している必要があります。

o   --domain=lab.local – IPA環境のDNSドメイン名を指定します。

o   --realm=LAB.LOCAL – Kerberosレルム名を指定します（通常、ドメイン名を大文字にしたもの）。

o   --ds-password – 内部ディレクトリサーバー（LDAP）の管理者（cn=Directory Manager）用パスワードを指定します（ここでは例として“admin123!”を設定）。

o   --admin-password – FreeIPAの管理者ユーザー（IPAのadminアカウント）のパスワードを指定します。

o   --no-ntp – NTP/chronyの設定をスキップします。今回は時刻同期を別途管理する方針のため指定しました（指定しない場合、インストーラがchronydをFedora/RHELのNTPプールや対話的に与えたNTPサーバーで設定します）。

o   --setup-dns – 統合DNSサーバー（BIND）のセットアップを有効にします。これによりFreeIPAがlab.localゾーンのDNSサーバーとなります。

o   --forwarder <IPアドレス> – BINDが外部ドメインを解決する際に問い合わせる上流DNSサーバーのIPを指定します。例では168.63.129.16を指定しました（到達可能なDNSサーバーの一例です）。パブリックDNS（例: Googleの8.8.8.8）や社内のDNSサーバーを指定しても構いません。インターネットにアクセスできない環境でルートヒントを使いたい場合は、このオプションを省略するか--no-forwardersを使用します。

           コマンドを実行すると、インストーラは設定の要約を表示し、確認を求めてきます。今回の場合、DNSフォワーダーが設定され「Reverse zone(s): No reverse zone」と表示されました。つまり、自動で逆引きゾーンは作成されない設定です（この逆引きゾーンの設定は後で行います）。インストーラが表示した設定内容を確認し、「Continue to configure the system with these values? [no]:」というプロンプトに対して「yes」と入力して続行しました[10]。

           重要:
インストール中、スクリプトはいくつかのチェックを行います。例えば: - ホストのFQDNが名前解決できるか確認します（DNS関連の問題を避けるため）。セットアップ時、インストーラは「freeipa.lab.local の DNS 解決をスキップしています（skipping DNS resolution of host freeipa.lab.local）」という警告を出しました。これは当該ホスト名の名前解決がその時点では/etc/hostsに頼っていたためです。 - 指定したDNSフォワーダーが応答するか確認します。フォワーダーが到達不能またはDNS応答しない場合、インストールは失敗し得ます。初回の試行ではデフォルトでlibvirtのゲートウェイ192.168.122.1をフォワーダーに指定したためタイムアウトとなり、インストールが失敗しました。この問題に対処するため、確実に応答するDNSサーバー（例として168.63.129.16）に変更し、VMからそのDNSへ到達できる経路（NATネットワーク経由）を確保しました。その結果、インストールは正常に進みました。

           インストール処理には数分かかり、各コンポーネント（CA、KDC、LDAP、Apache、PKIなど）が構成されます。この間、コンソールには[1/X]形式の進捗メッセージが表示されます。例えば、Kerberos KDCのセットアップ、管理者ユーザーの作成、IPA RA（証明書機関）の設定（「Configuring certificate server (pki-tomcatd) [1/32]...」等）といったメッセージがログに出力されます。完了すると、IPA設定のサマリー（管理者ユーザー情報やKerberosチケット取得方法など）が表示されます。

インストール後の作業:

サーバー側ファイアウォール設定:
FreeIPAインストール後、サーバーのファイアウォールで必要な通信が許可されていることを確認します。FreeIPAサーバーはデフォルトで複数のポートを使用します: TCP 80/443 (Web UIとAPI)、TCP/UDP 88 (Kerberos KDC)、TCP/UDP 464 (Kerberosパスワード変更)、TCP 389 (LDAP)、TCP 636 (LDAPS)、TCP 53およびUDP 53 (DNS)、UDP 123 (NTP、有効にした場合) 等です。FreeIPAサーバーVM上では標準でFirewalldが動作しています（RHEL/CentOS/Rocky Linuxのデフォルト）。インストーラはfirewalldに幾つかのサービスを追加する場合もあります（freeipa-ldapやfreeipa-kdc等のプリセットサービス）が、念のため必要なポートが開放されているか確認し、足りなければ追加入力します。

まずDNSとNTPサービスを許可しました:

sudo firewall-cmd --add-service=dns --add-service=ntp --permanent
sudo firewall-cmd --reload

これでDNSクエリとNTPが許可されます。（sudo firewall-cmd --list-allでfirewalldの設定を確認すると、publicゾーンにDNSとNTPサービスが開放されているのがわかります。）

次に、FreeIPAのWeb（HTTP/HTTPS）およびLDAP/Kerberos関連のポートを開放しました:

sudo firewall-cmd --add-service=http --add-service=https \
--add-service=ldap --add-service=ldaps \
--add-service=kerberos --add-service=kpasswd \
--permanent
sudo firewall-cmd --reload

上記を適用後、sudo firewall-cmd --list-allでpublicゾーンのサービス一覧にKerberosやLDAP、DNS等が含まれていることを確認できます。例えば、IPAクライアントインストーラのエラーメッセージには明示的にTCP 80, 88, 389およびUDP 88を開放するよう促す内容がありましたが、これらを開放したことでサービスへ正常に接続できるようになりました。

IPAサービスの確認:
サーバー構築後、正常に機能しているかテストします。 - サーバー上でKerberosチケットを取得できます: kinit adminを実行して管理者パスワードを入力し、ipa user-find adminでadminユーザーが検索できること、または単にipa pingコマンドでIPA APIとの通信確認を行います。

- DNSサービスが稼働していることを確認:
FreeIPAインストーラによりnamed-pkcs11（BIND）がlab.localゾーン用に構成されています。systemctl status named-pkcs11でサービスがアクティブ（active）になっていることを確認します。また、DNSフォワーダーが機能しているかテストします。例えばFreeIPAサーバー上で、ローカルDNSを使って外部ドメインを解決してみます:

```bash
dig @127.0.0.1 google.com A
```

フォワーダーが正しく設定され到達可能であれば、上記コマンドで応答が得られるはずです。実際、インストール直後はフォワーダー設定の不備で名前解決できませんでしたが、IPAのコマンドでフォワーダーを修正し（最初のインストール失敗時の設定を引き継いでいたため）、`ipa dnsconfig-mod --forwarder=<IPアドレス> --forward-policy=only`コマンドでグローバルフォワーダーを再設定し`named-pkcs11`サービスを再起動しました。その後`ipa dnsconfig-show`で`Global forwarders: 168.63.129.16`と表示され、再度`@127.0.0.1`宛のDNSクエリを試すと正常に外部ドメインを引けるようになりました。

以上で、FreeIPAサーバーfreeipa.lab.localのインストールと初期設定は完了です。DNSゾーンlab.localも有効化されました（ただし現時点ではbastionのレコードをまだ追加しておらず、逆引きゾーンも未作成です）。

次にDNSレコードの設定を行い、その後クライアントをドメインに参加させます。

DNS正引き・逆引きの設定 (FreeIPAでのDNS構成)

FreeIPAの統合DNSを使用する利点の一つは、ホストのDNSレコードを集中管理できることです。ここではbastion.lab.localホストのDNSエントリ（Aレコードによる正引きとPTRレコードによる逆引き）を追加します。（FreeIPAクライアント参加時にAレコードは自動追加するオプションもありますが、ここでは手動でこれらのDNSレコードを確実に設定する手順を示します。実際、今回のケースではクライアントインストール時にこのAレコードが存在しないと警告され、自動的に追加されましたが、学習目的で手動設定も行います。）

bastion.lab.localの正引きレコード (Aレコード) 追加:
bastion.lab.localが10.10.0.3に名前解決できるように、FreeIPAサーバーが権威を持つlab.localゾーンにAレコードを追加します。IPAコマンドで実行する構文はipa dnsrecord-add <ゾーン> <レコード名> --a-rec=<IP>です。以下を実行します:

On FreeIPA server:
kinit admin # 管理者としてKerberosチケットを取得（未認証なら実行）
ipa dnsrecord-add lab.local bastion --a-rec=10.10.0.3

これでAレコードが作成されます。成功したか確認するため、ipa dnsrecord-find lab.local bastionコマンドでレコードを検索します。今回、クライアントを参加させた後にこのレコードが存在することを確認しました（クライアントインストール時にこのAレコードが自動追加されています）。出力例ではbastionのAレコードが含まれています:

$ ipa dnsrecord-find lab.local bastion
Record name: bastion
A record: 10.10.0.3
SSHFP record: 4 1 F490E... , 4 2 ACC6F... (etc.)
...[21]

上記の結果から、bastion.lab.localに対しAレコードが10.10.0.3として登録されていることが確認できます。（また、クライアント参加後にFreeIPAがSSHFPレコードも追加していることがわかります。これはbastionホストのSSH公開鍵フィンガープリントで、SSHクライアントのホスト確認に有用です。）

逆引きDNS (PTRレコード) の設定:
PTRレコードはIPアドレスからホスト名を引く逆引き用のレコードです。一部のサービスやツールではPTRによるホスト名解決が行われるため、設定しておくと望ましいです。FreeIPAインストーラは10.10.0.0/24用の逆引きゾーンを自動作成しなかったため（インストールサマリーで「No reverse zone」と表示されました）、これを手動で追加します。

まず逆引きゾーン名を決定します。IPv4の場合、逆引きゾーン名は対象ネットワークの各オクテットを逆順に並べ、in-addr.arpaを付与したものになります。今回のネットワーク10.10.0.0/24の場合、/24は10.10.0.x範囲を扱うためゾーン名は0.10.10.in-addr.arpaとなります（/16なら10.10.in-addr.arpaのようになりますが、ここでは/24のネットワークに限定したゾーンです）。

逆引きゾーンの追加:
ipa dnszone-addコマンドを使用してゾーンを作成します。以下を実行しました:

ipa dnszone-add 0.10.10.in-addr.arpa

このコマンドで逆引きゾーンが作成されます。出力にはゾーン作成が確認できる情報が表示されます:

Zone name: 0.10.10.in-addr.arpa.
Active zone: True
Authoritative nameserver: freeipa.lab.local.
...
BIND update policy: grant LAB.LOCAL krb5-subdomain 0.10.10.in-addr.arpa. PTR;
Dynamic update: False

（上記のupdate policyは、レルムLAB.LOCAL内のIPAクライアントがKerberos経由でPTRレコードを更新できることを意味します。デフォルトでは動的更新は無効なので、ここではIPAコマンドでレコード管理を行っています。）

bastion用PTRレコードの追加:
続いて、その逆引きゾーンにbastionホストのPTRレコードを追加します。対象IPは10.10.0.3で、ホスト部のオクテット（最後の3）をレコード名として登録します。以下を実行しました[23]:

ipa dnsrecord-add 0.10.10.in-addr.arpa 3 --ptr-rec=bastion.lab.local.

※PTRレコードにはホスト名を末尾にドット付きで指定しています。上記コマンドにより、名前「3」のPTRレコードが「bastion.lab.local.」を指すよう作成されます。
追加後、ipa dnsrecord-find 0.10.10.in-addr.arpa 3で確認します。出力例:

Record name: 3
PTR record: bastion.lab.local.
----------------------------
Number of entries returned 1[24]

逆引きDNSエントリーが正常に追加されたことがわかります。
これでFreeIPA上のDNS構成は完了です。正引きゾーンlab.localにはfreeipaおよびbastionのレコードが登録され、逆引きゾーン0.10.10.in-addr.arpaにはbastionのIPに対応するPTRが登録されました。FreeIPAサーバー自身（freeipa.lab.local = 10.10.0.2）についてはまだ逆引きゾーンがありませんが、必要であれば同様にこのネットワーク範囲のゾーンを追加し、10.10.0.2のPTRを設定できます。（インストーラ実行時、「10.10.0.2の逆引きレコードは既に存在する」といったメッセージが表示されました。おそらく/etc/hosts等で名前が見つかっただけでゾーン上には未登録だったためです。これを正式に追加する場合、ipa dnsrecord-add 0.10.10.in-addr.arpa 2 --ptr-rec=freeipa.lab.localのようにすれば良いでしょう。）

DNS解決の検証:
DNSを設定したことで、FreeIPAサーバーをDNSサーバーとして使用するクライアントではbastion.lab.localが10.10.0.3に解決でき、逆引きも可能になるはずです。FreeIPAサーバー自身、または（後でIPA DNSを使う設定をする）bastion上でテストできます。例えばFreeIPAサーバー上で:

dig bastion.lab.local @127.0.0.1 +short # 結果: 10.10.0.3
dig -x 10.10.0.3 @127.0.0.1 +short # 結果: bastion.lab.local.

設定後、これらの名前解決は期待通り成功しました。DNS設定が正しく行われたことを確認できました。
（これでbastionホストをFreeIPAクライアントとして参加させる準備が整いました。）

BastionをFreeIPAクライアントとして参加させる (Rocky Linuxクライアントのドメイン参加)

サーバーの準備が整いDNSも構成できたので、次のステップはbastion.lab.localホストをFreeIPAドメインに参加させることです。クライアントを参加させることで、そのホストは集中認証（SSSD/Kerberos）を利用するよう設定され、IPA上にホストプリンシパルが作成されます（DNSレコードもオプションで追加されますが、これはすでに手動で設定済みです）。手順は以下の通りです。

IPAクライアントパッケージのインストール: bastion（Rocky Linuxシステム）上でFreeIPAクライアント用ソフトウェアをインストールします:

sudo dnf install -y ipa-client

これによりipa-clientとその依存関係（SSSD、Kerberos、certmongerなど）がインストールされます。実行例では、sssdやoddjob、certmonger等のパッケージが一緒に導入されました（ログには多数のパッケージが表示されましたがここでは割愛します）。

bastionのリゾルバ設定をFreeIPA DNSに向ける: これは以前nmcliで設定済みですが、bastionの/etc/resolv.confにnameserver 10.10.0.2およびsearch lab.localが入っていることを確認します。以下のように内容をチェックできます。

$ cat /etc/resolv.conf
# Generated by NetworkManager
search lab.local
nameserver 10.10.0.2[26]

これにより、bastionはFreeIPAサーバーをDNSとして参照するようになります。この設定がない場合、クライアントインストーラはIPAサーバー名を見つけられず失敗する可能性があります（代替として/etc/hostsにIPAサーバーを登録する手もありますが、DNSを使うのが望ましいです）。

ipa-client-installの実行:
bastion上で実際にクライアントの登録コマンドを実行します。ドメイン名、サーバー名、レルム名などを指定して、自動検出に頼らないようにします（DNSでSRVレコードが正しく設定されていれば自動検出も可能ですが、ここでは明示指定します）。実行したコマンドは以下の通りです[27]:

    sudo ipa-client-install \
--domain=lab.local \
--server=freeipa.lab.local \
--realm=LAB.LOCAL \
--hostname=bastion.lab.local \
--mkhomedir \
--principal=admin

           このコマンドの意味は以下の通りです。

o   --domain=lab.local – IPAレルムのDNSドメイン名です。

o   --server=freeipa.lab.local – 登録先のIPAサーバーを指定します（自動検出をスキップ）。

o   --realm=LAB.LOCAL – Kerberosレルム名です。

o   --hostname=bastion.lab.local – クライアントに設定するホスト名です（インストーラがマシンのホスト名をこれに設定する場合もあります）。

o   --mkhomedir – IPAユーザーが初回ログインした際にホームディレクトリを自動作成するようPAMに設定します（oddjobdによって実現）。テスト環境でIPAユーザーがこのホストにログインする可能性がある場合、便利なオプションです。

o   --principal=admin – IPA管理者ユーザーとして認証してクライアント登録を行う指定です。実行時に先ほどサーバー設定時に決めたadminユーザーのパスワード入力を求められます。

           対話型のプロンプト:
クライアントインストーラを実行すると、途中でいくつか情報を表示し、確認入力を求めてきます。

o   DNS検出に関する警告: サーバーを手動指定したため、「他のサーバーにフェイルオーバーできないが固定値で進めるか？」と警告されます（SRVレコードによるDNS検出をスキップしたため）。具体的にはProceed with fixed values and no DNS discovery? [no]:と表示されるので、「yes」と入力します[28]。

o   chronyの設定:
続いてDo you want to configure chrony with NTP server or pool address? [no]:と尋ねられます。特に指定しなければデフォルトの「no」で構いません（Enterキー押下でデフォルト選択）。今回はNTPサーバーを指定しなかったため、デフォルトのまま進めました。インストーラはchronycを使い、一度だけIPAサーバーまたはNTPプールと時刻同期を試みます。IPAサーバーがDNS SRV経由でNTPを広告していたり、--ntp-serverオプションを指定していればそれを使用します。今回、特にNTP設定がなかったため（No SRV records of NTP servers found and no NTP server or pool address was provided.というメッセージ）、システム既定のchrony設定を使って同期が行われました。その際「Attempting to sync time... Time synchronization was successful.」と出力されました[29]。これは重要な処理で、サーバーとクライアントの時刻差が大きいとKerberos認証が失敗する可能性があるためです。幸いにも今回の環境では時刻差は小さく、この同期は成功しました。

           その後、Password for admin@LAB.LOCAL:と表示されるので、IPA管理者（admin@LAB.LOCAL）のパスワードを入力します。パスワードが正しければ、クライアントの登録処理が続行されます。

           クライアントのインストールツール（ipa-client-install）は次のような設定を自動で行います:

o   サーバーからCA証明書を取得してインストール

o   /etc/ipa/default.confにドメインやレルム情報を設定

o   SSSDの設定ファイル /etc/sssd/sssd.conf をIPAバックエンド用に構成

o   Kerberos設定ファイル /etc/krb5.conf を構成

o   SSSDサービスやoddjobdサービスの有効化など

o   bastion.lab.localのホストプリンシパルをIPAサーバー上に作成し、ホストのキータブを取得

o   --mkhomedirを指定していた場合、PAMにホームディレクトリ自動作成設定を追加（oddjobd経由で初回ログイン時にホームが作られます）

           実行中、以下のようなメッセージが表示されれば成功です: 「Enrolled in IPA realm LAB.LOCAL」（IPAレルムLAB.LOCALに参加しました）、/etc/sssd/sssd.confの設定完了（Configured）、SSSD enabled（SSSD有効化）等、最後に「Client configuration complete.」および「The ipa-client-install command was successful」（クライアント設定が完了し、ipa-client-installコマンドは成功しました）といったメッセージが出力されます。

           実際、我々の環境でも「Hostname (bastion.lab.local) does not have A/AAAA record. Missing reverse record(s) for address(es): 10.10.0.3.」という趣旨のメッセージが表示されました。これは最初Aレコードを手動追加していなかったためです。ただしクライアントインストールの過程で、IPA DNSにそのホストのAレコードを追加しようと試み、最終的に自動追加されました（ゾーンが動的更新を許可する設定になっていたため）。またbastionホストのSSH鍵のSSHFPレコードも追加されました。一方でPTRは逆引きゾーン自体が無かったため追加されず、このため前述の手順で逆引きゾーンとPTRを手動追加しました。これらの警告は情報提供のためのもので、インストール自体は問題なく完了しています。

クライアントが正常に参加できたら、bastionホストはIPAクライアントとなっています。bastion上で以下のようなテストを行ってみましょう。

Kerberos認証の確認:
管理者ユーザー（またはIPAの任意のユーザー）でKerberosチケットを取得し、接続をテストします。

    $ kinit admin
Password for admin@LAB.LOCAL: ********

           その後、klistコマンドでチケットが取得できたことを確認し、ipa pingコマンドを実行してIPAサーバーとの接続疎通をチェックします。ipa pingはIPA APIへの簡易な接続確認コマンドで、サーバーのバージョン情報が返ってくれば成功です。例えば本環境では以下の応答があり、通信が確認できました:

    $ ipa ping
--------------------------------------------
IPA server version 4.12.2, API version 2.254
--------------------------------------------[33]

IPA上のホストエントリー確認:
bastionが参加したことで、IPAサーバー上にホストエントリーが作成されています。クライアントまたはサーバー側からipa host-show bastion.lab.localやipa host-find bastion.lab.localで確認できます。例えばbastion上で（admin権限を取得した上で）ipa host-find bastion.lab.localを実行したところ、以下のような情報が得られました:

$ ipa host-find bastion.lab.local
--------------
1 host matched
--------------
Host name: bastion.lab.local
Platform: x86_64
Operating system: 5.14.0-570.52.1.el9_6.x86_64
Principal name: host/bastion.lab.local@LAB.LOCAL
SSH public key fingerprint: (SHA256 hashes of host keys...)
----------------------------
Number of entries returned 1[34]

これにより、IPAサーバー側でbastionホストが認識されており、OSやカーネル情報（ホスト登録データから報告）、ホストプリンシパルやSSH鍵フィンガープリントがIPAに保存されていることが確認できます。

クライアントでDNS解決をテスト:
bastionクライアントがFreeIPAのDNSを使用するようになったので、名前解決が機能するか確認します。

$ host freeipa.lab.local
freeipa.lab.local has address 10.10.0.2

$ host bastion.lab.local
bastion.lab.local has address 10.10.0.3

$ host 10.10.0.3
3.0.10.10.in-addr.arpa domain name pointer bastion.lab.local.

上記の通り、bastionからfreeipa.lab.localおよびbastion.lab.localが正しく解決でき、10.10.0.3のPTRもbastion.lab.localを指していることを確認できました。（digコマンドでも同様に確認可能です。）

IPAユーザーでのログインテスト（任意）:
IPAサーバー上のWeb UIまたはipa user-addコマンドでテスト用ユーザーを1人作成し、そのユーザーの資格情報でbastionにログイン（SSHまたはコンソール）を試してみます。--mkhomedirを指定していれば、初回ログイン時にホームディレクトリが自動作成されるはずです。これにより、このホストがIPAにより中央管理された認証基盤に組み込まれていることを実感できます。（管理者アカウントでkinitした状態でSSH接続すると管理者のKerberosチケットが使われてしまう可能性があるため、テスト前にkdestroyでadminのチケットを破棄するか、別の通常ユーザーでkinitしてから試行すると良いでしょう。）

これでbastionホストはFreeIPAドメインに無事参加しました。

検証とテスト

以上の手順が正しく行われたか、以下の点をまとめて確認しましょう。

Pingと基本接続:
すでに実施しましたが、bastionとFreeIPAサーバー間でホスト名によるpingが通ること（DNSおよびネットワーク接続が機能していること）を確認します。
DNSルックアップテスト:
FreeIPAサーバーまたはクライアント上で、digやhostコマンドを使用してDNSレコードが正しく構成されていることを確認します。例えば:

dig bastion.lab.local @10.10.0.2 # => 10.10.0.3 を返す
dig -x 10.10.0.3 @10.10.0.2 # => bastion.lab.local. を返す
dig freeipa.lab.local @10.10.0.2 # => 10.10.0.2 を返す

上記の応答が得られれば、正引きおよび逆引きのDNSが適切に構成されています。IPAデータベース上にもbastionのレコードが登録されていることが確認できています。

ファイアウォールの確認:
bastion（クライアント）側からIPAサーバーの各ポートに接続できることを確認します。例えば、nc -zv freeipa.lab.local 389（LDAPポート）、nc -zv freeipa.lab.local 88（Kerberosポート）、nc -zv freeipa.lab.local 80（HTTPポート）等を実行します。最初これらのコマンドで "No route to host" エラーが出た場合、サーバー側のファイアウォールでブロックされている可能性があります（実際、セットアップ当初はそうでした）。上記の手順でファイアウォール設定を修正した後には、これらのコマンドが成功するか、少なくとも "No route" エラーが出なくなることを確認してください。"Connection refused" が出る場合はサービスがリスンしていない可能性がありますが、FreeIPAサーバー上では必要なサービスは起動済みのはずです。"No route" は通常ファイアウォールで遮断されていることを意味します。
IPAサービスの疎通確認:
クライアント側でkinitにより認証を取得した上で、ipa pingコマンドを実行し、クライアントがサーバーのAPIと通信できることを確認します。応答としてサーバーのバージョン情報が返ってくれば、クライアントはサーバーのCA証明書を信頼し、Kerberos認証でHTTPS通信ができていることを意味します。
時間同期の確認:
サーバーとクライアントの時刻が同期されているか、少なくとも差がごくわずかであることを確認します。両方のマシンでchronyc trackingコマンドを使うか、単純にdateコマンドで表示される時刻を比較します。NTPを構成していない場合でも、両者のシステム時刻が合っていることが重要です（FreeIPAではipa time-showコマンドでIPA内の時刻情報を確認することもできます）。時刻の差が数分以上あると、Kerberos認証が「時計のずれが大きすぎます（Clock skew too great）」等のエラーで失敗するので注意してください。
ログインのテスト:
IPAサーバー上で作成したユーザーアカウントで、bastionホストにSSHまたはコンソールログインできることを確認します。--mkhomedirを指定していれば、初回ログイン時にホームディレクトリが作成されます。これによりシステムが中央認証に正しく組み込まれていることを実証できます（テスト時には管理者のKerberosチケットをkdestroyするか、通常ユーザーでkinitしてからログインを試すようにしてください）。

以上の検証により、FreeIPAドメイン内でbastionクライアントが正常に機能している（ネットワーク接続、DNS解決、IPAクライアントの動作が意図通りである）ことを確認しました。

トラブルシューティングと問題解決

今回のセットアップ中に、いくつかのよくある問題に直面しました。以下に問題の内容、原因、および解決方法を示します。

FreeIPAインストーラーでDNSフォワーダー検証に失敗:
初回のFreeIPAインストール試行時（ipa-server-install実行時）、「DNSフォワーダーのチェック中」にタイムアウトが発生し失敗しました。

原因:
指定したフォワーダー（192.168.122.1）がDNSクエリに応答しなかったためです（今回の場合、KVM NATのDNSがVMから利用できない設定でした）。

解決策:
応答のある信頼できるDNSサーバー（例えば公共DNSなど）を指定し直しました。インストールコマンドのフォワーダーを168.63.129.16に変更したところ成功しました。または、VMがインターネットに出られるよう経路を確保する、指定したフォワーダーが到達可能であることを確認する、といった対策が必要です（隔離環境なら--no-forwardersを使い、後でフォワーダー/ヒントを設定する方法もあります）。
デフォルトルート未設定/外部ネットワークに到達できない:
当初、VMからインターネットへの接続（DNSクエリやNTP同期）ができませんでした。

原因:
VMに適切なデフォルトゲートウェイが設定されておらず、外部ネットワークへのルートがなかったためです。

解決策:
デフォルトゲートウェイを正しく設定しました。我々のケースでは、内部ネットワーク側に10.10.0.254をゲートウェイとして設定し（ホストでIP転送も有効化）、これによりVMが外部のDNSやNTPサーバーに到達できるようになりました。nmcliでのゲートウェイ設定やip routeの出力を確認し、NATインターフェースがデフォルトルートを提供するよう調整しました。
FreeIPAクライアントのインストール失敗（ポート遮断/"No route"エラー）:
bastion上で最初にipa-client-installを実行した際、「LDAPサーバーが応答していないためIPAサーバーか確認できない」（LDAP server is not responding...）というエラーが出て失敗しました。クライアント側でncコマンドを使うとポート80, 389, 88に対し「No route to host」と表示されました。

原因:
FreeIPAサーバー側のファイアウォールがこれらのポートをブロックしていたため、クライアントからIPAサービスに到達できなかったのです。

解決策:
FreeIPAサーバーのファイアウォールで必要なポートを開放しました。前述の通り、HTTP、HTTPS、LDAP、LDAPS、Kerberos、kpasswd、DNS、NTP等のサービスを追加してfirewalldをリロードしました。その後、クライアントのインストールは成功しました。（ラボ環境であれば、一時的にサーバー側のfirewalldを停止する方法もありますが、特定ポートのみ開放する方が安全です。）
クライアント参加時のKerberosエラー（時刻のずれ）:
クライアントの時計がサーバーと大きくずれている場合、Kerberos認証が拒否されることがあります（"Clock skew too great"等のエラーやSSLハンドシェイク失敗が発生）。

原因:
サーバーとクライアントの時刻が同期されていないためです。

解決策:
サーバー・クライアント双方でNTP/Chronyを実行し、時刻同期を確実に行います。今回のケースではクライアントインストーラ内の時刻同期機能が成功しましたが、失敗した場合は手動で時刻を合わせる必要があります。例えばクライアント上でchronyc makestepを実行するか、一時的に手動で時刻を合わせてから再度インストールを試みます。本番環境では全てのサーバー/クライアントが共通のNTPソースに同期するように構成すべきです。
DNSでIPAサーバー名を解決できない:
クライアントインストーラがfreeipa.lab.localを名前解決できない場合、IPAサーバーに接続できず失敗します。

原因:
クライアント側のDNS設定が不備、またはIPAサーバー名が解決不能な状態です。

解決策:
我々の場合と同様、インストール前にクライアントの/etc/hostsにIPAサーバーを追記するか、/etc/resolv.confをIPAサーバー（もしくはIPAサーバー名を知っている別のDNS）を指すよう設定します。今回はnmcliでnameserverを10.10.0.2に設定したことで、クライアントがIPAサーバー名を解決できるようになりました。事前にhost freeipa.lab.localやping freeipa.lab.localで名前解決が成功することを確認すると安心です。
DNS逆引きゾーンが無い:
クライアント参加後、「逆引きレコードが見つからない」というメッセージが表示されました[31]。

原因:
最初に逆引きDNSゾーンを作成していなかったため、クライアントのIPに対応するPTRが追加できなかったのです。

解決策:
前述の通り、IPAで逆引きゾーンを作成（ipa dnszone-add）し、PTRレコード（ipa dnsrecord-add ... --ptr-rec=...）を追加しました。これは主に完全性のための手順で、PTRが無くても参加自体は失敗しません。しかし後から追加することで逆引きlookupの要求にも対応できるようになります。
ファイアウォール越しのNTPサービス:
IPAをNTPサーバーとして構成した場合（またはクライアントが外部NTPに同期する場合）、UDPポート123が許可されていることを確認してください。我々はサーバー側でntpサービス（UDP 123）も開放しました[12]。FreeIPAサーバーをNTPサーバーとして動かす場合（--no-ntpを指定せずchronydをIPA対応で設定した場合）、クライアントはドメイン経由で自動的にNTP設定を取得できます。それ以外の場合でも、両方が何らかのNTPソースで同期されていることが重要です。
その他の問題:
上記以外にも問題が発生した場合:

·       ホスト名の不一致:
サーバーのホスト名とドメイン名が正しく一貫していることを確認してください（インストール中にlocalhostや意図しないドメイン名が設定されていると失敗します）。

·       ipa-server-installの再実行:
インストールが失敗して再試行する場合、最初の不完全なセットアップを削除する必要があります（ipa-server-install --uninstall -Uを実行してから再度インストールします）。

·       クライアント再登録:
クライアントを再インストールするか再度参加させたい場合、IPA上に既存のホストエントリーが残っていると登録に失敗することがあります。その際はIPAサーバー上でipa host-del bastion.lab.localで古いエントリーを削除するか、クライアントインストーラ実行時に--force-joinオプションを使用します。

·       ログの確認:
FreeIPAサーバーのログは/var/log/ipaserver/に、クライアント側のログは/var/log/ipaclient-install.logに出力されています。問題発生時は詳細なエラー情報を確認できます。
上記の問題に対処した結果、最終的に環境のセットアップは成功しました。

まとめ

本チュートリアルでは、Rocky Linuxのbastion.lab.localホストをFreeIPAドメインlab.localに統合する手順を、初心者向けに詳細な解説付きでステップバイステップで説明しました。RHELのKVMホスト上での初期環境構築、静的IPのネットワーク設定、FreeIPAサーバーのインストールと設定（統合DNSのセットアップとフォワーダー構成を含む）、クライアントのDNS正引き（A）レコードおよび逆引き（PTR）レコードの追加、そしてipa-client-installを用いたクライアントのFreeIPAサーバーへの参加まで、一通りの手順を網羅しました。その途中で、DNS名解決の問題、ファイアウォールによる通信遮断、NTPの時刻同期不良、ゲートウェイルートの欠如といった一般的な問題にも遭遇し、それぞれに対する解決策も提示しています。

このガイドに沿って進めれば、同様の環境を再現できるはずです。FreeIPAによりアイデンティティ管理とDNS管理が一元化され、bastionホストはこの基盤を信頼する状態になりました（Kerberos認証が有効化され、DNSも適切に構成済みです）。FreeIPAで作成したアカウントを使用してbastionにログインできるようになり、FreeIPAのインターフェースやコマンドを通じてDNSエントリを管理することも可能です。この構成は、lab.localドメインに他のホストやサービスを追加して拡張していくための基盤となります。

今後は、FreeIPAサーバーのメンテナンス（必要に応じたCA証明書の更新や冗長化のためのレプリカ追加など）を忘れず行い、クライアントの時刻やDNS設定が常に正しいことを確認してください。基本的な部分が構築できたことで、HBAC（Host-Based Access Control）やホームディレクトリの自動マウント、Windowsクライアントとの信頼関係の構築など、FreeIPAのさらなる機能を試すことも可能です（これらのトピックは本稿では扱いません）。

お疲れ様でした。