<div dir="ltr">When I have had issues like this playing with ldap, it is because I get distracted by the ldap part and forget to check firewalls and other details. <div><br></div><div>So... not to be insulting but are you sure the firewall is enabled on both ends on port 636 for LDAPS. Are you certain that the ldaps is running on the default port?</div><div><br></div><div>Good luck,</div><div>Paul</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 20, 2015 at 10:17 AM, Keith Larson <span dir="ltr">&lt;<a href="mailto:klarson@k12group.net" target="_blank">klarson@k12group.net</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div style="font:10pt/normal Segoe UI;margin:16px 16px 4px;font-size-adjust:none;font-stretch:normal"><div><div>Let me expand on this further because I can see how your solution would work in a single environment, but that doesn&#39;t apply to my configuration.</div><div> </div><div>I have an application that needs to perform ldap queries against multiple/many ldap sources and it must do it over secure ldap.  I was able to make it work against eDirectory by exporting the root CA certificate (self-signed) from each tree and concatenating them into a single CA cert file.  Then I updated my openldap.conf to use that as the CA cert file.  Then my linux client trusts all certs signed by all of these different CA&#39;s.  All works perfectly against eDirectory.</div><div> </div><div>When I try to do the same thing for Active Directory, it works with a non-secure ldap connection just fine.  It is when I try to establish a secure ldap connection that I get the same error.  No matter what I have done with certs, I still get the same error, so it could just be a syntax error on my part.</div><div> </div><div>this command works:</div><div>ldapsearch -H <a>ldap://dc-fqdn</a> -x -D &quot;domain\user&quot; -w password -b &quot;dc=k12group,dc=local&quot; objectclass=user</div><div> </div><div>this command fails:</div><div><div>ldapsearch -H <a>ldaps://dc-fqdn</a> -x -D &quot;domain\user&quot; -w password -b &quot;dc=k12group,dc=local&quot; objectclass=user</div><div> </div><div>error returned:</div><div>ldap_sasl_bind(SIMPLE): Can&#39;t contact LDAP server (-1)</div></div><span class=""><span style="padding-right:0px;padding-left:0px;margin-bottom:5px;display:block"><span style="display:block"><br><span style="font-size:10pt;display:inline-block"><div>Keith Larson</div>
<div>Franklin Computer Services - K12group</div>
<div><a href="mailto:klarson@k12group.net" target="_blank">klarson@k12group.net</a></div>
<div><a href="tel:%28614%29%20561-4887" value="+16145614887" target="_blank">(614) 561-4887</a> (mobile)</div>
<div> </div></span></span></span><span style="margin-bottom:5px;display:block"> </span></span><div><span>&gt;&gt;&gt; Scott Merrill &lt;<a href="mailto:skippy@skippy.net" target="_blank">skippy@skippy.net</a>&gt; 1/19/2015 2:43 PM &gt;&gt;&gt;<br></span><div><div class="h5"><div><div><br>&gt; On Jan 19, 2015, at 2:06 PM, Keith Larson &lt;<a href="mailto:klarson@k12group.net" target="_blank">klarson@k12group.net</a>&gt; wrote:<br>&gt; <br>&gt; I&#39;m trying to establish a secure ldap connection to AD using ldapsearch from an OpenSuSE box.  I&#39;m having a hard time getting the certificate portion worked out.  I had someone walk me through the setup on the AD side and we could make a connection with ADSIedit, but not from the linux client.<br>&gt;  <br><br>Does OpenSuSE use sssd? <br><br>This is the relevant section that we have in our sssd.conf file for RHEL:<br><br>[domain/LDAP]<br>cache_credentials = true<br>auth_provider = ldap<br>id_provider = ldap<br>enumerate = false<br>ldap_uri = ldaps://ad1.domain.local<br>ldap_cacert = /etc/openldap/cacerts/ActiveDirectory-CA.pem<br>ldap_referrals = false<br>ldap_id_use_start_tls = false<br>ldap_search_base = dc=domain,dc=local<br>ldap_default_bind_dn = ldap_auth@domain.local<br>ldap_default_authtok_type = password<br>ldap_default_authtok = SecurePassW0rdHere!<br>ldap_schema = AD<br>ldap_user_principal = userPrincipalName<br>ldap_user_fullename = displayName<br>ldap_user_name = sAMAccountName<br>ldap_user_home_directory = unixHomeDirectory<br>ldap_user_shell = loginShell<br><br>We created an AD user named ldap_auth and gave it a strong non-expiring password. The only permissions on this account are to be able to perform LDAP binds.  We then had our Windows admins export the public key from the AD Certificate Authority and use that to ensure that our Linux systems can trust the AD server certificates.<br><br>Then configure PAM correctly.<br><br>/etc/pam.d/system-auth-ac:<br>auth        required      pam_env.so<br>auth        sufficient    pam_unix.so nullok try_first_pass<br>auth        requisite     pam_succeed_if.so uid &gt;= 500 quiet<br>auth        sufficient    pam_sss.so use_first_pass<br>auth        required      pam_deny.so<br><br>account     required      pam_unix.so broken_shadow<br>account     sufficient    pam_localuser.so<br>account     sufficient    pam_succeed_if.so uid &lt; 500 quiet<br>account     [default=bad success=ok user_unknown=ignore] pam_sss.so<br>account     required      pam_permit.so<br><br>password    requisite     pam_cracklib.so try_first_pass retry=3 type=<br>password    sufficient    pam_unix.so md5 shadow nullok try_first_pass use_authtok<br>password    sufficient    pam_sss.so use_authtok<br>password    required      pam_deny.so<br><br>session     optional      pam_keyinit.so revoke<br><br>/etc/pam.d/password-auth-ac:<br>auth        required      pam_env.so<br>auth        sufficient    pam_unix.so nullok try_first_pass<br>auth        requisite     pam_succeed_if.so uid &gt;= 500 quiet<br>auth        sufficient    pam_sss.so use_first_pass<br>auth        required      pam_deny.so<br><br>account     required      pam_unix.so broken_shadow<br>account     sufficient    pam_localuser.so<br>account     sufficient    pam_succeed_if.so uid &lt; 500 quiet<br>account     [default=bad success=ok user_unknown=ignore] pam_sss.so<br>account     required      pam_permit.so<br><br>password    requisite     pam_cracklib.so try_first_pass retry=3 type=<br>password    sufficient    pam_unix.so md5 shadow nullok try_first_pass use_authtok<br>password    sufficient    pam_sss.so use_authtok<br>password    required      pam_deny.so<br><br>session     optional      pam_keyinit.so revoke<br><br><br>Then symlink those to the ones that are actually used by the system:<br># ln -s /etc/pam.d/system-auth-ac /etc/pam.d/system-auth<br># ln -s /etc/pam.d/password-auth-ac /etc/pam.d/password-auth<br><br>We use Puppet to manage all of the above.<br><br>Cheers,<br>Scott<br><br><br>_______________________________________________<br>colug-432 mailing list<br><a href="mailto:colug-432@colug.net" target="_blank">colug-432@colug.net</a><br><a href="http://lists.colug.net/mailman/listinfo/colug-432" target="_blank">http://lists.colug.net/mailman/listinfo/colug-432</a><br></div></div></div></div></div></div></div>
<br>_______________________________________________<br>
colug-432 mailing list<br>
<a href="mailto:colug-432@colug.net">colug-432@colug.net</a><br>
<a href="http://lists.colug.net/mailman/listinfo/colug-432" target="_blank">http://lists.colug.net/mailman/listinfo/colug-432</a><br>
<br></blockquote></div><br></div>