Proxy authentication

We have openSUSE desktops that we would like to configure behind a proxy for web browsing. Since users have a choice of multiple browsers, it is easiest to set up the system-wide proxy configuration through YAST2 > Network Services > Proxy. Adding specific username/password credentials in this system setting is not appropriate, as these are shared machines with multiple accounts.

In Leap 42.3, if we did not specify proxy credentials, each user’s browser would prompt for credentials upon receiving the proxy authentication request. Unfortunately, this is not happening with Leap 15. By leaving the username/password fields blank in YAST2 > Network Services > Proxy, the end result is that the browser does not prompt for credentials anymore, and the connection fails with “ERROR 407: Proxy Authentication Required.”

Per browser workarounds/configurations are undesirable as these are multi-user desktops and we are looking for a central configuration solution to match our proxy server configuration. Any insight or assistance in getting the system proxy settings to prompt users for proxy credentials within their browser of choice would be greatly appreciated. Thanks in advance.

You’re actually asking about 2 separate things related to properly setting up a Web proxy…

  1. Where your web proxy is located (It’s not always the same as your Default Gateway node)
  2. Authentication credentials

To address the first issue (where your Web Proxy is somewhere on your network), there is a configuration called WPAD. You set it up and every web browser, no matter what make should by default consume the script, self-configure and point to your web proxy. That’s because unless you made any changes, <all> web browsers are configured by default to use WPAD if it’s found on your network… Notice I’m being a little vague here about how you might distribute your WPaD configuration because there are several ways possible (see my links below). In fact, if your supported web browsers are known to prefer different ways, you may end up setting up many ways for your clients to find their WPAD files.

The second issue is authentication… And, that will depend on what kind of security you configure… eg
LDAP kerberos tokens?
AD tokens?

Proxies, including web proxies can be set up numerous ways to support various credentials, only you know what you’re setting up. Or, if you’re a tiny network, then set up anonymous authentication and don’t require any kind of authentication.

Configuring for different kinds of proxies


Thank you for the prompt reply. To clarify, we already have an existing proxy server in place. We have migrated to Leap 15 on our desktop and we are having trouble with their authentication to the proxy server. It is set up for username/password authentication. Previously, in Leap 42.1 (verified this, thought it was 42.3 earlier), a user would get prompted for their proxy credentials inside the web browser of their choice.

I attempted to duplicate this using YAST2 > Network Services > Proxy on the Leap 15 desktops, but I am having no luck. I have to leave the username and password fields blank in the Proxy panel because authentication to the proxy server should be on a per-user basis, not a per-system basis.

I can confirm from the logs on the proxy server that each of the Leap 15 desktops is correctly pointed to the proxy server, however users’ web browsers are not prompting for credentials. Instead, the Leap 15 client connects to the proxy server and fails with a “407: Proxy Authentication Required” message.

So I am hoping to find the correct way to configure these desktops so that they will prompt the user for their proxy credentials during a web browsing session. It seems to work fine on Leap 42.1 but it is not working in Leap 15. I suspect that I have missed a configuration change somewhere.

You don’t mention which browsers. Do Chromium and Firefox both have the same issue?

Thank you for the follow up question.

Yes, they do both behave the same way by default. Chrome uses the system’s settings for proxy server, and Firefox is set to “use system proxy settings”. With this setting, neither browser will prompt the user for proxy credentials.

However, for testing purposes, if I change Firefox to “automatic proxy configuration URL” and point it to our proxy server, it prompts the user as expected and works perfectly. The problem is that I cannot configure Chrome in the same way. As far as I can tell, Chrome only wants to use the system settings for a proxy server.

Beyond Firefox and Chrome that is installed on all desktops, we also allow the users to install any browser of their choice, which is another reason why a general solution would be preferable.

As a result, I have fallen back to unsuccessfully trying to use Yast to configure the system proxy for HTTP/HTTPS.

No idea if this will work;

Set your YaST Proxy system settings up with no password.

Under your user home directory create a file called .curlrc

In that file add:

--proxy-user "username:password"

You should understand that there is a big difference between an application level proxy like a Web Proxy and a system level proxy for which you might configure YaST.

Only the person who set up or manages your proxy will know what can work or won’t.

As I described,
If you’re certain that the web proxy configuration in a web browser works, then you should set up the WPAD option I described… It would work with every web browser on every machine automatically unless someone changed the default setting in the browser(and then it would only require checking the box to set the browser back to its default setting).


Here’s a couple additional thoughts…

If you’re striving for a centrally managed network authentication solution,
Have you considered or implemented network based security, eg LDAP, AD or something similar?
If you did, that would address your authentication issues properly by implementing Single Sign-On.

Just wondering if you are specifying the correct port number for your proxy URL, whether you’re configuring in WPAD, in a browser or in YaST.


Thank you for the additional feedback. Yes, the port number is correct. As I mentioned earlier, the desktops communicate with the proxy server on the correct port, which is why the proxy server responds with the 407 error and logs the client connect on the server side.

These are public use desktops in a lab environment that utilize a frozen image. So SSO does not apply as users are not utilizing their credentials until the point in time where they access Internet services through the proxy server. The historical setup continues to work fine with Leap 42.1 using the proxy configured through Network Manager. With that configuration, Network Proxy/Method Automatic, and pointed to the proxy’s PAC file, it would work as expected. Browsers set to “use system proxy” would communicate with the proxy and prompt the user for credentials.

I am obviously new to Leap 15 which appears to abandon Network Manager in favor of the Proxy settings in Yast. Yast’s Proxy setting wants an explicit username/password. This change appears to cause the issue we are now experiencing on the Leap 15 test desktops. Of course, the proxy does utilize SSO on the back end as it serves thousands of users from Linux/Win/Mac clients, but on the front end, the clients are anonymous until they contact the proxy server.

I can certainly pursue the WPAD solution with coordination from the DHCP admin, however it is not clear if offering up the PAC url to applications via DHCP would be any different than the system proxy offering it to the applications. Will the WPAD configuration force every browser to prompt users for credentials?

To review, the browsers are getting pointed to the remote PAC file already, they are just not prompting the user for credentials as they should.

Ultimately, disabling wicked and going back to Network Manager to duplicate the exact 42.1 configuration was the best solution here. I was hoping to get it to work with wicked as default and use the system proxy, but without an “automatic proxy” option, I could not get it to work.

Thank you for all of the suggestions. They offered alternatives and lead me to do further research on the topic.