ネットワーク認証をセキュアに行うために、FreeRADIUSとActive Directory（LDAP）を連携させる構成は多くの企業で利用されています。しかし、設定が正しいにもかかわらず「ldap:hit reconnection limit」エラーが発生する事例も少なくありません。
FreeRADIUSとActive Directoryの認証トラブル概要
FreeRADIUSは、RADIUSプロトコルを利用した認証・認可・課金(AAA)サービスを提供するサーバーソフトウェアです。一方のActive Directory（LDAPサーバーとして機能する役割を併せ持つ）では、ユーザーアカウントやグループ、ポリシーなどを一元管理します。企業や組織でこの2つを連携させれば、シングルサインオンや一元的なアカウント管理を実現でき、利便性やセキュリティを向上させることが可能です。
しかし、いざ連携を試みると、認証時に「ldap:hit reconnection limit」というエラーに直面する場合があります。これは、LDAPクライアントであるFreeRADIUSがLDAPサーバー（Active Directory）に対して再接続要求を行う中で、再接続回数の上限に到達したことを示唆するメッセージです。バインド自体は成功しているのに、なぜか認証がうまくいかない――このような状況に陥る要因は複数考えられます。
エラーの背景と原因
「ldap:hit reconnection limit」というエラーが発生する主な原因は、以下のようなケースが代表的です。
- LDAPサーバーへの再接続を必要以上に繰り返している
- 通信エラーや設定ミスによる再接続の連発により、クライアント側(FreeRADIUS)またはサーバー側(Active Directory)が許容する接続の上限数に引っかかる。
- Active Directory側の接続制限が厳しすぎる
- Active Directoryのレジストリやポリシーで設定されたMaxConnやMaxConnectionsなどの制限が厳しく、短時間に多くの再接続要求を行うとブロックされる。
- FreeRADIUSのLDAPモジュール設定(タイムアウトやリトライ回数)が不適切
- リトライ回数が大きすぎて逆に問題を引き起こす、または小さすぎて安定した再接続が確立できず、連続してリトライが走ってしまう。
こうした状況を解消するためには、両方の構成(FreeRADIUS側とActive Directory側)を見直し、不要な再接続が発生しないよう最適化していくことが重要になります。
LDAPサーバー(Active Directory)の稼働状況とネットワークの確認
まずは、当たり前のように思える初歩的な点から振り返ることが大切です。意外なところにボトルネックや制限が存在しているかもしれません。
ネットワーク接続の基本検証
- pingテスト
FreeRADIUSサーバーからActive Directoryサーバーに対してpingを実行し、疎通可能か確認します。 - ポートの確認
LDAPが平文またはSTARTTLSで通信する場合は通常ポート389、LDAPSを使う場合は636が利用されます。ファイアウォールやセキュリティアプライアンスにより、これらのポートがブロックされていないかも確かめてください。 - DNSの設定
Active Directoryと連携する際、DNSが正しく解決できないと認証に失敗するケースがあります。FQDNでの名前解決が適切に行われるか、DNSサーバーの設定を見直しましょう。
Active Directory側のエラー確認
Windows Serverのイベントビューア(「Directory Service」または「LDAP Interface」など)を確認し、LDAPに関連したエラーログが出ていないかチェックすることが大切です。もし頻繁に以下のようなログが残っていれば、LDAP接続の過負荷や制限が原因の可能性があります。
- 接続数が上限を超過したことを示す警告
- 特定のクライアントIPからの接続が大量に発生しブロックされた旨のログ
Active Directoryの接続制限の見直し
Active Directoryには、クライアントからの同時接続や一定時間あたりの再接続数を制御する機能が存在します。標準では大幅に制限されているわけではありませんが、組織のセキュリティポリシーや運用要件に合わせて制限値がカスタマイズされているケースもあります。
MaxConn値やLDAPポリシーの調整
Active Directoryでは、「MaxConnections」や「MaxConn」というパラメータをレジストリやグループポリシーで管理している場合があります。再接続要求がこの制限を上回ると、新規接続を受け付けなくなることがあります。
設定値を見直し、極端に低い値になっていないか確認してください。
また、組織ポリシーとして設定を変更しづらい場合には、FreeRADIUS側の接続試行回数や不要な認証リクエストを減らす方向で対策する必要があります。
ロードバランシングと冗長構成
Active Directoryサーバーが複数台存在する環境では、負荷分散を実施している場合もあります。負荷分散の設定によっては、同一セッションが異なるサーバーに対して行われ、想定外の再接続要求が増えてしまうことがあります。
仮にロードバランサーがセッションを正しく維持しないまま、都度新規の接続として扱っているならば、Active Directory側から見ると「短時間で多数の再接続」が行われているように見えてしまいます。ロードバランサー側のセッションスティッキー設定を見直し、クライアントとサーバー間で継続的なセッションが保持されるように調整しましょう。
FreeRADIUSのLDAPモジュール設定のポイント
次に、FreeRADIUS側の設定を深堀りします。とくに注目すべきは、mods-available/ldap (あるいは mods-enabled/ldap) などの設定ファイルです。多くのディストリビューションでは /etc/raddb/ 以下に配置されますが、環境によってパスやファイル名が異なる場合があります。
主な設定パラメータと推奨調整例
以下のようなパラメータが存在し、それぞれの値を適切に調整することで「ldap:hit reconnection limit」のエラーを緩和または解消できる可能性があります。
| パラメータ | 役割 | 例（推奨値は環境次第） |
|---|---|---|
| retry_count | LDAPサーバーへのリトライ回数 | 3～5程度 |
| retry_delay | リトライを行う際のインターバル(秒) | 10～30秒 |
| timeout | LDAPサーバーへの接続要求1回あたりのタイムアウト(秒) | 5～10秒 |
| idle_timeout | 未使用セッションを切断する時間(秒) | 60～300秒 |
| start_tls | STARTTLSを利用する場合に有効化 | yes/no |
| tls_mode | TLS/SSL接続のモード指定 | ldaps/auto |
例：設定ファイルの抜粋（イメージ）
ldap {
server = "ldap.example.local"
port = 389
identity = "CN=RadiusBind,OU=ServiceAccounts,DC=example,DC=local"
password = "P@ssw0rd"
base_dn = "DC=example,DC=local"
# コネクション周りの設定
timeout = 10
retry_count = 5
retry_delay = 30
idle_timeout = 300
# TLSの設定
start_tls = yes
tls_require_cert = "allow"
tls_mode = ldaps
}このような設定例は環境によって最適値が大きく異なります。ネットワークの品質やActive Directoryの応答速度、組織のポリシーなどを踏まえて、少しずつパラメータを調整してください。
タイムアウトとリトライ回数のバランス
リトライ回数が多すぎると、問題解決どころかLDAPサーバーへの過剰接続の原因になります。逆に少なすぎると、一時的なネットワーク障害があった際に接続が確立されにくくなるリスクがあります。
一般的には3～5回程度が目安ですが、組織のユーザー数や認証リクエスト頻度が多い場合は、ログをモニタリングしながら微調整を繰り返すとよいでしょう。
不要な認証リクエスト増加の要因排除
- 誤ったNAS設定
RADIUSクライアント(NAS: Network Access Server)側の設定ミスにより、繰り返し同じユーザー認証を大量に投げてくるケースがあります。NASのログも合わせて確認し、異常なトラフィックがないか把握しておきましょう。 - アカウントロックアウトポリシー
Active Directoryでアカウントロックアウトポリシーが厳しい設定になっている場合、パスワードの入力ミスが一定回数を超えるとアカウントがロックされ、その後もRADIUSサーバーが再度認証を試み続けると再接続が連発される恐れがあります。このような運用ポリシーの場合、ロック発生時の挙動をFreeRADIUS側で適切にハンドリングするか、ユーザー通知を迅速に行う仕組みが必要です。
TLS/SSL証明書の不備による接続不安定化
LDAP通信をTLS/SSLで暗号化している環境では、証明書の期限切れや不正なCN(Common Name)設定により接続エラーが頻発し、そのたびに再接続が発生することもあります。結果として、短時間に大量の再接続要求が生じ、「ldap:hit reconnection limit」に至るケースがあります。
証明書のチェックポイント
- 有効期限の確認
証明書の期限切れがないかをまずチェックしましょう。期限切れ間近の場合は更新を計画的に進める必要があります。 - CN（Common Name）とサーバー名の整合性
サーバー証明書のCNやSubject Alternative Name (SAN)が、実際のActive DirectoryサーバーのFQDNと一致していないとエラーになる可能性があります。 - 証明書チェーンの信頼性
ルート証明書や中間証明書がFreeRADIUSサーバー側で適切に信頼されていない場合も、接続失敗の原因になります。OSの証明書ストアへのインポートやtls_ca_certfile設定などを確認してください。
トラブルシューティング手順の例
ここまで解説してきたポイントを踏まえ、実際に「ldap:hit reconnection limit」エラーが出た場合の調査手順をまとめてみます。
- ログの収集 FreeRADIUS側のログ（例:
/var/log/radius/radius.logや/var/log/freeradius/radius.log）と、Active Directory側のイベントビューアを両方確認し、同時刻にどのようなエラーが出ているかを確認します。 - ネットワーク疎通のテスト pingやポートスキャンを用いて、LDAPポート(389もしくは636)へのアクセスが正常に行えるか確認します。ファイアウォール設定を再点検することも忘れずに。
- AD側の接続制限・ポリシーを確認 レジストリやグループポリシーでMaxConnや最大同時接続数が小さすぎないかチェックします。また、ロードバランサーや複数ドメインコントローラの構成有無も要確認です。
- FreeRADIUSのldap設定ファイルの見直し
retry_countやretry_delay、timeoutなどの値を調整し、過度な再接続を生まないようにします。さらに、必要に応じてidle_timeoutやtls_modeなどを最適化します。 - 証明書の有効期限と信頼チェーンの点検 TLS/SSL通信を使っている場合、証明書が有効かつ正しく設定されているかを確認します。特にCNやSANがADのFQDNと一致しているかも重要です。
- 認証回数の増加要因を排除 NASのループ設定や誤ったスクリプトによる連続認証が起きていないか、アカウントロックアウトが頻発していないかなどを調べ、異常な再認証が発生していないか確認します。
運用の安定化に向けた追加のヒント
ここまでの対策を施しても、環境によっては思わぬところで再接続が増えたり、接続制限に引っかかったりすることがあります。長期的に安定運用するためのヒントをまとめました。
モニタリングとアラートの設定
- FreeRADIUSのログ監視
ログローテーションの設定を最適化し、リアルタイムでログを確認できるようにしておくと便利です。 - Active Directoryのイベント通知
イベントビューアのログを収集し、特定のIDやメッセージが出たタイミングでアラートを発報する仕組みを導入しておくことで、早期に問題を発見できます。
キャパシティプランニング
企業や組織でのユーザー数、認証数の増加に合わせて、Active DirectoryやFreeRADIUSサーバーのリソース、ネットワーク帯域を適切にスケールアップ・スケールアウトすることも重要です。
例えば、ユーザー数が大幅に増えるイベント（新入社員の一斉システムアクセス、シフトの交代時間帯など）では急激な認証リクエストが発生しやすいため、事前に十分な能力を持ったサーバー配置やロードバランシング、タイムアウト設定を行っておくと安心です。
テスト環境での検証
運用開始後に大きな変更を加えるのはリスクが高いため、可能であればテスト用のActive DirectoryサーバーとFreeRADIUSサーバーを準備し、設定変更を試してみるとよいでしょう。
テスト環境で以下のような検証を行います。
- LDAPサーバーの接続制限値を極端に小さくして、どのようなエラーが出るか再現実験
- FreeRADIUSのタイムアウト値やリトライ回数を変動させて、認証成功率やログの変化を観察
- ネットワーク遅延やパケットロスを人工的に発生させるツールを使い、どのくらいで再接続が発生するかを測定
このように検証データを積み重ねることで、本番環境の設定値をより自信をもって調整できます。
まとめ：両者の連携とログ解析が鍵
「ldap:hit reconnection limit」というエラーは、単純にLDAP接続のIDやパスワードが間違っているといった初歩的なミスではなく、Active Directory側の制限やFreeRADIUS側の再接続設定の問題など、さまざまな要因が絡み合って発生することが多いです。
そのため、最初のアプローチとしては、まず両者のログをつぶさに確認することが極めて重要です。エラーのタイミング、回数、同時に発生している事象など、複合的に判断して原因を絞り込んでいきましょう。
ログから得られる情報をもとに、
- Active Directory側で不要な制限がかかっていないか
- FreeRADIUSのLDAP接続設定が環境に見合っているか
- 証明書やセキュリティ設定が適切に機能しているか
- 不要な認証要求が膨大に発生していないか
を順番に潰していけば、再接続回数の上限に到達してしまうような事態は徐々に緩和されるはずです。
また、将来的にユーザー数の増加や複数認証方式への拡張を視野に入れている場合は、運用段階でのモニタリングとチューニングが欠かせません。早期の段階でログ収集やアラートを整備し、少しでも異変を感じたら対策に乗り出せる体制を築くことが、安定した認証基盤を支える最善策といえます。
コメント