LDAPサーバが停止するとシステム全体が止まってしまう.
サービスを提供し続けるためにLDAPサーバを複数立てて万が一に備える

samba-adは dns/ldap/smb(sysvol)と様々な機能を持ちながらfailoverを行えているsamba/2ndDC.
どうようにLDAPもfailoverは可能でそれを試してみた

2022y11m20d_023005051.png

使うのはOpenLDAP. RHEL8系は「389DirectoryServer」が既定っぽいが、使い慣れているので

方針

  • LDAPデータの修正(ユーザ追加/パスワード変更)はMain側で行い、standbyでは行わない
    データの流れはMainからstandbyの方向で
  • レプリケーションにはsyncreplで行い refreshOnly モードで対応
    常時接続でなく、定期更新で
  • LDAPクライアントはどちらも参照可能とする
    standbyが参照の際はデータ更新させない

Main LDAP構築

一台目のLDAPサーバはLDAP参照で構築. 「cn=Manager,dc=sybyl,dc=local」「ou=People」「ou=Group」を作成してldapsも有効にした状態

hostnameldap-server(192.168.0.81)
OSRocky Linux release 8.5
LDAPopenldap-2.4.46
baseDNdc=sybyl,dc=local
ディレクトリ管理者cn=Manager,dc=sybyl,dc=local
portldap(389/tcp), ldaps(636/tcp)

まずはLDAPデータをstandbyに渡せるように調整します

openLDAPのoverlay機能を使って、syncreplを可能にする「syncprov.la」モジュールを取り込みます. 詳細はLDAP/memberOfで.
「syncprov.la」は「/usr/lib64/openldap」に用意されています

[root@ldap-server ~]# vi ldap/module-syncrepl.ldif
dn: cn=module,cn=config
objectClass: olcModulelist
cn: module
olcModulePath: /usr/lib64/openldap
olcModuleLoad: syncprov.la
 
[root@ldap-server ~]#

この「ldap/module-syncrepl.ldif」を取り込む

[root@ldap-server ~]# ldapadd -H ldapi:/// -f ldap/module-syncrepl.ldif
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
adding new entry "cn=module,cn=config"
 
[root@ldap-server ~]#
 
(確認)
[root@ldap-server ~]# ldapsearch -LLL -H ldapi:/// -b cn=config | less
 :
dn: cn=module{0},cn=config
objectClass: olcModuleList
cn: module{0}
olcModulePath: /usr/lib64/openldap
olcModuleLoad: {0}syncprov.la
 :
[root@ldap-server ~]#

*既に「cn=module{0},cn=config」が存在しているなら「ldap/module-syncrepl.ldif」を下記に変えます.

dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: syncprov.la

次にsyncprovを有効にさせます. LDAPデータベース設定エントリは「ldapsearch -H ldapi:/// -b cn=config dn」から「olcDatabase={2}mdb,cn=config」なので下記のldifを作成

[root@ldap-server ~]# vi ldap/syncprov.ldif
dn: olcOverlay=syncprov,olcDatabase={2}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
olcSpSessionLog: 100
 
[root@ldap-server ~]#

そして登録します

[root@ldap-server ~]# ldapadd -H ldapi:/// -f ldap/syncprov.ldif
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
adding new entry "olcOverlay=syncprov,olcDatabase={2}mdb,cn=config"
 
[root@ldap-server ~]#
 
(確認)
[root@ldap-server ~]# ldapsearch -LLL -H ldapi:/// -b  cn=config | less
 :
dn: olcOverlay={0}syncprov,olcDatabase={2}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: {0}syncprov
olcSpSessionlog: 100
 :
[root@ldap-server ~]#

以上で送り側、standbyからの要求を受け入れる準備が完了しました. 次にリクエストを出す側のstandby側の設定

Standby LDAP構築

どこまで作ればいいのかな?追加のschemaがあるのならそれも事前に入れて置く?とか事前に思ってました.
っでいろいろ試して後述の「SyncRepl」の「searchbase」で定義した配下しか対象としない模様. なので事前に作るのは枠もschemaも含めて事前に作る必要があるみたい.

https://www.openldap.org/doc/admin24/replication.htmlから「cn=config」もコピーできるのなら最高と思ったのだが、
なんかできない. なのでホントのコンテンツ「"dc=sybyl,dc=local"」のみ対象としてます. 「"dc=sybyl,dc=local"」にはschemaは含まれないよ

以下手順.

