krb auth weirdness found out

[Sam Liddicott]

I have the answer (which turns out to be another question) after
spending a couple of dreary days investigating why I get
dcerpc_bind_auth_send() from openchange (with specified creds) causing
errors like this:

kinit for Sam at GALAXY failed (Cannot contact any KDC for requested realm:
unable to reach any KDC in realm GALAXY)
Failed to get CCACHE for GSSAPI client: Cannot contact any KDC for
requested realm
Cannot reach a KDC we require to contact host at NOVA
Failed to start GENSEC client mech gssapi_krb5: NT_STATUS_INVALID_PARAMETER

(when GALAXY is a domain value not a REALM value which should be
galaxy.test.dbamsystems.local) and I have to wait for the time it takes
to fail this before it continues with the NTML auth (which is what it
should have been doing all along).

Strangely the reason is that the specified credentials had a domain
specified but not a realm, and although the default realm was picked up,
it was still true that (cred->domain_obtained > cred->realm_obtained)
which means that when kerberos_util.c/kinit_to_ccache calls
kerberos_util.c/principal_from_credentials which does:

    princ_string = cli_credentials_get_principal(credentials, mem_ctx);
the princ_string is of the form user at domain and not user at realm, e.g.
                     = "sam at GALAXY"

HOWEVER principal_from_credentials() then calls krb5_parse_name to put
GALAXY in princ->realm which is passed back to kinit_to_cache. I don't
think GALAXY should be in princ->realm as it isn't a realm value.
[remember (cred->domain_obtained > cred->realm_obtained)]

kinit_to_ccache then passes this princ instead of the credentials to
kerberos_kinit_password_cc
which calls krb5_get_init_creds_password to populate some krb5_creds
from princ, thus filling in
the krb5_creds realm with GALAXY (parsed from princ when GALAXY clearly
is not a realm!

[I hope you can follow all this, it took me hours!]

And this makes it to nested functions so that this is used as the realm
in init_cred_loop and krb5_sendto_kdc_flags which of course fail!

All this is the behaviour if the realm is not filled in on the original
credentials.

Bugs?
I think the first semantic "error" is in principal_from_credentials
which seems to presume that the value after @ will always be a realm value;

but also I think that kinit_to_ccache needs some code path to avoid
calling kerberos_kinit_password_cc if it doesn't have a realm. I'm not
sure if it matters that is because principal_from_credentials leaves
realm to NULL or because it detects that the realm has no dots in, or it
checks (cred->domain_obtained > cred->realm_obtained)

HOWEVER[2] despite all this, the auth mechanism then goes on to use the
username and password (who knows why it was using kerberos for specified
creds?) and makes a connection successfully. Hurrah!

HOWEVER[3] if I do fill in the realm value explicitly for specified
credentials I avoid the kerberos error entirely but openchange fails
further on (but doesn't fail if I leave in the wrong realm). I've been
getting the "ASN.1 unexpected field number" below since I added and
removed an extra windows DC.

GSS Update(krb5)(2) Update failed:  Miscellaneous failure (see text):
ASN.1 unexpected field number
SPNEGO(gssapi_krb5) login failed: NT_STATUS_LOGON_FAILURE
librpc/rpc/dcerpc_connect.c:700 continue_pipe_auth
Failed to bind to uuid f5cc5a18-4264-101a-8c59-08002b2f8426 -
NT_STATUS_LOGON_FAILURE

But this is a different bug I'll continue with.

Julien, please can you try editing ./mapiproxy/dcesrv_mapiproxy.c and
fill in the realm somewhat like this:

realm = lp_parm_string(dce_call->conn->dce_ctx->lp_ctx, NULL,
"dcerpc_mapiproxy", "realm");
..
if (realm) {
  cli_credentials_set_realm(credentials, realm, CRED_SPECIFIED);
}

and see if mapiproxy still works for you? And I'll try to get to the
bottom of the ASN.1 error.

Sam