On ti, 19 syys 2017, Ronald Wimmer wrote:
Adding "-r" leads to this error message:
ipa-getkeytab -r -k /etc/httpd.keytab -p
Failed to parse result: Insufficient access rights
Failed to get keytab
The ipa user is admin which should have all permissions and the OS
user on the server where the command was issued is "root".
VERSION: 4.5.0, API_VERSION: 2.228
What am I missing here?
Please spend some time reading the documentation. It is vast and has a
lot of answers to questions people keep asking on these lists.
On 2017-09-19 11:24, Alexander Bokovoy wrote:
>On ti, 19 syys 2017, Ronald Wimmer wrote:
>>Why does fetching a keytab influence its version number?
>>If i have three servers in a load balancer service compound and do a
>>ipa-getkeytab -k /etc/httpd.keytab -p
>>on each of the servers the kvno will be increased with every fetch
>>command leading to invalidating the keytab on the first two
>>servers if I issue the command on the third?
>>I would really appreciate some clarification here.
>ipa-getkeytab by design resets the key. It is documented elsewhere, in
>the man page for ipa-getkeytab and also in IPA documentation.
>If you are on newer IPA version (4.1 or later), its ipa-getkeytab has
>option '-r' that allows to retrieve existing key if you have enough
>privileges for that.
>>On 2017-09-14 11:46, Alexander Bokovoy wrote:
>>>On to, 14 syys 2017, Ronald Wimmer via FreeIPA-users wrote:
>>>>today I found out that some entries in a keytab file seemed to
>>>>Request ticket server
>>>>HTTP/mwc.linux.mydomain.at(a)LINUX.MYDOMAIN.AT kvno 4 not found
>>>>in keytab; keytab is likely out of date
>>>>Fetching the keytab again with ipa-getkeytab fixed the
>>>>problem. But why is this happening? Do keytab entries expire?
>>>>I have not set any custom password or ticket policies.
>>>You did most likely change the key on the KDC side by running
>>>ipa-getkeytab at some other place. This is what kvno 4 tells you about
>>>-- it is key version number. 4 means there were at least three
>>>changes since that original key issuance time already.
/ Alexander Bokovoy