Re: [SSSD-users] Use of TLS security certificates in sssd for ldap authentication ?

[Licause, Al (CSC AMS BCS - UNIX/Linux Network Support)]

Thanks much for the input.

Al Licause
 

-----Original Message-----
From: sssd-users-bounces(a)lists.fedorahosted.org
[mailto:[e-mail]] On Behalf Of Jakub Hrozek
Sent: Friday, August 02, 2013 12:05 AM
To: sssd-users(a)lists.fedorahosted.org
Subject: Re: [SSSD-users] Use of TLS security certificates in sssd for ldap authentication
?

On Thu, Aug 01, 2013 at 08:04:46PM +0000, Licause, Al (CSC AMS BCS - UNIX/Linux Network
Support) wrote:
>  
>  
>  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:[e-mail]] 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:[e-mail]] 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
>  
In general I think authconfig should be used to set up the PAM stack.
Setting the PAM config manually is error-prone, using a tool that was built for the job is
safer and easier (not to mention we work with the authconfig developer quite closely so
the integration is usually[1] quite good)

You can see some details on what modules get contacted and what the result of the
conversation was by tailing /var/log/secure.

[1] I'm looking at you, sudo and autofs
_______________________________________________
sssd-users mailing list
sssd-users(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users