構築事例：389 Directory Serverを利用したLDAPサーバ

新サーバでも389 Directory Serverを提案

当初の予定では、LDAPサーバとして実績が豊富で、CentOS7の標準のOpenLDAPを提案していました。しかし、旧389 Directory Serverを調査していると、OpenLDAPでは、設定できない項目があることに気づきました。そこで、新サーバでも389 Directory Serverを使用することを提案しました。

OpenLDAPに移行しようとしたけどできなかったこと

旧389 Directory Serverでは、ManagerのDNがcn=Directory Managerでしたが、OpenLDAPでは、cn=Directory Managerにすることができませんでした。また、メールサーバや特別なプログラムなどがLDAPと連携していて、ManagerのDNを変更することができませんでした。このような理由から、ManagerのDNを同じにするために、新サーバでも389 Directory Serverを採用し、解決しました。

バージョン間での動作の違いで課題になったこと

389 Directory Serverでは、「パスワード保存形式」という設定があり、旧サーバは、平文パスワードが保存されていました。ケーブルテレビ契約者が使うWebUIや管理者が使うWebUIでも平文パスワードがそのまま保存されていることを前提として作られており、平文パスワードを保存する必要がありました。しかし、新サーバの389 Directory Serverは、平文パスワードではなく、ハッシュ化するのが、デフォルトでした。そのため、パスワードがハッシュ化されてしまい、移行後のサービス試験でNGとなってしまいました。

LDAPデータの移行に時間がかかる問題を移行時に解決

リハーサルで旧389 Directory Serverから新389 Directory ServerにLDAPデータを移行したところ、1分程度で完了しました。しかし、本番移行の時に再度旧389 Directory Serverから新389 Directory ServerにLDAPデータを移行しようとしたところ、8時間程度かかることが判明しました。原因は不明でしたが、データが残った状態でインポート作業をすると、かなり時間がかかってしまうかもしれないと予測し、LDAP移行をする直前に、新サーバのLDAPデータをあえてすべて削除しました。その結果、スムーズなデータ移行ができました。

認証サーバ構築の事例一覧

• OpenLDAPによるLDAPサーバのユーザ統合管理システム事例
• OpenLDAPによるLDAPサーバのマルチマスタ構成事例
• LDAPサーバ冗長化事例
• RADIUSサーバ事例
• CaptivePortalを利用したSNS認証事例
• Google AuthenticatorとFreeRADIUSを使ったOTP認証事例
• daloRADIUSを使用したRADIUSサーバ事例
• 389 Directory Serverを利用したLDAPサーバ事例
• OpenXPKIを利用したプライベート認証局事例
• Nginxを利用したクライアント認証サーバ導入事例
• FreeRADIUSを利用した認証サーバ事例
• Amazon Linux 2へ認証サーバOSの移行事例
• Keycloakを利用したシングルサインオン認証サーバの導入事例
• 管理の負担を軽減したKeycloakによるシングルサインオンサーバ構築事例
• 多要素認証にTOTPを利用したKeycloakサーバ導入事例