[PATCH 8/9] kerberos: Don't include GSS_C_DCE_STYLE in default gss_init_sec_context() flags.
Otherwise the returned ticket won't be accepted by WWW server when wrapped in an HTTP request. Original Rob's patch doesn't have this flag either. This patch is one of the fixes to make Kerberos Authentication Tester work. Signed-off-by: Dmitry Timoshkov <dmitry(a)baikal.ru> --- dlls/kerberos/krb5_ap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dlls/kerberos/krb5_ap.c b/dlls/kerberos/krb5_ap.c index ba89806957..66c795c377 100644 --- a/dlls/kerberos/krb5_ap.c +++ b/dlls/kerberos/krb5_ap.c @@ -326,7 +326,7 @@ static SECURITY_STATUS name_sspi_to_gss( const UNICODE_STRING *name_str, gss_nam static ULONG flags_isc_req_to_gss( ULONG flags ) { - ULONG ret = GSS_C_DCE_STYLE; + ULONG ret = 0; if (flags & ISC_REQ_DELEGATE) ret |= GSS_C_DELEG_FLAG; if (flags & ISC_REQ_MUTUAL_AUTH) ret |= GSS_C_MUTUAL_FLAG; if (flags & ISC_REQ_REPLAY_DETECT) ret |= GSS_C_REPLAY_FLAG; -- 2.15.1
On Thu, 2018-01-25 at 11:34 +0800, Dmitry Timoshkov wrote:
diff --git a/dlls/kerberos/krb5_ap.c b/dlls/kerberos/krb5_ap.c index ba89806957..66c795c377 100644 --- a/dlls/kerberos/krb5_ap.c +++ b/dlls/kerberos/krb5_ap.c @@ -326,7 +326,7 @@ static SECURITY_STATUS name_sspi_to_gss( const UNICODE_STRING *name_str, gss_nam static ULONG flags_isc_req_to_gss( ULONG flags ) { - ULONG ret = GSS_C_DCE_STYLE; + ULONG ret = 0; if (flags & ISC_REQ_DELEGATE) ret |= GSS_C_DELEG_FLAG; if (flags & ISC_REQ_MUTUAL_AUTH) ret |= GSS_C_MUTUAL_FLAG; if (flags & ISC_REQ_REPLAY_DETECT) ret |= GSS_C_REPLAY_FLAG;
This breaks my tests: 0009:trace:secur32:EncryptMessage 0x32fca0 0 0x32fc64 0 0009:trace:secur32:lsa_EncryptMessage 0x1307f8 0 0x32fc64 0) 0009:trace:kerberos:kerberos_SpSealMessage (7cef1cb8 0x00000000 0x32fc64 0) 0009:trace:kerberos:kerberos_SpSealMessage gss_wrap_iov returned 000d0000 minor status 00000016 0009:fixme:kerberos:status_gss_to_sspi couldn't convert status 0x000d0000 to SECURITY_STATUS kerberos.c:309: Test failed: got 80090304 kerberos.c:312: Test failed: wrong data kerberos.c:315: Test failed: got 12000 kerberos.c:316: Test failed: buffer not modified 0009:trace:secur32:DecryptMessage 0x32fccc 0x32fc64 0 (nil) 0009:trace:secur32:lsa_DecryptMessage 0x136608 0x32fc64 0 (nil)) 0009:trace:kerberos:kerberos_SpUnsealMessage (7ced5de8 0x32fc64 0 (nil)) kerberos.c:319: Test failed: got 80090301 0009:trace:secur32:MakeSignature 0x32fca0 0 0x32fc64 0 0009:trace:secur32:lsa_MakeSignature 0x1307f8 0 0x32fc64 0) 0009:trace:kerberos:kerberos_SpMakeSignature (7cef1cb8 0x00000000 0x32fc64 0) 0009:trace:kerberos:kerberos_SpMakeSignature gss_get_mic returned 00000000 minor status 00000000 kerberos.c:342: Test succeeded inside todo block: got 37 0009:trace:secur32:VerifySignature 0x32fccc 0x32fc64 0 (nil) 0009:trace:secur32:lsa_VerifySignature 0x136608 0x32fc64 0 (nil)) 0009:trace:kerberos:kerberos_SpVerifySignature (7ced5de8 0x32fc64 0 (nil)) 0009:trace:kerberos:kerberos_SpVerifySignature gss_verify_mic returned 00000000 minor status 00000000 0009:trace:secur32:DeleteSecurityContext 0x32fca0 0009:trace:secur32:lsa_DeleteSecurityContext 0x1307f8 0009:trace:kerberos:kerberos_SpDeleteContext (7cef1cb8) 0009:trace:kerberos:kerberos_SpDeleteContext gss_delete_sec_context returned 00000000 minor status 00000000 0009:trace:secur32:DeleteSecurityContext 0x32fccc 0009:trace:secur32:lsa_DeleteSecurityContext 0x136608 0009:trace:kerberos:kerberos_SpDeleteContext (7ced5de8) 0009:trace:kerberos:kerberos_SpDeleteContext gss_delete_sec_context returned 00000000 minor status 00000000 0009:trace:secur32:FreeCredentialsHandle 0x32fc98 0009:trace:secur32:lsa_FreeCredentialsHandle 0x12a1b0 0009:trace:kerberos:kerberos_SpFreeCredentialsHandle (7ceec378) 0009:trace:kerberos:kerberos_SpFreeCredentialsHandle gss_release_cred returned 00000000 minor status 00000000 0009:trace:secur32:FreeCredentialsHandle 0x32fcc4 0009:trace:secur32:lsa_FreeCredentialsHandle 0x1307e0 0009:trace:kerberos:kerberos_SpFreeCredentialsHandle (7cee9dc0) 0009:trace:kerberos:kerberos_SpFreeCredentialsHandle gss_release_cred returned 00000000 minor status 00000000 Makefile:187: recipe for target 'kerberos.ok' failed make: *** [kerberos.ok] Error 7
Hans Leidekker <hans(a)codeweavers.com> wrote:
static ULONG flags_isc_req_to_gss( ULONG flags ) { - ULONG ret = GSS_C_DCE_STYLE; + ULONG ret = 0; if (flags & ISC_REQ_DELEGATE) ret |= GSS_C_DELEG_FLAG; if (flags & ISC_REQ_MUTUAL_AUTH) ret |= GSS_C_MUTUAL_FLAG; if (flags & ISC_REQ_REPLAY_DETECT) ret |= GSS_C_REPLAY_FLAG;
This breaks my tests:
0009:trace:secur32:EncryptMessage 0x32fca0 0 0x32fc64 0 0009:trace:secur32:lsa_EncryptMessage 0x1307f8 0 0x32fc64 0) 0009:trace:kerberos:kerberos_SpSealMessage (7cef1cb8 0x00000000 0x32fc64 0) 0009:trace:kerberos:kerberos_SpSealMessage gss_wrap_iov returned 000d0000 minor status 00000016 0009:fixme:kerberos:status_gss_to_sspi couldn't convert status 0x000d0000 to SECURITY_STATUS kerberos.c:309: Test failed: got 80090304 kerberos.c:312: Test failed: wrong data kerberos.c:315: Test failed: got 12000 kerberos.c:316: Test failed: buffer not modified
Could you please provide the test sources along with the following log: KRB5_TRACE=/dev/stdout WINEDEBUG=+secur32 wine yourtest.exe with the attached patch applied? Also how are you testing kerberos SSP/AP? With my secur32 patches from the queue or something else? -- Dmitry.
Dmitry Timoshkov <dmitry(a)baikal.ru> wrote:
Could you please provide the test sources along with the following log: KRB5_TRACE=/dev/stdout WINEDEBUG=+secur32 wine yourtest.exe
with the attached patch applied?
Since the attached patch doesn't touch the APIs from not yet commited patches (it's for current winehq git) please also add + if (ret) trace_gss_status( ret, minor_status ); to SpSealMessage(). Thanks. -- Dmitry.
On Thu, 2018-01-25 at 19:39 +0800, Dmitry Timoshkov wrote:
Hans Leidekker <hans(a)codeweavers.com> wrote:
static ULONG flags_isc_req_to_gss( ULONG flags ) { - ULONG ret = GSS_C_DCE_STYLE; + ULONG ret = 0; if (flags & ISC_REQ_DELEGATE) ret |= GSS_C_DELEG_FLAG; if (flags & ISC_REQ_MUTUAL_AUTH) ret |= GSS_C_MUTUAL_FLAG; if (flags & ISC_REQ_REPLAY_DETECT) ret |= GSS_C_REPLAY_FLAG;
This breaks my tests:
0009:trace:secur32:EncryptMessage 0x32fca0 0 0x32fc64 0 0009:trace:secur32:lsa_EncryptMessage 0x1307f8 0 0x32fc64 0) 0009:trace:kerberos:kerberos_SpSealMessage (7cef1cb8 0x00000000 0x32fc64 0) 0009:trace:kerberos:kerberos_SpSealMessage gss_wrap_iov returned 000d0000 minor status 00000016 0009:fixme:kerberos:status_gss_to_sspi couldn't convert status 0x000d0000 to SECURITY_STATUS kerberos.c:309: Test failed: got 80090304 kerberos.c:312: Test failed: wrong data kerberos.c:315: Test failed: got 12000 kerberos.c:316: Test failed: buffer not modified
Could you please provide the test sources along with the following log: KRB5_TRACE=/dev/stdout WINEDEBUG=+secur32 wine yourtest.exe
Attached log is from runnning this command with your debug patch applied: KRB5_TRACE=/dev/stdout WINEDEBUG=+secur32,+kerberos ../../../tools/runtest -P wine -T ../../.. -M secur32.dll -p secur32_test.exe.so kerberos
Also how are you testing kerberos SSP/AP? With my secur32 patches from the queue or something else?
Yes, this is against your secur32 patches. The server is a Windows 2008 domain controller. See the test source for more details.
Hans Leidekker <hans(a)codeweavers.com> wrote:
Could you please provide the test sources along with the following log: KRB5_TRACE=/dev/stdout WINEDEBUG=+secur32 wine yourtest.exe
Attached log is from runnning this command with your debug patch applied: KRB5_TRACE=/dev/stdout WINEDEBUG=+secur32,+kerberos ../../../tools/runtest -P wine -T ../../.. -M secur32.dll -p secur32_test.exe.so kerberos
Thanks. From the log: 0009:trace:kerberos:kerberos_SpSealMessage (7c623a20 0x00000000 0x32fc64 0) 0009:trace:kerberos:kerberos_SpSealMessage gss_wrap_iov returned 000d0000 minor status 00000016 0009:trace:kerberos:trace_gss_status_ex GSS-API error: 0x000d0000: "Unspecified GSS failure. Minor code may provide more information" 0009:trace:kerberos:trace_gss_status_ex GSS-API error: 0x00000016: "Invalid argument" Looks like gss_wrap_iov() depends on GSS_C_DCE_STYLE being provided at the context creation time. That's weird, I can't find an explanation that this flag is required for this API. Did you test kerberos+secur32 patches with Kerberos Authentication Tester in your kerberos testing environment? -- Dmitry.
Dmitry Timoshkov <dmitry(a)baikal.ru> wrote:
Hans Leidekker <hans(a)codeweavers.com> wrote:
Could you please provide the test sources along with the following log: KRB5_TRACE=/dev/stdout WINEDEBUG=+secur32 wine yourtest.exe
Attached log is from runnning this command with your debug patch applied: KRB5_TRACE=/dev/stdout WINEDEBUG=+secur32,+kerberos ../../../tools/runtest -P wine -T ../../.. -M secur32.dll -p secur32_test.exe.so kerberos
Thanks. From the log:
0009:trace:kerberos:kerberos_SpSealMessage (7c623a20 0x00000000 0x32fc64 0) 0009:trace:kerberos:kerberos_SpSealMessage gss_wrap_iov returned 000d0000 minor status 00000016 0009:trace:kerberos:trace_gss_status_ex GSS-API error: 0x000d0000: "Unspecified GSS failure. Minor code may provide more information" 0009:trace:kerberos:trace_gss_status_ex GSS-API error: 0x00000016: "Invalid argument"
Looks like gss_wrap_iov() depends on GSS_C_DCE_STYLE being provided at the context creation time. That's weird, I can't find an explanation that this flag is required for this API.
https://web.mit.edu/kerberos/krb5-1.12/doc/appdev/gssapi.html "If the context was established using the GSS_C_DCE_STYLE flag (described in RFC 4757), wrap tokens compatible with Microsoft DCE RPC can be constructed. In this case, the IOV list must include a SIGN_ONLY buffer, a DATA buffer, a second SIGN_ONLY buffer, and a HEADER buffer in that order (the order of the buffer contents remains arbitrary). The application must pad the DATA buffer to a multiple of 16 bytes as no padding or trailer buffer is used." So the implementation of kerberos_SpSealMessage() should be fixed. Since this is your code would you mind have a look at it? -- Dmitry.
On Thu, 2018-01-25 at 20:30 +0800, Dmitry Timoshkov wrote:
Dmitry Timoshkov <dmitry(a)baikal.ru> wrote:
Hans Leidekker <hans(a)codeweavers.com> wrote:
Could you please provide the test sources along with the following log: KRB5_TRACE=/dev/stdout WINEDEBUG=+secur32 wine yourtest.exe
Attached log is from runnning this command with your debug patch applied: KRB5_TRACE=/dev/stdout WINEDEBUG=+secur32,+kerberos ../../../tools/runtest -P wine -T ../../.. -M secur32.dll -p secur32_test.exe.so kerberos
Thanks. From the log:
0009:trace:kerberos:kerberos_SpSealMessage (7c623a20 0x00000000 0x32fc64 0) 0009:trace:kerberos:kerberos_SpSealMessage gss_wrap_iov returned 000d0000 minor status 00000016 0009:trace:kerberos:trace_gss_status_ex GSS-API error: 0x000d0000: "Unspecified GSS failure. Minor code may provide more information" 0009:trace:kerberos:trace_gss_status_ex GSS-API error: 0x00000016: "Invalid argument"
Looks like gss_wrap_iov() depends on GSS_C_DCE_STYLE being provided at the context creation time. That's weird, I can't find an explanation that this flag is required for this API.
https://web.mit.edu/kerberos/krb5-1.12/doc/appdev/gssapi.html "If the context was established using the GSS_C_DCE_STYLE flag (described in RFC 4757), wrap tokens compatible with Microsoft DCE RPC can be constructed. In this case, the IOV list must include a SIGN_ONLY buffer, a DATA buffer, a second SIGN_ONLY buffer, and a HEADER buffer in that order (the order of the buffer contents remains arbitrary). The application must pad the DATA buffer to a multiple of 16 bytes as no padding or trailer buffer is used."
So the implementation of kerberos_SpSealMessage() should be fixed. Since this is your code would you mind have a look at it?
Sure, I can take a look. Can you show me how to reproduce your failure?
Hans Leidekker <hans(a)codeweavers.com> wrote:
Looks like gss_wrap_iov() depends on GSS_C_DCE_STYLE being provided at the context creation time. That's weird, I can't find an explanation that this flag is required for this API.
https://web.mit.edu/kerberos/krb5-1.12/doc/appdev/gssapi.html "If the context was established using the GSS_C_DCE_STYLE flag (described in RFC 4757), wrap tokens compatible with Microsoft DCE RPC can be constructed. In this case, the IOV list must include a SIGN_ONLY buffer, a DATA buffer, a second SIGN_ONLY buffer, and a HEADER buffer in that order (the order of the buffer contents remains arbitrary). The application must pad the DATA buffer to a multiple of 16 bytes as no padding or trailer buffer is used."
So the implementation of kerberos_SpSealMessage() should be fixed. Since this is your code would you mind have a look at it?
Sure, I can take a look. Can you show me how to reproduce your failure?
Just run the tester, type http://wintest2.test.local in the "Url:" field and press "Test" button. Make sure that you have a valid TGT in the cache. (I assume that SPN "HTTP/wintest2.test.local" from the log you've provided ealier exists on the server, otherwise you may need to list available SPNs on the Windows side using 'setspn -T yourdomain.com - Q */*' and find one starting with HTTP/ prefix). -- Dmitry.
Dmitry Timoshkov <dmitry(a)baikal.ru> wrote:
Hans Leidekker <hans(a)codeweavers.com> wrote:
Looks like gss_wrap_iov() depends on GSS_C_DCE_STYLE being provided at the context creation time. That's weird, I can't find an explanation that this flag is required for this API.
https://web.mit.edu/kerberos/krb5-1.12/doc/appdev/gssapi.html "If the context was established using the GSS_C_DCE_STYLE flag (described in RFC 4757), wrap tokens compatible with Microsoft DCE RPC can be constructed. In this case, the IOV list must include a SIGN_ONLY buffer, a DATA buffer, a second SIGN_ONLY buffer, and a HEADER buffer in that order (the order of the buffer contents remains arbitrary). The application must pad the DATA buffer to a multiple of 16 bytes as no padding or trailer buffer is used."
So the implementation of kerberos_SpSealMessage() should be fixed. Since this is your code would you mind have a look at it?
Sure, I can take a look. Can you show me how to reproduce your failure?
Just run the tester, type http://wintest2.test.local in the "Url:" field and press "Test" button. Make sure that you have a valid TGT in the cache. (I assume that SPN "HTTP/wintest2.test.local" from the log you've provided ealier exists on the server, otherwise you may need to list available SPNs on the Windows side using 'setspn -T yourdomain.com - Q */*' and find one starting with HTTP/ prefix).
I forgot to mention that Kerberos Tester requires 'winetricks dotnet20' to function, it won't work with wine-mono. -- Dmitry.
On Thu, 2018-01-25 at 20:51 +0800, Dmitry Timoshkov wrote:
Sure, I can take a look. Can you show me how to reproduce your failure?
Just run the tester, type http://wintest2.test.local in the "Url:" field and press "Test" button. Make sure that you have a valid TGT in the cache. (I assume that SPN "HTTP/wintest2.test.local" from the log you've provided ealier exists on the server, otherwise you may need to list available SPNs on the Windows side using 'setspn -T yourdomain.com - Q */*' and find one starting with HTTP/ prefix).
The tool expects a web server with a specific configuration. I installed IIS 7.0, added the 'Windows Authentication' feature and enabled it for the test site. It turns out that it's testing the Negotiate provider, which doesn't do the same three-leg authentication as the Kerberos provider.
Hans Leidekker <hans(a)codeweavers.com> wrote:
On Thu, 2018-01-25 at 20:51 +0800, Dmitry Timoshkov wrote:
Sure, I can take a look. Can you show me how to reproduce your failure?
Just run the tester, type http://wintest2.test.local in the "Url:" field and press "Test" button. Make sure that you have a valid TGT in the cache. (I assume that SPN "HTTP/wintest2.test.local" from the log you've provided ealier exists on the server, otherwise you may need to list available SPNs on the Windows side using 'setspn -T yourdomain.com - Q */*' and find one starting with HTTP/ prefix).
The tool expects a web server with a specific configuration. I installed IIS 7.0, added the 'Windows Authentication' feature and enabled it for the test site.
It turns out that it's testing the Negotiate provider, which doesn't do the same three-leg authentication as the Kerberos provider.
Thanks for the ongoing efforts. The Negotiate provider is just a thin layer that switches between NTLM and Kerberos, probabaly IIS doesn't use Kerberos for some reason and falls back to NTLM. Inspecting HTTP headers in Kerberos Tester or HTTP exchange in Wireshark may help. I have created a simple test app that replicates in plain C what Kerberos Tester is doing and does some additional logging/HTTP headers dumping. On the other hand since I have a working server with proper Kerberos support and dedicated SPNs I could try to take care of the problem on my own, and you then may switch to reviewing secur32 patches in the queue. Just let me know if you prefer going this way. -- Dmitry.
On Tue, 2018-01-30 at 17:47 +0800, Dmitry Timoshkov wrote:
Hans Leidekker <hans(a)codeweavers.com> wrote:
On Thu, 2018-01-25 at 20:51 +0800, Dmitry Timoshkov wrote:
Sure, I can take a look. Can you show me how to reproduce your failure?
Just run the tester, type http://wintest2.test.local in the "Url:" field and press "Test" button. Make sure that you have a valid TGT in the cache. (I assume that SPN "HTTP/wintest2.test.local" from the log you've provided ealier exists on the server, otherwise you may need to list available SPNs on the Windows side using 'setspn -T yourdomain.com - Q */*' and find one starting with HTTP/ prefix).
The tool expects a web server with a specific configuration. I installed IIS 7.0, added the 'Windows Authentication' feature and enabled it for the test site.
It turns out that it's testing the Negotiate provider, which doesn't do the same three-leg authentication as the Kerberos provider.
Thanks for the ongoing efforts.
The Negotiate provider is just a thin layer that switches between NTLM and Kerberos, probabaly IIS doesn't use Kerberos for some reason and falls back to NTLM. Inspecting HTTP headers in Kerberos Tester or HTTP
It detects the authentication type as Kerberos.
exchange in Wireshark may help. I have created a simple test app that replicates in plain C what Kerberos Tester is doing and does some additional logging/HTTP headers dumping.
On the other hand since I have a working server with proper Kerberos support and dedicated SPNs I could try to take care of the problem on my own, and you then may switch to reviewing secur32 patches in the queue. Just let me know if you prefer going this way.
Sure, we can revisit this when we have a better understanding of the problem.
Hans Leidekker <hans(a)codeweavers.com> wrote:
Just run the tester, type http://wintest2.test.local in the "Url:" field and press "Test" button. Make sure that you have a valid TGT in the cache. (I assume that SPN "HTTP/wintest2.test.local" from the log you've provided ealier exists on the server, otherwise you may need to list available SPNs on the Windows side using 'setspn -T yourdomain.com - Q */*' and find one starting with HTTP/ prefix).
The tool expects a web server with a specific configuration. I installed IIS 7.0, added the 'Windows Authentication' feature and enabled it for the test site.
It turns out that it's testing the Negotiate provider, which doesn't do the same three-leg authentication as the Kerberos provider.
Thanks for the ongoing efforts.
The Negotiate provider is just a thin layer that switches between NTLM and Kerberos, probabaly IIS doesn't use Kerberos for some reason and falls back to NTLM. Inspecting HTTP headers in Kerberos Tester or HTTP
It detects the authentication type as Kerberos.
That's a good starting point. Does KRB5_TRACE=/dev/stdout in addition to WINEDEBUG=+secur32,+kerberos help to shed some light on the reason of the failure? Or you didn't try to run the Kerberos Tester on the Wine side and just tried it under Windows? I've personally found out that usually tracking down kerberos related failures under linux+wine is much easier than under windows. Just in case I'm attaching a test with source that I'm using for internal kerberos testing, the test replicates what Kerberos Tester is doing, but doesn't require dotnet. The test needs a server address of a kerberized HTTP server. $> KRB5_TRACE=/dev/stdout WINEDEBUG=+secur32,+kerberos wine kerberos.exe myserver.sample.com The test dumps server responces and it's usually very helpful to look at the ticket generated by InitializeSecurityContext(), if there is "NTLM" signature there, then kerberos is not used for some reason. -- Dmitry.
On Tue, 2018-01-30 at 18:55 +0800, Dmitry Timoshkov wrote:
It detects the authentication type as Kerberos.
That's a good starting point. Does KRB5_TRACE=/dev/stdout in addition to WINEDEBUG=+secur32,+kerberos help to shed some light on the reason of the failure? Or you didn't try to run the Kerberos Tester on the Wine
Here's the log.
Hans Leidekker <hans(a)codeweavers.com> wrote:
It detects the authentication type as Kerberos.
That's a good starting point. Does KRB5_TRACE=/dev/stdout in addition to WINEDEBUG=+secur32,+kerberos help to shed some light on the reason of the failure? Or you didn't try to run the Kerberos Tester on the Wine
Here's the log.
Thanks, looks like you have a working Kerberos setup on a WWW server side. It seems the app doesn't like what QueryContextAttributesW(NEGOTIATION_INFO) returns. I have a private build here with another version of Kerberos patches and it doesn't include SECPKG_FLAG_APPCONTAINER_CHECKS in the package flags. Currently I can't run Kerberos Tester under winehq and check whether it's a real culprit. Did you try with my test program? It doesn't care about NEGOTIATION_INFO. -- Dmitry.
Dmitry Timoshkov <dmitry(a)baikal.ru> wrote:
Hans Leidekker <hans(a)codeweavers.com> wrote:
It detects the authentication type as Kerberos.
That's a good starting point. Does KRB5_TRACE=/dev/stdout in addition to WINEDEBUG=+secur32,+kerberos help to shed some light on the reason of the failure? Or you didn't try to run the Kerberos Tester on the Wine
Here's the log.
Thanks, looks like you have a working Kerberos setup on a WWW server side. It seems the app doesn't like what QueryContextAttributesW(NEGOTIATION_INFO) returns. I have a private build here with another version of Kerberos patches and it doesn't include SECPKG_FLAG_APPCONTAINER_CHECKS in the package flags. Currently I can't run Kerberos Tester under winehq and check whether it's a real culprit.
Did you try with my test program? It doesn't care about NEGOTIATION_INFO.
Actually it appears to be what the problem we are talking about is. Please try with GSS_C_DCE_STYLE removed and see whether it helps. -- Dmitry.
Dmitry Timoshkov <dmitry(a)baikal.ru> wrote:
Otherwise the returned ticket won't be accepted by WWW server when wrapped in an HTTP request.
Original Rob's patch doesn't have this flag either.
This patch is one of the fixes to make Kerberos Authentication Tester work.
This patch is marked as 'Superseded' in the patch tracker, but my testing shows that (after applying "[PATCH 13/13] secur32: Add support for switching between Kerberos and NTLM in Negotiate provider.") both my test program and Kerberos Authentication Tester still fail to authenticate without removing GSS_C_DCE_STYLE when creating initial Kerberos context. Thus, I believe that 'Superseded' state was assigned by mistake. If that's not the case please point out to a patch that was supposed to obsolete this one. -- Dmitry.
On Mon, 2018-02-05 at 11:27 +0800, Dmitry Timoshkov wrote:
Dmitry Timoshkov <dmitry(a)baikal.ru> wrote:
Otherwise the returned ticket won't be accepted by WWW server when wrapped in an HTTP request.
Original Rob's patch doesn't have this flag either.
This patch is one of the fixes to make Kerberos Authentication Tester work.
This patch is marked as 'Superseded' in the patch tracker, but my testing shows that (after applying "[PATCH 13/13] secur32: Add support for switching between Kerberos and NTLM in Negotiate provider.") both my test program and Kerberos Authentication Tester still fail to authenticate without removing GSS_C_DCE_STYLE when creating initial Kerberos context.
Thus, I believe that 'Superseded' state was assigned by mistake. If that's not the case please point out to a patch that was supposed to obsolete this one.
I showed you how simply removing GSS_C_DCE_STYLE failed my tests, so the patch should have been marked as rejected. Note that Kerberos Authentication Tester only tests initializing a Negotiate security context whereas my tests work directly against the Kerberos provider, and they include tests for signing and sealing. I have submitted a patch that should fix your problem.
Hans Leidekker <hans(a)codeweavers.com> wrote:
This patch is marked as 'Superseded' in the patch tracker, but my testing shows that (after applying "[PATCH 13/13] secur32: Add support for switching between Kerberos and NTLM in Negotiate provider.") both my test program and Kerberos Authentication Tester still fail to authenticate without removing GSS_C_DCE_STYLE when creating initial Kerberos context.
Thus, I believe that 'Superseded' state was assigned by mistake. If that's not the case please point out to a patch that was supposed to obsolete this one.
I showed you how simply removing GSS_C_DCE_STYLE failed my tests, so the patch should have been marked as rejected.
Sure, I was mostly curious about the replacement patch.
Note that Kerberos Authentication Tester only tests initializing a Negotiate security context whereas my tests work directly against the Kerberos provider, and they include tests for signing and sealing.
I have submitted a patch that should fix your problem.
Thanks, your patch looks good to me. Please also note that I have a much more complex application than Kerberos Tester that requires support for Kerberos authentication, and I'm mentioning Kerberos Tester just so you could reproduce the problem on your own. -- Dmitry.
participants (2)
-
Dmitry Timoshkov -
Hans Leidekker