Hi,
Is it possible to retrieve an existing user keytab, without resetting the key? I see there is "ipa-getkeytab -r", but it doesn't seem to work for me, at least not for user principals:
$ kinit admin <password> $ ipa-getkeytab -p auto -r -k new.auto.keytab Failed to load translations Failed to parse result: Insufficient access rights Failed to get keytab
Should I add some permissions to the user "admin"...?
--- Regards, Dmitry Perets
On pe, 22 marras 2019, Dmitry Perets via FreeIPA-users wrote:
Hi,
Is it possible to retrieve an existing user keytab, without resetting the key? I see there is "ipa-getkeytab -r", but it doesn't seem to work for me, at least not for user principals:
$ kinit admin
<password> $ ipa-getkeytab -p auto -r -k new.auto.keytab Failed to load translations Failed to parse result: Insufficient access rights Failed to get keytab
Should I add some permissions to the user "admin"...?
It is not possible to use ipa-getkeytab for retrieving a key of a user in normal environment. There are few reasons for that.
First, ipa-getkeytab relies on access controls that define who can regenerate a key or retrieve one. These access controls need to be defined in the target LDAP object (user, in this case). For services and hosts we have these covered with special commands in IPA CLI:
ipa {host|service}-{allow|disallow}-{create|retrieve}-keytab
These commands create or remove appropriate attributes from the object in question. There is no such command for user object. Technically, one could certainly add the attributes to a user but this wasn't done in past.
If you know a password, you can generate keytab manually by using ktutil command:
ktutil> add_entry -password -p principal -k kvno -f
The key part here is '-f' which fetches a salt from KDC. Otherwise, you'd need to use '-s salt' option to specify a salt manually. Option '-f' appeared in MIT 1.18, '-s' in MIT Kerberos 1.17.
In past we didn't like the idea to add support for keytab retrieval/creation to user objects as it would violate the concept that only user itself knows own password and everyone else is tampering it, thus causing a password expiration immediately.
Interesting idea, but seems to require a time machine. The kerberos in centos 8 is 1.16. I believe Ubuntu 18 is also.
On Nov 22, 2019, at 1:21 PM, Alexander Bokovoy via FreeIPA-users <freeipa-users@lists.fedorahosted.orgmailto:freeipa-users@lists.fedorahosted.org> wrote:
ktutil> add_entry -password -p principal -k kvno -f
The key part here is '-f' which fetches a salt from KDC. Otherwise, you'd need to use '-s salt' option to specify a salt manually. Option '-f' appeared in MIT 1.18, '-s' in MIT Kerberos 1.17.
On pe, 22 marras 2019, Charles Hedrick via FreeIPA-users wrote:
Interesting idea, but seems to require a time machine. The kerberos in centos 8 is 1.16. I believe Ubuntu 18 is also.
Actually, I did check of the source code commits in upstream MIT Kerberos and I attributed it wrongly. '-f' is part of 1.17 release and '-s' is in 1.16 release. So, it should be in RHEL 8.
On Nov 22, 2019, at 1:21 PM, Alexander Bokovoy via FreeIPA-users <freeipa-users@lists.fedorahosted.orgmailto:freeipa-users@lists.fedorahosted.org> wrote:
ktutil> add_entry -password -p principal -k kvno -f
The key part here is '-f' which fetches a salt from KDC. Otherwise, you'd need to use '-s salt' option to specify a salt manually. Option '-f' appeared in MIT 1.18, '-s' in MIT Kerberos 1.17.
In centos 8, the man page for ktuil says 1.16.1. -f isn’t in the man page nor does it work. yum also shows the version of 1.16.1.
-s is there but not -f. When I tried it without -f the resulting key table didn’t work.
Ubuntu 20.4 will be out shortly. Hopefully Centos 8.x will include 17. But for the moment this isn’t a realistic solution.
On Nov 22, 2019, at 2:04 PM, Alexander Bokovoy <abokovoy@redhat.commailto:abokovoy@redhat.com> wrote:
Actually, I did check of the source code commits in upstream MIT Kerberos and I attributed it wrongly. '-f' is part of 1.17 release and '-s' is in 1.16 release. So, it should be in RHEL 8.
On pe, 22 marras 2019, Charles Hedrick via FreeIPA-users wrote:
In centos 8, the man page for ktuil says 1.16.1. -f isn’t in the man page nor does it work. yum also shows the version of 1.16.1.
-s is there but not -f. When I tried it without -f the resulting key table didn’t work.
Because you need to specify salt. To find it out without '-f', you need to use Kerberos tracing in kinit to see the salt. Below is a script I made some time ago that automates it but since salt and key can be anything, it might fail escaping characters too.
------------------------ #!/bin/bash if test $# -ne 1 ; then echo "$0 <username>" exit 1 fi
user=$1 read -sp "${user}'s pass:" pass echo salt=$(printf "%b" "$pass\n" | KRB5_TRACE=/dev/stdout kinit $user|grep salt|cut -d, -f2|head -1|cut -d" -f2-) KVNO=$(kvno "$user" | awk '{print $NF}') ETYPE=$(klist -ef | grep -A 1 krbtgt | tail -1 | awk '{print $NF}') printf "%b" "addent -password -p $user -k $KVNO -e $ETYPE -s "$salt\n$pass\nwrite_kt $user.keytab" | ktutil printf "%b" "read_kt $user.keytab\nlist\nquit\n" | ktutil kinit -k -t $user.keytab $user ------------------------
I think it was published in this mailing list already at least once.
Ubuntu 20.4 will be out shortly. Hopefully Centos 8.x will include 17. But for the moment this isn’t a realistic solution.
On Nov 22, 2019, at 2:04 PM, Alexander Bokovoy <abokovoy@redhat.commailto:abokovoy@redhat.com> wrote:
Actually, I did check of the source code commits in upstream MIT Kerberos and I attributed it wrongly. '-f' is part of 1.17 release and '-s' is in 1.16 release. So, it should be in RHEL 8.
Hi,
Can you please remind me from which IPA version you support service principals not bound to hosts? I think that would be then a better solution for my case, as I am really using this user for non-interactive workloads.
And in the meantime, what is the nicest solution for some service that has instances on multiple hosts? I could of course define separate service principals for each one of them (e.g.. MYSVC/hostname), but if - for example - they need to read secrets from the same shared Vault, I then must add all of them as its members. And there are 30 instances... That is why I thought to let them authenticate with the same principal.
Any solution for this in current version of IPA (4.6)?
--- Regards, Dmitry Perets
On Fri, 22 Nov 2019, 20:05 Alexander Bokovoy, abokovoy@redhat.com wrote:
On pe, 22 marras 2019, Charles Hedrick via FreeIPA-users wrote:
Interesting idea, but seems to require a time machine. The kerberos in centos 8 is 1.16. I believe Ubuntu 18 is also.
Actually, I did check of the source code commits in upstream MIT Kerberos and I attributed it wrongly. '-f' is part of 1.17 release and '-s' is in 1.16 release. So, it should be in RHEL 8.
On Nov 22, 2019, at 1:21 PM, Alexander Bokovoy via FreeIPA-users <freeipa-users@lists.fedorahosted.org<mailto:
freeipa-users@lists.fedorahosted.org>>
wrote:
ktutil> add_entry -password -p principal -k kvno -f
The key part here is '-f' which fetches a salt from KDC. Otherwise, you'd need to use '-s salt' option to specify a salt manually. Option '-f' appeared in MIT 1.18, '-s' in MIT Kerberos 1.17.
-- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland
service principals have never been bound to hosts. The hostname is just part of the principal name. It’s not enforced. Pick whatever hostname you want. (I actually think this is a bug.)
On Nov 22, 2019, at 2:14 PM, Dmitry Perets <dmitry.perets@gmail.commailto:dmitry.perets@gmail.com> wrote:
Hi,
Can you please remind me from which IPA version you support service principals not bound to hosts? I think that would be then a better solution for my case, as I am really using this user for non-interactive workloads.
And in the meantime, what is the nicest solution for some service that has instances on multiple hosts? I could of course define separate service principals for each one of them (e.g.. MYSVC/hostname), but if - for example - they need to read secrets from the same shared Vault, I then must add all of them as its members. And there are 30 instances... That is why I thought to let them authenticate with the same principal.
Any solution for this in current version of IPA (4.6)?
--- Regards, Dmitry Perets
On Fri, 22 Nov 2019, 20:05 Alexander Bokovoy, <abokovoy@redhat.commailto:abokovoy@redhat.com> wrote: On pe, 22 marras 2019, Charles Hedrick via FreeIPA-users wrote:
Interesting idea, but seems to require a time machine. The kerberos in centos 8 is 1.16. I believe Ubuntu 18 is also.
Actually, I did check of the source code commits in upstream MIT Kerberos and I attributed it wrongly. '-f' is part of 1.17 release and '-s' is in 1.16 release. So, it should be in RHEL 8.
On Nov 22, 2019, at 1:21 PM, Alexander Bokovoy via FreeIPA-users <freeipa-users@lists.fedorahosted.orgmailto:freeipa-users@lists.fedorahosted.org<mailto:freeipa-users@lists.fedorahosted.orgmailto:freeipa-users@lists.fedorahosted.org>> wrote:
ktutil> add_entry -password -p principal -k kvno -f
The key part here is '-f' which fetches a salt from KDC. Otherwise, you'd need to use '-s salt' option to specify a salt manually. Option '-f' appeared in MIT 1.18, '-s' in MIT Kerberos 1.17.
-- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland
On pe, 22 marras 2019, Charles Hedrick via FreeIPA-users wrote:
service principals have never been bound to hosts. The hostname is just part of the principal name. It’s not enforced. Pick whatever hostname you want. (I actually think this is a bug.)
No, this is not really what it is. Service principals are always bound to a host name but starting with FreeIPA 4.7.0 it is possible to create service principals that have no host object with the same host name.
So, before FreeIPA 4.7, you needed to do
ipa host-add foo.bar.z ipa service-add HTTP/foo.bar.z
Since FreeIPA 4.7.0 you can do
ipa service-add HTTP/foo.bar.z --skip-host-check
to create a service principal without managed host. It still would require foo.bar.z properly mappable to the IPA realm (see https://vda.li/en/posts/2019/03/24/Kerberos-host-to-realm-translation/) but that host doesn't need to exist in IPA.
On Nov 22, 2019, at 2:14 PM, Dmitry Perets <dmitry.perets@gmail.commailto:dmitry.perets@gmail.com> wrote:
Hi,
Can you please remind me from which IPA version you support service principals not bound to hosts? I think that would be then a better solution for my case, as I am really using this user for non-interactive workloads.
And in the meantime, what is the nicest solution for some service that has instances on multiple hosts? I could of course define separate service principals for each one of them (e.g.. MYSVC/hostname), but if - for example - they need to read secrets from the same shared Vault, I then must add all of them as its members. And there are 30 instances... That is why I thought to let them authenticate with the same principal.
Any solution for this in current version of IPA (4.6)?
Regards, Dmitry Perets
On Fri, 22 Nov 2019, 20:05 Alexander Bokovoy, <abokovoy@redhat.commailto:abokovoy@redhat.com> wrote: On pe, 22 marras 2019, Charles Hedrick via FreeIPA-users wrote:
Interesting idea, but seems to require a time machine. The kerberos in centos 8 is 1.16. I believe Ubuntu 18 is also.
Actually, I did check of the source code commits in upstream MIT Kerberos and I attributed it wrongly. '-f' is part of 1.17 release and '-s' is in 1.16 release. So, it should be in RHEL 8.
On Nov 22, 2019, at 1:21 PM, Alexander Bokovoy via FreeIPA-users <freeipa-users@lists.fedorahosted.orgmailto:freeipa-users@lists.fedorahosted.org<mailto:freeipa-users@lists.fedorahosted.orgmailto:freeipa-users@lists.fedorahosted.org>> wrote:
ktutil> add_entry -password -p principal -k kvno -f
The key part here is '-f' which fetches a salt from KDC. Otherwise, you'd need to use '-s salt' option to specify a salt manually. Option '-f' appeared in MIT 1.18, '-s' in MIT Kerberos 1.17.
-- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland
Bound in the sense that it has the hostname as part of the principal, not in the sense that there’s any actual connection with that host when you use it.
Dmitry Perets wants to use the same principal and key table on several hosts. They can simply create a principal for one of them. It and its key table can be used anywhere. We do it regularly. I would prefer this not to work, but it does.
On Nov 22, 2019, at 2:40 PM, Alexander Bokovoy <abokovoy@redhat.commailto:abokovoy@redhat.com> wrote:
No, this is not really what it is. Service principals are always bound to a host name but starting with FreeIPA 4.7.0 it is possible to create service principals that have no host object with the same host name.
On pe, 22 marras 2019, Charles Hedrick wrote:
Bound in the sense that it has the hostname as part of the principal, not in the sense that there’s any actual connection with that host when you use it.
Dmitry Perets wants to use the same principal and key table on several hosts. They can simply create a principal for one of them. It and its key table can be used anywhere. We do it regularly. I would prefer this not to work, but it does.
Correct. And it doesn't need any of the newer functionality too.
On Nov 22, 2019, at 2:40 PM, Alexander Bokovoy <abokovoy@redhat.commailto:abokovoy@redhat.com> wrote:
No, this is not really what it is. Service principals are always bound to a host name but starting with FreeIPA 4.7.0 it is possible to create service principals that have no host object with the same host name.
Oh ok, so I just need to create IPA host and let admin fetch its keytab on all real hosts running the service. Fair enough, thanks!
Btw in the meantime I discovered that it is possible to retrieve user's keytab with "ipa-getkeytab -r" if you authenticate as "cn=Directory Manager". Apparently, it has the rights to do this. But the only way then is by specifying its password in command line with "ipa-getkeytab -w" (it doesn't support prompting you securely, like kinit or ldapsearch do). So it is NOT a good idea to do so, unless you then clean up your history etc.... Better not :)
--- Regards, Dmitry Perets
On Fri, 22 Nov 2019, 21:01 Alexander Bokovoy, abokovoy@redhat.com wrote:
On pe, 22 marras 2019, Charles Hedrick wrote:
Bound in the sense that it has the hostname as part of the principal, not in the sense that there’s any actual connection with that host when you use it.
Dmitry Perets wants to use the same principal and key table on several hosts. They can simply create a principal for one of them. It and its key table can be used anywhere. We do it regularly. I would prefer this not to work, but it does.
Correct. And it doesn't need any of the newer functionality too.
On Nov 22, 2019, at 2:40 PM, Alexander Bokovoy <abokovoy@redhat.com
mailto:abokovoy@redhat.com> wrote:
No, this is not really what it is. Service principals are always bound to a host name but starting with FreeIPA 4.7.0 it is possible to create service principals that have no host object with the same host name.
-- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland
You can always fetch key tables using kadmin.local on one of the kdc’s.
I haven't actually tried using ipa-getkeytab on the wrong host. I just copied the key table. I doubt ipa-getkeytab checks that the hostname matches, but it’s always possible.
On Nov 22, 2019, at 3:48 PM, Dmitry Perets <dmitry.perets@gmail.commailto:dmitry.perets@gmail.com> wrote:
Oh ok, so I just need to create IPA host and let admin fetch its keytab on all real hosts running the service. Fair enough, thanks!
Btw in the meantime I discovered that it is possible to retrieve user's keytab with "ipa-getkeytab -r" if you authenticate as "cn=Directory Manager". Apparently, it has the rights to do this. But the only way then is by specifying its password in command line with "ipa-getkeytab -w" (it doesn't support prompting you securely, like kinit or ldapsearch do). So it is NOT a good idea to do so, unless you then clean up your history etc.... Better not :)
--- Regards, Dmitry Perets
On Fri, 22 Nov 2019, 21:01 Alexander Bokovoy, <abokovoy@redhat.commailto:abokovoy@redhat.com> wrote: On pe, 22 marras 2019, Charles Hedrick wrote:
Bound in the sense that it has the hostname as part of the principal, not in the sense that there’s any actual connection with that host when you use it.
Dmitry Perets wants to use the same principal and key table on several hosts. They can simply create a principal for one of them. It and its key table can be used anywhere. We do it regularly. I would prefer this not to work, but it does.
Correct. And it doesn't need any of the newer functionality too.
On Nov 22, 2019, at 2:40 PM, Alexander Bokovoy <abokovoy@redhat.commailto:abokovoy@redhat.com<mailto:abokovoy@redhat.commailto:abokovoy@redhat.com>> wrote:
No, this is not really what it is. Service principals are always bound to a host name but starting with FreeIPA 4.7.0 it is possible to create service principals that have no host object with the same host name.
-- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland
Here’s an approach that will work if you’re on the kdc. Become root. Run kadmin.local.
ktadd -k XXX.kt -norandkey XXX
-rorandley is the equivalent of -r
That creates a key table XXX.kt (or adds to if it already exists). No password needed except what you normally do to become root.
On Nov 22, 2019, at 3:48 PM, Dmitry Perets <dmitry.perets@gmail.commailto:dmitry.perets@gmail.com> wrote:
Oh ok, so I just need to create IPA host and let admin fetch its keytab on all real hosts running the service. Fair enough, thanks!
Btw in the meantime I discovered that it is possible to retrieve user's keytab with "ipa-getkeytab -r" if you authenticate as "cn=Directory Manager". Apparently, it has the rights to do this. But the only way then is by specifying its password in command line with "ipa-getkeytab -w" (it doesn't support prompting you securely, like kinit or ldapsearch do). So it is NOT a good idea to do so, unless you then clean up your history etc.... Better not :)
Incidentally, I’m not entirely sure we want this to work. We’re concerned about what happens if a system is compromised. That’s a concern because many of our systems are run by grad students. With root you could get a copy of someone else’s key table. At that point you could use it on any machine in the system, and the real user would probably never know.
We use a daemon that allows a user to register that they want to be able to do cron jobs (could be used for other things) on that system. The client can fetch a credential, which is locked to the IP address and not forward able. (The primary intent is to use it with NFS. It doesn’t need forward able credentials.)
On Nov 22, 2019, at 2:04 PM, Alexander Bokovoy abokovoy@redhat.com wrote:
On pe, 22 marras 2019, Charles Hedrick via FreeIPA-users wrote:
Interesting idea, but seems to require a time machine. The kerberos in centos 8 is 1.16. I believe Ubuntu 18 is also.
Actually, I did check of the source code commits in upstream MIT Kerberos and I attributed it wrongly. '-f' is part of 1.17 release and '-s' is in 1.16 release. So, it should be in RHEL 8.
On Nov 22, 2019, at 1:21 PM, Alexander Bokovoy via FreeIPA-users <freeipa-users@lists.fedorahosted.orgmailto:freeipa-users@lists.fedorahosted.org> wrote:
ktutil> add_entry -password -p principal -k kvno -f
The key part here is '-f' which fetches a salt from KDC. Otherwise, you'd need to use '-s salt' option to specify a salt manually. Option '-f' appeared in MIT 1.18, '-s' in MIT Kerberos 1.17.
-- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland
freeipa-users@lists.fedorahosted.org
-
Alexander Bokovoy -
Charles Hedrick -
Dmitry Perets