#642 sssd 1.2.4 doesn't gracefully fail password changes in ldap offline mode
Closed: Fixed None Opened 13 years ago by sejeff.

Instead:

[root@ops2 ~]# passwd jschroeder
Changing password for user jschroeder.
passwd: Authentication token manipulation error
[root@ops2 ~]# su - jschroeder
[jschroeder@ops2 ~]$ passwd
Changing password for user jschroeder.
Current Password: 
passwd: Authentication token manipulation error
[jschroeder@ops2 ~]$

And in the logs:

<87> Oct 12 07:47:18.000 ops2.dev1.int passwd: pam_unix(passwd:chauthtok): user "jschroeder" does not exist in /etc/passwd
<85> Oct 12 07:47:18.000 ops2.dev1.int passwd: pam_sss(passwd:chauthtok): Authentication failed for user jschroeder: 4 (System error)
<27> Oct 12 07:48:45.000 ops2.dev1.int sssd[be[LDAP]]: Could not start TLS. (null)
<27> Oct 12 07:48:45.000 ops2.dev1.int sssd[be[LDAP]]: Could not start TLS. (null)
<27> Oct 12 07:48:45.000 ops2.dev1.int sssd[be[LDAP]]: Could not start TLS. (null)
<85> Oct 12 07:48:45.000 ops2.dev1.int passwd: pam_sss(passwd:chauthtok): Authentication failed for user jschroeder: 4 (System error)

I do recall perhaps a year or so ago testing sssd's offline mode. When I tried to run passwd to change a password, the passwd command spit out an error that password changes can't be performed in offline mode.


Fields changed

description: Instead:

[root@ops2 ~]# passwd jschroeder
Changing password for user jschroeder.
passwd: Authentication token manipulation error
[root@ops2 ~]# su - jschroeder
[jschroeder@ops2 ~]$ passwd
Changing password for user jschroeder.
Current Password:
passwd: Authentication token manipulation error
[jschroeder@ops2 ~]$

And in the logs:

<87> Oct 12 07:47:18.000 ops2.dev1.int passwd: pam_unix(passwd:chauthtok): user "jschroeder" does not exist in /etc/passwd
<85> Oct 12 07:47:18.000 ops2.dev1.int passwd: pam_sss(passwd:chauthtok): Authentication failed for user jschroeder: 4 (System error)
<27> Oct 12 07:48:45.000 ops2.dev1.int sssd[be[LDAP]]: Could not start TLS. (null)
<27> Oct 12 07:48:45.000 ops2.dev1.int sssd[be[LDAP]]: Could not start TLS. (null)
<27> Oct 12 07:48:45.000 ops2.dev1.int sssd[be[LDAP]]: Could not start TLS. (null)
<85> Oct 12 07:48:45.000 ops2.dev1.int passwd: pam_sss(passwd:chauthtok): Authentication failed for user jschroeder: 4 (System error)

I do recall perhaps a year or so ago testing sssd's offline mode. When I tried to run passwd to change a password, the passwd command spit out an error that password changes can't be performed in offline mode.
=> Instead:
{{{
[root@ops2 ~]# passwd jschroeder
Changing password for user jschroeder.
passwd: Authentication token manipulation error
[root@ops2 ~]# su - jschroeder
[jschroeder@ops2 ~]$ passwd
Changing password for user jschroeder.
Current Password:
passwd: Authentication token manipulation error
[jschroeder@ops2 ~]$
}}}

And in the logs:
{{{
<87> Oct 12 07:47:18.000 ops2.dev1.int passwd: pam_unix(passwd:chauthtok): user "jschroeder" does not exist in /etc/passwd
<85> Oct 12 07:47:18.000 ops2.dev1.int passwd: pam_sss(passwd:chauthtok): Authentication failed for user jschroeder: 4 (System error)
<27> Oct 12 07:48:45.000 ops2.dev1.int sssd[be[LDAP]]: Could not start TLS. (null)
<27> Oct 12 07:48:45.000 ops2.dev1.int sssd[be[LDAP]]: Could not start TLS. (null)
<27> Oct 12 07:48:45.000 ops2.dev1.int sssd[be[LDAP]]: Could not start TLS. (null)
<85> Oct 12 07:48:45.000 ops2.dev1.int passwd: pam_sss(passwd:chauthtok): Authentication failed for user jschroeder: 4 (System error)
}}}

I do recall perhaps a year or so ago testing sssd's offline mode. When I tried to run passwd to change a password, the passwd command spit out an error that password changes can't be performed in offline mode.

summary: [REGRESSION] sssd 1.2.4 doesn't gracefully fail password changes in ldap offline mode => sssd 1.2.4 doesn't gracefully fail password changes in ldap offline mode

We do not set the backend into offline mode if an TLS error occurs. We need tpo figure out under which circumstances an TLS error means offline.

Maybe it makes sense to just add a rootDSE search at the beginning of the connection. This means an extra roundtrip to the LDAP server, but will indicate more clearly if the server is available or not.

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.5.0

Fields changed

owner: somebody => sbose

After a closer look the solution is simpler than I thought. There are just some flaws in the offline detection.

Fixed by 488f178

resolution: => fixed
status: new => closed

Fields changed

rhbz: => 0

Metadata Update from @sejeff:
- Issue assigned to sbose
- Issue set to the milestone: SSSD 1.5.0

7 years ago

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/1684

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.

Metadata