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

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

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

# This line seems to be required for RHEL v6.3
ldap_tls_cacert = /etc/openldap/osncerts/server.pem

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.

Can anyone explain this ?

Are there any plans to require a security certificate in sssd when using ldap for
authentication ?

Are there any plans to force encrypted communicates in sssd when using ldap for
authentication ?

Al Licause

Use of TLS security certificates in sssd for ldap authentication ?

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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


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

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


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.

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


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

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.13 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlH6qXEACgkQeiVVYja6o6PIUQCdG0KUk7/xXjh4810dhiwOpGb+
> v/MAoLAdSFjaQVi31j+1gviEdsYlQVTm
> =xH2T
> -----END PGP SIGNATURE-----

Use of TLS security certificates in sssd for ldap authentication ?

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

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
?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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
>  

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



> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.13 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlH6qXEACgkQeiVVYja6o6PIUQCdG0KUk7/xXjh4810dhiwOpGb+
> v/MAoLAdSFjaQVi31j+1gviEdsYlQVTm
> =xH2T
> -----END PGP SIGNATURE-----
>  
_______________________________________________
sssd-users mailing list
sssd-users(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Use of TLS security certificates in sssd for ldap authentication ?

[Stephen Gallagher]

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


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

Use of TLS security certificates in sssd for ldap authentication ?

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

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
>  





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

Use of TLS security certificates in sssd for ldap authentication ?

[Jakub Hrozek]

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

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