1:30 p.m.
On to, 10 elo 2017, Matthew Carter via FreeIPA-users wrote:
The clients machines on my network from time to time get brought to
another network and plugged in to test programs that are being
developed. In the past this hasn't been an issue as it's usually a
short stay and thus the kerberos key is cached and doesn't expire.
Recently I have had a user who has requested that he be able to mount
an NFS share on the "other network".
Naturally I thought of building a sudo rule and adding it to the
freeipa server, as we don't allow user mounts due to security
requirements. The issue is however that the sudo mount request will be
made when the user is not on the network and thus I imagine that it
will get denied. Anyone have experience with this, or thoughts? If I
put a rule to allow mounting the share by this user in the local
sudoers file, will the system verify the user against the cached user
key and thus allow the mount?
Let's step away a bit and look at a normal
Kerberos operation. A client
requests a ticket granting ticket (TGT) from a KDC first. Then, using a valid
TGT, it requests a service ticket to a server from a KDC. Both these
steps require access to the KDC itself.
When there is a valid service ticket (say, to nfs/some.server.fqdn), a
client will present this service ticket to the NFS server and this means
it needs access to the NFS server here. And NFS server should have a
valid TGT itself, so it needs to have access to KDC. A client at this
point is not necessary able to talk to KDC.
So, if the client is able to talk to NFS server, it would be able to
authenticate if it obtained a ticket to it before going offline.
Now, a user can trivially request a service ticket to NFS server before
going offline with 'kvno' utility. A process of mounting a share will
then re-use the existing service ticket regardless how it was obtained.
All it needs is to be able to talk to the NFS server itself.
SSSD caches sudo rules -- see sssd-sudo(5) and sssd-ldap(5) (in the
latter search for ldap_sudo_*_refresh_interval options) for details and
default values.
Given above, I think it should just work within the constraints of
Kerberos tickets' validity and caching of sudo rules.
--
/ Alexander Bokovoy