Bug 960001 - krb5_get_init_creds_password() with empty password and no prompter: KRB5_PREAUTH_FAILED
krb5_get_init_creds_password() with empty password and no prompter: KRB5_PREA...
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: krb5 (Show other bugs)
19
Unspecified Unspecified
unspecified Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks: 949853
  Show dependency treegraph
 
Reported: 2013-05-06 08:01 EDT by David Spurek
Modified: 2015-03-02 00:27 EST (History)
9 users (show)

See Also:
Fixed In Version: krb5-1.11.3-1.fc19
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-06-12 12:51:26 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description David Spurek 2013-05-06 08:01:12 EDT
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 08:10:40 EDT
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 08:11:33 EDT
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 15:08:20 EDT
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 15:56:30 EDT
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 09:40:30 EDT
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 11:14:17 EDT
(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 11:51:33 EDT
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 12:02:32 EDT
(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 16:45:31 EDT
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 15:35:37 EDT
Reopening to track the krb5 fix.
Comment 12 Fedora Update System 2013-05-14 00:39:15 EDT
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 07:53:29 EDT
Patch posted on the krb5dev mailing list:

http://mailman.mit.edu/pipermail/krbdev/2013-May/011566.html
Comment 14 Stef Walter 2013-06-12 11:49:33 EDT
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 12:51:26 EDT
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 13:01:28 EDT
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.