Hide Forgot
This bug is created as a clone of upstream ticket: https://fedorahosted.org/sssd/ticket/1635 One of our users noted on the sssd-users list that the behaviour of ldap_sasl_authid has changed between 1.8 and 1.9: https://lists.fedorahosted.org/pipermail/sssd-users/2012-November/000279.html We should investigate if it's the case and either amend the code or the docs as appropriate.
To reproduce, simply configure AD or IPA provider and use a full principal in ldap_sasl_authid. The initialization of the provider will fail.
Verified in version 1.9.2-24 Output of beaker automation run: :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [ LOG ] :: adprovider_010 Verify bz877972 Using full principal ldap_sasl_authid=host/adclient.addomain.com :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: Starting sssd: [ OK ] [ OK ] :: [ PASS ] :: Running 'service sssd start' testuser01:*:770812699:770800513:testuser01:/: :: [ PASS ] :: Running 'getent passwd testuser01' spawn ssh -q -l testuser01 localhost echo 'login successful' testuser01@localhost's password: login successful :: [ PASS ] :: Authentication successful, as expected :: [ PASS ] :: Running 'auth_success testuser01 Secret123' :: [ PASS ] :: File '/var/log/sssd/sssd_ADTEST.log' should contain 'Option ldap_sasl_authid has value host/adclient.addomain.com' :: [ PASS ] :: File '/var/log/sssd/sssd_ADTEST.log' should contain 'Principal matched to the sample' adprovider-010-Verify-bz877972-Using-full-principal-ldap-sasl-authid-host-adclient-addomain-com-SSSDAD-COM result: PASS
Note that this still does not work as of: sssd-1.9.2-4.upstream_1_9_3.el6_3.x86_64 Additionally, when this parameter is used, an end dollar letter '$' is automatically appended - i.e. if I use: ldap_sasl_authid = logina$ principal 'logina$$@<REALM>' is used instead. I believe we should not even attempt to add dollar at the end automatically under no conditions as it is very confusing. We should only add the Kerberos realm *if it is missing* and nothing else. Ondrej
Sorry Ondrej, sssd-1.9.2-4.upstream_1_9_3.el6_3.x86_64 was wrong, see the message on sssd-devel. I fixed the repo, can you try upgrading to -5 and retry? Sorry for the inconvenience.
Ondrej confirmed that his case didn't work correctly even with the latest packages. Putting back to ASSIGNED as per comment #5.
I can confirm the issue above has been fixed in: sssd-1.9.2-6.upstream_1_9_3.el6_3.x86_64 Thanks Jakub for the prompt fix.
Verified in version 1.9.2-59 Output from beaker automation run: :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [ LOG ] :: adprovider_010 Verify bz877972 Using full principal ldap_sasl_authid=host/adclient.addomain.com :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: Stopping sssd: [ OK ] Starting sssd: [ OK ] [ OK ] :: [ PASS ] :: Running 'service sssd start' :: [ PASS ] :: File '/var/log/sssd/sssd_ADTEST.log' should contain 'Option ldap_sasl_authid has value host/adclient.addomain.com' :: [ PASS ] :: File '/var/log/sssd/sssd_ADTEST.log' should contain 'authid contains realm \[SSSDAD.COM\]' :: [ PASS ] :: File '/var/log/sssd/sssd_ADTEST.log' should contain 'Will look for host/adclient.addomain.com in' :: [ PASS ] :: File '/var/log/sssd/sssd_ADTEST.log' should contain 'Trying to find principal host/adclient.addomain.com in keytab' :: [ PASS ] :: File '/var/log/sssd/sssd_ADTEST.log' should contain 'Principal matched to the sample (host/adclient.addomain.com)' testuser01:*:770815747:770800513:testuser01:/: :: [ PASS ] :: Running 'getent passwd testuser01' spawn ssh -q -l testuser01 localhost echo 'login successful' testuser01@localhost's password: login successful :: [ PASS ] :: Authentication successful, as expected :: [ PASS ] :: Running 'auth_success testuser01 Secret123' '2695502e-5034-4d82-a4aa-947ad3ea8924' adprovider-010-Verify-bz877972-Using-full-principal-ldap-sasl-authid-host-adclient-addomain-com-SSSDAD-COM result: PASS
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. http://rhn.redhat.com/errata/RHSA-2013-0508.html