The following issues are often reported and have simple solutions.
•Rules are being ignored
•Problems using Web Browsers
•Problems with non-browser applications
•Warning Page Causes Some Websites To Fail
•Problems with Secure (HTTPS) Form Submissions
10.5.1 Rules are Being Ignored
•Ensure that the rule logic works as expected. Test the page which should trigger the rule using Test Rules. See “Testing Access Policy” for details.
•Check that rule processing is enabled. Right-click Access Policy in the Console and select Enable Rule Processing.
10.5.2 Problems Using Web Browsers
10.5.2.1 Users have to log on at the beginning of every browser session
WebMarshal requires users to be authenticated (log on) so that user matching Rules can work. Authentication can be by Windows Authentication or Basic Authentication. Windows Authentication negotiates the strongest available protocol from Kerberos or NTLM.
Some browser applications are not able to retrieve the credentials of the Windows user automatically. With these browsers the user must log in to start each session. In most cases users can choose to remember the password. To retrieve the Windows credential automatically, you can use Edge or most current major browsers.
10.5.2.2 Users are unable to authenticate
When users try to access the web, they are repeatedly prompted to enter their user name and password.
Some browsers may support only Basic Authentication. This type of authentication involves passing a user name and password to the proxy server. The proxy server tries to perform a simulated logon to validate the credentials. If the user does not have logon rights on the WebMarshal server computer, logon fails repeatedly.
To resolve the problem, do one of the following:
•Use a browser that supports Windows Authentication, such as Firefox or Microsoft Edge
•On the WebMarshal Server computer, grant the Windows NT permission “log on locally” to all accounts used for browsing
10.5.3 Problems With Non-Browser Applications
Rules which require that users accept a warning message before allowing access to a certain site are not acceptable to a non-browser based application. This is because the application requests a download but does not receive the expected file; instead it receives the WebMarshal warning message.
To resolve the problem, do one of the following:
•Create a rule to permit open access to the sites concerned
•Grant additional permissions to the users who are affected
•Set up IP/Workstation authentication for the workstations which run the non-browser applications
•Include the target site on the proxy server exclusion list (see “Configuring Ports and Authentication” on page 143).
10.5.4 Warning Page Causes Some Websites To Fail
This usually happens when a site has off-site links, most often when posting a form. The problem occurs when a user enters data into a form and clicks the Submit button. WebMarshal presents a page that asks if temporary access is required. If the user clicks Yes, they find that the form data has not been correctly posted.
To resolve the problem, several actions are possible:
•Create a rule to permit open access to the sites concerned.
•Grant additional permissions to the users who are affected.
10.5.5 Problems with Secure (HTTPS) Form Submissions
When WebMarshal requires the user to acknowledge a warning before accessing a secure website, the user is redirected to the root page of the secure site.
Because the original request was submitted and replied to securely, WebMarshal does not have access to the details of the request and cannot return the page requested.
To resolve the problem, you can enable HTTPS content inspection.
If you do not want to inspect HTTPS content for the site, you can create a Standard Rule to allow access to the site. If you do not want to enable HTTPS content inspection, you can create a rule to allow access to all secure sites (HTTPS://*). This rule should be evaluated after any general blocking rules (for instance, a rule blocking offensive sites).