[colug-432] secure ldap connection to Active Directory

[Keith Larson]

yes, I am certain of all of that.
 >>> Paul Schwendenman <schwendenman.paul at gmail.com> 1/20/2015 10:27 AM >>>
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. 

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?

Good luck,
Paul

On Tue, Jan 20, 2015 at 10:17 AM, Keith Larson <klarson at k12group.net> wrote:


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.
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.
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.
this command works:
ldapsearch -H ldap://dc-fqdn -x -D "domain\user" -w password -b "dc=k12group,dc=local" objectclass=user
this command fails:
ldapsearch -H ldaps://dc-fqdn -x -D "domain\user" -w password -b "dc=k12group,dc=local" objectclass=user
error returned:
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

Keith Larson
Franklin Computer Services - K12group
klarson at k12group.net
(614) 561-4887
( tel:%28614%29%20561-4887)  (mobile)
>>> Scott Merrill <skippy at skippy.net> 1/19/2015 2:43 PM >>>

> On Jan 19, 2015, at 2:06 PM, Keith Larson <klarson at k12group.net> wrote:
> 
> 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.
> 

Does OpenSuSE use sssd? 

This is the relevant section that we have in our sssd.conf file for RHEL:

[domain/LDAP]
cache_credentials = true
auth_provider = ldap
id_provider = ldap
enumerate = false
ldap_uri = ldaps://ad1.domain.local
ldap_cacert = /etc/openldap/cacerts/ActiveDirectory-CA.pem
ldap_referrals = false
ldap_id_use_start_tls = false
ldap_search_base = dc=domain,dc=local
ldap_default_bind_dn = ldap_auth at domain.local
ldap_default_authtok_type = password
ldap_default_authtok = SecurePassW0rdHere!
ldap_schema = AD
ldap_user_principal = userPrincipalName
ldap_user_fullename = displayName
ldap_user_name = sAMAccountName
ldap_user_home_directory = unixHomeDirectory
ldap_user_shell = loginShell

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.

Then configure PAM correctly.

/etc/pam.d/system-auth-ac:
auth required pam_env.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth sufficient pam_sss.so use_first_pass
auth required pam_deny.so

account required pam_unix.so broken_shadow
account sufficient pam_localuser.so
account sufficient pam_succeed_if.so uid < 500 quiet
account [default=bad success=ok user_unknown=ignore] pam_sss.so
account required pam_permit.so

password requisite pam_cracklib.so try_first_pass retry=3 type=
password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok
password sufficient pam_sss.so use_authtok
password required pam_deny.so

session optional pam_keyinit.so revoke

/etc/pam.d/password-auth-ac:
auth required pam_env.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth sufficient pam_sss.so use_first_pass
auth required pam_deny.so

account required pam_unix.so broken_shadow
account sufficient pam_localuser.so
account sufficient pam_succeed_if.so uid < 500 quiet
account [default=bad success=ok user_unknown=ignore] pam_sss.so
account required pam_permit.so

password requisite pam_cracklib.so try_first_pass retry=3 type=
password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok
password sufficient pam_sss.so use_authtok
password required pam_deny.so

session optional pam_keyinit.so revoke


Then symlink those to the ones that are actually used by the system:
# ln -s /etc/pam.d/system-auth-ac /etc/pam.d/system-auth
# ln -s /etc/pam.d/password-auth-ac /etc/pam.d/password-auth

We use Puppet to manage all of the above.

Cheers,
Scott


_______________________________________________
colug-432 mailing list
colug-432 at colug.net
http://lists.colug.net/mailman/listinfo/colug-432

_______________________________________________
colug-432 mailing list
colug-432 at colug.net
http://lists.colug.net/mailman/listinfo/colug-432


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.colug.net/pipermail/colug-432/attachments/20150120/745d1018/attachment.html