Ldap

Openldap - slap_access_allowed: auth access denied by =0 - 無法對使用者進行身份驗證

  • February 9, 2021

最近我將我的 openldap 伺服器配置為使用證書。但在這樣做的過程中,也弄亂了不安全的埠。現在,身份驗證根本不適用於任何使用者。我正在使用 python-ldap 客戶端來創建連接。

import ldap
import os
l = ldap.initialize('ldap://<ip>:1389')
l.set_option(ldap.OPT_REFERRALS, 0)
l.set_option(ldap.OPT_PROTOCOL_VERSION, 3)
l.simple_bind_s('uid=myuser,ou=People,ou=myorg,dc=my,dc=com', 'mypasspw')

我正在接受ldap.INVALID_CREDENTIALS: {'desc': 'Invalid credentials'}所有使用者的請求。

我在調試模式下啟動了 ldap 伺服器,這裡是日誌。

6021594b connection_read(12): checking for input on id=1000
ber_get_next
ldap_read: want=8, got=8
 0000:  30 46 02 01 01 60 41 02                            0F...`A.
ldap_read: want=64, got=64
 0000:  01 03 04 32 75 69 64 3d  73 62 61 74 72 61 2c 6f   ...2uid=myuser,o
 0010:  75 3d 50 65 6f 70 6c 65  2c 6f 75 3d 62 6c 75 65   u=People,ou=myo
 0020:  70 6c 61 6e 65 74 2c 64  63 3d 63 69 65 6e 61 2c   rg,dc=my,
 0030:  64 63 3d 63 6f 6d 80 08  73 62 61 74 72 61 70 77   dc=com..mypasspw
ber_get_next: tag 0x30 len 70 contents:
ber_dump: buf=0x7f5f1c2fe390 ptr=0x7f5f1c2fe390 end=0x7f5f1c2fe3d6 len=70
 0000:  02 01 01 60 41 02 01 03  04 32 75 69 64 3d 73 62   ...`A....2uid=my
 0010:  61 74 72 61 2c 6f 75 3d  50 65 6f 70 6c 65 2c 6f   user,ou=People,o
 0020:  75 3d 62 6c 75 65 70 6c  61 6e 65 74 2c 64 63 3d   u=myorg,dc=
 0030:  63 69 65 6e 61 2c 64 63  3d 63 6f 6d 80 08 73 62   my,dc=com..my
 0040:  61 74 72 61 70 77                                  passpw
