構築事例:389 Directory Serverを利用したLDAPサーバ
デージーネットでケーブルテレビの契約ユーザ向けの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データをあえてすべて削除しました。その結果、スムーズなデータ移行ができました。
導入後の結果
構築時、移行時に問題が何点か発生しましたが、すべて解決することができ、無事にCentOS7 + 389 Directory Server の新LDAPサーバでサービスを開始することができました。
【Webセミナー】CentOS8 サポート終了に伴う今後の考え方
日程: | 1月22日(金)Webセミナー「BigBlueButton」を使用します。 |
内容: | CentOS8のサポートが2021年に終了すると発表されました。CentOS8を利用していたユーザは今後、どのようにしていくとよいのかわかりやすく解説します! |
ご興味のあるかたはぜひご参加ください。 |