Back to bug 785877

Who When What Removed Added
Jenny Severance 2012-01-31 14:38:36 UTC Flags needinfo?(sgallagh)
Stephen Gallagher 2012-01-31 14:43:41 UTC Flags needinfo?(sgallagh)
Stephen Gallagher 2012-02-07 21:29:50 UTC Status NEW MODIFIED
Fixed In Version sssd-1.8.0-2.el6.beta2
errata-xmlrpc 2012-02-07 21:46:13 UTC Status MODIFIED ON_QA
Jan Zeleny 2012-04-04 11:20:09 UTC CC jzeleny
releng-rhel 2012-04-19 02:03:33 UTC Blocks 814002
releng-rhel 2012-04-19 03:26:24 UTC Blocks 814002
Kaleem 2012-05-22 13:49:32 UTC Status ON_QA ASSIGNED
CC ksiddiqu
Jenny Severance 2012-06-12 17:30:34 UTC Priority unspecified medium
Jenny Severance 2012-09-21 18:17:08 UTC QA Contact seceng-idm-qe-list kbanerje
Dennis Gregorovic 2012-10-04 18:35:32 UTC Assignee sgallagh jhrozek
Jakub Hrozek 2012-10-09 20:51:43 UTC Status ASSIGNED MODIFIED
Fixed In Version sssd-1.8.0-2.el6.beta2 sssd-1.9.1-1.el6
errata-xmlrpc 2012-10-11 15:31:30 UTC Status MODIFIED ON_QA
Jakub Hrozek 2013-01-17 10:02:42 UTC Doc Text Cause: when reconnecting to an LDAP server going online, SSSD didn't check if it was re-initialized during the downtime
Consequence: if during the downtime server was reinitialized and filled with completely different data SSSD wouldn't update its database This was problematic in combination with enumeration - user could get some information from SSSD which would not be valid.
Fix: LDAP provider is now checking for max USN if the server supports it. If USN is lower than ti was before server went down the entire database is refreshed.
Result: in LDAP server supports USN, its reinitialization is detected at least when possible and the possibility of having cached invalid data is reduced
Result:
Cause: when reconnecting to an LDAP server going online, SSSD didn't check if it was re-initialized during the downtime
Consequence: if during the downtime server was reinitialized and filled with completely different data SSSD wouldn't update its database This was problematic in combination with enumeration - user could get some information from SSSD which would not be valid.
Fix: LDAP provider is now checking for max USN if the server supports it. If USN is lower than ti was before server went down the entire database is refreshed.
Result: in LDAP server supports USN its reinitialization is detected at least when possible and the possibility of having cached invalid data is reduced
Result:
Workaround: stop the SSSD before reconnecting to re-initialized server; clear the SSSD caches manually before reconnecting; start the SSSD
Jakub Hrozek 2013-01-17 11:42:29 UTC Status ON_QA ASSIGNED
CC pbrezina
Component sssd sssd
Version 6.3 7.0
Product Red Hat Enterprise Linux 6 Red Hat Enterprise Linux 7
Daniel Mach 2013-01-22 08:16:02 UTC Assignee jhrozek sgallagh
Dmitri Pal 2013-03-20 23:37:30 UTC Assignee sgallagh jhrozek
Jakub Hrozek 2013-03-26 18:17:20 UTC Status ASSIGNED POST
Jakub Hrozek 2013-04-08 15:29:57 UTC Status POST MODIFIED
Fixed In Version sssd-1.9.1-1.el6 sssd-1.10.0-1.el7.alpha1
Ondrej Hudlicky 2013-06-12 13:21:11 UTC Status MODIFIED ON_QA
Jakub Hrozek 2013-10-04 13:24:53 UTC Status ON_QA MODIFIED
errata-xmlrpc 2013-10-29 14:02:09 UTC Status MODIFIED ON_QA
Nirupama Karandikar 2014-03-06 10:20:15 UTC Status ON_QA VERIFIED
CC nkarandi
Ludek Smid 2014-06-13 11:02:47 UTC Status VERIFIED CLOSED
Resolution --- CURRENTRELEASE
Last Closed 2014-06-13 07:02:47 UTC
Pavel Březina 2020-05-02 16:17:32 UTC Link ID Github SSSD/sssd/issues/1776

Back to bug 785877