Hello. We are building a kickstart profile so that we can begin using RHEL 6 in our environment. However, we have run into a problem with sssd and ldaps. It seems that in RHEL 6 nss_ldap has been depreciated and replaced with sssd. I have been able to configure sssd for regular ldap without problem. When I attempt to enable ldaps by changing the ldap uri to ldaps:// authentication no longer functions. However, id and getent functionality remains. Debug level was changed to 10 and here is what I see in the logs for sssd.
(Thu Feb 10 12:03:04 2011) [sssd[be[default]]] [simple_bind_send] (4): Executing simple bind as: uid=testuser,ou=people,dc=mydomain,dc=com (Thu Feb 10 12:03:04 2011) [sssd[be[default]]] [simple_bind_send] (8): ldap simple bind sent, msgid = 2 (Thu Feb 10 12:03:04 2011) [sssd[be[default]]] [sdap_process_result] (8): Trace: sh[0x1994860], connected[1], ops[0x1a5dde0], ldap[0x16d2fc0] (Thu Feb 10 12:03:04 2011) [sssd[be[default]]] [sdap_process_result] (4): ldap_result gave -1, something bad happend! (Thu Feb 10 12:03:04 2011) [sssd[be[default]]] [sdap_handle_release] (8): Trace: sh[0x1994860], connected[1], ops[0x1a5dde0], ldap[0x16d2fc0], destructor_lock[0], release_memory[0] (Thu Feb 10 12:03:04 2011) [sssd[be[default]]] [remove_connection_callback] (9): Successfully removed connection callback.
Unfortunately, "Something bad happend!" isn't quite specific enough to track down the problem.
Below is other pertinent information for this case.
SSSD version: sssd-1.2.1-28.el6.x86_64 SSSD.conf: [sssd] config_file_version = 2
reconnection_retries = 3
sbus_timeout = 30 services = nss, pam
domains = default [nss] filter_groups = root filter_users = root reconnection_retries = 3
[pam] reconnection_retries = 3
[domain/default] ldap_tls_reqcert = demand auth_provider = ldap cache_credentials = False ldap_id_use_start_tls = False debug_level = 20 enumerate = True ldap_schema = rfc2307 ldap_group_search_base = ou=posixGroups,dc=mydomain,dc=com ldap_user_search_base = ou=People,dc=mydomain,dc=com ldap_default_authtok_type = password ldap_search_base = dc=mydomain,dc=com chpass_provider = ldap id_provider = ldap ldap_default_bind_dn = uid=binduser,ou=Special Users,dc=mydomain,dc=com ldap_uri = ldaps://ldap.mydomain.com/ ldap_default_authtok = XXXXXXXXXXX ldap_tls_cacertdir = /etc/ssl/certs
Please let me know if there is other information that you need.
Thank you very much for any help you can provide. Ive been trying to track down this problem for three days.
Brandon
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/10/2011 12:40 PM, sssd help wrote:
Hello. We are building a kickstart profile so that we can begin using RHEL 6 in our environment. However, we have run into a problem with sssd and ldaps. It seems that in RHEL 6 nss_ldap has been depreciated and replaced with sssd. I have been able to configure sssd for regular ldap without problem. When I attempt to enable ldaps by changing the ldap uri to ldaps:// authentication no longer functions. However, id and getent functionality remains. Debug level was changed to 10 and here is what I see in the logs for sssd.
...
Unfortunately, "Something bad happend!" isn't quite specific enough to track down the problem.
...
Please let me know if there is other information that you need.
Thank you very much for any help you can provide. Ive been trying to track down this problem for three days.
Could you explain why you're switching from TLS to LDAPS? In most cases, I would think that TLS would be preferable.
I've been trying to reproduce this problem locally, but it's working fine for me with sssd-1.2.1-28.el6_0.4.x86_64 (the latest available errata for RHEL6).
The reason for the "Something bad happend!" error is because that's a section of the code where the openldap client libraries (which we use to perform our LDAP routines) has reported an error but not a reason for the error. So unfortunately, I'm not sure we can get any better information there. The manual page for this openldap function reads: "ldap_result() returns -1 if something bad happens". There's no indication of any way to get more information from the library about why it failed.
There's a possibility that more information will be available from the LDAP_DIAGNOSTIC_MESSAGE, though this isn't documented. I've created a scratch build of SSSD for you to try. If extra information is available, it should be printed with the included patch.
Please download and try out the RPMs from http://koji.fedoraproject.org/koji/taskinfo?taskID=2830662 and then please let me know if the added logging gives any clues.
- -- Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
Thank you for the reply Stephen. I will begin work on the build you provided.
To answer your question about TLS vs SSL, we cant use TLS in our environment because of a number of tools we use that need to authenticate to ldap and do not support TLS. So for the time being LDAPS is the only way to go for us.
I also didnt realize that we were using a slightly outdated version of sssd. Ill do some upgrade testing as well and let you know.
Thanks again!
On Thu, Feb 10, 2011 at 1:47 PM, Stephen Gallagher sgallagh@redhat.comwrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/10/2011 12:40 PM, sssd help wrote:
Hello. We are building a kickstart profile so that we can begin using RHEL 6 in our environment. However, we have run into a problem with sssd and ldaps. It seems that in RHEL 6 nss_ldap has been depreciated and replaced with sssd. I have been able to configure sssd for regular ldap without problem. When I attempt to enable ldaps by changing the ldap uri to ldaps:// authentication no longer functions. However, id and getent functionality remains. Debug level was changed to 10 and here is what I see in the logs for sssd.
...
Unfortunately, "Something bad happend!" isn't quite specific enough to track down the problem.
...
Please let me know if there is other information that you need.
Thank you very much for any help you can provide. Ive been trying to track down this problem for three days.
Could you explain why you're switching from TLS to LDAPS? In most cases, I would think that TLS would be preferable.
I've been trying to reproduce this problem locally, but it's working fine for me with sssd-1.2.1-28.el6_0.4.x86_64 (the latest available errata for RHEL6).
The reason for the "Something bad happend!" error is because that's a section of the code where the openldap client libraries (which we use to perform our LDAP routines) has reported an error but not a reason for the error. So unfortunately, I'm not sure we can get any better information there. The manual page for this openldap function reads: "ldap_result() returns -1 if something bad happens". There's no indication of any way to get more information from the library about why it failed.
There's a possibility that more information will be available from the LDAP_DIAGNOSTIC_MESSAGE, though this isn't documented. I've created a scratch build of SSSD for you to try. If extra information is available, it should be printed with the included patch.
Please download and try out the RPMs from http://koji.fedoraproject.org/koji/taskinfo?taskID=2830662 and then please let me know if the added logging gives any clues.
Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk1UMqQACgkQeiVVYja6o6PXdQCfdcwqHHiY3sUoQJYCivewr/fu WdgAn2TvDXB2HmsCPVebfEJm5BdHoihN =tRYb -----END PGP SIGNATURE----- _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/10/2011 01:53 PM, sssd help wrote:
Thank you for the reply Stephen. I will begin work on the build you provided.
To answer your question about TLS vs SSL, we cant use TLS in our environment because of a number of tools we use that need to authenticate to ldap and do not support TLS. So for the time being LDAPS is the only way to go for us.
I also didnt realize that we were using a slightly outdated version of sssd. Ill do some upgrade testing as well and let you know.
Thanks again!
There should be no upgrade issues from 1.2.1-28 to 1.2.1-28.4. There are just a few bugfixes.
I based the scratch-build I sent you on 1.2.1-28.4 (with the extra logging patch included)
- -- Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
Stephen, I installed the packages you sent me. Here is the new log output:
(Thu Feb 10 14:26:30 2011) [sssd[be[default]]] [simple_bind_send] (4): Executing simple bind as: uid=testuser,ou=people,dc=mydomain,dc=com (Thu Feb 10 14:26:30 2011) [sssd[be[default]]] [simple_bind_send] (8): ldap simple bind sent, msgid = 2 (Thu Feb 10 14:26:30 2011) [sssd[be[default]]] [sdap_process_result] (8): Trace: sh[0x8f6900], connected[1], ops[0xe3b510], ldap[0xc3b000] (Thu Feb 10 14:26:30 2011) [sssd[be[default]]] [sdap_process_result] (4): ldap_result gave -1, something bad happened! (Thu Feb 10 14:26:30 2011) [sssd[be[default]]] [sdap_process_result] (4): ldap_result failed: [(null)] (Thu Feb 10 14:26:30 2011) [sssd[be[default]]] [sdap_handle_release] (8): Trace: sh[0x8f6900], connected[1], ops[0xe3b510], ldap[0xc3b000], destructor_lock[0], release_memory[0] (Thu Feb 10 14:26:30 2011) [sssd[be[default]]] [remove_connection_callback] (9): Successfully removed connection callback.
To get authentication to work with sssd I found that i have to edit sssd.conf in a couple of places. One, change the ldap_uri to ldap.mydomain.com and Two, change ldap_tls_reqcert to "never". When ldap_tls_reqcert is set to default (hard/demand) authentication fails. I decided to tail access logs on our ldap server to look at the difference in a request from my test machine that works (over 389/ldap) and one that fails (over 686/ldaps)
Failed request:
[10/Feb/2011:14:23:05 -0500] conn=581553 op=9 msgId=11 - SRCH base="ou=people,dc=mydomain,dc=com" scope=2 filter="(&(uid=testuser)(objectClass=posixAccount))" attrs="objectClass uid userPassword uidNumber gidNumber gecos homeDirectory loginShell krbprincipalname cn modifyTimestamp shadowLastChange shadowMin shadowMax shadowWarning shadowInactive shadowExpire shadowFlag krblastpwdchange krbpasswordexpiration pwdAttribute" [10/Feb/2011:14:23:05 -0500] conn=581553 op=9 msgId=11 - RESULT err=0 tag=101 nentries=1 etime=0
Successful request:
[10/Feb/2011:14:33:43 -0500] conn=581558 op=27 msgId=29 - SRCH base="ou=people,dc=mydomain,dc=com" scope=2 filter="(&(uid=testuser)(objectClass=posixAccount))" attrs="objectClass uid userPassword uidNumber gidNumber gecos homeDirectory loginShell krbprincipalname cn modifyTimestamp shadowLastChange shadowMin shadowMax shadowWarning shadowInactive shadowExpire shadowFlag krblastpwdchange krbpasswordexpiration pwdAttribute" [10/Feb/2011:14:33:43 -0500] conn=581558 op=27 msgId=29 - RESULT err=0 tag=101 nentries=1 etime=0
The requests seem to yeild the same results so im confused as to why one is failing and the other is not.
I should note that in the ssl cert directory i am using the same cert that we use on all of the other systems in our environment (mostly RHEL5.3) and i have run cacertdir_rehash on the directory as it says in the sssd-ldap(5) man page.
Any suggestions? Thank you for your help so far.
On Thu, Feb 10, 2011 at 1:59 PM, Stephen Gallagher sgallagh@redhat.comwrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/10/2011 01:53 PM, sssd help wrote:
Thank you for the reply Stephen. I will begin work on the build you provided.
To answer your question about TLS vs SSL, we cant use TLS in our environment because of a number of tools we use that need to authenticate to ldap and do not support TLS. So for the time being LDAPS is the only way to go for us.
I also didnt realize that we were using a slightly outdated version of sssd. Ill do some upgrade testing as well and let you know.
Thanks again!
There should be no upgrade issues from 1.2.1-28 to 1.2.1-28.4. There are just a few bugfixes.
I based the scratch-build I sent you on 1.2.1-28.4 (with the extra logging patch included)
Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk1UNZQACgkQeiVVYja6o6OFhwCgpMCAwD5LlY2gA0Aesn+mhc/M UL4An2CNSB/XbtuoEAcSkFI69eNJULzm =XaBq -----END PGP SIGNATURE----- _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/10/2011 02:39 PM, sssd help wrote:
Stephen, I installed the packages you sent me. Here is the new log output:
(Thu Feb 10 14:26:30 2011) [sssd[be[default]]] [simple_bind_send] (4): Executing simple bind as: uid=testuser,ou=people,dc=mydomain,dc=com (Thu Feb 10 14:26:30 2011) [sssd[be[default]]] [simple_bind_send] (8): ldap simple bind sent, msgid = 2 (Thu Feb 10 14:26:30 2011) [sssd[be[default]]] [sdap_process_result] (8): Trace: sh[0x8f6900], connected[1], ops[0xe3b510], ldap[0xc3b000] (Thu Feb 10 14:26:30 2011) [sssd[be[default]]] [sdap_process_result] (4): ldap_result gave -1, something bad happened! (Thu Feb 10 14:26:30 2011) [sssd[be[default]]] [sdap_process_result] (4): ldap_result failed: [(null)] (Thu Feb 10 14:26:30 2011) [sssd[be[default]]] [sdap_handle_release] (8): Trace: sh[0x8f6900], connected[1], ops[0xe3b510], ldap[0xc3b000], destructor_lock[0], release_memory[0] (Thu Feb 10 14:26:30 2011) [sssd[be[default]]] [remove_connection_callback] (9): Successfully removed connection callback.
To get authentication to work with sssd I found that i have to edit sssd.conf in a couple of places. One, change the ldap_uri to ldap.mydomain.com and Two, change ldap_tls_reqcert to "never". When ldap_tls_reqcert is set to default (hard/demand) authentication fails. I decided to tail access logs on our ldap server to look at the difference in a request from my test machine that works (over 389/ldap) and one that fails (over 686/ldaps)
Authentication fails when it's set to hard/demand? That would suggest that your CA certificate is not being read (or is not the correct CA certificate). There should be a log message when this fails that explains why it failed.
Failed request:
[10/Feb/2011:14:23:05 -0500] conn=581553 op=9 msgId=11 - SRCH base="ou=people,dc=mydomain,dc=com" scope=2 filter="(&(uid=testuser)(objectClass=posixAccount))" attrs="objectClass uid userPassword uidNumber gidNumber gecos homeDirectory loginShell krbprincipalname cn modifyTimestamp shadowLastChange shadowMin shadowMax shadowWarning shadowInactive shadowExpire shadowFlag krblastpwdchange krbpasswordexpiration pwdAttribute" [10/Feb/2011:14:23:05 -0500] conn=581553 op=9 msgId=11 - RESULT err=0 tag=101 nentries=1 etime=0
Successful request:
[10/Feb/2011:14:33:43 -0500] conn=581558 op=27 msgId=29 - SRCH base="ou=people,dc=mydomain,dc=com" scope=2 filter="(&(uid=testuser)(objectClass=posixAccount))" attrs="objectClass uid userPassword uidNumber gidNumber gecos homeDirectory loginShell krbprincipalname cn modifyTimestamp shadowLastChange shadowMin shadowMax shadowWarning shadowInactive shadowExpire shadowFlag krblastpwdchange krbpasswordexpiration pwdAttribute" [10/Feb/2011:14:33:43 -0500] conn=581558 op=27 msgId=29 - RESULT err=0 tag=101 nentries=1 etime=0
The requests seem to yeild the same results so im confused as to why one is failing and the other is not.
I should note that in the ssl cert directory i am using the same cert that we use on all of the other systems in our environment (mostly RHEL5.3) and i have run cacertdir_rehash on the directory as it says in the sssd-ldap(5) man page.
Any suggestions? Thank you for your help so far.
Yeah, this isn't a certificate issue here (though I'm concerned that you have to set ldap_tls_reqcert = allow. If you have a valid CA cert, you should be able to use that. Maybe you should try ldap_tls_cacert = /path/to/actual/cert
Something's wrong with ldap_result (which is how the openldap libraries process the response from the server). And as we've unfortunately proven here, there's no actual error message to tell us what it was. ("ldap_result failed: [(null)]")
The implication here is that the LDAP server sent us a badly-formatted result packet. So I'm wondering if the issue might be on the server (but that seems unlikely if you have other tools using LDAPS successfully).
What LDAP server are you using, by the way?
- -- Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
We are using Sun DSEE 6. Would errors regarding certificate failures be in the same /var/log/sssd/sssd_default.log or one of the others.
Thanks.
On Thu, Feb 10, 2011 at 2:52 PM, Stephen Gallagher sgallagh@redhat.comwrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/10/2011 02:39 PM, sssd help wrote:
Stephen, I installed the packages you sent me. Here is the new log
output:
(Thu Feb 10 14:26:30 2011) [sssd[be[default]]] [simple_bind_send] (4): Executing simple bind as: uid=testuser,ou=people,dc=mydomain,dc=com (Thu Feb 10 14:26:30 2011) [sssd[be[default]]] [simple_bind_send] (8):
ldap
simple bind sent, msgid = 2 (Thu Feb 10 14:26:30 2011) [sssd[be[default]]] [sdap_process_result] (8): Trace: sh[0x8f6900], connected[1], ops[0xe3b510], ldap[0xc3b000] (Thu Feb 10 14:26:30 2011) [sssd[be[default]]] [sdap_process_result] (4): ldap_result gave -1, something bad happened! (Thu Feb 10 14:26:30 2011) [sssd[be[default]]] [sdap_process_result] (4): ldap_result failed: [(null)] (Thu Feb 10 14:26:30 2011) [sssd[be[default]]] [sdap_handle_release] (8): Trace: sh[0x8f6900], connected[1], ops[0xe3b510], ldap[0xc3b000], destructor_lock[0], release_memory[0] (Thu Feb 10 14:26:30 2011) [sssd[be[default]]]
[remove_connection_callback]
(9): Successfully removed connection callback.
To get authentication to work with sssd I found that i have to edit sssd.conf in a couple of places. One, change the ldap_uri to ldap.mydomain.com and Two, change ldap_tls_reqcert to "never". When ldap_tls_reqcert is set to default (hard/demand) authentication fails. I decided to tail access logs on our ldap server to look at the difference
in
a request from my test machine that works (over 389/ldap) and one that
fails
(over 686/ldaps)
Authentication fails when it's set to hard/demand? That would suggest that your CA certificate is not being read (or is not the correct CA certificate). There should be a log message when this fails that explains why it failed.
Failed request:
[10/Feb/2011:14:23:05 -0500] conn=581553 op=9 msgId=11 - SRCH base="ou=people,dc=mydomain,dc=com" scope=2 filter="(&(uid=testuser)(objectClass=posixAccount))" attrs="objectClass
uid
userPassword uidNumber gidNumber gecos homeDirectory loginShell krbprincipalname cn modifyTimestamp shadowLastChange shadowMin shadowMax shadowWarning shadowInactive shadowExpire shadowFlag krblastpwdchange krbpasswordexpiration pwdAttribute" [10/Feb/2011:14:23:05 -0500] conn=581553 op=9 msgId=11 - RESULT err=0 tag=101 nentries=1 etime=0
Successful request:
[10/Feb/2011:14:33:43 -0500] conn=581558 op=27 msgId=29 - SRCH base="ou=people,dc=mydomain,dc=com" scope=2 filter="(&(uid=testuser)(objectClass=posixAccount))" attrs="objectClass
uid
userPassword uidNumber gidNumber gecos homeDirectory loginShell krbprincipalname cn modifyTimestamp shadowLastChange shadowMin shadowMax shadowWarning shadowInactive shadowExpire shadowFlag krblastpwdchange krbpasswordexpiration pwdAttribute" [10/Feb/2011:14:33:43 -0500] conn=581558 op=27 msgId=29 - RESULT err=0 tag=101 nentries=1 etime=0
The requests seem to yeild the same results so im confused as to why one
is
failing and the other is not.
I should note that in the ssl cert directory i am using the same cert
that
we use on all of the other systems in our environment (mostly RHEL5.3)
and i
have run cacertdir_rehash on the directory as it says in the sssd-ldap(5) man page.
Any suggestions? Thank you for your help so far.
Yeah, this isn't a certificate issue here (though I'm concerned that you have to set ldap_tls_reqcert = allow. If you have a valid CA cert, you should be able to use that. Maybe you should try ldap_tls_cacert = /path/to/actual/cert
Something's wrong with ldap_result (which is how the openldap libraries process the response from the server). And as we've unfortunately proven here, there's no actual error message to tell us what it was. ("ldap_result failed: [(null)]")
The implication here is that the LDAP server sent us a badly-formatted result packet. So I'm wondering if the issue might be on the server (but that seems unlikely if you have other tools using LDAPS successfully).
What LDAP server are you using, by the way?
Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk1UQhMACgkQeiVVYja6o6PSgQCgj/FwDZfopizSg1qy28qqj21l J+EAn0ZoSskCetuU2cS2Hcg/9CZF+CqD =1Rji -----END PGP SIGNATURE----- _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/10/2011 03:25 PM, sssd help wrote:
We are using Sun DSEE 6. Would errors regarding certificate failures be in the same /var/log/sssd/sssd_default.log or one of the others.
It should still be in /var/log/sssd/sssd_default.log
I'm at something of a loss on the ldap_result issue though. I don't have a clue why it would behave any differently on LDAPS as opposed to LDAP+TLS.
- -- Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
I can also confirm that i am using a CA cert bundle provided by our CA.
On Thu, Feb 10, 2011 at 3:28 PM, Stephen Gallagher sgallagh@redhat.comwrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/10/2011 03:25 PM, sssd help wrote:
We are using Sun DSEE 6. Would errors regarding certificate failures be
in
the same /var/log/sssd/sssd_default.log or one of the others.
It should still be in /var/log/sssd/sssd_default.log
I'm at something of a loss on the ldap_result issue though. I don't have a clue why it would behave any differently on LDAPS as opposed to LDAP+TLS.
Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk1USlIACgkQeiVVYja6o6P7iACfQtLFQjYCxp7hgSbStc3VAlTy kp8Aniyog28zrjhFxul6WFKeEFs0KsaT =XXMe -----END PGP SIGNATURE----- _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
Hey Stephen, Just a little more information incase this helps in troubleshooting. After talking to my group i was reminded that the reason we cant use TLS is because we are using hardware loadbalancers to handle the ssl offload and proxy between multiple ldap servers.
Is there any reason you can think of that using a loadbalancer in this case would cause an initial ldaps connection to fail?
I noticed in the logs that even though i explicitly request sssd to not use start_tls, it still runs:
"Executing START_TLS"
is there any way to stop this behavior?
On Thu, Feb 10, 2011 at 3:41 PM, sssd help sssdhelp@gmail.com wrote:
I can also confirm that i am using a CA cert bundle provided by our CA.
On Thu, Feb 10, 2011 at 3:28 PM, Stephen Gallagher sgallagh@redhat.comwrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/10/2011 03:25 PM, sssd help wrote:
We are using Sun DSEE 6. Would errors regarding certificate failures be
in
the same /var/log/sssd/sssd_default.log or one of the others.
It should still be in /var/log/sssd/sssd_default.log
I'm at something of a loss on the ldap_result issue though. I don't have a clue why it would behave any differently on LDAPS as opposed to LDAP+TLS.
Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk1USlIACgkQeiVVYja6o6P7iACfQtLFQjYCxp7hgSbStc3VAlTy kp8Aniyog28zrjhFxul6WFKeEFs0KsaT =XXMe -----END PGP SIGNATURE----- _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/10/2011 06:08 PM, sssd help wrote:
Hey Stephen, Just a little more information incase this helps in troubleshooting. After talking to my group i was reminded that the reason we cant use TLS is because we are using hardware loadbalancers to handle the ssl offload and proxy between multiple ldap servers.
Is there any reason you can think of that using a loadbalancer in this case would cause an initial ldaps connection to fail?
It's possible that a faulty SSL load balancer might be resulting in sending back invalid data. But I'd assume you'd be seeing that in all your clients, not just SSSD. It's worth investigating, though. It's possible that the load balancers are adding something to the message that SSSD is not expecting (but should be). It's hard to debug over SSL, though.
I noticed in the logs that even though i explicitly request sssd to not use start_tls, it still runs:
"Executing START_TLS"
is there any way to stop this behavior?
Are you seeing that START_TLS message when you have an ldaps:// URI specified? That sounds like a bug, if so. (Shouldn't be happening; we check for whether an encrypted channel is already available before we call that function)
If you're using ldap:// as a URI, it's not possible to disable TLS for authentication. This is because the LDAP protocol sends bind passwords in the clear. SSSD mandates that passwords must be sent over an encrypted channel, to protect against password sniffing.
In an earlier email, you said "When I attempt to enable ldaps by changing the ldap uri to ldaps:// authentication no longer functions. However, id and getent functionality remains."
Are you sure this is true? Since you have "enumerate = true", all of your identities would have been cached when you were using ldap://, so they may just be returning from the cache when you switch to ldaps://
Please purge the cache when switching to ldaps (rm -f /var/lib/sss/db/cache_default.ldb) and then please retest. (I want to know if the problem is truly exclusive to authentication)
- -- Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
On Fri, Feb 11, 2011 at 07:27:36AM -0500, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/10/2011 06:08 PM, sssd help wrote:
Hey Stephen, Just a little more information incase this helps in troubleshooting. After talking to my group i was reminded that the reason we cant use TLS is because we are using hardware loadbalancers to handle the ssl offload and proxy between multiple ldap servers.
Is there any reason you can think of that using a loadbalancer in this case would cause an initial ldaps connection to fail?
It's possible that a faulty SSL load balancer might be resulting in sending back invalid data. But I'd assume you'd be seeing that in all your clients, not just SSSD. It's worth investigating, though. It's possible that the load balancers are adding something to the message that SSSD is not expecting (but should be). It's hard to debug over SSL, though.
I noticed in the logs that even though i explicitly request sssd to not use start_tls, it still runs:
"Executing START_TLS"
is there any way to stop this behavior?
Are you seeing that START_TLS message when you have an ldaps:// URI specified? That sounds like a bug, if so. (Shouldn't be happening; we check for whether an encrypted channel is already available before we call that function)
I've just checked, we call START_TLS on every authentication and do not check if TLS is already active due to ldaps. Maybe Sun DSEE does not like the double encryption. Can you check if
ldapsearch -ZZ -H ldaps://....
works with your LDAP server?
bye, Sumit
Thank you for the taking a look Sumit.
I am testing with ldapsearch now. My first searches are returning: ldap_start_tls: Connect error (-11)
which i guess is what we would expect since we cant do tls against our load balancers. I will continue testing and let you know if I come up with something different.
Brandon
On Fri, Feb 11, 2011 at 7:37 AM, Sumit Bose sbose@redhat.com wrote:
On Fri, Feb 11, 2011 at 07:27:36AM -0500, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/10/2011 06:08 PM, sssd help wrote:
Hey Stephen, Just a little more information incase this helps in troubleshooting. After talking to my group i was reminded that the
reason we
cant use TLS is because we are using hardware loadbalancers to handle
the
ssl offload and proxy between multiple ldap servers.
Is there any reason you can think of that using a loadbalancer in this
case
would cause an initial ldaps connection to fail?
It's possible that a faulty SSL load balancer might be resulting in sending back invalid data. But I'd assume you'd be seeing that in all your clients, not just SSSD. It's worth investigating, though. It's possible that the load balancers are adding something to the message that SSSD is not expecting (but should be). It's hard to debug over SSL, though.
I noticed in the logs that even though i explicitly request sssd to not
use
start_tls, it still runs:
"Executing START_TLS"
is there any way to stop this behavior?
Are you seeing that START_TLS message when you have an ldaps:// URI specified? That sounds like a bug, if so. (Shouldn't be happening; we check for whether an encrypted channel is already available before we call that function)
I've just checked, we call START_TLS on every authentication and do not check if TLS is already active due to ldaps. Maybe Sun DSEE does not like the double encryption. Can you check if
ldapsearch -ZZ -H ldaps://....
works with your LDAP server?
bye, Sumit _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
I can confirm now that using ldapsearch to perform lookups against the target directory works as long as -ZZ is not enabled.
so:
ldapsearch -H ldaps://..... works perfectly fine over 636, while /etc/openldap/ldap.conf has its tls_cacertdir set to the same directory as the ldap_tls_cacertdir directory in sssd.conf.
It seems pretty clear that in our case executing start_tls is causing problems. Is there any way to make sure that it does not run?
Brandon
On Fri, Feb 11, 2011 at 12:23 PM, sssd help sssdhelp@gmail.com wrote:
Thank you for the taking a look Sumit.
I am testing with ldapsearch now. My first searches are returning: ldap_start_tls: Connect error (-11)
which i guess is what we would expect since we cant do tls against our load balancers. I will continue testing and let you know if I come up with something different.
Brandon
On Fri, Feb 11, 2011 at 7:37 AM, Sumit Bose sbose@redhat.com wrote:
On Fri, Feb 11, 2011 at 07:27:36AM -0500, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/10/2011 06:08 PM, sssd help wrote:
Hey Stephen, Just a little more information incase this helps in troubleshooting. After talking to my group i was reminded that the
reason we
cant use TLS is because we are using hardware loadbalancers to handle
the
ssl offload and proxy between multiple ldap servers.
Is there any reason you can think of that using a loadbalancer in this
case
would cause an initial ldaps connection to fail?
It's possible that a faulty SSL load balancer might be resulting in sending back invalid data. But I'd assume you'd be seeing that in all your clients, not just SSSD. It's worth investigating, though. It's possible that the load balancers are adding something to the message that SSSD is not expecting (but should be). It's hard to debug over SSL, though.
I noticed in the logs that even though i explicitly request sssd to
not use
start_tls, it still runs:
"Executing START_TLS"
is there any way to stop this behavior?
Are you seeing that START_TLS message when you have an ldaps:// URI specified? That sounds like a bug, if so. (Shouldn't be happening; we check for whether an encrypted channel is already available before we call that function)
I've just checked, we call START_TLS on every authentication and do not check if TLS is already active due to ldaps. Maybe Sun DSEE does not like the double encryption. Can you check if
ldapsearch -ZZ -H ldaps://....
works with your LDAP server?
bye, Sumit _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/11/2011 12:23 PM, sssd help wrote:
Thank you for the taking a look Sumit.
I am testing with ldapsearch now. My first searches are returning: ldap_start_tls: Connect error (-11)
which i guess is what we would expect since we cant do tls against our load balancers. I will continue testing and let you know if I come up with something different.
Ok, this is actually probably a bug in the SSSD then. We shouldn't be attempting to perform a START_TLS while using LDAPS.
Sumit opened https://fedorahosted.org/sssd/ticket/795 to track fixing this.
I've submitted a patch for this issue to the list and kicked off a scratch-build for RHEL 6 RPMs. Please try http://koji.fedoraproject.org/koji/taskinfo?taskID=2833544 and let me know if it resolves your issue.
- -- Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
This is great. Thank you for providing the new rpms.
However, I installed them and it looks like START_TLS isnt quite out of the picture.
[root@mgnttest02 sssd]# rpm -qa sssd sssd-1.2.1-28.el6.4.2.x86_64
from the sssd_default.log
(Fri Feb 11 14:27:08 2011) [sssd[be[default]]] [auth_resolve_done] (8): [ldaps://ldap.mydomain.com/] is a secure channel. No need to run START_TLS (Fri Feb 11 14:27:08 2011) [sssd[be[default]]] [sdap_connect_send] (4): Executing START TLS
Looks like sssd is still trying to start tls.
On Fri, Feb 11, 2011 at 1:52 PM, Stephen Gallagher sgallagh@redhat.comwrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/11/2011 12:23 PM, sssd help wrote:
Thank you for the taking a look Sumit.
I am testing with ldapsearch now. My first searches are returning: ldap_start_tls: Connect error (-11)
which i guess is what we would expect since we cant do tls against our
load
balancers. I will continue testing and let you know if I come up with something different.
Ok, this is actually probably a bug in the SSSD then. We shouldn't be attempting to perform a START_TLS while using LDAPS.
Sumit opened https://fedorahosted.org/sssd/ticket/795 to track fixing this.
I've submitted a patch for this issue to the list and kicked off a scratch-build for RHEL 6 RPMs. Please try http://koji.fedoraproject.org/koji/taskinfo?taskID=2833544 and let me know if it resolves your issue.
Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk1VhYYACgkQeiVVYja6o6OyngCZATEZjYYhbz2V+AWlPmBT9nbu 68QAn2CMQMx9ZtQj/UcesV33vRf+aQJP =IhEN -----END PGP SIGNATURE----- _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/11/2011 02:32 PM, sssd help wrote:
This is great. Thank you for providing the new rpms.
However, I installed them and it looks like START_TLS isnt quite out of the picture.
[root@mgnttest02 sssd]# rpm -qa sssd sssd-1.2.1-28.el6.4.2.x86_64
from the sssd_default.log
(Fri Feb 11 14:27:08 2011) [sssd[be[default]]] [auth_resolve_done] (8): [ldaps://ldap.mydomain.com/] is a secure channel. No need to run START_TLS (Fri Feb 11 14:27:08 2011) [sssd[be[default]]] [sdap_connect_send] (4): Executing START TLS
Looks like sssd is still trying to start tls.
Yup, that's what I get for not actually testing the backport. I missed one (important) line when I ported the patch back to 1.2.x. I'm rebuilding the scratch build now.
Please try the new build from http://koji.fedoraproject.org/koji/taskinfo?taskID=2833696
- -- Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
This is fantastic Stephen! Completely works, over 636 and everything. Thank you so much for your help on this. I can officially run ~$ service bang-head-against-wall stop.
In the future, how should we look to manage this package? Are these fixes going to be in all future builds of sssd? Do you know when it will be part of a GA release?
Thank you again.
Brandon
On Fri, Feb 11, 2011 at 2:46 PM, Stephen Gallagher sgallagh@redhat.comwrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/11/2011 02:32 PM, sssd help wrote:
This is great. Thank you for providing the new rpms.
However, I installed them and it looks like START_TLS isnt quite out of
the
picture.
[root@mgnttest02 sssd]# rpm -qa sssd sssd-1.2.1-28.el6.4.2.x86_64
from the sssd_default.log
(Fri Feb 11 14:27:08 2011) [sssd[be[default]]] [auth_resolve_done] (8): [ldaps://ldap.mydomain.com/] is a secure channel. No need to run
START_TLS
(Fri Feb 11 14:27:08 2011) [sssd[be[default]]] [sdap_connect_send] (4): Executing START TLS
Looks like sssd is still trying to start tls.
Yup, that's what I get for not actually testing the backport. I missed one (important) line when I ported the patch back to 1.2.x. I'm rebuilding the scratch build now.
Please try the new build from http://koji.fedoraproject.org/koji/taskinfo?taskID=2833696
Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk1VkhsACgkQeiVVYja6o6MScwCfeWcxp8IzPrbjaUqkn4A63/xj Tg0AoIErbaAXmH5udzYbB6JeWbnIpbMw =/tlC -----END PGP SIGNATURE----- _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/11/2011 03:04 PM, sssd help wrote:
This is fantastic Stephen! Completely works, over 636 and everything. Thank you so much for your help on this. I can officially run ~$ service bang-head-against-wall stop.
In the future, how should we look to manage this package? Are these fixes going to be in all future builds of sssd? Do you know when it will be part of a GA release?
In SSSD, we're planning to carry it in any forthcoming release of the 1.5.x line or later. The patch I rolled into those test builds is currently going through code review.
I opened a Bugzilla bug for the issue: https://bugzilla.redhat.com/show_bug.cgi?id=676911
Keep an eye there for when Red Hat will ship a supported set of RPMs that addresses this issue.
Thank you for your help tracking this down!
- -- Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
On Thu, 10 Feb 2011 13:53:58 -0500 sssd help sssdhelp@gmail.com wrote:
To answer your question about TLS vs SSL, we cant use TLS in our environment because of a number of tools we use that need to authenticate to ldap and do not support TLS. So for the time being LDAPS is the only way to go for us.
Keep in mind that you can you both LDAP+TLS and LDAPS at the same time, nothing prevents doing that afaik.
Simo.
sssd-devel@lists.fedorahosted.org
-
Simo Sorce -
sssd help -
Stephen Gallagher -
Sumit Bose