Re[2]: using keytab with preauth and ldap alias canonicalization

This message is a bit of a ramble, apologies, I'm trying to figure out 
my options...

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 
next case...

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.

Chris




------ Original Message ------
From: "Greg Hudson" <[email protected]>
To: "Chris Hecker" <[email protected]>; "[email protected]" <[email protected]>
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.
_______________________________________________
krbdev mailing list             [email protected]
https://mailman.mit.edu/mailman/listinfo/krbdev