John A. Sullivan III wrote:
> Hello, all. We are experiencing a weird problem and have not been able
> to fix it. We have just renamed the top level of our tree from
> dc=old,dc=biz to dc=new,dc=com. All went very well (well, very well
> until we also changed the certificates and keys to be from the new
> Certificate Authority - but we have that sorted now, too) except one
> remaining error.
>
> Our Zimbra (6.0.5) mail server authenticates users against our CentOS
> 8.1 Directory Server. It is working but, every time a user tries to
> authenticate, we generate an error:
>
> slapi_search_internal ("CN=zimbra.new.com, OU=MailServers, DC=new,
DC=com", subtree, objectclass=*) err 32
>
> and in the access log we see:
> conn=174 SSL 128-bit RC4; client CN=zimbra.new.com,OU=MailServers,DC=new,DC=com;
issuer CN=newca.new.com,OU=PKI,DC=new,DC=com
> conn=173 SSL failed to map client certificate to LDAP DN (No such object)
>
> We then see the directory search user (we do not allow anonymous access)
> correctly bind and authenticate.
>
> It is as if the directory server is accidentally trying to do cert
> mapping and authenticate the mail server whenever it tries to establish
> an ldaps connection. As far as I understand, one needs to tell
> Directory Server to do this by adding a usercertificate attribute to the
> user we want to authenticate via X.509 cert. I've searched the entire
> database dump and nothing has that attribute. certmap.conf has been
> unchanged and is all commented out except for:
> certmap default default
>
> What is causing this and how do I fix it?
>
http://www.redhat.com/docs/manuals/dir-server/8.1/admin/Managing_SSL-Star...
http://www.redhat.com/docs/manuals/dir-server/8.1/admin/Managing_SSL-Usin...
and
http://directory.fedoraproject.org/wiki/Howto:CertMapping
> Our migration procedure was to stop dirsrv, dump the userRoot and
> NetscapeRoot databases, make all the substitutions via sed in dse.ldif
> (and .bak and .startOK), make all the substitutions via sed in the
Hmm . . .
strange. We had intentionally set them to "allow" in case we
ever do client certificate based authentication. We did not have a
problem until this recent change. I wonder what changed. Thanks -
disabling it altogether has solved the problem for now - John