Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 8 replies
  • Subscribers 1 subscriber
  • Views 3066 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Proxy SSO Issues

DrewbleIT
Hello!

We are testing a PAC as it's a bit more intelligent for our mobile users than other implementations. That said, we are having issues in testing where everything works fine for the user and then suddenly they are getting blocked from everything (hitting default block rule). In looking at the logs, the user doesn't appear to be passing creds as the firewall just see's the IP address. 

To fix - the user has to log out of windows and back on. Then the username re-appears in the logs. 

Any thoughts? 

PAC 
function FindProxyForURL(url, host) {

    if (shExpMatch(url, "https://${asg_hostname}*")) return "DIRECT";

    if (shExpMatch(url, "https://" + dnsResolve(host) + "*")) return "DIRECT";

    if (isPlainHostName(host)) return "DIRECT";

    if (shExpMatch(url, "*.local/*")) return "DIRECT";

    if (shExpMatch(url, "*domain.local*")) return "DIRECT";

    if (shExpMatch(url, "*domain.net*")) return "DIRECT";

	if (isInNet (host, "10.0.0.0", "255.0.0.0" ) ||

		isInNet (host, "172.16.0.0",  "255.240.0.0") ||

		isInNet (host, "192.168.0.0",  "255.255.0.0") ||

		isInNet (host, "127.0.0.0", "255.255.255.255"))

    return "DIRECT";

// DEFAULT RULE: All other traffic, use below proxies, in fail-over order.	

 return "PROXY proxy1.domain.LOCAL:8080; PROXY x.x.x.x:8080; DIRECT";

}


This thread was automatically locked due to age.
  • 0
    By which method do you deliver the pac to the users?
    Which browser do your users use?
    Version of UTM?
    Is the second proxy an ip address or a fqdn?

    Help us to help you ;-).

    Regards
    Manfred
  • 0 in reply to Hallowach2
    By which method do you deliver the pac to the users? GPO
    Which browser do your users use? Occurs in both Chrome and IE.
    Version of UTM? 9.315-2
    Is the second proxy an ip address or a fqdn? Second proxy was an IP address. However, the issue isn't occurring on the second proxy. (I know there can be issues with SSO and not using FQDN.) Just in case i actually removed the second proxy. Additionally, when users go direct, they hit a transparent rule which allows them to the Internet but applied company policies

    Help us to help you ;-).

    Regards
    Manfred


    I hope this helps. [:)]
  • 0
    So your utm hosts the pac configuration and you use the internet explorer maintenance part of the gpo to configure the users browsers, right?

    Two things come to my mind:
    1. internet explorer maintenance isn't the most reliable thing -> maybe try a different deployment method or maybe there are confliting settings in some gpo's
    2. you use some dns dependant functions in your pac -> maybe try to not use them

    But I guess it is something related to the gpo because relogin fixes the problem.

    Regards
    Manfred
  • 0 in reply to Hallowach2
    So your utm hosts the pac configuration and you use the internet explorer maintenance part of the gpo to configure the users browsers, right?

    Two things come to my mind:
    1. internet explorer maintenance isn't the most reliable thing -> maybe try a different deployment method or maybe there are confliting settings in some gpo's
    2. you use some dns dependant functions in your pac -> maybe try to not use them

    But I guess it is something related to the gpo because relogin fixes the problem.

    Regards
    Manfred

    Thank you for your assistance;

    Well I'm actually using the IE Settings section and created an IE 10+ policy for the PAC setting. IE Maintenance is being deprecated so it no longer shows up on non IE9 systems. The only addition is the new policy and PAC setting and is being applied to users who currently do not have proxy settings so in running gpresult's i see no conflicting policies. Just in case, we could test using DHCP. 

    Here's the behavior we are seeing. 

    Users authenticate just fine to proxy for hours. All logs show the correct profile and action. Then all of the sudden test users (not all at the same time) will get blocked from everything. Proxy logs show the correct profile (SSO Profile) and incorrect action (Default Block All). Interestingly enough, I have yet to have this happen today and did change the PAC to below code yesterday. 

    function FindProxyForURL(url, host) {

        if (shExpMatch(url, "https://${asg_hostname}*")) return "DIRECT";

        if (shExpMatch(url, "*.local/*")) return "DIRECT";

        if (shExpMatch(url, "*.domain.local/*")) return "DIRECT";

        if (shExpMatch(url, "*.domain.net/*")) return "DIRECT";

    	if (isInNet (host, "10.0.0.0", "255.0.0.0" ) ||

    		isInNet (host, "172.16.0.0",  "255.240.0.0") ||

    		isInNet (host, "192.168.0.0",  "255.255.0.0") ||

    		isInNet (host, "127.0.0.0", "255.255.255.255"))

        return "DIRECT";

    // DEFAULT RULE: All other traffic, use below proxies, in fail-over order.	

     return "PROXY proxy.domain.local:8080; PROXY proxy1.domain.local:8080; DIRECT";

    }
  • 0
    That sounds realy strange. 

    Aren't these two lines redundant?:
    if (shExpMatch(url, "*.local/*")) return "DIRECT";
    if (shExpMatch(url, "*.domain.local/*")) return "DIRECT";

    And I forgot to ask you to post some loglines of the blocked accesses - maybe that helps.

    Regards
    Manfred
  • 0 in reply to Hallowach2
    That sounds realy strange. 

    Aren't these two lines redundant?:
    if (shExpMatch(url, "*.local/*")) return "DIRECT";
    if (shExpMatch(url, "*.domain.local/*")) return "DIRECT";

    And I forgot to ask you to post some loglines of the blocked accesses - maybe that helps.

    Regards
    Manfred


    They are - I actually started out by using the PAC Magic tool and left some of those lines in. I removed it just in case.  


    function FindProxyForURL(url, host) {

        if (shExpMatch(url, "https://${asg_hostname}*")) return "DIRECT";

        if (shExpMatch(url, "*.local/*")) return "DIRECT";

        if (shExpMatch(url, "*.domain.net/*")) return "DIRECT";

    	if (isInNet (host, "10.0.0.0", "255.0.0.0" ) ||

    		isInNet (host, "172.16.0.0",  "255.240.0.0") ||

    		isInNet (host, "192.168.0.0",  "255.255.0.0") ||

    		isInNet (host, "127.0.0.0", "255.255.255.255"))

        return "DIRECT";

    // DEFAULT RULE: All other traffic, use below proxies, in fail-over order.	

     return "PROXY proxy.domain.local:8080; PROXY proxy1.domain.local:8080; DIRECT";

    }
  • 0
    Oh and as for the logs I'll try to grab some when/if we see it occur again. I was trying to get some packet captures as well to analyze just having a tough time coordinating the issue occurring and getting the captures. 

    I do agree though - It certainly is odd. Everything IMO seems to point to a cred issue (SSO). If it were DNS, it wouldn't be getting to the proxy and should hit the direct path thus hitting the transparent profile. Additionally if it were a policy issue it should only be hitting the transparent profile.  (Thinking out loud)
Unfiltered HTML