preauth (I'm a Roomba in a 2'x2' room)

[Jeff Blaine]

I can't even get the included encrypted-challenge plugin
to work, and for the same reason, I cannot get my plugin
to work.

Can anyone provide me with instructions to just get the
included encrypted-challenge plugin to work? :(

Generating preauth hint list
.. type 2 is timestamp
.. .. ok
.. type 136 is FAST
.. .. no get_edata() to call
.. type 11 is etype-info
.. .. get_edata() failed
.. type 19 is etype-info2
.. .. ok
.. type 3 (pw-salt) has flag PA_PSEUDO - skipping
.. type 13 is sam-response
.. .. no get_edata() to call
.. type 12 is sam-challenge
.. .. get_edata() failed
.. type 128 (pac-request) has flag PA_PSEUDO - skipping
.. type 138 is Encrypted challenge
enc-challenge: return ENOENT from kdc_include_padata()
.. .. get_edata() failed
.. type 150 is MyPlugin
MyPlugin: return ENOENT from kdc_include_padata()
.. .. get_edata() failed

The plugin function's code (the get_edata func) is:

static krb5_error_code
kdc_include_padata(krb5_context context, krb5_kdc_req *request,
                   struct _krb5_db_entry_new *client,
                   struct _krb5_db_entry_new *server,
                   preauth_get_entry_data_proc get_entry_proc,
                   void *pa_module_context, krb5_pa_data *data)
{
    krb5_error_code retval = 0;
    krb5_keyblock *armor_key = NULL;
    retval = fast_kdc_get_armor_key(context, get_entry_proc,
                                    request, client, &armor_key);
    if (retval)
        return retval;
    if (armor_key == 0) {
        krb5_klog_syslog (LOG_INFO,
                          "enc-challenge: return ENOENT from
kdc_include_padata()");
        return ENOENT;
    }
    krb5_free_keyblock(context, armor_key);
    return 0;
}


On 4/28/2010 6:37 PM, Greg Hudson wrote:
> On Wed, 2010-04-28 at 17:54 -0400, Jeff Blaine wrote:
>>  > 3.2.  Initial Pre-authentication Required Error
> [...]
> 
>> So clearly this has been thought of.  Do we just say that
>> MIT Kerberos does not support this draft yet?  Or do we just
>> say that the statements above are purely hypothetical and
>> not part of the real draft's intended scope?
> 
> We don't make use of authentication sets, but they are not a required
> feature of the specification.