using keytab with preauth and ldap alias canonicalization
checker at d6.com
Mon Oct 4 23:38:42 EDT 2021
This message is a bit of a ramble, apologies, I'm trying to figure out
If you do upgrade, the KDC doesn't need to be 1.17 or even be running
MIT krb5. The API just makes an unauthenticated AS-REQ and looks at the
method data in the PREAUTH_REQUIRED error
Okay, so I could actually port this new API to my older client lib if I
wanted, or do this query manually as well? Although I should probably
update it anyway.
Maybe it would be helpful if I outlined my various use cases...
The first time the player starts the game and wants to go online, what
happens depends on how they launched the game. Sometimes I get a
username/password, and then create a key from that and save it in the
keytab. Other times I get a keyblock from a server process that talks
to kadmind and I save that to a keytab. Then we fall through to the
If there is an existing keytab, I load the key from that, and then send
it to the KDC to get a TGT.
So, currently, all paths go through the existing key path eventually,
which is where I'm running into trouble.
I assume given a key created for checkersp, there is no way to change it
into a key for checker, so I'd need to reprompt or get a new keyblock
for the canonical name? Is there a way to validate that the checkersp
key is at least correct, or is that info not available because the KDC
only has the key with the canonical salt and stuff? I guess I haven't
tested the case of adding an alias that becomes the canonical princ. Is
the existing password key in the KDC invalid then...in other words,
assuming I just use LDAP to add another princ and set it canonical
without touching other LDAP fields, is the key data invalid at that
point because the salt is wrong? I'll have to handle that case I
think...will I have to force a password update on that account, assuming
again there's no way to rekey from one princ salt to another?
I'm also going to have to handle the case where the canonical alias is
created after a player already has a keytab saved, so I'm going to have
to deal with the error of the key login path failing regardless. Hmm.
------ Original Message ------
From: "Greg Hudson" <ghudson at mit.edu>
To: "Chris Hecker" <checker at d6.com>; "krbdev at mit.edu" <krbdev at mit.edu>
Sent: 2021-10-03 22:34:23
Subject: Re: using keytab with preauth and ldap alias canonicalization
>On 10/4/21 12:28 AM, Chris Hecker wrote:> Wait, so to be clear, at the
>time when I create the keytab I don't know
>> if the princ is canonical or not. So I need to use that new API on each
>> princ after the user enters it, and use that to create the keytab?
>> Is there a way to do this with the API before 1.17 or do I need to
>> update everything? Is this only on the client, or does the KDC need to
>> be 1.17 as well?
>If you have the username and password, you could obtain credentials with
>krb5_get_init_creds_password() (with the canonicalize flag set in the
>gic options) and look at the client principal. It would be a bit less
>efficient than what ktutil addent -f does in 1.17 and it won't handle
>all of the same edge cases such as non-default salts, but I think it
>should work for your purposes.
>If you do upgrade, the KDC doesn't need to be 1.17 or even be running
>MIT krb5. The API just makes an unauthenticated AS-REQ and looks at the
>method data in the PREAUTH_REQUIRED error.
More information about the krbdev