Skip to main content

I've been working on an issue that I've seen quite a bit, but unfortunately haven't been able to quite get resolved just yet, so I thought I'd turn to the brilliant folks here to see if I can maybe get closer to a resolution than where I have been.

For a couple of months now, all of our Mac users have begun experiencing the dreaded "Proxy Authentication Required" prompt:

We used to see proxy authentication prompts a lot over a year ago, but I eventually convinced our Security team to enable Kerberos authentication on our WebSense proxy servers, which all but eliminated the proxy prompts through Safari for the longest time. Unfortunately, we've started seeing the system level Proxy prompt interrupting users more and more recently (mainly when the computers return from sleep, but sometimes just at random). For the more technical folks, we can tell them to just ignore the prompt and everything will work fine, but a lot of the users hate being interrupted, especially by a prompt that usually doesn't do anything from their perspective.

For reference, most of our users are not in JAMF yet. We are planning on moving them to JAMF in the next couple of weeks, but for now I'm just trying to get the issue resolved on my machines that are in JAMF so it makes it even more enticing for our users to move over.

Here's what I'm seeing on my Macs enrolled in JAMF:
User can login to their Mac via cached AD credentials (wireless user) after the computer has been asleep for 15-20 minutes - Note - This doesn't seem to affect our machines when we login / authenticate live via Ethernet. The Mac has NoMAD installed and configured, so the standard Kerberos ticket (krbtgt/domain.com) gets pulled without an issue immediately after the Mac connects to the internal wireless network. The Macs are using a proxy.pac file that is distributed on the proxy server. Sometimes (not every time, unfortunately) the user will see the above prompt when the background apps attempt to connect to internet resources. If the user enters their credentials or hits "Not Now" twice, the prompt will go away and the device will eventually pull a Kerberos ticket for the proxy server automatically (sometimes only after Safari is launched). From that point forward, the active Kerberos ticket for our Proxy server will usually take effect and provide the appropriate authentication, however we have seen the proxy prompt appear even with a valid kerberos ticket for our proxy server.

I'm looking to prevent the users from having the joy of seeing the proxy prompt multiple times a day. From what I can tell, there are two possible reasons we're seeing this prompt. 1 - A background service is attempting to access internet based resources before the Mac has a chance to pull a Kerberos ticket from the proxy server. The proxy server is prompting for authentication, and since we don't have an active / valid ticket, is defaulting back to NTLM - hence the password prompt. 2 - If we have a valid ticket but see the prompt, it's likely because the Mac is using one of the three possible DNS names for our proxy server and the name the Mac chose to utilize does not match the name of the issued Kerberos ticket. Since the kerberos ticket name doesn't match what the server is expecting, it fails the Kerberos authentication prompt and falls back to NTLM.

Here's what I've tried so far:
Configured NoMAD for our Macs. Though we now pull our standard Kerberos tickets automatically, it hasn't seemed to help the proxy issue.
Configured a script that adds the proxy.pac configuration to system preferences on user login. This same script also adds the IP address and preferred DNS name of our Proxy server to the hosts file, as our proxy server (10.x.x.x) resolves to 3 different DNS names.
Verified with our security department that Kerberos authentication is working fine for the Windows clients, and it does work well on the Mac once we have a matching Kerberos ticket for the proxy server.

Does anyone have any further ideas that I could try to suppress this prompt?

bump

I'm interested in a fix for this as well. We're seeing it more and more now in High Sierra. Causes havoc when users change their password on a different machine.

Have you tried added the domain infront of the username?

ie: "domainusername" (note the backslash)

You'll need to go through your keychain and remove any previous entries. This is how we get it to work in our environment.

Also I've seen times where the keychain just refuses to store the credentials. Usually the only way to fix that is to recreate the users login keychain.

Using DOMAINusername works for me (after removing all other keychain entries) but, I would be interested in seeing your script for the .pac file.

Commenting to bump.

Is the proxy using NTLM for auth?

Ours uses NTLM.

So, in order to save some other folks sanity after reading my post, I thought I'd post a followup that we were able to pretty much resolve this. There was a combination of things that we did, but for the most part folks are now content with the way our proxy servers are functioning.

For starters, we installed NoMAD across the board on every single Mac and trained our users on how to use it to their advantage. That suppressed a lot of the prompts, but folks still received them from time to time. Luckily, NoMAD also helped a lot with our manual password change process and automated a lot of the manual steps our users were having to run through, so they're much happier now with that implemented.

To resolve the proxy issue, our security team modified the proxy configuration to allow system processes to use our non-authenticated proxy (it's very limited, but most Apple resources and some of our required software apps can get out). We were seeing a lot of failed proxy attempts from the MacOS system because they were trying to get out without authentication. Once the processes that weren't able to get out before were now able to reach the net, the proxy prompts went away, with the exception of when devices don't have a valid Kerberos ticket and their devices fall back to NTLM.

So, are you saying that the device itself is able to authenticate to the proxy (for those background/non-userh specific processed like Software Update)? We also live in the painful World of Websense (ForcePoint), and we have our security team whitelisting (either via SSL decryption or authentication bypasses, or both) on what seems a daily basis.
Are your Macs bound to AD then, I assume? Is Nomad pulling machine Kerberos tickets, or only user?

Bump

Yes so installing nomad just kept mdmore1's users current on the kerberos ticket so they would not fall back to NTLM password auth.

We are having an issue now where after the bluecoat auth times out safari can not use the keychain entry to re auth. IT will just stay at 20 % loading bar in safari.

If you open up chrome or firefox both browsers will immediately realize the session is not authenticated and prompt for proxy login.

After that you can close and re open safari and it will start to work again since it has an authenticated session. We currently have an issue open with apple right now on this.

Hi comunitty.
Someone has found a stable solution to this problem? Related to pop-ups which appear after the proxy setting

We are having an issue now where after the bluecoat auth times out safari can not use the keychain entry to re auth. IT will just stay at 20 % loading bar in safari. If you open up chrome or firefox both browsers will immediately realize the session is not authenticated and prompt for proxy login. After that you can close and re open safari and it will start to work again since it has an authenticated session. We currently have an issue open with apple right now on this.

@ClassicII I'm currently having the same issue with one slight difference. Even after authenticating with Chrome or Firefox, Safari will not load a site. Did Apple ever give you any resolution on your issue?

Reference this Apple article. https://support.apple.com/en-us/HT210060

The best approach is to work with the proxy team and determine the destinations being blocked at your proxy. Also install tools on the Mac so you can monitor all traffic so you can compare to the traffic at the proxy. Had to do this recently and it is time consuming but ultimately can be cleaned up and work if you get the right Apple services whitelisted through your proxy.

Terms & ConditionsCookie settingsAccessibility statement