On 05/12/2010 12:19 AM, Stephen Gallagher wrote:
Simo and I had a long discussion on IRC today regarding how to
handle
the kdcinfo and kpasswdinfo files for the Kerberos locator plugin.
The basic problem is this: our recent changes made it so that when we
shut down the SSSD, we remove the kdcinfo files. When we start back up,
we write a new kdcinfo file with a correct IP address if available, or
with a fake one if we're offline.
This is causing problems with non-SSSD kerberized services. Prior to
these changes, we always left the kdcinfo file around, so when we went
online (such as connecting to a VPN), the locator plugin would already
have the old IP saved, so we would be able to hand it off and continue
to work.
Now, we continue to return "Can't contact KDC" until the SSSD performs
an online kinit. This may not happen immediately (or for a very long
time). And until that happens, kerberized servers and applications won't
work.
It is essential to (re-)locate KDC as soon as VPN (or other type of)
connection is up. It can be done by installing appropriate hooks for
ifup/ifdown and NetworkManager.
Actually the best solution would be for the locator plugin not to read
configuration files, but to contact SSSD directly over DBUS. This way
locator plugin can wait for KDC detection process to complete or even
start the detection on-demand if not started by ifup/NetworkManager hooks.
After much discussion, Simo and I have come up with the following
approach: When the SSSD is offline (mark_offline() is called) we should
remove the kdcinfo and kpasswdinfo files. In the locator plugin, if
those files are not present, we should return the appropriate error code
to pass the handling on to the krb5.conf.
I disagree with this approach. It seems appropriate to return "NOT
HANDLED" from locator plugin when SSSD is down. In this case application
or service should locate KDC itself as SSSD is not available.
When SSSD backend is offline, SSSD has already determined that no KDC is
reachable and put backend offline. So SSSD has an authoritative answer
and it does not make sense to repeat search and wait for another couple
minutes for search to fail. My opinion is that in OFFLINE state locator
plugin must return KRB5_KDC_UNREACH.
We will then allow the configuration in krb5.conf to handle requests
until we go online, at which time we will write out the kdcinfo files
and handle it ourselves.
This will probably require the following changes:
1) Enable providers to register a callback for "mark_offline()"
2) Create a callback for the kerberos provider to remove kdcinfo and
kpasswdinfo files upon going offline (and also when shutting down)
3) Modify the locator plugin to return "not handled" if the kdcinfo file
is missing.