I have a large number of CentOS machines (both 6 & 7) getting account information from an LDAP database using SSSD. It all works fine and is fairly reliable. However, I'm having problems with persuading the caching system to forget about users when they are deleted from LDAP. I know about sss_cache with either -E or -U options, but that doesn't delete anything, just invalidates the cache entry. If the cache is invalid SSS will, obviously, go back to the source and return the information there, however, bizarrely, if the original source doesn't have the information (like when a user is deleted) the cached information is still returned. That cached information is retained for ever it seems so my supposedly deleted user accounts still appear to be active on the machines. And it also seems you can't actually turn off caching - even though there are options in sssd.conf to do so. It looks like the "cache_credentials = False" option still caches things, but just acts like the entries are always invalid. I can of course do stop sssd delete the contents of /var/lib/sss/db start sssd and that's what I do when things become an issue. But surely there is a better way of SSSD actually realising that a user has been deleted from LDAP? Pete
On Mon, 6 Aug 2018, Pete Biggs wrote:> > I have a large number of CentOS machines (both 6 & 7) getting account > information from an LDAP database using SSSD. It all works fine and is > fairly reliable. > > However, I'm having problems with persuading the caching system to > forget about users when they are deleted from LDAP. > > I know about sss_cache with either -E or -U options, but that doesn't > delete anything, just invalidates the cache entry. > > If the cache is invalid SSS will, obviously, go back to the source and > return the information there, however, bizarrely, if the original > source doesn't have the information (like when a user is deleted) the > cached information is still returned. That cached information is > retained for ever it seems so my supposedly deleted user accounts still > appear to be active on the machines. > > And it also seems you can't actually turn off caching - even though > there are options in sssd.conf to do so. It looks like the > "cache_credentials = False" option still caches things, but just acts > like the entries are always invalid. > > I can of course do > > stop sssd > delete the contents of /var/lib/sss/db > start sssd > > and that's what I do when things become an issue. But surely there is a > better way of SSSD actually realising that a user has been deleted from > LDAP?Concerning a wedged cache, deleting the relevant *.ldb files from /var/lib/sss/db is the only solution that's worked for me, though I've had to resort to it only a couple time. I've never tried disabling the cache, so I'm no help there. -- Paul Heinlein heinlein at madboa.com 45?38' N, 122?6' W
On 08/06/2018 03:16 AM, Pete Biggs wrote:> If the cache is invalid SSS will, obviously, go back to the source and > return the information there, however, bizarrely, if the original > source doesn't have the information (like when a user is deleted) the > cached information is still returned. That cached information is > retained for ever it seems so my supposedly deleted user accounts still > appear to be active on the machines.Best practice is to lock accounts, and not to delete them.
> If the cache is invalid SSS will, obviously, go back to the source and > return the information there, however, bizarrely, if the original > source doesn't have the information (like when a user is deleted) the > cached information is still returned. That cached information is > retained for ever it seems so my supposedly deleted user accounts still > appear to be active on the machines. >OK. The underlying problem wasn't specifically the cache. But it appears that an update to SSSD/LDAP has introduced the "feature" of not believing self-signed certificates, even if the CA for those certificates is in place on the host. It used to work, but now doesn't. The consequence of this is that the connection to the LDAP server fails and it falls back to the cache contents, even if the cache is marked invalid. Setting "ldap_tls_reqcert = never" in sssd.conf fixed it - it still encrypts, but the certificate isn't checked. This is not a cue for a diatribe about how self signed certificates are bad and how easy it is to get a real SSL certificate. There are reasons. It's just annoying that something that used to work, was a perfectly correct thing to do, has now been broken. P.
On Mon, 2018-08-06 at 19:55 -0700, Gordon Messmer wrote:> On 08/06/2018 03:16 AM, Pete Biggs wrote: > > If the cache is invalid SSS will, obviously, go back to the source and > > return the information there, however, bizarrely, if the original > > source doesn't have the information (like when a user is deleted) the > > cached information is still returned. That cached information is > > retained for ever it seems so my supposedly deleted user accounts still > > appear to be active on the machines. > > > Best practice is to lock accounts, and not to delete them. >I'm sure it is, but sometimes "best practice" gets over-ridden by "company policy" and "fix a problem". P.
> >> If the cache is invalid SSS will, obviously, go back to the source and >> return the information there, however, bizarrely, if the original >> source doesn't have the information (like when a user is deleted) the >> cached information is still returned. That cached information is >> retained for ever it seems so my supposedly deleted user accounts still >> appear to be active on the machines. >> > > OK. The underlying problem wasn't specifically the cache. But it > appears that an update to SSSD/LDAP has introduced the "feature" of not > believing self-signed certificates, even if the CA for those > certificates is in place on the host. It used to work, but now doesn't. > > The consequence of this is that the connection to the LDAP server fails > and it falls back to the cache contents, even if the cache is marked > invalid. > > Setting "ldap_tls_reqcert = never" in sssd.conf fixed it - it still > encrypts, but the certificate isn't checked. > > This is not a cue for a diatribe about how self signed certificates are > bad and how easy it is to get a real SSL certificate. There are > reasons. It's just annoying that something that used to work, was a > perfectly correct thing to do, has now been broken.I think I've been hit by a similar problem but in my case it was with using socat OPENSSL-CONNECT. Once the old self signed certificates expired, I recreated them but still, the connection would fail. It did so until I specified "verify=0" to socat OPENSSL-CONNECT and it worked again. Simon