I've been using sssd + AD to do auth for a few years now. Offline authentication is enabled and works normally. In that time I've upgraded my Ubuntu laptop several times, and each time I noticed that after the update, I cannot log in unless I'm on the corp network with direct access to AD. That hasn't really been a problem until now. I'm working from home over vpn all the time and don't have to option of going in to get on the corp network.
I know the workaround is to use a local account, get on the VPN, authenticate with my AD account and populate the cache, but IT doesn't like me creating local users and it's a pain. I haven't tried the latest update yet (19.10 -> 20.04, sssd currently 2.2.0).
Since something in the upgrade process is presumably destroying the cache, I was wondering if there's a "nice" way around this? Ubuntu upgrades for sssd seem like they're just upgrading sssd via apt, so I'm wondering why these major updates seem to operate differently from minor ones, and if that's intentional.
Thanks!
On 7/29/20 5:27 PM, xcorvis@gmail.com wrote:
I've been using sssd + AD to do auth for a few years now. Offline authentication is enabled and works normally. In that time I've upgraded my Ubuntu laptop several times, and each time I noticed that after the update, I cannot log in unless I'm on the corp network with direct access to AD. That hasn't really been a problem until now. I'm working from home over vpn all the time and don't have to option of going in to get on the corp network.
I know the workaround is to use a local account, get on the VPN, authenticate with my AD account and populate the cache, but IT doesn't like me creating local users and it's a pain. I haven't tried the latest update yet (19.10 -> 20.04, sssd currently 2.2.0).
Since something in the upgrade process is presumably destroying the cache, I was wondering if there's a "nice" way around this? Ubuntu upgrades for sssd seem like they're just upgrading sssd via apt, so I'm wondering why these major updates seem to operate differently from minor ones, and if that's intentional.
SSSD itself certainly does not destroy any cached content during updates. We takes lots of care to keep the cache working. Even if we did some incompatible changes in the cache format we just update it first time SSSD is run and no data is thrown away.
Is it possible that Ubuntu removes the old cache as part of the upgrade process?
If SSSD doesn't do it, then that seems likely. I'll try opening up a bug with the ubuntu maintainers after my next upgrade, when I have some more data. Thanks!
I tried the update today... and it worked fine, the cache worked like it was supposed to. I did pause at the point when I was prompted to reboot, and I ran 'id' and 'sudo', and checked that the cache file existed, everything was fine. I swear I've been doing upgrades every 6 months for 3 years and this is the first time it retained my creds. But hey, it works and that's what's important. Thanks again.
On (29/07/20 15:27), xcorvis@gmail.com wrote:
I've been using sssd + AD to do auth for a few years now. Offline authentication is enabled and works normally. In that time I've upgraded my Ubuntu laptop several times, and each time I noticed that after the update, I cannot log in unless I'm on the corp network with direct access to AD. That hasn't really been a problem until now. I'm working from home over vpn all the time and don't have to option of going in to get on the corp network.
I know the workaround is to use a local account, get on the VPN, authenticate with my AD account and populate the cache, but IT doesn't like me creating local users and it's a pain. I haven't tried the latest update yet (19.10 -> 20.04, sssd currently 2.2.0).
You can use `sss_seed` to add user to the cache even when you are offline. https://linux.die.net/man/8/sss_seed
But you need to run as root.
LS
I did not know about that tool, that should save me a few steps. I was not looking forward to configuring the VPN under another user. Thanks!
sssd-users@lists.fedorahosted.org