[SSSD] Problems configuring sssd for ssl/ldaps no tls

[sssd help]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://fedorahosted.org/pipermail/sssd-devel/attachments/20110210/8cc4589e/attachment.html

[Stephen Gallagher]

Post by sssd help
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.

...

Post by sssd help
Unfortunately, "Something bad happend!" isn't quite specific enough to
track down the problem.

...

Post by sssd help
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/

[sssd help]

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!

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

Post by sssd help
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.

...

Post by sssd help
Unfortunately, "Something bad happend!" isn't quite specific enough to
track down the problem.

...

Post by sssd help
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
"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 at lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/sssd-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://fedorahosted.org/pipermail/sssd-devel/attachments/20110210/96cdf00f/attachment.html

[Stephen Gallagher]

Post by sssd help
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/

[sssd help]

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.

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

Post by sssd help
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 at lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/sssd-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://fedorahosted.org/pipermail/sssd-devel/attachments/20110210/0c29ff58/attachment-0001.html

[Stephen Gallagher]

Post by sssd help
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
Trace: sh[0x8f6900], connected[1], ops[0xe3b510], ldap[0xc3b000]
ldap_result gave -1, something bad happened!
ldap_result failed: [(null)]
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.

Post by sssd help
[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
[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/

[sssd help]

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.

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

Post by sssd help
Stephen, I installed the packages you sent me. Here is the new log
Executing simple bind as: uid=testuser,ou=people,dc=mydomain,dc=com

ldap

Post by sssd help
simple bind sent, msgid = 2
Trace: sh[0x8f6900], connected[1], ops[0xe3b510], ldap[0xc3b000]
ldap_result gave -1, something bad happened!
ldap_result failed: [(null)]
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]

Post by sssd help
(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

Post by sssd help
a request from my test machine that works (over 389/ldap) and one that

fails

Post by sssd help
(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.

Post by sssd help
[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

Post by sssd help
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
[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

Post by sssd help
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

Post by sssd help
failing and the other is not.
I should note that in the ssl cert directory i am using the same cert

that

Post by sssd help
we use on all of the other systems in our environment (mostly RHEL5.3)

and i

Post by sssd help
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 at lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/sssd-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://fedorahosted.org/pipermail/sssd-devel/attachments/20110210/a3e52d10/attachment-0001.html

[Stephen Gallagher]

Post by sssd help
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/

[sssd help]

I can also confirm that i am using a CA cert bundle provided by our CA.

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

Post by sssd help
We are using Sun DSEE 6. Would errors regarding certificate failures be

in

Post by sssd help
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 at lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/sssd-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://fedorahosted.org/pipermail/sssd-devel/attachments/20110210/d9c3a630/attachment.html

[sssd help]

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?

Post by sssd help
I can also confirm that i am using a CA cert bundle provided by our CA.

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

Post by sssd help
We are using Sun DSEE 6. Would errors regarding certificate failures be

in

Post by sssd help
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 at lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/sssd-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://fedorahosted.org/pipermail/sssd-devel/attachments/20110210/80bc8a4b/attachment.html

[Stephen Gallagher]

Post by sssd help
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.

Post by sssd help
I noticed in the logs that even though i explicitly request sssd to not use
"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/

[Sumit Bose]

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

Post by sssd help
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.

Post by sssd help
I noticed in the logs that even though i explicitly request sssd to not use
"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 help]

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

Post by sssd help

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

Post by sssd help
Hey Stephen, Just a little more information incase this helps in
troubleshooting. After talking to my group i was reminded that the

reason we

Post by sssd help
cant use TLS is because we are using hardware loadbalancers to handle

the

Post by sssd help
ssl offload and proxy between multiple ldap servers.
Is there any reason you can think of that using a loadbalancer in this

case

Post by sssd help
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.

Post by sssd help
I noticed in the logs that even though i explicitly request sssd to not

use

Post by sssd help
"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 at lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/sssd-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://fedorahosted.org/pipermail/sssd-devel/attachments/20110211/e5e872e3/attachment.html

[sssd help]

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

Post by sssd help
Thank you for the taking a look Sumit.
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

Post by sssd help

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

Post by sssd help
Hey Stephen, Just a little more information incase this helps in
troubleshooting. After talking to my group i was reminded that the

reason we

Post by sssd help
cant use TLS is because we are using hardware loadbalancers to handle

the

Post by sssd help
ssl offload and proxy between multiple ldap servers.
Is there any reason you can think of that using a loadbalancer in this

case

Post by sssd help
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.

Post by sssd help
I noticed in the logs that even though i explicitly request sssd to

not use

Post by sssd help
"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 at lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/sssd-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://fedorahosted.org/pipermail/sssd-devel/attachments/20110211/911002ab/attachment.html

[Stephen Gallagher]

Post by sssd help
Thank you for the taking a look Sumit.
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/

[sssd help]

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

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

Post by sssd help
Thank you for the taking a look Sumit.
ldap_start_tls: Connect error (-11)
which i guess is what we would expect since we cant do tls against our

load

Post by sssd help
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 at lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/sssd-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://fedorahosted.org/pipermail/sssd-devel/attachments/20110211/9c033b51/attachment.html

[Stephen Gallagher]

Post by sssd help
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 at mgnttest02 sssd]# rpm -qa sssd
sssd-1.2.1-28.el6.4.2.x86_64
from the sssd_default.log
[ldaps://ldap.mydomain.com/] is a secure channel. No need to run START_TLS
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/

[sssd help]

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

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

Post by sssd help
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

Post by sssd help
picture.
[root at mgnttest02 sssd]# rpm -qa sssd
sssd-1.2.1-28.el6.4.2.x86_64
from the sssd_default.log
[ldaps://ldap.mydomain.com/] is a secure channel. No need to run

START_TLS

Post by sssd help
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 at lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/sssd-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://fedorahosted.org/pipermail/sssd-devel/attachments/20110211/e40b31d9/attachment-0001.html

[Stephen Gallagher]

Post by sssd help
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/

[Simo Sorce]

On Thu, 10 Feb 2011 13:53:58 -0500

Post by sssd help
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.