Bug 905619
| Summary: | passwd returns anonymous bind not allowed and does not follow referrals to a chpass server | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Orion Poplawski <orion> | ||||
| Component: | sssd | Assignee: | SSSD Maintainers <sssd-maint> | ||||
| Status: | CLOSED UPSTREAM | QA Contact: | Namita Soman <nsoman> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 7.0 | CC: | dpal, grajaiya, jgalipea, jhrozek, mkosek, pbrezina, sbose, ssorce | ||||
| Target Milestone: | rc | ||||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2018-04-18 15:02:52 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 1420851 | ||||||
| Attachments: |
|
||||||
|
Description
Orion Poplawski
2013-01-29 18:54:01 UTC
[domain/default] ldap_id_use_start_tls = True cache_credentials = True ldap_search_base = dc=example,dc=com id_provider = ldap auth_provider = ldap chpass_provider = ldap ldap_uri = ldap://ldap.sub.example.com/,ldap://ldap2.sub.example.com/ ldap_tls_cacertdir = /etc/openldap/cacerts ldap_account_expire_policy = 389ds enumerate = True [sssd] services = nss, pam config_file_version = 2 domains = default [nss] [pam] [sudo] [autofs] [ssh] Server is running 389ds Sorry but there is not enough information to debug the problem. How often does this happen? Every time, occasionaly? Is there a pattern? Do you have logs? If not, can you set debug_level=10 into the domain section, restart the SSSD and try to capture the problem. Also, the 6.4 is getting close. If you have a testing machine that doesn't run in production, I could build you a test packages roughly equivalent to what 6.4 is going to be. Haven't found a pattern yet. Just that sometimes when someone goes to change their password it fails. I haven't reproduced it yet. I've turned on debugging so hopefully we'll get some useful information when it happens again. Let's hold off test packages until we get some more info. This request was not resolved in time for the current release. Red Hat invites you to ask your support representative to propose this request, if still desired, for consideration in the next release of Red Hat Enterprise Linux. FWIW - here's the full passwd error: Changing password for user lund. Current Password: New password: Retype new password: Password change failed. Server message: Anonymous Binds are not allowed. passwd: Authentication token manipulation error Unfortunately I had put in "debug = 10" instead of "debug_level = 10" (I'm still stuck in the old format) so I don't have any debug info from this failure. Hi Orion, I tried to reproduce this bug with your configuration, I tried few different scenarios, but I didn't manage to get the error. Did it occur since? Do you have the logs? Created attachment 707123 [details]
sssd_default.log
Looks like I can reproduce it now:
Mar 8 09:40:20 earth passwd: pam_unix(passwd:chauthtok): user "schuck" does not exist in /etc/passwd
Mar 8 09:40:20 earth passwd: pam_sss(passwd:chauthtok): User info message: Password change failed. Server message: Anonymous Binds are not allowed.
Mar 8 09:40:20 earth passwd: pam_sss(passwd:chauthtok): Password change failed for user schuck: 20 (Authentication token manipulation error)
I've attached the sssd_default.log from the time period of the password change attempt.
Hi Orion, It looks like the DS misconfiguration, do you have password policy module loaded and configured? I have no reason to believe it isn't: passwordInHistory: 6 passwordUnlock: on passwordGraceLimit: 1 passwordMustChange: off passwordWarning: 1209600 passwordLockout: off passwordMinLength: 10 passwordMinDigits: 0 passwordMinAlphas: 0 passwordMinUppers: 0 passwordMinLowers: 0 passwordMinSpecials: 0 passwordMin8bit: 0 passwordMaxRepeats: 0 passwordMinCategories: 3 passwordMinTokenLength: 3 passwordMaxFailure: 3 passwordMaxAge: 31536000 passwordResetFailureCount: 600 passwordisglobalpolicy: off passwordlegacypolicy: on passwordTrackUpdateTime: off passwordChange: on passwordExp: on passwordLockoutDuration: 3600 passwordCheckSyntax: on passwordMinAge: 0 passwordStorageScheme: SSHA nsslapd-pluginarg2: userpassword Can it be that the server runs out of connections? I remember that in the past there was a limitation in 389 on how many searches can be in motion from same same client at the same time. Can this be the similar situation. Imagine the scenario: Client starts a search that takes too long, the monitor decides to kill back end, a new BE is started a new search is requested but server things there is another search in progress at the same time and rejects the client. SSSD restart might clean things somehow. Just a theory... No, the logs doesn't indicate anything like this. Orion, can you paste output of: ldapsearch -x -H ldap://example.com -s base -b "" "(objectclass=*)" supportedExtension supportedControl Also your sssd.conf would be nice to have. Thank you. namingContexts: dc=example,dc=com namingContexts: o=netscaperoot supportedExtension: 2.16.840.1.113730.3.5.7 supportedExtension: 2.16.840.1.113730.3.5.8 supportedExtension: 2.16.840.1.113730.3.5.3 supportedExtension: 2.16.840.1.113730.3.5.12 supportedExtension: 2.16.840.1.113730.3.5.5 supportedExtension: 2.16.840.1.113730.3.5.6 supportedExtension: 2.16.840.1.113730.3.5.9 supportedExtension: 2.16.840.1.113730.3.5.4 supportedExtension: 2.16.840.1.113730.3.6.5 supportedExtension: 2.16.840.1.113730.3.6.6 supportedExtension: 2.16.840.1.113730.3.6.7 supportedExtension: 2.16.840.1.113730.3.6.8 supportedExtension: 1.3.6.1.4.1.1466.20037 supportedExtension: 1.3.6.1.4.1.4203.1.11.1 supportedControl: 2.16.840.1.113730.3.4.2 supportedControl: 2.16.840.1.113730.3.4.3 supportedControl: 2.16.840.1.113730.3.4.4 supportedControl: 2.16.840.1.113730.3.4.5 supportedControl: 1.2.840.113556.1.4.473 supportedControl: 2.16.840.1.113730.3.4.9 supportedControl: 2.16.840.1.113730.3.4.16 supportedControl: 2.16.840.1.113730.3.4.15 supportedControl: 2.16.840.1.113730.3.4.17 supportedControl: 2.16.840.1.113730.3.4.19 supportedControl: 1.3.6.1.4.1.42.2.27.8.5.1 supportedControl: 1.3.6.1.4.1.42.2.27.9.5.2 supportedControl: 1.2.840.113556.1.4.319 supportedControl: 1.3.6.1.4.1.42.2.27.9.5.8 supportedControl: 1.3.6.1.4.1.4203.666.5.16 supportedControl: 2.16.840.1.113730.3.4.14 supportedControl: 2.16.840.1.113730.3.4.20 supportedControl: 1.3.6.1.4.1.1466.29539.12 supportedControl: 2.16.840.1.113730.3.4.12 supportedControl: 2.16.840.1.113730.3.4.18 supportedControl: 2.16.840.1.113730.3.4.13 supportedSASLMechanisms: EXTERNAL supportedSASLMechanisms: CRAM-MD5 supportedSASLMechanisms: DIGEST-MD5 supportedSASLMechanisms: PLAIN supportedSASLMechanisms: GSSAPI supportedSASLMechanisms: LOGIN supportedSASLMechanisms: ANONYMOUS supportedLDAPVersion: 2 supportedLDAPVersion: 3 vendorName: 389 Project vendorVersion: 389-Directory/1.2.11.15 B2013.053.215 dataversion: 020130307152447020130307152447 netscapemdsuffix: cn=ldap://dc=example,dc=com:389 sssd.conf: [domain/default] debug_level = 10 ldap_id_use_start_tls = True cache_credentials = True ldap_search_base = dc=example,dc=com id_provider = ldap auth_provider = ldap chpass_provider = ldap ldap_uri = ldap://ldap.example.com/,ldap://ldap2.example.com/ ldap_tls_cacertdir = /etc/openldap/cacerts ldap_account_expire_policy = 389ds enumerate = True [sssd] services = nss, pam config_file_version = 2 domains = default [nss] [pam] [sudo] [autofs] [ssh] On a successful password change: (Tue Mar 12 10:07:15 2013) [sssd[be[default]]] [sdap_control_create] (0x0080): Server does not support the requested control [1.3.6.1.4.1.42.2.27.8.5.1]. (Tue Mar 12 10:07:15 2013) [sssd[be[default]]] [sdap_exop_modify_passwd_send] (0x0100): Executing extended operation (Tue Mar 12 10:07:15 2013) [sssd[be[default]]] [sdap_exop_modify_passwd_send] (0x2000): ldap_extended_operation sent, msgid = 3 (Tue Mar 12 10:07:15 2013) [sssd[be[default]]] [sdap_process_result] (0x2000): Trace: sh[0x18164d0], connected[1], ops[0x1817730], ldap[0x17dfda0] (Tue Mar 12 10:07:15 2013) [sssd[be[default]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! (Tue Mar 12 10:07:15 2013) [sssd[be[default]]] [sdap_process_result] (0x2000): Trace: sh[0x18164d0], connected[1], ops[0x1817730], ldap[0x17dfda0] (Tue Mar 12 10:07:15 2013) [sssd[be[default]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_EXTENDED] (Tue Mar 12 10:07:15 2013) [sssd[be[default]]] [sdap_exop_modify_passwd_done] (0x0200): Server returned no controls. (Tue Mar 12 10:07:15 2013) [sssd[be[default]]] [sdap_exop_modify_passwd_done] (0x0080): ldap_extended_operation result: Success(0), (null) (Tue Mar 12 10:07:15 2013) [sssd[be[default]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 0, <NULL>) [Success] (Tue Mar 12 10:07:15 2013) [sssd[be[default]]] [be_pam_handler_callback] (0x0100): Sending result [0][default] (Tue Mar 12 10:07:15 2013) [sssd[be[default]]] [be_pam_handler_callback] (0x0100): Sent result [0][default] (Tue Mar 12 10:07:15 2013) [sssd[be[default]]] [sdap_handle_release] (0x2000): Trace: sh[0x18164d0], connected[1], ops[(nil)], ldap[0x17dfda0], destructor_lock[0], release_memory[0] Thanks. So unsupported control is obviously not the problem. Although I wonder why we detect it as unsupported when it is present in rootDSE. Did you manage to take directory server logs? I see there are 2 servers in the ssd configuration, is it possible the 2 servers have different configurations, and sssd fails only when falling back to the second server ? According to the logs the initial user bind is against the ldap2... server, sssd receives a referral and tries to connect to the ldap... server re-running the operation. The operation against ldap... fails, because the rebind is done anonymously, because sssd currently does not support rebinds with user credentials. I guess the ldap2... server is a read-only replica. To avoid that this server is used for password changes please use ldap_chpass_uri in sssd.conf where you list only the writable LDAP servers. I will open an SSSD upstream ticket to handle rebinds with user credentials correctly. Thanks everyone. I'll use the ldap_chpass_url workaround for now. FWIW - # ldapsearch -x -H ldap://ldap2.cora.nwra.com -s base -b "" "(objectclass=*)" | grep -F 1.3.6.1.4.1.42.2.27.8.5.1 supportedControl: 1.3.6.1.4.1.42.2.27.8.5.1 So I'm not sure what's up with that. (In reply to comment #19) > Thanks everyone. I'll use the ldap_chpass_url workaround for now. FWIW - > > # ldapsearch -x -H ldap://ldap2.cora.nwra.com -s base -b "" > "(objectclass=*)" | grep -F 1.3.6.1.4.1.42.2.27.8.5.1 > supportedControl: 1.3.6.1.4.1.42.2.27.8.5.1 > > So I'm not sure what's up with that. That makes sense, since the control is supported on this server. It takes the request, sees that it is not allowed to change the password since it only has read-only copy of the tree and returns a referral to a writable server. Since there is a clear workaround re-purporting the ticket till later release. Upstream ticket: https://fedorahosted.org/sssd/ticket/1836 Thank you for filing this bug report. Since fixing this bug requires work in the upstream SSSD project which is not scheduled for the immediate future, I added a conditional development nack, pending upstream availability. Thank you for filing this bug report. Since fixing this bug requires work in the upstream SSSD project which is not scheduled for the immediate future, I added a conditional development nack for RHEL-7.5, pending upstream availability. We don't have plans to address this issue in RHEL in the immediate future. Therefore I'm closing this request with the UPSTREAM resolution. Please reopen if you disagree. |