Hi,
today I found out that some entries in a keytab file seemed to have expired:
Request ticket server HTTP/mwc.linux.mydomain.at@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.
Regards, Ronald
On to, 14 syys 2017, Ronald Wimmer via FreeIPA-users wrote:
Hi,
today I found out that some entries in a keytab file seemed to have expired:
Request ticket server HTTP/mwc.linux.mydomain.at@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 different changes since that original key issuance time already.
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 HTTP/compoundservice.linux.mydomain.at@LINUX.MYDOMAIN.AT
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.
Regards, Ronald
On 2017-09-14 11:46, Alexander Bokovoy wrote:
On to, 14 syys 2017, Ronald Wimmer via FreeIPA-users wrote:
Hi,
today I found out that some entries in a keytab file seemed to have expired:
Request ticket server HTTP/mwc.linux.mydomain.at@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 different changes since that original key issuance time already.
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 HTTP/compoundservice.linux.mydomain.at@LINUX.MYDOMAIN.AT
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. https://www.freeipa.org/page/V4/Keytab_Retrieval_Management describes this feature.
Regards, Ronald
On 2017-09-14 11:46, Alexander Bokovoy wrote:
On to, 14 syys 2017, Ronald Wimmer via FreeIPA-users wrote:
Hi,
today I found out that some entries in a keytab file seemed to have expired:
Request ticket server HTTP/mwc.linux.mydomain.at@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 different changes since that original key issuance time already.
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 HTTP/compoundservice.linux.mydomain.at@LINUX.MYDOMAIN.AT
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. https://www.freeipa.org/page/V4/Keytab_Retrieval_Management describes this feature.
Thanks a lot for this vital information!
Regards, Ronald
Adding "-r" leads to this error message:
ipa-getkeytab -r -k /etc/httpd.keytab -p HTTP/mwoc.linux.mydomain.at@LINUX.MYDOMAIN.AT 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".
ipa --version VERSION: 4.5.0, API_VERSION: 2.228
What am I missing here?
Regards, Ronald
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 HTTP/compoundservice.linux.mydomain.at@LINUX.MYDOMAIN.AT
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. https://www.freeipa.org/page/V4/Keytab_Retrieval_Management describes this feature.
Regards, Ronald
On 2017-09-14 11:46, Alexander Bokovoy wrote:
On to, 14 syys 2017, Ronald Wimmer via FreeIPA-users wrote:
Hi,
today I found out that some entries in a keytab file seemed to have expired:
Request ticket server HTTP/mwc.linux.mydomain.at@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 different changes since that original key issuance time already.
On ti, 19 syys 2017, Ronald Wimmer wrote:
Adding "-r" leads to this error message:
ipa-getkeytab -r -k /etc/httpd.keytab -p HTTP/mwoc.linux.mydomain.at@LINUX.MYDOMAIN.AT 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".
ipa --version VERSION: 4.5.0, API_VERSION: 2.228
What am I missing here?
Documentation!
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/htm...
Please spend some time reading the documentation. It is vast and has a lot of answers to questions people keep asking on these lists.
Regards, Ronald
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 HTTP/compoundservice.linux.mydomain.at@LINUX.MYDOMAIN.AT
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. https://www.freeipa.org/page/V4/Keytab_Retrieval_Management describes this feature.
Regards, Ronald
On 2017-09-14 11:46, Alexander Bokovoy wrote:
On to, 14 syys 2017, Ronald Wimmer via FreeIPA-users wrote:
Hi,
today I found out that some entries in a keytab file seemed to have expired:
Request ticket server HTTP/mwc.linux.mydomain.at@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 different changes since that original key issuance time already.
On 2017-09-19 11:53, Alexander Bokovoy wrote:
[...] Please spend some time reading the documentation. It is vast and has a lot of answers to questions people keep asking on these lists.
I've already spent some time reading the documentation. Since "ipa-getkeytab" worked I was not aware of the fact that "ipa-getkeytab -r" would need:
ipa service-allow-retrieve-keytab HTTP/cluster.idm.example.com --hosts={node01.idm.example.com,node02.idm.example.com}
On ti, 19 syys 2017, Ronald Wimmer wrote:
On 2017-09-19 11:53, Alexander Bokovoy wrote:
[...] Please spend some time reading the documentation. It is vast and has a lot of answers to questions people keep asking on these lists.
I've already spent some time reading the documentation. Since "ipa-getkeytab" worked I was not aware of the fact that "ipa-getkeytab -r" would need:
ipa service-allow-retrieve-keytab HTTP/cluster.idm.example.com --hosts={node01.idm.example.com,node02.idm.example.com}
That's why I gave you these links as you have obviously didn't read them.
Glad that it works now.
On 19.09.17 12:07, Alexander Bokovoy wrote:
On ti, 19 syys 2017, Ronald Wimmer wrote:
On 2017-09-19 11:53, Alexander Bokovoy wrote:
[...] Please spend some time reading the documentation. It is vast and has a lot of answers to questions people keep asking on these lists.
I've already spent some time reading the documentation. Since "ipa-getkeytab" worked I was not aware of the fact that "ipa-getkeytab -r" would need:
ipa service-allow-retrieve-keytab HTTP/cluster.idm.example.com --hosts={node01.idm.example.com,node02.idm.example.com}
That's why I gave you these links as you have obviously didn't read them.
Glad that it works now.
As we ran into this problem again it should be mentioned that restarting gssproxy.service can be necessary.
In our case Apache was looking for a KVNO 1 whereas the actual file did already have version number 4.
Cheers, Ronald
On Wed, 2023-06-07 at 10:36 +0200, Ronald Wimmer via FreeIPA-users wrote:
On 19.09.17 12:07, Alexander Bokovoy wrote:
On ti, 19 syys 2017, Ronald Wimmer wrote:
On 2017-09-19 11:53, Alexander Bokovoy wrote:
[...] Please spend some time reading the documentation. It is vast and has a lot of answers to questions people keep asking on these lists.
I've already spent some time reading the documentation. Since "ipa-getkeytab" worked I was not aware of the fact that "ipa-getkeytab -r" would need:
ipa service-allow-retrieve-keytab HTTP/cluster.idm.example.com --hosts={node01.idm.example.com,node02.idm.example.com}
That's why I gave you these links as you have obviously didn't read them.
Glad that it works now.
As we ran into this problem again it should be mentioned that restarting gssproxy.service can be necessary.
In our case Apache was looking for a KVNO 1 whereas the actual file did already have version number 4.
FWIW, gssapi should pick up new keys in keytabs without the need to restart.
Simo.
On 07.06.23 14:25, Simo Sorce via FreeIPA-users wrote:
On Wed, 2023-06-07 at 10:36 +0200, Ronald Wimmer via FreeIPA-users wrote:
On 19.09.17 12:07, Alexander Bokovoy wrote:
On ti, 19 syys 2017, Ronald Wimmer wrote:
On 2017-09-19 11:53, Alexander Bokovoy wrote:
[...] Please spend some time reading the documentation. It is vast and has a lot of answers to questions people keep asking on these lists.
I've already spent some time reading the documentation. Since "ipa-getkeytab" worked I was not aware of the fact that "ipa-getkeytab -r" would need:
ipa service-allow-retrieve-keytab HTTP/cluster.idm.example.com --hosts={node01.idm.example.com,node02.idm.example.com}
That's why I gave you these links as you have obviously didn't read them.
Glad that it works now.
As we ran into this problem again it should be mentioned that restarting gssproxy.service can be necessary.
In our case Apache was looking for a KVNO 1 whereas the actual file did already have version number 4.
FWIW, gssapi should pick up new keys in keytabs without the need to restart.
I had to fetch a new keytab for this particular host as the host was accidentally deleted in IPA. (would the old keytab file on the server still have worked after re-adding the host in IPA?)
Ronald Wimmer via FreeIPA-users wrote:
On 07.06.23 14:25, Simo Sorce via FreeIPA-users wrote:
On Wed, 2023-06-07 at 10:36 +0200, Ronald Wimmer via FreeIPA-users wrote:
On 19.09.17 12:07, Alexander Bokovoy wrote:
On ti, 19 syys 2017, Ronald Wimmer wrote:
On 2017-09-19 11:53, Alexander Bokovoy wrote:
[...] Please spend some time reading the documentation. It is vast and has a lot of answers to questions people keep asking on these lists.
I've already spent some time reading the documentation. Since "ipa-getkeytab" worked I was not aware of the fact that "ipa-getkeytab -r" would need:
ipa service-allow-retrieve-keytab HTTP/cluster.idm.example.com --hosts={node01.idm.example.com,node02.idm.example.com}
That's why I gave you these links as you have obviously didn't read them.
Glad that it works now.
As we ran into this problem again it should be mentioned that restarting gssproxy.service can be necessary.
In our case Apache was looking for a KVNO 1 whereas the actual file did already have version number 4.
FWIW, gssapi should pick up new keys in keytabs without the need to restart.
I had to fetch a new keytab for this particular host as the host was accidentally deleted in IPA. (would the old keytab file on the server still have worked after re-adding the host in IPA?)
The old keytab would not work. A keytab contains a secret. That is used to authenticate. If the value doesn't exist on the server, auth fails.
rob
On Wed, 2023-06-07 at 14:35 +0200, Ronald Wimmer via FreeIPA-users wrote:
On 07.06.23 14:25, Simo Sorce via FreeIPA-users wrote:
On Wed, 2023-06-07 at 10:36 +0200, Ronald Wimmer via FreeIPA-users wrote:
On 19.09.17 12:07, Alexander Bokovoy wrote:
On ti, 19 syys 2017, Ronald Wimmer wrote:
On 2017-09-19 11:53, Alexander Bokovoy wrote:
[...] Please spend some time reading the documentation. It is vast and has a lot of answers to questions people keep asking on these lists.
I've already spent some time reading the documentation. Since "ipa-getkeytab" worked I was not aware of the fact that "ipa-getkeytab -r" would need:
ipa service-allow-retrieve-keytab HTTP/cluster.idm.example.com --hosts={node01.idm.example.com,node02.idm.example.com}
That's why I gave you these links as you have obviously didn't read them.
Glad that it works now.
As we ran into this problem again it should be mentioned that restarting gssproxy.service can be necessary.
In our case Apache was looking for a KVNO 1 whereas the actual file did already have version number 4.
FWIW, gssapi should pick up new keys in keytabs without the need to restart.
I had to fetch a new keytab for this particular host as the host was accidentally deleted in IPA. (would the old keytab file on the server still have worked after re-adding the host in IPA?)
Not really. However for a server, if you re-key the principal you SHOULD preserve the old key in the keytab and just add the new key in, not replace the keytab.
Because any client that already has obtained a ticket for the server will not go and refresh it until it expires. So if you just replace the keytab you will have a communication breakout with exisitng clients that can last hours (unless they delete and re-init their credential cache).
The old key can be remove after all tickets are expired, the expiration time used for TGT is a good measure to know for how long you should keep the old key in (could be anythign from hours to days).
Simo.
freeipa-users@lists.fedorahosted.org
-
Alexander Bokovoy -
Rob Crittenden -
Ronald Wimmer -
Simo Sorce