Currently, the SSSD resets the offline flag for a backend whenever the routing table changes. This means that the next action that comes in that would require an online lookup will go to the network. At this time, any pending callbacks that are awaiting processing (e.g. the deferred offline kerberos authentication) will fire.
However, the problem is that the order of operations ends up behaving like this in a common scenario:
1) Turn on laptop (off the network)
2) Sign into your kerberos account with offline credentials
3) Connect to the VPN
4) Wait a while until some event happens that ends up connecting to the network for a lookup
5) Kerberos credentials are updated
We should add a method to the data provider interface (goingOnline) that will be triggered whenever the offline flag is reset due to a routing table change. The callback for this method should be provider-specific, but essentially perform a no-op network function to immediately test whether we actually are back online. For example, when this method is invoked for the LDAP provider, it should perform a rootDSE lookup.
milestone: NEEDS_TRIAGE => SSSD 1.5.0
priority: major => minor
owner: somebody => sbose
priority: minor => major
status: new => assigned
resolution: => fixed
status: assigned => closed
Note to QA:
A good way to automate this test would be to take the following steps:
1. Set krb5_store_password_if_offline = true
1. Restart SSSD and perform an online krb5 auth
1. Shut down sssd
1. Manually alter /etc/resolv.conf so that the DNS server points to somewhere invalid (e.g. 127.0.0.2)
1. Start up sssd
1. Perform a kerberos authentication (this will be offline using cached credentials)
1. Change /etc/resolv.conf back to a valid DNS server.
1. Within five seconds, the user should receive a valid TGT in their credential cache.
rhbz: => 0
Metadata Update from @sgallagh:
- Issue assigned to sbose
- Issue set to the milestone: SSSD 1.5.0
to comment on this ticket.
Copyright © 2014-2017 Red Hat
3.7.1 — Documentation