gssntlm_acquire_cred_from fails with ENOENT for external credentials if NTLM_USER_FILE is unset

[kvv81]

Using the latest code from github, I'm runing gss-server + gss-client utilities with gssntlmssp plugin installed.
My computer is joined to AD (has 'host' service keys in krb5.keytab file), it has winbind running and I use AD (external) credentials to run the simple test:

$ gss-server host

$ gss-client -mech '{1.3.6.1.4.1.311.2.2.10}' -user 'AD_DOMAIN\test_user' -pass 'password' localhost host HELLO

I'm getting this unexpected error from server-side:

starting...
GSS-API error accepting context: Unspecified GSS failure.  Minor code may provide more information
GSS-API error accepting context: No such file or directory

After debugging I found the root-cause:
[1600941819] ERROR: gssntlm_acquire_cred_from() @ src/gss_creds.c:445 [851968:2]

#0  gssntlm_acquire_cred_from (minor_status=minor_status@entry=0x7fffffffd9ec, desired_name=0x555555762e60, time_req=time_req@entry=4294967295, desired_mechs=desired_mechs@entry=0x0, 
    cred_usage=cred_usage@entry=1, cred_store=0x0, output_cred_handle=output_cred_handle@entry=0x7fffffffda38, actual_mechs=actual_mechs@entry=0x0, time_rec=time_rec@entry=0x0)
    at src/gss_creds.c:397
#1  0x00007ffff5bc383c in gssntlm_accept_sec_context (minor_status=0x7fffffffe11c, context_handle=0x55555575a090, acceptor_cred_handle=<optimized out>, input_token=<optimized out>, 
    input_chan_bindings=0x0, src_name=0x7fffffffe008, mech_type=0x7fffffffe018, output_token=0x7fffffffe170, ret_flags=0x7fffffffdff4, time_rec=0x0, delegated_cred_handle=0x0)
    at src/gss_sec_ctx.c:890
#2  0x00007ffff7b9d6d6 in gss_accept_sec_context () from /lib64/libgssapi_krb5.so.2

The bug is inside gssntlm_acquire_cred_from() function in this section of code:

    if (cred_usage == GSS_C_INITIATE) {
        if (name != NULL && name->type != GSSNTLM_NAME_USER) {
            set_GSSERRS(ERR_NOUSRNAME, GSS_S_BAD_NAMETYPE);
            goto done;
        }

        if (cred_store != GSS_C_NO_CRED_STORE) {
            retmin = get_creds_from_store(name, cred, cred_store);
        } else {
            char *filename;

            filename = get_user_file_envvar();
            if (!filename) {
                set_GSSERRS(ENOENT, GSS_S_CRED_UNAVAIL);
                goto done;
            }
            retmin = get_user_file_creds(filename, name, cred);
            if (retmin) {
                retmin = external_get_creds(name, cred);
            }

            free(filename);
        }

The problem is that external_get_creds() is even NOT TRIED if get_user_file_envvar() returned NULL and ENOENT is returned immediately without winbind calls.
I.e. if local users file environment variable NTLM_USER_FILE is not set then external credentials are skipped.
Expected behaviour is to use external users regardless of NTLM_USER_FILE variable (it should be optional).

I think that this bug have been done recently into this commit:

Date:   Mon Jul 20 15:45:45 2020 -0400

    Add ability to pass keyfile via cred store

[simo5]

I added a patch to the PR to fix the name crash, given you cannot fully test that work without fixing #42 as well.

[kvv81]

Yes, this time everything is Ok.
I tested basic NTLM flow with gssntlmssp+winbind and everything is good now (no crashes, no errors, authentications works from server-side).
Simpe utility run:

$ ltrace gss-server host
...
gss_accept_sec_context(0x7ffcbf1a5b3c, 0x7ffcbf1a5b58, 0x556e1a216b30, 0x7ffcbf1a5ba0) = 1
gss_accept_sec_context(0x7ffcbf1a5b3c, 0x7ffcbf1a5b58, 0x556e1a216b30, 0x7ffcbf1a5ba0) = 0

Run NTLM auth in VAST SMB server:

2020-09-25 08:11:10.899224472 (P09784:E002:S253:F00265b) {SMB-:HI-:INF} [smb2_kerberos_api.cpp:299:accept_security_context]: Accepted GSS security context: input token length=74, output token length=262, validity_time=4294967295 secs, ret_flags=0x0, is_auth_completed=0
2020-09-25 08:11:10.957464820 (P09784:E002:S252:F00265c) {SMB-:HI-:INF} [smb2_kerberos_api.cpp:299:accept_security_context]: Accepted GSS security context: input token length=547, output token length=29, validity_time=4294967295 secs, ret_flags=0x20, is_auth_completed=1
2020-09-25 08:11:10.957703017 (P09784:E002:S255:F00265d) {SMB-:LOW:DBG} [smb2_kerberos_api.cpp:453:get_access_token]: NTLM mech detected, getting SIDs via gssntlmssp...
2020-09-25 08:11:10.957707817 (P09784:E002:S255:F00265d) {SMB-:HI-:INF} [smb2_kerberos_api.cpp:571:get_sids_from_ntlm_name]: Got 139 bytes of 'urn:gssntlmssp:sids' attribute of security context
2020-09-25 08:11:10.957708617 (P09784:E002:S255:F00265d) {SMB-:HI-:INF} [smb2_kerberos_api.cpp:572:get_sids_from_ntlm_name]: urn:gssntlmssp:sids=S-1-5-21-2754487483-1525494564-1268692904-2626,S-1-5-21-2754487483-1525494564-1268692904-513,S-1-5-21-2754487483-1525494564-1268692904-513
2020-09-25 08:11:10.957716117 (P09784:E002:S255:F00265d) {SMB-:LOW:DBG} [smb2_kerberos_api.cpp:542:get_sids_from_buffer]: UserSID = S-1-5-21-2754487483-1525494564-1268692904-2626
2020-09-25 08:11:10.957717717 (P09784:E002:S255:F00265d) {SMB-:LOW:DBG} [smb2_kerberos_api.cpp:546:get_sids_from_buffer]: grp[0] = S-1-5-21-2754487483-1525494564-1268692904-513

Thank you very much for fast fix, your help is REALLY appreciated!
Looking for those commits in 'main' branch...