Instead of trying to authenticate with the realm, when krb5_get_init_creds_password() sees an empty password, and no prompter has been set, then it doesn't try to preauth against the server, but immediately returns KRB5_PREAUTH_FAILED.

In general we expect to get back an error code like KRB5KDC_ERR_PREAUTH_FAILED if it preauth fails (bad password) on the KDC side.

Work around can be seen by adding a null prompter that does:

static krb5_error_code
null_prompter (krb5_context context,
               void *data,
               const char *name,
               const char *banner,
               int num_prompts,
               krb5_prompt prompts[])
{
	int i;

	for (i = 0; i < num_prompts; i++)
		prompts[i].reply->length = 0;

	return 0;
}

The problematic code in question is in krb5 in preauth2.c:

static krb5_error_code
get_as_key(krb5_context context, krb5_clpreauth_rock rock,
           krb5_keyblock **keyblock)
{
    krb5_init_creds_context ctx = (krb5_init_creds_context)rock;
    krb5_error_code ret;
    krb5_data *salt;

>>>> HERE <<<<
    if (ctx->as_key.length == 0) {
        salt = ctx->default_salt ? NULL : &ctx->salt;
        ret = ctx->gak_fct(context, ctx->request->client, ctx->etype,
                           ctx->prompter, ctx->prompter_data, salt,
                           &ctx->s2kparams, &ctx->as_key, ctx->gak_data,
                           ctx->rctx.items);
        if (ret)
            return ret;
    }
    *keyblock = &ctx->as_key;
    return 0;
}

Posted to krb5dev mailing list here: http://mailman.mit.edu/pipermail/krbdev/2013-May/011525.html

Workaround in adcli here: http://cgit.freedesktop.org/realmd/adcli/commit/?id=8fdaed506001a4205b969a290428a1251356ecf8

adcli-0.7-1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/adcli-0.7-1.fc19

Should there be a different bug for the krb5 libraries, or should this be reassigned to adcli?

realmd-0.14.0-1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/realmd-0.14.0-1.fc19

(In reply to comment #5)
> Should there be a different bug for the krb5 libraries, or should this be
> reassigned to adcli?

I had been tracking all the various work-arounds using this same bug, but if you prefer them to be split up then that's fine too.

Are workarounds all that's planned for addressing this?  I ask because it looks like the update system plans to close this bug when one of the attached updates is pushed, regardless of whether or not a proper fix lands in Fedora's krb5 package.

(In reply to comment #8)
> Are workarounds all that's planned for addressing this?  

I'm hoping to try to implement what Greg suggested on krbdev.

> I ask because it
> looks like the update system plans to close this bug when one of the
> attached updates is pushed, regardless of whether or not a proper fix lands
> in Fedora's krb5 package.

Oops, yeah it's hard to tell the update system which bugs to close and which ones not to when an update tracks multiple bugs. I guess we'll just reopen if it gets autoclosed. Is that okay? I will removed it as a blocker at that point though.

Package adcli-0.7-1.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing adcli-0.7-1.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-7599/adcli-0.7-1.fc19
then log in and leave karma (feedback).

Reopening to track the krb5 fix.

adcli-0.7-1.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

Patch posted on the krb5dev mailing list:

http://mailman.mit.edu/pipermail/krbdev/2013-May/011566.html

Patch committed upstream.

Nalin, do you think this is worth backporting and including in Fedora 19?

Not yet present in a krb5 release at this time.

I've worked around it in adcli and realmd, and this is a problem for applications using the krb5 API, rather than when using the kinit tool.

commit f3458ed803ae97b6c6c7c63baeb82b26c4943d4c
Author: Greg Hudson <ghudson>
Date:   Thu May 23 15:33:58 2013 -0400

    Make empty passwords work via init_creds APIs
    
    In the gak_data value used by krb5_get_as_key_password, separate the
    already-known password from the storage we might have allocated to put
    it in, so that we no longer use an empty data buffer to determine
    whether we know the password.  This allows empty passwords to work via
    the API.
    
    Remove the kadm5 test which explicitly uses an empty password.
    
    Based on a patch from Stef Walter.
    
    ticket: 7642

Just saw that you already included this patch in the krb5 package. Thanks!

https://admin.fedoraproject.org/updates/FEDORA-2013-9820/krb5-1.11.3-1.fc19

Verified with the test case attached posted to the krb5dev mailing list.

[stef@stef tmp]$ ./frob-krb5-preauth 
frob-krb5-preauth: krb5_get_init_creds_password: Preauthentication failed