<html><head>
<meta content="IE=edge" http-equiv="X-UA-Compatible">
<meta name="Generator" content="Novell Groupwise Client (Version 14.0.0 Build: 115243)">
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head><body style="font: 10pt/normal Segoe UI; margin: 16px 16px 4px; font-size-adjust: none; font-stretch: normal;"><div id="GroupWiseSection_1421774995000_klarson@k12group.net_59511A0513870000BD1BF681F57056B0_" class="GroupWiseMessageBody"><div>yes, I am certain of all of that.</div><span style="margin-bottom: 5px; display: block;"> </span><div id="GroupWiseSection_1421767674000_schwendenman.paul@gmail.com" class="GroupWiseMessageBody"><span class="GroupwiseReplyHeader">>>> Paul Schwendenman <schwendenman.paul@gmail.com> 1/20/2015 10:27 AM >>><br></span><div>
<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"><<a href="mailto:klarson@k12group.net" target="_blank">klarson@k12group.net</a>></span> wrote:<br><blockquote style="margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;" class="gmail_quote">
<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'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'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 "domain\user" -w password -b "dc=k12group,dc=local" objectclass=user</div><div> </div><div>this command fails:</div><div><div>ldapsearch -H <a>ldaps://dc-fqdn</a> -x -D "domain\user" -w password -b "dc=k12group,dc=local" objectclass=user</div><div> </div><div>error returned:</div><div>ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)</div></div><span><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" target="_blank" value="+16145614887">(614) 561-4887</a> (mobile)</div>
<div> </div></span></span></span><span style="margin-bottom: 5px; display: block;"> </span></span><div><span>>>> Scott Merrill <<a href="mailto:skippy@skippy.net" target="_blank">skippy@skippy.net</a>> 1/19/2015 2:43 PM >>><br></span><div><div class="h5"><div><div><br>> On Jan 19, 2015, at 2:06 PM, Keith Larson <<a href="mailto:klarson@k12group.net" target="_blank">klarson@k12group.net</a>> wrote:<br>> <br>> I'm trying to establish a secure ldap connection to AD using ldapsearch from an OpenSuSE box. I'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>> <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 >= 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 < 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 >= 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 < 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>
</div></div></div></body></html>