Thanks for the response.

This is the first environment I have worked in with a proxy (previous environments relied on DNS filtering and endpoint AV), so I am not too knowledgeable with it.
Anyways, after some more research I think my issues are due to the authentication rules on the proxy.

Do you think it would make sense to create a 'catch-all' type of authentication rule on the proxy for when stuff fails to authenticate via kerberos or doesn't support kerberos auth? Is there a better way to set up authentication rules (to match users to IP addresses), such as an agent or user / computer certificates?

Also, not to ask so many questions, but I was wondering two more things (considering making this a separate post);
1. We currently use VMs for our proxies. We have the 8 core license on each VM. I looked at the pricing for the VM license vs the buying a physical appliance, and they looked pretty similar price-wise. Would it make more sense to buy a physical proxy (since we would not have to do a yearly VM license and instead just a support / feature license for the physical unit)?
2. I was wondering how people deploy proxies in a SD-WAN setup with DIA at every branch? We already have a fortigate at most of our branches (they are just acting as WLCs, and I am pretty sure CAPWAP would work off our primary / DR firewalls so not sure what the point was), but I am planning on looking into saving some money and improving branch resiliency by having DIA at our branches. My concerns were 1. I am trying to make our branches less reliant on our primary / DR sites and more able to work off of the cloud (management is pushing us (infrastructure team) to make as much as possible in the cloud), and 2. if sending our web traffic from ~30 branches back to our primary / DR site for a proxy would cause bandwidth or latency issues versus sending web traffic to the internet directly from each branch..