[Freeipa-users] documentation or example of using S42U for NFS
Greg
gkubok at gmail.com
Thu Mar 2 02:29:22 UTC 2017
I've been at this as well for a while now, and managed to make it work for
my NFS needs (automounting user homes with password-less logons).
Whether and how this would apply to cron or other services, I don't know
yet, but presumably would/should work in a similar manner.
My env:
$ lsb_release -d
Description: Red Hat Enterprise Linux Server release 7.3 (Maipo)
$ rpm -q ipa-server
ipa-server-4.4.0-14.el7_3.4.x86_64
$ ipa --version
VERSION: 4.4.0, API_VERSION: 2.213
This is what worked for me in the end:
1. Create "nfs/nfsserver.dom.com at DOM.COM" service, and add to NFS server's
/etc/krb5.keytab.
2. Create IPA "servicedelegation" rule/targets, so that they look like so:
$ ipa servicedelegationrule-show ipa-nfs-delegation
Delegation name: ipa-nfs-delegation
Allowed Target: ipa-nfs-delegation-targets
Member principals: *host*/*nfsclient*.dom.com at DOM.COM
$ ipa servicedelegationtarget-show ipa-nfs-delegation-targets
Delegation name: ipa-nfs-delegation-targets
Member principals: *nfs*/*nfsserver*.dom.com at DOM.COM
Only niggle here is IPA CLI didn't let me add "host/..." principal to the
rule, or perhaps there's a default LDAP ACI of some sort and it requires a
privilege/permission to be granted. The "ipa
servicedelegationrule-add-member ..." command simply says "no such entry"
for "host/..." type principals. Maybe IPA folks can comment.
I force added it to the delegation rule via LDAP instead using this ldif:
dn: cn=ipa-nfs-delegation,cn=s4u2proxy,cn=etc,dc=dom,dc=com
changetype: modify
add: memberPrincipal
memberPrincipal: host/nfsclient.dom.com at DOM.COM
The "nfs/..." principal can be added using CLI
"ipa servicedelegationtarget-add-member ..." just fine.
3. Allow the "nfsclient" host to impersonate users:
$ ipa host-mod nfsclient.dom.com --ok-to-auth-as-delegate=true
4. On the "nfsclient" machine, add "impersonate = true" line in the
"[service/nfs-client]" section of /etc/gssproxy/gssproxy.conf.
5. Restart nfs/gssproxy/rpc services on client and server (it's probably
just gssproxy on the client that needs a kick, but just to be sure). I was
also religiously doing "sss_cache -E" for good measure, unmounting anything
that got mounted, and clearing /var/lib/gssproxy/clients of all caches, to
start as cleanly before each attempt at user logon. Obv make sure the user
does not have an existing/valid ticket in their own cache ("kdestroy -A" as
the user), otherwise it'll just mount successfully without delegation.
I think that's it, I've messed about with the config for a long time and in
many places, so there's a small chance there's something else that I did
and don't remember. Gssproxy config on "nfsserver" is vanilla, as are my
sssd.confs and krb5.confs on both machines, can't think of much else that I
might've changed for now.
So my IPA automount config now mounts users' home dirs on the "nfsclient",
without any tickets or keytabs from users.
There's also a "krb5_principal" option available in gssproxy.conf - I tried
to set that to "nfs/nfsclient at DOM.COM" in "[service/nfs-client]" section on
the "nfsclient" machine, to try and force gssproxy to use that principal
instead of "host/...", but it didn't seem to work, gssproxy defaults to
"host/...". Possibly mis-understanding what this option is for, and
possibly "host/..." is the safer/standard option? I'm assuming it's default
for a reason, or maybe just operational convenience (not having to pollute
/etc/krb5.keytabs with more principals than necessary).
Hope this helps.
--
Thanks,
Greg Kubok.
On 1 March 2017 at 22:47, Orion Poplawski <orion at cora.nwra.com> wrote:
> If you ever get this into a repository, I'd love to see it. Thanks.
>
> On 01/17/2017 07:44 PM, Charles Hedrick wrote:
> > Instructions like that are several places. But NFS is different, and I
> believe the configuration would be different from other services.
> >
> > I’ve given up on this approach, and have written my own utilities. I’ve
> actually got three. The first two assume that users who want to do cron
> jobs on a machine register a keytab for that machine on a secure system. I
> don’t want to put the actual keytab on the machine where the user is
> running, because if someone can become root, they can take the keytab and
> use it anywhere. (I’m in a computer science dept with systems run by
> faculty and grad students; also systems in public labs.)
> >
> > So instead, I allow users to register that they want to do cron on a
> specific machine by putting a keytab on a secure server, associated with
> their username and the hostname. I expect to write a web app to set that up.
> >
> > Credserv runs on the machine with the keytabs. It accepts a request from
> a server, authenticated using the host’s host key (i.e. /etc/krb5.keytab),
> with a username in the request. If the user has registered a keytab for
> that host, credserv returns a credential, locked to that IP address, with
> forwarding off.
> >
> > Kgetcred is the client side. It runs setuid root (so it can read
> /etc/krb5.keytab), though it drops privs as quickly as possible. It creates
> a credentials cache for the user from the credentials returned from
> credserv.
> >
> > This gives the best granularity of control I can come up with.
> >
> > There’s a third utility in the family: renewd. It gets the uids of all
> current processes, and renews credentials for all of the users. It’s more
> complex than you’d expect because a normal renewal (as in kinit -R or
> kstart) leaves a brief period of time when the credentials cache is
> unusable. This can result in NFS failing. I use a special approach that
> depends upon the details of the KEYRING implementation. It should be free
> of race conditions for NFS. If desired, a different approach to avoid race
> conditions could be used for caches located in /tmp. I haven’t written that
> code but there’s a comment in the source outlining it.
> >
> > I’ll be creating a git repository for the code.
> >
> >
> >> On Jan 17, 2017, at 6:41:13 PM, Orion Poplawski <orion at cora.nwra.com>
> wrote:
> >>
> >> On 01/09/2017 09:52 AM, Charles Hedrick wrote:
> >>> Various documentation suggests that it is possible for Gssproxy to get
> tickets for users who need to use NFS. This is a possible way to handle
> things like cron jobs.
> >>>
> >>> However while a gssproxy.conf example is given, there’s no sign of
> what needs to be done in freeipa to authorize it. I tried following
> instructions for LDAP access, but it doesn’t work. NFS seems to use a
> different, two-stage method for getting credentials, so that’s not a
> surprise. There are, not surprisingly, no useful error messages even with
> logging turned all the way up.
> >>>
> >>>
> >>
> >> I'm interested in this as well. All I've been able to find so far is:
> >>
> >> https://vda.li/en/posts/2013/07/29/Setting-up-S4U2Proxy-with-FreeIPA/
> >>
> >> haven't tried anything.
> >>
> >> --
> >> Orion Poplawski
> >> Technical Manager 720-772-5637
> >> NWRA, Boulder/CoRA Office FAX: 303-415-9702
> >> 3380 Mitchell Lane orion at nwra.com
> >> Boulder, CO 80301 http://www.nwra.com
> >
>
>
> --
> Orion Poplawski
> Technical Manager 720-772-5637
> NWRA, Boulder/CoRA Office FAX: 303-415-9702
> 3380 Mitchell Lane orion at nwra.com
> Boulder, CO 80301 http://www.nwra.com
>
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20170302/19a153bb/attachment.htm>
More information about the Freeipa-users
mailing list