-----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.
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>
> 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 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.
-----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-----