在ldap-2.4中启用TLS之后，不能使用EXTERNALauthentication

我使用以下LDIF文件来激活LDAP服务器的TLS支持：

dn: cn=config changetype: modify add: olcTLSCipherSuite olcTLSCipherSuite: NORMAL - add: olcTLSCRLCheck olcTLSCRLCheck: none - add: olcTLSVerifyClient olcTLSVerifyClient: never - add: olcTLSCACertificateFile olcTLSCACertificateFile: /etc/ssl/certs/CA.crt - add: olcTLSCertificateFile olcTLSCertificateFile: /etc/ssl/certs/server.pem - add: olcTLSCertificateKeyFile olcTLSCertificateKeyFile: /etc/ssl/private/key.pem

并使用以下LDIF强制客户端连接的TLS使用情况：

 dn: cn=config changetype: modify add: olcSecurity olcSecurity: tls=1

在此之后，我不能再使用“-Y EXTERNAL”来读取或修改configuration模式。例如，如果我运行，我得到SASL错误：

 $ sudo ldapsearch -Q -Y EXTERNAL -H ldapi:/// -b "" -LLL -s base -Z supportedSASLMechanisms ldap_sasl_interactive_bind_s: Authentication method not supported (7) additional info: SASL(-4): no mechanism available:

如果我检查支持的SASL机制：

 $ sudo ldapsearch -x -H ldapi:/// -b "" -LLL -s base -Z supportedSASLMechanisms dn: supportedSASLMechanisms: DIGEST-MD5 supportedSASLMechanisms: CRAM-MD5 supportedSASLMechanisms: NTLM supportedSASLMechanisms: PLAIN supportedSASLMechanisms: LOGIN

我真的不能看到列表中包含的外部。我在这里错过了什么？

这是在Ubuntu-12.04和slapd-2.4.31上。

如果无法访问正在运行的configuration，则必须停止slapd并脱机编辑configuration。

停止slapd ： service slapd stop
将configuration数据库转储到文本文件： slapcat -F /etc/ldap/slapd.d -b cn=config -l config.ldif
移动现有的configuration数据库： mv /etc/ldap/slapd.d{,.old}
创build一个新的空configuration数据库：

mkdir /etc/ldap/slapd.d chown --reference=/etc/ldap/slapd.d.old /etc/ldap/slapd.d chmod --reference=/etc/ldap/slapd.d.old /etc/ldap/slapd.d
编辑转储的config.ldif以删除您的olcSecurity设置（或将olcRootDN和olcRootPW添加到cn=config ，或者您喜欢的任何其他更改）
将已编辑的LDIF加载到新的空数据库中： slapadd -F /etc/ldap/slapd.d -b cn=config -l config.ldif

（以上假设您的configuration位于/etc/ldap/slapd.d ，这是Debian和Ubuntu中的默认configuration。）

请注意，一个完整LDIF的slapadd应该总是进入一个空的数据库; 所以如果你犯了一个错误， slapadd失败，请确保在再次尝试之前清除部分数据库。

您可以在OpenLDAPpipe理指南以及相关手册页中find更多信息。

查看代码：在服务器端，在servers / slapd / daemon.c中，EXTERNAL的授权是在accept()连接accept()之后立即使用uid和gid设置的。稍后，在servers / slapd / connection.c中，如果TLS处于活动状态，则会使用客户端证书中的名称来覆盖它。由于您没有提供客户端证书，此时authid被NULL覆盖，使得EXTERNAL不可用。

简而言之，如果TLS处于活动状态，则不使用uid + gid authid。根据你的观点，这可能被认为是一个错误; 理想情况下，它会回落到高位身份证。

也就是说，ldapi上的TLS实际上并不是必须的，因为本地套接字已经提供了完全的隐私; 所以你可以在你自己的数据库上设置olcSecurity ，而不是为前端和cn=config （见例如这篇文章），或者你可以使用ssf=而不是tls=并且适当地设置olcLocalSSF 。或者，您可以使用不同的DN作为cn=config的pipe理器，以便不依赖于peercredfunction。

谢谢rtandy。我真的不想把它放在ldapi上，但是并没有意识到它也会受到影响。

问题是EXTERNAL是我可以修改cn=config的唯一方法，因为我已经失去了访问权限，并没有按照build议创build另一个cn=config admin，还有其他方法可以解决这个问题吗？