[root@ldap-standby ~]# dnf --enablerepo=powertools install openldap-servers openldap-clients -y
[root@ldap-standby ~]# cp -a /usr/share/openldap-servers/DB_CONFIG.example /var/lib/ldap/DB_CONFIG
[root@ldap-standby ~]# chown ldap:ldap /var/lib/ldap/DB_CONFIG
 
[root@ldap-standby ~]# systemctl enable slapd.service --now
[root@ldap-standby ~]# firewall-cmd --add-service=ldap --add-service=ldaps --zone=public --permanent
[root@ldap-standby ~]# firewall-cmd --reload
 
[root@ldap-standby ~]# echo "TLS_REQCERT never" >>  /etc/openldap/ldap.conf
[root@ldap-standby ~]# ldapsearch  -x -H ldaps://ldap-server -b dc=sybyl,dc=local

スキーマの登録. samba、radiusのスキーマがMainにあるなら同時にそれも加える

[root@ldap-standby ~]# ldapadd -H ldapi:/// -f /etc/openldap/schema/cosine.ldif
[root@ldap-standby ~]# ldapadd -H ldapi:/// -f /etc/openldap/schema/nis.ldif
[root@ldap-standby ~]# ldapadd -H ldapi:/// -f /etc/openldap/schema/inetorgperson.ldif
 
[root@ldap-standby ~]# ldapadd -H ldapi:/// -f samba.ldif

LDAPの所で構築に使った「rootpw.ldif」「ldapdomain.ldif」を反映させる

[root@ldap-standby ~]# ldapadd -H ldapi:// -f rootpw.ldif 
[root@ldap-standby ~]# ldapmodify -H ldapi:/// -f  ldapdomain.ldif

それとLDAPS対応も行う

[root@ldap-standby ~]# cd /etc/openldap/certs/
[root@ldap-standby certs]# openssl genrsa 2048 > server.key
[root@ldap-standby certs]# openssl req -new -key server.key -out server.csr    <-- JPのみ入力してあとはリターンキーのみで逃げる
[root@ldap-standby certs]# openssl x509 -in server.csr -out server.crt -req -signkey server.key -days 3650
 

これでldap-standbyの下地はMain側とほぼ同じになりました.

この段階で ldap-standbyを「LDAP Admin」で調べると
2022y11m20d_222339136.png
となる.

次に、Main側への接続情報を登録します

[root@ldap-standby ~]# vi syncrepl.ldif
dn: olcDatabase={2}mdb,cn=config
changetype: modify
add: olcSyncRepl
olcSyncRepl: rid=1
  provider=ldap://ldap-server:389/
  bindmethod=simple
  binddn="cn=Manager,dc=sybyl,dc=local"          <--- 一般ユーザでもいいかも
  credentials=xxxxxxxxxxxxxxxxxxxxx              <---"cn=Manager,dc=sybyl,dc=local"のパスワード
  type=refreshAndPersist
  interval=00:00:05:00
  searchbase="dc=sybyl,dc=local"
  scope=sub
  retry="60 10 300 3"
 
[root@ldap-standby ~]# ldapmodify -H ldapi:/// -f  syncrepl.ldif

実行直後にMain側からデータが移され、下記のようになる.
2022y11m20d_222844742.png

ログ

本当にデータがコピーされているかはログで確認します
ログと言ってもいまや journalctl で確認になりますが、

[root@ldap-standby ~]# journalctl -u slapd

client側

せっかくfailoverな仕組みを作ってclientが利用できなきゃ意味がない.
LDAP/Clientの「authselect - sssd」形式なら ldap_uri 欄にカンマ(,)区切りでLDAPサーバを記載します

[root@ldap-client ~]# vi /etc/sssd/sssd.conf
 :
ldap_uri = ldaps://ldap-server/ 
   ↓
ldap_uri = ldaps://ldap-server/,ldaps://ldap-standby/ 
 :
[root@ldap-client ~]# 
[root@ldap-client ~]# systemctl restart sssd

で完了

めも

「cn=config」もコピー出来たらなと思って作ってみたが、ダメだったldif

dn: cn=config
changetype: modify
add: olcSyncRepl
olcSyncRepl: rid=2
  provider=ldap://ldap-server/
  bindmethod=simple
  binddn="cn=config"
  credentials=xxxxxxxxxxxxxxxxxxxxxxxxxxxx
  type=refreshAndPersist
  interval=00:00:05:00
  searchbase="cn=config"
  retry="60 10 300 3"

トップ   編集 添付 複製 名前変更     ヘルプ   最終更新のRSS
Last-modified: 2022-11-20 (日) 23:05:17 (7d)