Using a master key and principal name to derive password for principal

Alexander Bokovoy abokovoy at
Wed Oct 16 06:49:00 EDT 2019

On ke, 16 loka 2019, Ts7 Coe wrote:
>> Then you don't actually need keys at all. If no one is going to make
>> an AS_REQ or TGS_REQ with the principal as a target, then you do not
>> need keys.
>The principals will authenticate with each other, so any principal could
>be a target of TGS_REQ. So I thinks there still must be keys for every

Yes, for server principals. Are you planning to use PKINIT-enabled users
to authenticate to each other? Typically, PKINIT is used for non-target

>> Try to not set entry.key_data and entry.n_key_data (where entry is
>> krb5_db_entry structure) fields. We do this in FreeIPA for principals
>> that have no key associated and it works for PKINIT. It works just
>> fine.
>I thinks this operation is identical with purgekeys command? Then it could
>also make the principal unable to be a server role.

In our cases users aren't server principals. The operation is not really a
'purgekeys' -- we simply set no Kerberos keys when creating users. So you'd
have something like

$ kinit admin
$ ipa user-add some-user
$ openssl req -new -newkey rsa:2048 -days 365 -nodes -keyout private.key -out cert.csr -subj '/CN=some-user'
$ ipa cert-request cert.csr --principal=some-user --profile-id=caIPAuserCert
$ ipa user-show some-user --out=cert.out

and then you can auth as that user

$ kinit -X X509_user_identity=FILE:./cert.out,private.key some-user
$ klist
Ticket cache: KEYRING:persistent:0:krb_ccache_hTd5xt5
Default principal: some-user at EXAMPLE.TEST

Valid starting     Expires            Service principal
10/16/19 12:09:13  10/17/19 12:09:12  krbtgt/EXAMPLE.TEST at EXAMPLE.TEST

User principal has no password or Kerberos keys on the account:

$ ipa user-show some-user | egrep '(Password|Kerberos)'
  Password: False
  Kerberos keys available: False

Practically, this will not work with server principals, of course.

/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland

More information about the krbdev mailing list