You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Tell us about your request
Current proxy support in DD enables GSSAPI/SPNEGO options like Kerberos/Negotiate and NTLM, but if those auth types fail for any reason do to a breakdown specific to the auth type DD shifts into an aggressive retry (clients generating almost 2k requests per minute) to get to desktop.docker.com using the same authentication type.
There should be a max retry and an exponential backoff rather than ddos'ing the proxy hoping you get a different answer than 407.
Also falling back through the www-authenticate header in the 407 and trying all the options provided vs just hammering the most secure would allow folks to still function. SPNs can be wonky or there can be other ticket related nonsense that might cause SPNEGO to try Kerberos, but it not work for that specific client.
Which service(s) is this request for?
Docker Desktop - Business
Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
Trying to not ddos critical infrastructure.
Are you currently working around the issue?
Easiest answer if the PAC sends to a auth required proxy is to use "manual" to send to a proxy that does not require authentication for all connections. Basically avoid the 407 and the current situation. Proxy is also supported in admin-settings today so you can push the config down to logged in users w/o too much heartache if needed.
Another option is to update your settings.json to disable kerberos/ntlm completely as noted in the proxy doc. This setting only applies to very recent releases and is more complicated for a User than Settings/Resources/Proxies, but if there is no unauthenticated proxy option it's the only one that would work to avoid this issue. That setting is not in admin-settings so a bit more complicated to get out there.
Additional context
Related to Case #: 00108451
The text was updated successfully, but these errors were encountered:
Tell us about your request
Current proxy support in DD enables GSSAPI/SPNEGO options like Kerberos/Negotiate and NTLM, but if those auth types fail for any reason do to a breakdown specific to the auth type DD shifts into an aggressive retry (clients generating almost 2k requests per minute) to get to desktop.docker.com using the same authentication type.
There should be a max retry and an exponential backoff rather than ddos'ing the proxy hoping you get a different answer than 407.
Also falling back through the www-authenticate header in the 407 and trying all the options provided vs just hammering the most secure would allow folks to still function. SPNs can be wonky or there can be other ticket related nonsense that might cause SPNEGO to try Kerberos, but it not work for that specific client.
Which service(s) is this request for?
Docker Desktop - Business
Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
Trying to not ddos critical infrastructure.
Are you currently working around the issue?
Easiest answer if the PAC sends to a auth required proxy is to use "manual" to send to a proxy that does not require authentication for all connections. Basically avoid the 407 and the current situation. Proxy is also supported in admin-settings today so you can push the config down to logged in users w/o too much heartache if needed.
Another option is to update your settings.json to disable kerberos/ntlm completely as noted in the proxy doc. This setting only applies to very recent releases and is more complicated for a User than Settings/Resources/Proxies, but if there is no unauthenticated proxy option it's the only one that would work to avoid this issue. That setting is not in admin-settings so a bit more complicated to get out there.
Additional context
Related to Case #: 00108451
The text was updated successfully, but these errors were encountered: