@fberat This is the issue we were talking about today.

@abbra Any thoughts here?

In general, I do not recommend to store users' long term keys in a keytab. This is wrong and insecure.

We disabled ability for users to request a direct ticket to another non-service account (e.g. themselves or another user) due to an ability to use this for offline Kerberoast attacks. The corresponding CVE was CVE-2024-3183. There is even a public proof of concept breaking code: https://github.com/Cyxow/CVE-2024-3183-POC

In general, obtaining a keytab for itself can be done through ipa-getkeytab tool but it requires direct access to LDAP and there is a catch: userPassword attribute in LDAP will not be updated with the new password. See https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org/thread/3B22FMDNN4KI2VTLMNGTWBFNFMCGMQVT/ for details.

On the other hand, if user is not really changing a password, the KVNO value will be bumped and Kerberos key will be updated using the same password, so should be OK.

# kinit admin
# ipa user-add testuser --random --first=Test --last=User
....
# kinit testuser
Password for testuser@MINIMAL.TEST: 
Password expired.  You must change it now.
Enter new password: 
Enter it again: 
# ipa-getkeytab -p testuser@MINIMAL.TEST -k testuser.keytab -P
New Principal Password: 
Verify Principal Password: 
Keytab successfully retrieved and stored in: testuser.keytab
# klist -kt testuser.keytab 
Keytab name: FILE:testuser.keytab
KVNO Timestamp           Principal
---- ------------------- ------------------------------------------------------
   3 11/20/2025 07:23:23 testuser@MINIMAL.TEST
   3 11/20/2025 07:23:23 testuser@MINIMAL.TEST
   3 11/20/2025 07:23:23 testuser@MINIMAL.TEST
   3 11/20/2025 07:23:23 testuser@MINIMAL.TEST

Again, as I said, this requires to have access to the LDAP server. An admin can also look up the KVNO value for the user as well by using kadmin.local getprinc name command:

# kadmin.local getprinc testuser|grep Key:
Key: vno 3, aes256-cts-hmac-sha384-192:special
Key: vno 3, aes128-cts-hmac-sha256-128:special
Key: vno 3, aes256-cts-hmac-sha1-96:special
Key: vno 3, aes128-cts-hmac-sha1-96:special
MKey: vno 1

If the recommendation is not to use a keytab then should https://docs.fedoraproject.org/en-US/infra/howtos/create_keytab/ be retired and removed?

No objections from my side if the answer is "You always have to type your password."

Just keep in mind that the actual solution will be that users write their passwords into shell scripts and we'll be overall less secure on the Fedora developer end-point side, but this is a social problem that you don't need to fix. Fedora as a whole needs to adopt some practice that works.

Generally speaking I used to use a password manager for this, but in Fedora 43 the switch to only Wayland without a portal meant keepassx stopped being able to auto-type my sequences after I unlocked.

Again, any high-level guidance would be great.

If the recommendation is not to use a keytab then should https://docs.fedoraproject.org/en-US/infra/howtos/create_keytab/ be retired and removed?

Probibly so yeah...

No objections from my side if the answer is "You always have to type your password."

Well, what are you trying to do? Is this for you personally to use some services? Or you are trying to setup something automated that uses your credentials? or ?

Well, what are you trying to do? Is this for you personally to use some services? Or you are trying to setup something automated that uses your credentials? or ?

I realize this is XY problem territory, I've asked about how to get a kvno value, when in truth the problem I have is finding a Fedora-approved way to reduce the friction of my kerberos login in Fedora 43.

I am looking for a Fedora-approved method of storing my credentials encrypted that I could then pass to kerberos in a low-friction manner.

This is for my personal use as a Fedora developer on my own development system (also running Fedora).

The article needs to be retired, I think I mentioned this multiple times during past years' Flock.

Regarding ease of use of credentials in Fedora, you should be using renewable credentials in SSSD. You don't need to have any domain configured, just use sssd-kcm to store creds in KCM. See man page for sssd-kcm(8) for details. All credentials stored in KCM will be tried for renewal within their lifetime.

When running kinit, make sure to specify a life time of your credential: "kinit -l7d username". Fedora KDC allows renewable credentials of 24 hours lifetime with a week-long time to renew them. It means you don't need to kinit as often and SSSD will handle the renewal process.

@abbra Thank you! Yes, retiring the article would be the best next step.

I can take the action to follow up on sssd-kcm to store creds and maybe wiki something and eventually get it into the "Using Fedora Accounts" (https://docs.fedoraproject.org/en-US/fedora-accounts/user/)

Docs pr to remove the current keytab doc: https://pagure.io/infra-docs-fpo/pull-request/439

@abbra What is the recommendation for "bot" users for services? We can't be expected to have a human present to type in a password whenever the service dies and gets automatically restarted. Even setting a month-long renewal time and making a human re-auth monthly would be painful.

@sgallagh depends on what specifically those bots do. In general, they should be IPA services (ipa service-add ...) instead of IPA users (ipa user-add ...)

If they need to login to POSIX environment, then those POSIX users can have ~/.k5login file defining the list of Kerberos services which are permitted to login as those users and sshd server performs lookup and authorization using this file for GSSAPI authentication.

When you have a keytab, you can simply login by setting KRB5_CLIENT_KTNAME=/path/to/keytab.file ssh ...., this will automatically acquire Kerberos ticket from the client keytab.

If you need the service account to authenticate to web applications, the account should not be different from IPA users in that purpose.

@abbra OK, it's possible I misread your earlier comments. It sounded like you were advocating for not using keytabs at all anymore. I'm asking if it's still acceptable to use them for service accounts.

In specific, I'm asking in relation to https://forge.fedoraproject.org/releng/tickets/issues/13132

Looks like that's the latter case and since you do not expect to ever use people's login directly, only in automation, using keytab is justified there.

There are few issues on IPA side for self-retrieval of the keytab for users. If you are using ipa-getkeytab as administrator, those would not apply and everything should work fine