Bug 960001 - krb5_get_init_creds_password() with empty password and no prompter: KRB5_PREAUTH_FAILED
Summary: krb5_get_init_creds_password() with empty password and no prompter: KRB5_PREA...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: krb5
Version: 19
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
Assignee: Nalin Dahyabhai
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 949853
TreeView+ depends on / blocked
 
Reported: 2013-05-06 12:01 UTC by David Spurek
Modified: 2015-03-02 05:27 UTC (History)
9 users (show)

Fixed In Version: krb5-1.11.3-1.fc19
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-06-12 16:51:26 UTC
Type: Bug


Attachments (Terms of Use)

Description David Spurek 2013-05-06 12:01:12 UTC
Description of problem:
Test case is similar as bz#959999, but output is different (see Additional info).

Join the domain, but instead of specifying the domain name, specify the server host name. This test case not works. 

More informations you can find here:
https://fedoraproject.org/wiki/QA:Testcase_realmd_join_server

Version-Release number of selected component (if applicable):
realmd-0.13.91-1.fc19

How reproducible:
always

Steps to Reproduce:
1.realm join --user=Administrator <server host name>
2.
3.
  
Actual results:
Fail

Expected results:
Pass

Additional info:

 host -t SRV _ldap._tcp.security.baseos.qe
_ldap._tcp.security.baseos.qe has SRV record 0 100 389 dc.security.baseos.qe.


realm join -v -U Amy dc.security.baseos.qe
 * Resolving: _ldap._tcp.dc._msdcs.dc.security.baseos.qe
 * Resolving: _ldap._tcp.dc.security.baseos.qe
 * Resolving: dc.security.baseos.qe
 * Sending MS-CLDAP ping to: 10.34.36.170
 * Performing LDAP DSE lookup on: 10.34.36.170
 * Successfully discovered: security.baseos.qe
Password for Amy: 
 * Required files: /usr/sbin/sss_cache, /usr/sbin/sssd, /usr/sbin/adcli
 * LANG=C /usr/sbin/adcli join --verbose --domain security.baseos.qe --domain-realm SECURITY.BASEOS.QE --domain-controller dc.security.baseos.qe --login-type user --login-user Amy --stdin-password
 * Using domain name: security.baseos.qe
 * Calculated computer account name from fqdn: CLIENT
 * Using domain realm: security.baseos.qe
 * Sending cldap pings to domain controller: dc.security.baseos.qe
 * Received NetLogon info from: DC.security.baseos.qe
 * Wrote out krb5.conf snippet to /var/cache/realmd/adcli-krb5-eMNnqZ/krb5.d/adcli-krb5-conf-1WQSXD
 ! Couldn't get kerberos ticket for: Amy@SECURITY.BASEOS.QE: Generic preauthentication failure
adcli: couldn't connect to security.baseos.qe domain: Couldn't get kerberos ticket for: Amy@SECURITY.BASEOS.QE: Generic preauthentication failure
 ! Failed to join the domain
realm: Couldn't join realm: Failed to join the domain

Comment 1 Stef Walter 2013-05-06 12:10:40 UTC
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;
}

Comment 2 Stef Walter 2013-05-06 12:11:33 UTC
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;
}

Comment 4 Fedora Update System 2013-05-06 19:08:20 UTC
adcli-0.7-1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/adcli-0.7-1.fc19

Comment 5 Nalin Dahyabhai 2013-05-06 19:56:30 UTC
Should there be a different bug for the krb5 libraries, or should this be reassigned to adcli?

Comment 6 Fedora Update System 2013-05-07 13:40:30 UTC
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

Comment 7 Stef Walter 2013-05-07 15:14:17 UTC
(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.

Comment 8 Nalin Dahyabhai 2013-05-07 15:51:33 UTC
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.

Comment 9 Stef Walter 2013-05-07 16:02:32 UTC
(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.

Comment 10 Fedora Update System 2013-05-07 20:45:31 UTC
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).

Comment 11 Stef Walter 2013-05-13 19:35:37 UTC
Reopening to track the krb5 fix.

Comment 12 Fedora Update System 2013-05-14 04:39:15 UTC
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.

Comment 13 Stef Walter 2013-05-22 11:53:29 UTC
Patch posted on the krb5dev mailing list:

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

Comment 14 Stef Walter 2013-06-12 15:49:33 UTC
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@mit.edu>
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

Comment 15 Stef Walter 2013-06-12 16:51:26 UTC
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

Comment 16 Stef Walter 2013-06-12 17:01:28 UTC
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


Note You need to log in before you can comment on or make changes to this bug.