Al Licause
HP L2 UNIX Network Services
HP Customer Support Center
Hours 7am-3pm Pacific time USA
Manager: tom.cernilli(a)hp.com
-----Original Message-----
From: sssd-users-bounces(a)lists.fedorahosted.org
[mailto:sssd-users-bounces@lists.fedorahosted.org] On Behalf Of Stephen Gallagher
Sent: Thursday, August 01, 2013 12:21 PM
To: sssd-users(a)lists.fedorahosted.org
Subject: Re: [SSSD-users] Use of TLS security certificates in sssd for ldap authentication
?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 08/01/2013 02:46 PM, Licause, Al (CSC AMS BCS - UNIX/Linux Network
Support) wrote:
Please see my responses in line....
Al Licause HP L2 UNIX Network Services HP Customer Support Center
Hours 7am-3pm Pacific time USA Manager: tom.cernilli(a)hp.com
-----Original Message----- From:
sssd-users-bounces(a)lists.fedorahosted.org
[mailto:sssd-users-bounces@lists.fedorahosted.org] On Behalf Of
Stephen Gallagher Sent: Thursday, August 01, 2013 11:31 AM To:
sssd-users(a)lists.fedorahosted.org Subject: Re: [SSSD-users] Use of TLS
security certificates in sssd for ldap authentication ?
On 08/01/2013 02:13 PM, Licause, Al (CSC AMS BCS - UNIX/Linux Network
Support) wrote:
> I have been testing different configurations of sssd and RHEL
> V6.3 and V6.4.
> The sssd version on RHEL V6.3 is sssd-1.8.0-32.el6.x86_64
> The sssd version on RHEL V6.4 is sssd-1.9.2-82.el6.x86_64
> Recently in reviewing my configuration and comparing same to a
> customers sssd.conf I noticed
> that I was not able to authenticate ldap users on the RHEL V6.3
> system without some reference
> to a TLS security certificate. More to the point, you must point
> specifically at the
> certificate itself and not just the directory in which the
> certificate can be found:
> # This doesn't seem to work in RHEL V6.3
> #ldap_tls_cacertdir = /etc/openldap/osncerts
If this isn't working, check to make sure that you have run
'cacertdir_rehash' on that directory. I suspect you have not (and thus
it won't work with the cacertdir option).
>>> Bingo...that worked...thanks much Never would have seen this had
>>> you not mentioned it....is this procedure documented anywhere ?
> # This line seems to be required for RHEL v6.3
> ldap_tls_cacert = /etc/openldap/osncerts/server.pem
Specifying it directly avoids the need for properly hashing the
certificates.
>>>> Understood...again thanks.
> If this line is commented or is not in the sssd.conf, authentication
> fails and I see this
> error in the /var/log/messages file:
> Could not start TLS encryption. TLS error -8172:Peer's certificate
> issuer has been marked as not trusted by the user.
> I also see that no reference what so ever to the TLS certificate is
> required in RHEL V6.4 running the later version of sssd.
Check where your certificates are. I suspect they're in either the
default location (/etc/openldap/cacerts) or that
/etc/openldap/ldap.conf has the cacertdir option pointing to it for
you (and the directory is properly hashed). In that case, SSSD will
just pick up these values and use them without you needing to do
anything.
>>>> I have had difficulty in not only getting security certs to work
>>>> but also understanding the technique. As such I tried moving them
>>>> to a different area...and as you have pointed out...probably
>>>> shouldn't have. How does one tell if
>>>> the directory has been hashed ? Not sure I'm seeing
>>>> any indication with ls -l
If they're hashed, you'll see symlinks in the directory between the actual
certificate and what looks like a series of random numbers and letters.
>> Ok...I can see this....but I'm not seeing these hashed
links in /etc/openldap/cacerts so I'm wondering if this was done by default ?
Alternately, do you have 'ldap_tls_reqcert = allow' (or none) set in
your config (either in sssd.conf or ldap.conf)? This bypasses the
security check.
>>>> I have tried experimenting with those options as well and
>>>> have had various results. But as of now, I have all
>>>> references to TLS security options commented in my sssd on the
>>>> RHEL V6.4 system and it works just fine.....unless there is some
>>>> underlying mechanism at work here that I am not seeing ?
The defaults (when not otherwise set) are:
ldap_tls_reqcert = demand
ldap_tls_cacertdir = <openldap setting, usually /etc/openldap/cacerts>
>>> Good to know...thanks !
> Can anyone explain this ?
> Are there any plans to require a security certificate in sssd when
> using ldap for authentication ?
Not so much plans as a mandate. We don't allow using LDAP for auth
over an insecure tunnel EVER. If you try to perform a bind and SSSD
sees that the channel isn't secure, it will just immediately return
failure instead of attempting the auth. This is because the LDAP
protocol sends the password in plaintext, so we don't allow this to
happen unless the channel itself is encrypted.
>>>> This could be troublesome for troubleshooting. When the
>>>> logs don't really provide enough information, the tcpdumps fill
>>>> in the gaps and we can see precisely what information is presented
>>>> to/from ldap client and server.
Use a modern version of wireshark, then. It can be configured for use with SSL/TLS
certificates. Alternately, there is an undocumented option in SSSD to disable this
feature, which the clever can spot in the debug logs at level 7+.
>>> are you willing to share this option ?
>>> RE: Wireshark....I'll definitely look into this. We
do use Wireshark to view all of these tcpdumps....which I just uploaded the most current
version
>>> and if this can read encrypted data, this would resolve the issue.
> Are there any plans to force encrypted communicates in sssd when
> using ldap for authentication ?
We already do. You are almost certainly using it without realizing.
>>>> Then perhaps I'm confused again....my normal state. If
>>>> these links are always encrypted (i.e. ldap port 389...no ssl or
>>>> TLS running) how are we able to see clear channel tcpdump sessions
>>>> during authentication ?
>>>> Al
You should not be able to see these right now. If you can, I suspect you may not be using
SSSD to perform the authentication. You might have pam_ldap.so in your
/etc/pam.d/system-auth and/or /etc/pam.d/password-auth stacks. Make sure that you only
have pam_sss.so there.
>>> I just checked and do not find any instance of
pam_ldap.so in either system-auth and password-auth. So I suspect we are using
>>> sssd and the sssd logs seem to bear that out.
>>> I'd be happy to share any of our configuration if there are still any
questions on this.
>>> But this has been a very helpful conversation. Thanks
again.
>>> Al
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird -
http://www.enigmail.net/
iEYEARECAAYFAlH6tSEACgkQeiVVYja6o6OtzACgjJ5/lLfapAoCdwfAvnN3XfBM
77sAnRBeP4WTcutbQDJX2Y2DG7yEws7A
=U/u1
-----END PGP SIGNATURE-----
_______________________________________________
sssd-users mailing list
sssd-users(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users