LDAP's Problem (Mail 紀錄)

Dear All,

最近進行將LDAP由實體Server轉至虛擬Server上
大概將遇到的狀況說明

1. 一開始上線時遇到無法由學校webmail修改LDAP密碼
是因為ACL權限的問題
並非是因為 ppolicy 群組的部分 ( 因為查詢錯誤log紀錄都會查到 ppolicy 相關的設定，因此被誤導 )
在新版的openldap上由於會有兩組預設的ACL
##ACL 1
# enable on-the-fly configuration (cn=config)
#database config
access to *
by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage
by * none
##ACL 2
# enable server status monitoring (cn=monitor)
#database monitor
access to *
by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" read
by dn.exact="cn=Manager,ou=admin,dc=niu,dc=edu,dc=tw" read
by * none

依照之前的習慣將要新增的兩組ACL加在後面
##ACL 3
access to attrs=userPassword
by self write
by anonymous read
by dn.exact="cn=Manager,ou=admin,dc=niu,dc=edu,dc=tw" write
by * none
##ACL 4
access to *
by self write
by anonymous read
by dn.exact="cn=Manager,ou=admin,dc=niu,dc=edu,dc=tw" write
by users read
by * none

這邊由於ACL 1及 ACL 2就已經指向對於 * 進行設定
導致ACL 3並沒有任何效用
也因此我測試環境中以"cn=Manager,ou=admin,dc=niu,dc=edu,dc=tw"進行密碼修改時會符合ACL 4而成立
所以會有為什麼測試環境的openwebmail可以更改密碼，而學校的webmail不行的狀況
故我已經取消了ppolicy的檢查認證方式

2. 校園入口網站無法登入的狀況
這部分有兩個原因造成

2.1 依舊是ACL權限設定上的問題
在新版的LDAP設定上針對ACL有較嚴謹的設定

下面這是舊版ACL的設定
##ACL 5
access to attrs=userPassword
by self write
by * read
by * auth
##ACL 6
access to *
by * read

會發現任何人都可以對任何人的資訊進行讀取，這部分其實會有隱憂
因此改成
##ACL 7
access to attrs=userPassword
by self write
by anonymous read
by dn.exact="cn=Manager,ou=admin,dc=niu,dc=edu,dc=tw" write
by * none
##ACL 8
access to *
by self write
by dn.exact="cn=Manager,ou=admin,dc=niu,dc=edu,dc=tw" write
by * none

但是在校園入口網站透過POP3登入時
會觸發ACL 8的部分
並且是以anonymous進行資料的核對
但這邊並沒有針對anonymous 進行任何權限設定而失敗 (直接套用 by * none)
若是完全不加以使用ACL設定則會依照預設值讓anonymous讀取，因此就會成功
至於一開始測試的時候POP3認證是可以運作的
初步判定應該是那時候的ACL規則相互抵抗而失效，改採以預設規則進行

2.2 在移轉的過程中，我於slapd.conf中並未加入下面這行設定
password-hash {CRYPT}

這是Linux系統本身預設的密碼編碼設定
因此在經過修改密碼過後會造成密碼格式不同而導致POP3認證失敗
加入這一行設定後，再透過更改密碼的手續
POP3認證就會成功

這部分因為不知道會有多少使用者受影響
我主要是因為自己的兩個帳號在測試的過程中一職修改過密碼，所以都必須透過此步驟才能夠讓POP3認證通過
因此明天可能要決定一下是不是要套用舊的LDAP資料 ( 會影響這一兩天新增加的使用者或是有修改過密碼的使用者 )
或是讓反應入口網站無法登入的使用者測試是否可以登入webmail，並透過webmail的方式進行修改密碼
當然最好還是希望入口網站在未來可以增加直接使用LDAP或是Radius認證的方式

這一部分就等明天上班後有討論結果我再加以修改

以上是在半夜時趁使用者應該較少數量而進行的測試動作
希望影響的範圍不會太大 Orz