6021594b op tag 0x60, time 1612798283
ber_get_next
ldap_read: want=8 error=Resource temporarily unavailable
6021594b conn=1000 op=0 do_bind
ber_scanf fmt ({imt) ber:
ber_dump: buf=0x7f5f1c2fe390 ptr=0x7f5f1c2fe393 end=0x7f5f1c2fe3d6 len=67
 0000:  60 41 02 01 03 04 32 75  69 64 3d 73 62 61 74 72   `A....2uid=myuse
6021594b daemon: activity on 1 descriptor
6021594b daemon: activity on:
6021594b daemon: epoll: listen=7 active_threads=0 tvp=zero
6021594b daemon: epoll: listen=8 active_threads=0 tvp=zero
 0010:  61 2c 6f 75 3d 50 65 6f  70 6c 65 2c 6f 75 3d 62   a,ou=People,ou=
 0020:  6c 75 65 70 6c 61 6e 65  74 2c 64 63 3d 63 69 65   myorg,dc=my
 0030:  6e 61 2c 64 63 3d 63 6f  6d 80 08 73 62 61 74 72   ,dc=com..mypas
 0040:  61 70 77                                           spw
ber_scanf fmt (m}) ber:
ber_dump: buf=0x7f5f1c2fe390 ptr=0x7f5f1c2fe3cc end=0x7f5f1c2fe3d6 len=10
 0000:  00 08 73 62 61 74 72 61  70 77                     ..mypasspw
6021594b >>> dnPrettyNormal: <uid=myuser,ou=People,ou=myorg,dc=my,dc=com>
=> ldap_bv2dn(uid=myuser,ou=People,ou=myorg,dc=my,dc=com,0)
<= ldap_bv2dn(uid=myuser,ou=People,ou=myorg,dc=my,dc=com)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(uid=myuser,ou=People,ou=myorg,dc=my,dc=com)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(uid=myuser,ou=people,ou=myorg,dc=my,dc=com)=0
6021594b <<< dnPrettyNormal: <uid=myuser,ou=People,ou=myorg,dc=my,dc=com>, <uid=myuser,ou=people,ou=myorg,dc=my,dc=com>
6021594b do_bind: version=3 dn="uid=myuser,ou=People,ou=myorg,dc=my,dc=com" method=128
6021594b ==> mdb_bind: dn: uid=myuser,ou=People,ou=myorg,dc=my,dc=com
6021594b mdb_dn2entry("uid=myuser,ou=people,ou=myorg,dc=my,dc=com")
6021594b => mdb_dn2id("uid=myuser,ou=people,ou=myorg,dc=my,dc=com")
6021594b <= mdb_dn2id: got id=0xb
6021594b => mdb_entry_decode:
6021594b <= mdb_entry_decode
6021594b => access_allowed: result not in cache (userPassword)
6021594b => access_allowed: auth access to "uid=myuser,ou=People,ou=myorg,dc=my,dc=com" "userPassword" requested
6021594b => dn: [1]
6021594b => dn: [2] cn=subschema
6021594b => acl_get: [3] attr userPassword
6021594b => acl_mask: access to entry "uid=myuser,ou=People,ou=myorg,dc=my,dc=com", attr "userPassword" requested
6021594b => acl_mask: to value by "", (=0)
6021594b <= check a_dn_pat: cn=webadm,dc=webadm
6021594b <= acl_mask: no more <who> clauses, returning =0 (stop)
6021594b => slap_access_allowed: auth access denied by =0
6021594b => access_allowed: no more rules
6021594b send_ldap_result: conn=1000 op=0 p=3
6021594b send_ldap_result: err=49 matched="" text=""
6021594b send_ldap_response: msgid=1 tag=97 err=49
ber_flush2: 14 bytes to sd 12
 0000:  30 0c 02 01 01 61 07 0a  01 31 04 00 04 00         0....a...1....
ldap_write: want=14, written=14
 0000:  30 0c 02 01 01 61 07 0a  01 31 04 00 04 00         0....a...1....
^C6021594f daemon: shutdown requested and initiated.
6021594f daemon: closing 7
6021594f daemon: closing 8
6021594f connection_closing: readying conn=1000 sd=12 for close
6021594f connection_close: conn=1000 sd=12
6021594f daemon: removing 12
6021594f slapd shutdown: waiting for 0 operations/tasks to finish
6021594f slapd shutdown: initiated
6021594f slapd destroy: freeing system resources.
6021594f syncinfo_free: rid=011
6021594f slapd stopped.

我懷疑是某些東西不允許訪問 userPassword 但我不知道是什麼。我沒有接觸 olcAccess 配置,它們是:

olcAccess: to dn.base="" by * read
olcAccess: to dn.base="cn=Subschema" by * read
olcAccess: to * by dn="cn=webadm,dc=webADM" write
olcAccess: to * by self write by users read by anonymous auth

我在哪裡可以看得更遠?現在有點卡住了。

首先,看起來您正在以明文形式通過網路發送密碼。不要那樣做。獲取某種 TLS,無論是starttls 還是 LDAPS

此外,dn.base=""並且dn.base="cn=Subschema"通常由與您將應用 ACL 的後端不同的後端控制,因此您可能需要檢查您是否甚至需要放置它們的那些行。

對於您的實際問題: OpenLDAP ACL 是第一場比賽獲勝的情況。此外,所有行都以隱含的by * none. 因此,olcAccess: to * by dn="cn=webadm,dc=webADM" writeis Effective olcAccess: to * by dn="cn=webadm,dc=webADM" write by * none,這意味著您的下一行永遠不會被解析,因為您已經有一個匹配項。(流控制可以改變一些事情,但你可能還不需要它。)

標準:

olcAccess: to *
 by dn="cn=webadm,dc=webADM" write
 by self write
 by users read
 by anonymous auth

流量控制:

olcAccess: to *
 by group.exact="cn=ldap-admins,ou=groups,dc=example,dc=com" write
 by group.exact="cn=ldap-servers,ou=groups,dc=example,dc=com" read
 by dn.exact="cn=webadm,ou=users,dc=example,dc=com" write
 by * break
olcAccess: to attr=userPassword
 by self write
 by * auth
olcAccess: to attrs=member
 by set="this/owner & this/owner/member* & user" write
 by users read
olcAccess: to *
 by self write
 by users read
 by anonymous auth

(是的,你可以讓你的 webadm 成為 ldap-admins 的一部分,但實際上我不知道你在做什麼或你的系統的範圍。我還舉了最常用的集合作為例子萬一這在某些時候很方便。)

引用自:https://serverfault.com/questions/1052832