gss_accept_sec_context fails on 2nd call unless user credentials are cached in winbind cache

[kvv81]

I'm troubleshooting gssntlmssp issue: new user cannot authenticate because his credentials are not known for winbind cache.
According to the source code, gssntlm_accept_sec_context -> gssntlm_acquire_cred -> gssntlm_acquire_cred_from -> external_get_creds -> winbind_get_creds -> wbcCredentialCache is probably the relevant trace for this problem and winbind reports "could not find credentials for user" error for this. The issue is avoided only when the user credentials are already in winbind cache (can be done by 'wbinfo -K'), but this is not the general case.
Please advise if I do something wrong and some initial preparation is needed (but should be the same for all users in directory, not per-user action).

My linux 'cntos-volodymyr' machine is joined to domain and it is capable to do proper kerberos authentication (keytab file has records of host service for machine account), winbind is running and 'ntlm_auth' utility from samba works perfectly. To easily reproduce the issue with gssntlmssp, I run gss client/server utilities provided by MIT Kerberos library.

Client-side call:
$ gss-client -mech '{1.3.6.1.4.1.311.2.2.10}' -user volodymyr -pass 'password' cntos-volodymyr host HELLO_MSG

Server-side call (with gss troubleshooting):
$ ltrace gss-server host 2>&1 | grep gss
gss_accept_sec_context(0x7ffd373b2abc, 0x7ffd373b2ad8, 0x55dec98a7ea0, 0x7ffd373b2b20) = 1
gss_release_buffer(0x7ffd373b2ab8, 0x7ffd373b2b10, 184, 0) = 0
gss_accept_sec_context(0x7ffd373b2abc, 0x7ffd373b2ad8, 0x55dec98a7ea0, 0x7ffd373b2b20) = 0xd0000
gss_display_status(0x7ffd373b2998, 0xd0000, 1, 0) = 0
gss_release_buffer(0x7ffd373b2998, 0x7ffd373b29a0, 0x7f8fa9efca00, 0x7fffff9d) = 0
gss_display_status(0x7ffd373b29c8, 0x4e540016, 2, 0) = 0
gss_release_buffer(0x7ffd373b29c8, 0x7ffd373b29d0, 0x7f8fa9efca00, 0x7fffffc9) = 0

Winbind log:
process_request_written: [53057:unknown request]: delivered response to client
process_request_send: process_request: request fn NTLMAUTH
[53057]: perform NTLM auth on behalf of user VAST-SMB-DEV\volodymyr
winbindd_dual_ccache_ntlm_auth: could not find credentials for user VAST-SMB-DEV\volodymyr
process_request_written: [53057:unknown request]: delivered response to client

[simo5]

This looks like a honest bug.
It seem like we forcibly try to use gssntlm_acquire_cred() in the acceptor even for the winbindd case, which won't work unless somehow a user already previously authenticated with the same server.
Note that the only reason we seem to be doing this is to obtain a credential of the right type (EXTERNAL) in order to trigger the external code path in the following call to gssntlm_srv_auth()

What I do not recall is why we perform a wbcCredentialCache() call at all in winbind_get_creds(), given we do not use the result,.
I think this makes sense for the init_sec_context case, as we want to insure winbindd has cached the NT/LM hashes in order to perform authentication, but it clearly fails in the accept case.

One way to solve this is to change winbind_get_creds, to record the "cached" status in the external creds, and always returning success in the accpet case, while checking the cached status in the init case and failing there.

Do you have a chance to test a patch in this sense if I provide one ?

[simo5]

Please let me know if #33 fixes your problem.

[kvv81]

Yes, I have tested our SMB server with your patch (built gssntlmssp.so library from 'wb_accept_creds' branch and pointed /etc/gss/mech.d/ntlmssp.conf to new location) and now the issue has gone.
Different users can pass authentication properly without any additional actions from winbind side.

Also reproduction with gss client/server works fine now:
$ ltrace gss-server host 2>&1 | grep gss
...
gss_accept_sec_context(0x7ffdb576bb0c, 0x7ffdb576bb28, 0x55d5b2e44ea0, 0x7ffdb576bb70) = 1
gss_release_buffer(0x7ffdb576bb08, 0x7ffdb576bb60, 184, 0) = 0
gss_accept_sec_context(0x7ffdb576bb0c, 0x7ffdb576bb28, 0x55d5b2e44ea0, 0x7ffdb576bb70) = 0
gss_display_name(0x7ffdb576bb08, 0x55d5b2e3f030, 0x7ffdb576bb50, 0x7ffdb576bb38) = 0

Thank you very much for your help!