Red Hat Bugzilla – Bug 803842
Unable to bind to LDAP server when minssf set
Last modified: 2013-06-03 10:25:08 EDT
+++ This bug was initially created as a clone of Bug #803436 +++
Description of problem:
I changed the configuration of my IPA server and set minssf to 56, as is documented n the IPA guide. All my RHEL based systems continue to function. But my one fedora desktop is now unable to bind to the server, and as such is not getting any updated information.
From the logs:
Unexpected result from ldap: Server is unwilling to perform(53), Minimum SSF not met.
Version-Release number of selected component (if applicable):
set minssf on server, watch sssd fail to bind. Frankly with all the caching that goes on I wouldn't have even noticed that it wasn't working except for a password change that arose after minssf was set.
As I said this continues to work fine in RHEL 5 and 6, so chances are this is something new or a bugfix that wasn't forward ported.
--- Additional comment from email@example.com on 2012-03-15 13:47:41 EDT ---
--- Additional comment from firstname.lastname@example.org on 2012-03-15 14:03:24 EDT ---
Ok, it turns out that there are two bugs at play here.
The first is a 389-DS bug: https://fedorahosted.org/389/ticket/168
Basically, when setting the minssf to 56, it prevents SSSD from being able to read the RootDSE (that contains some basic information about the LDAP server's capabilities). In SSSD 1.5.x (aka RHEL 5.8 and 6.2) we had a bug that was coincidentally working in your favor. We weren't throwing an error at one particular point, and instead we continued on.
Just by pure luck, this would work fine with SSSD as long as enumerate = false (it could result in some unfortunate behavior with enumerate=true).
In SSSD 1.8.x, we fixed the error so that now the RootDSE is failing loudly instead of silently. In the average (non-IPA) case, we should be allowing it to just continue on, and we're submitting a patch upstream to do that. This will result in you continuing to see the behavior you saw on 1.5.x.
But the correct long-term fix is for https://fedorahosted.org/389/ticket/168 to be fixed (and for you to set the nsslapd-minssf-exclude-rootdse option.
Updating summary. This is not exclusive to IPA.
Thanks for the detailed info, any idea when 389 will be updated in RHEL 6 so that I can set the nsslapd-minssf-exclude-rootdse option?
(In reply to comment #3)
> Thanks for the detailed info, any idea when 389 will be updated in RHEL 6 so
> that I can set the nsslapd-minssf-exclude-rootdse option?
I don't personally know. I'd strongly suggest speaking to your support representative and opening a case with them. That will go a long way towards setting the proper priority for the 389 team.
Technical note added. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.
No technical note required
Verified in version:
# rpm -qi sssd | head
Name : sssd Relocations: (not relocatable)
Version : 1.8.0 Vendor: Red Hat, Inc.
Release : 23.el6 Build Date: Fri 20 Apr 2012 11:30:39 PM IST
Install Date: Wed 25 Apr 2012 07:28:48 PM IST Build Host: x86-003.build.bos.redhat.com
Group : Applications/System Source RPM: sssd-1.8.0-23.el6.src.rpm
Size : 7874744 License: GPLv3+
Signature : (none)
Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
URL : http://fedorahosted.org/sssd/
Summary : System Security Services Daemon
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.