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): sssd-1.8.0-6.fc16.x86_64 How reproducible: 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. -Erinn
Upstream ticket: https://fedorahosted.org/sssd/ticket/1257
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.
Correcting the previous statement. We cannot count on the server to always behave properly (this issue has turned up on AD and OpenLDAP configurations as well). We need to modify SSSD so that if it cannot get the RootDSE prior to authentication, we should attempt to acquire it afterwards. https://fedorahosted.org/sssd/ticket/1258
sssd-1.8.3-11.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/sssd-1.8.3-11.fc17
sssd-1.8.3-11.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/sssd-1.8.3-11.fc16
Package sssd-1.8.3-11.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing sssd-1.8.3-11.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-7279/sssd-1.8.3-11.fc17 then log in and leave karma (feedback).
sssd-1.8.3-11.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
sssd-1.8.3-11.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.