So, I tried doing the test section in the V4 doc below. However, I get an error.
https://www.freeipa.org/page/V4/Keytab_Retrieval
===================== [root@ipa home]# ipa-getkeytab -r -s ipa.neverland.ddns.me -p NFS/abyss.neverland.ddns.me -k abyss-nfs.keytab Failed to parse result: Insufficient access rights
Failed to get keytab
Boyd Ako via FreeIPA-users wrote:
So, I tried doing the test section in the V4 doc below. However, I get an error.
https://www.freeipa.org/page/V4/Keytab_Retrieval
===================== [root@ipa home]# ipa-getkeytab -r -s ipa.neverland.ddns.me -p NFS/abyss.neverland.ddns.me -k abyss-nfs.keytab Failed to parse result: Insufficient access rights
Failed to get keytab
What user do you have a TGT for when executing this command? admin should be able to do this.
rob
I did as admin and still
========== [binary@ipa ~]$ klist Ticket cache: KEYRING:persistent:1000:1000 Default principal: admin@NEVERLAND.DDNS.ME
Valid starting Expires Service principal 08/01/2019 02:09:35 08/02/2019 02:09:28 krbtgt/NEVERLAND.DDNS.ME@NEVERLAND.DDNS.ME [binary@ipa ~]$ ipa-getkeytab -r -s ipa.neverland.ddns.me -p NFS/abyss.neverland.ddns.me -k abyss-nfs.keytab Failed to parse result: Insufficient access rights
Failed to get keytab
On to, 01 elo 2019, Boyd Ako via FreeIPA-users wrote:
I did as admin and still
========== [binary@ipa ~]$ klist Ticket cache: KEYRING:persistent:1000:1000 Default principal: admin@NEVERLAND.DDNS.ME
Valid starting Expires Service principal 08/01/2019 02:09:35 08/02/2019 02:09:28 krbtgt/NEVERLAND.DDNS.ME@NEVERLAND.DDNS.ME [binary@ipa ~]$ ipa-getkeytab -r -s ipa.neverland.ddns.me -p NFS/abyss.neverland.ddns.me -k abyss-nfs.keytab Failed to parse result: Insufficient access rights
Failed to get keytab
Are you retrieving existing key or the key does not exist yet?
What does 'ipa service-show NFS/...' show?
Does it have 'Keytab: True' in the output?
BTW, for NFS your service principal has to be nfs/..., not NFS/.... This is described in the man page for rpc.gssd, section "Machine credentials".
On to, 01 elo 2019, Boyd Ako via FreeIPA-users wrote: Are you retrieving existing key or the key does not exist yet?
Created the host and the service. Not entirely sure about creating a key.
What does 'ipa service-show NFS/...' show?
[root@ipa binary]# ipa service-show nfs/abyss.neverland.ddns.me Principal name: NFS/abyss.neverland.ddns.me@NEVERLAND.DDNS.ME Principal alias: NFS/abyss.neverland.ddns.me@NEVERLAND.DDNS.ME Keytab: False Managed by: abyss.neverland.ddns.me Hosts allowed to retrieve keytab: ipa.neverland.ddns.me
Does it have 'Keytab: True' in the output?
Apparently no... How do I change it to true?
BTW, for NFS your service principal has to be nfs/..., not NFS/.... This is described in the man page for rpc.gssd, section "Machine credentials".
Well the Web UI seems to have made them with caps.
On ti, 13 elo 2019, Boyd Ako via FreeIPA-users wrote:
On to, 01 elo 2019, Boyd Ako via FreeIPA-users wrote: Are you retrieving existing key or the key does not exist yet?
Created the host and the service. Not entirely sure about creating a key.
What does 'ipa service-show NFS/...' show?
[root@ipa binary]# ipa service-show nfs/abyss.neverland.ddns.me Principal name: NFS/abyss.neverland.ddns.me@NEVERLAND.DDNS.ME Principal alias: NFS/abyss.neverland.ddns.me@NEVERLAND.DDNS.ME Keytab: False Managed by: abyss.neverland.ddns.me Hosts allowed to retrieve keytab: ipa.neverland.ddns.me
Does it have 'Keytab: True' in the output?
Apparently no... How do I change it to true?
By running ipa-getkeytab. Please read the documentation for ipa-getkeytab and note the difference in behavior when '-r' is passed. In short, if you haven't yet created a key (Keytab: False) you should not use '-r' option.
If you have already generated the key (Keytab: True) and you want to retrieve it for other server (typically for clustered environment), you must use '-r' option, after setting up who is allowed to retrieve the keytab.
BTW, for NFS your service principal has to be nfs/..., not NFS/.... This is described in the man page for rpc.gssd, section "Machine credentials".
Well the Web UI seems to have made them with caps.
It does not. The code for Web UI has the following (editable) list of pre-filled values: .... name: 'service', label: '@i18n:objects.service.service', options: [ 'cifs', 'DNS', 'ftp', 'HTTP', 'imap', 'ldap', 'libvirt', 'nfs', 'smtp', 'qpidd' ], editable: true, ....
and in the code of Web UI I don't see the service value normalized either way.
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
On pe, 16 elo 2019, Boyd Ako via FreeIPA-users wrote:
Thanks. Is there any way to test the keytab?
Obtain ticket granting ticket (TGT) with a keytab:
KRB5_TRACE=/dev/stderr kinit -k -t /path/to/keytab.file name-of-principal
Obtain a service ticket after the above:
KRB5_TRACE=/dev/stderr kvno -S host ipa.master.hostname
If the first one works, then keytab is good. If the second one works, then KDC recognizes your TGT.
freeipa-users@lists.fedorahosted.org