Hide Forgot
Created attachment 491111 [details] Test Description of problem: When configuring autofs through ldap such that server requires client certificates, connection does not work, i.e. mountpoint cannot be accessed. When client verification is dropped (but SSL/TLS and server verification is still enabled), everything works fine. According to man page of auto.master, automounter should be able to read openldap clients configuration (/etc/openldap/ldap.conf and ldaprc) and it is (server verification works fine), but it seems that client certificates are omitted. Version-Release number of selected component (if applicable): autofs-5.0.5-30.el6 How reproducible: Always Steps to Reproduce: 1. Configure autofs to works with openldap over SSL/TLS with both server and client certificates, create mountpoint setup on ldap server, try to access it. Additional info: For a detailed reproducer including all necessary configuration, see attached test, it is written using beakerlib (install beakerlib package). Run it as root from the test directory by 'bash runtesh.sh'.
There are some problems with the test although after all the playing around I'm not sure I remember all the things I did. In any case the test won't be used as it is within the autofs regression test suite. I would need to re-write it in the same way as all the other existing tests. I think that the certificates don't work but I can't be sure about that. After trying to manually configure ldap to use them I failed to get ldapsearch to work so I created my own. The test will add multiple lines to rsyslog.conf upon re-running the test causing syslog to log messages multiple times witch makes the log hard to follow (and it will add multiple entries to the hosts file as well). The ldap configuration set in /etc/sysconfig/autofs used doesn't match the ldif data loaded into the LDAP database. The ldif data uses attributes of ou for the map and cn for the key but the configuration didn't specify the ou attribute for the map, IIRC. In any case it's a matter of setting them consistently or not setting the entries in the configuration and letting autofs work it out (which also requires the ldif entries to use a consistent set of attributes). There is a small syntax error in the map entry for the indirect mount key loop. In the map entry the location was given as ldap://my-domain.com/ou=auto.misc,dc=my-domain,dc=com which is mixed old and new syntax and caused some confusion for autofs. There is probably a bug in there somewhere but I'm inclined to say using mixed old and new syntax isn't supported. The old syntax is <prot>:<server name>:<dn> and the newer syntax is <proto>://<server name>/<dn>. I think including the "//" in what probably looks like the old syntax to autofs caused the confusion. Replacing the ":" before the dn with a "/" fixes this problem. After all this I found that the test still wouldn't work but setting up autofs manually using each of the test configurations worked fine for TLS and SSL. I really have no idea why. Ian
Ian, I am sorry that the reproducing test is in such a bad condition, I was preparing it in such a hurry. I will correct it (hopefully today or tomorrow) according to your hints and write here a more detailed description of the problem. The test now does a slightly more stuff which may obfuscate the problem with client certificates. Anyway, I am pretty sure that client certificates do not work right now.
(In reply to comment #2) > Ian, I am sorry that the reproducing test is in such a bad condition, I was > preparing it in such a hurry. I will correct it (hopefully today or tomorrow) > according to your hints and write here a more detailed description of the > problem. The test now does a slightly more stuff which may obfuscate the > problem with client certificates. Anyway, I am pretty sure that client > certificates do not work right now. OK, that would be useful for when I convert it to run under the autofs workflow tests, assuming we can identify a problem. I know you believe that the certification doesn't work but the procedure you used (the way I originally expected people to use client certificates) did work for me. We also have the ability to use the SASL EXTERNAL mechanism now that allows the mapping of a user so that LDAP server ACLs can be used. Ian
At this stage I wasn't able to reproduce this problem and since we have several regression tests using certificate authentication I need to wait until I get enough to duplicate the problem. Ondrej, if you have anything more on this please post it. If there is no further information yet I'll need to defer this until 6.3.
I cannot reproduce it as well right now. There seems to be a serious flaw in the test, since my configuration does not work at all (even without SSL/TLS). Let met try it once more during this weekend. However, I am pretty sure that ldap client certificates support does not work in autofs. Thus I am proposing this bug for the next release and diving into details to correct current confusing reproducer.
(In reply to comment #7) > I cannot reproduce it as well right now. There seems to be a serious flaw in > the test, since my configuration does not work at all (even without SSL/TLS). > Let met try it once more during this weekend. However, I am pretty sure that > ldap client certificates support does not work in autofs. Thus I am proposing > this bug for the next release and diving into details to correct current > confusing reproducer. Please, since your sure it doesn't work, look at test autofs-tests/bugzillas/bz607785 within an autofs checkout and see if you can pick the flaw in the test and verify correcting it makes the test fail, and we can discus that.
Since we don't have feedback according to the comments above I'm going to defer this. If we don't get feedback during the next update cycle I'll need to close this.
As per comment #10 I'm going to close this bug. If this is still a problem and you can provide the needed feedback plaes re-open the bug.