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
Workaround: stop the SSSD before reconnecting to re-initialized server; clear the SSSD caches manually before reconnecting; start the SSSD