サーバ構築のデージーネットTOP > OSS情報 > システム構築 > 認証サーバ構築 > 389 Directory Serverを利用したLDAPサーバ構築

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

Open Smart Design

デージーネットでケーブルテレビの契約ユーザ向けのLDAPサーバのリプレースを行いました。これまで使用してきた389 Directory ServerからOpenLDAPへリプレースしようとしましたが、設定上、うまくいかないことがあり、新サーバでも389 Directory Serverを採用することになりました。旧389 Directory Serverで利用していたLDAPのデータもすべて移行しました。

お客様が悩まれていた課題: RHEL6を使用しており、サポートが完了するので、新しいOSにしたい。; 仮想環境をリプレースするタイミングで、新しい仮想環境に新しいLDAPサーバを構築したい。; LDAPサーバのサポートがほしい。

+導入企業プロフィール: ★
導入企業業種

ケーブルテレビ

ユーザー規模

一般向けと法人向けを含めて約7万アカウント

利用OS

CentOS7

導入月

2019年1月頃

デージーネットが提案した「389 Directory Serverを利用したLDAPサーバ構築」

既存の389 Directory Serverを調査し、新389 Directory Serverへのサーバ移行を立案

新サーバでも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データをあえてすべて削除しました。その結果、スムーズなデータ移行ができました。