[colug-432] secure ldap connection to Active Directory

[Paul Schwendenman]

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 (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/b426e2c8/attachment-0001.html