很抱歉因為不熟悉而導致這一次移轉LDAP的過程出現那麻多問題Orz
只能說版本的變動讓我有非常陌生的感覺

======================補充 2013/05/30===================
看了一下以上信件~我看不懂XD
所以請育豪幫忙拉一下目前的acl設定，設定如下....(這樣就很清楚了)

# - modulepath is architecture dependent value (32/64-bit system)
# - back_sql.la overlay requires openldap-server-sql package
# - dyngroup.la and dynlist.la cannot be used at the same time

modulepath /usr/lib/openldap
# modulepath /usr/lib64/openldap

# moduleload accesslog.la
# moduleload auditlog.la
# moduleload back_sql.la
# moduleload chain.la
# moduleload collect.la
# moduleload constraint.la
# moduleload dds.la
# moduleload deref.la
# moduleload dyngroup.la
# moduleload dynlist.la
# moduleload memberof.la
# moduleload pbind.la
# moduleload pcache.la
#moduleload ppolicy.la
# moduleload refint.la
# moduleload retcode.la
# moduleload rwm.la
# moduleload seqmod.la
# moduleload smbk5pwd.la
# moduleload sssvlv.la
moduleload syncprov.la
# moduleload translucent.la
# moduleload unique.la
# moduleload valsort.la

# The next three lines allow use of TLS for encrypting connections using a
# dummy test certificate which you can generate by changing to
# /etc/pki/tls/certs, running "make slapd.pem", and fixing permissions on
# slapd.pem so that the ldap user or group can read it. Your client software
# may balk at self-signed certificates, however.
# TLSCACertificateFile /etc/pki/tls/certs/ca-bundle.crt
# TLSCertificateFile /etc/pki/tls/certs/slapd.pem
# TLSCertificateKeyFile /etc/pki/tls/certs/slapd.pem

# 2012-02-21 add by cowman
TLSCipherSuite HIGH:MEDIUM:+SSLv2:+SSLv3:RSA
#TLSCACertificateFile /etc/openldap/cacerts/server.pem
#TLSCertificateFile /etc/openldap/cacerts/server.pem
#TLSCertificateKeyFile /etc/openldap/cacerts/server.pem
#TLSCACertificateFile /etc/openldap/cacerts/root.crt
#TLSCertificateFile /etc/openldap/cacerts/server.crt
#TLSCertificateKeyFile /etc/openldap/cacerts/server.crt
TLSCACertificateFile /etc/openldap/TWGA/root.crt
TLSCertificateFile /etc/openldap/TWGA/server.crt
TLSCertificateKeyFile /etc/openldap/TWGA/server.crt
TLSVerifyClient allow


# Sample security restrictions
# Require integrity protection (prevent hijacking)
# Require 112-bit (3DES or better) encryption for updates
# Require 63-bit encryption for simple bind
# security ssf=1 update_ssf=112 simple_bind=64

# Sample access control policy:
# Root DSE: allow anyone to read it
# Subschema (sub)entry DSE: allow anyone to read it
# Other DSEs:
# Allow self write access
# Allow authenticated users read access
# Allow anonymous users to authenticate
# Directives needed to implement policy:
# access to dn.base="" by * read
# access to dn.base="cn=Subschema" by * read
# access to *
# by self write
# by users read
# by anonymous auth
#
# if no access controls are present, the default policy
# allows anyone and everyone to read anything but restricts
# updates to rootdn. (e.g., "access to * by * read")
#
# rootdn can always read and write EVERYTHING!

access to attrs=userPassword
by self write
by anonymous read
by dn.exact="cn=Manager,ou=admin,dc=niu,dc=edu,dc=tw" write
by * none

access to *
by self write
by anonymous read
by dn.exact="cn=Manager,ou=admin,dc=niu,dc=edu,dc=tw" write
by users read
by * none

# enable on-the-fly configuration (cn=config)
#database config
access to *
by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage
by * none

# enable server status monitoring (cn=monitor)
#database monitor
access to *
by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" read
by dn.exact="cn=Manager,ou=admin,dc=niu,dc=edu,dc=tw" read
by * none