macOS – Fix Network Authentication Change Password Not Working on El Capitan

Update: It wasn't the VPN client causing this, but after lengthy troubleshooting (see comments) it turned out to be Skype, possibly due to UPnP related bugs.

Try disabling your Cisco AnyConnect(?) VPN client (if you're not sure how, open Activity Monitor, find a process named acvpnagent and quit it).

From your description, it may well be the case that the VPN client is either failing to establish a tunnel or taking a rather long to do so, either of which could cause the apparent loss of the default route you're describing (you can ping anything on your local network, but nothing past the router).

If disabling the above (and any other) VPN client doesn't resolve it, please add the results of:

• ifconfig (not just ifconfig en1 - there's an interface utun0 appearing in your log)
• netstat -rnfinet

... at each of these stages:

• immediately after connecting to your Wifi (while the network seems to be up)
• during the problem
• and after recovery

I can confirm that I see the identical problem with Safari 7.0.2 (9537.74.9), with all current Mac OS X Mavericks updates installed. (Thousands of request packets per second with the same kind of content as described above.)

However, while this may or may not help the original poster, I have found that this problem only occurs if the Windows server has Integrated Windows Authentication (also known as NTLM Authentication) and Negotiate Authentication enabled.

The server then sends these two headers:

WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM

Safari will reply:

Authorization: Negotiate YEgGBisGAQUFAqA+MDygDjAMBgorBgEEAYI3AgIKoioEKE5UTE1TU1AAAQAAAAUCiGIAAAAAGAAAAAAAAAAYAAAABgGwHQ8AAAA=

And from there, the loop will get going.

But if Negotiate Authentication is not enabled on the server, there will be only one WWW-Authenticate header:

WWW-Authenticate: NTLM

And Safari's reply will be something like:

Authorization: NTLM TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA=

This will work just fine. Essentially, it seems that Negotiate is broken in Safari, and since the server sends Negotiate first, indicating a preference for it, Safari will try it and enter an infinite loop that prevents it from falling back to NTLM.

So, if the server administrator can be persuaded to turn off Negotiate in the authentication settings, the problem may be solved.

I might add that Firefox sends the "Authorization: NTLM ..." header regardless of whether the server provides Negotiate in addition to NTLM or not. Presumably, Negotiate is not implemented in Firefox.

Update

Safari 7.0.3 (9537.75.14) still exhibits the same problem.

We previously reported the issue as a bug at bugreport.apple.com, but the bug was closed as a duplicate of a previous bug—the contents of which we cannot see, except that it is still marked as open.

Update 2

I can confirm hauns's finding that the authentication works with Safari 7.0.4 (9537.76.4).

Update 3

This issue is back in Safari 7.0.5 (9537.77.4)

Update 4

This issue is still present in Safari 7.0.6 (9537.78.2), as noted by hauns, with cifs or smb volumes mounted.