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
-----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.
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@hp.com
-----Original Message----- From: sssd-users-bounces@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@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
_______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
-----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@hp.com
-----Original Message----- From: sssd-users-bounces@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@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.
Al Licause HP L2 UNIX Network Services HP Customer Support Center Hours 7am-3pm Pacific time USA Manager: tom.cernilli@hp.com
-----Original Message----- From: sssd-users-bounces@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@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@hp.com
-----Original Message----- From: sssd-users-bounces@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@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
_______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
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@hp.com
-----Original Message----- From: sssd-users-bounces@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@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@hp.com
-----Original Message----- From: sssd-users-bounces@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@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
Thanks much for the input.
Al Licause
-----Original Message----- From: sssd-users-bounces@lists.fedorahosted.org [mailto:sssd-users-bounces@lists.fedorahosted.org] On Behalf Of Jakub Hrozek Sent: Friday, August 02, 2013 12:05 AM To: sssd-users@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@hp.com
-----Original Message----- From: sssd-users-bounces@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@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@hp.com
-----Original Message----- From: sssd-users-bounces@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@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@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
sssd-users@lists.fedorahosted.org
-
Jakub Hrozek -
Licause, Al (CSC AMS BCS - UNIX/Linux Network Support) -
Stephen Gallagher