Home | Site Map | Cisco How To Net How To | Wireless | Search | Forums | Services | Donations | Careers | About Us | Contact Us|

Track user web activity with GFI WebMonitor™. Download free trial!
Bob Lin Photography services

Real Estate Photography services 

 

ISA Troubleshooting

 

Cannot access server 2003


Error Code: 502 Proxy Error
How to fix Error code: 500 Internal Server Error in ISA
How to repair Error Code 10061 in ISA: Connection refused
How to solve the dreaded "403 Forbidden" error in ISA and TMG
ISA server Error Code: 502 Proxy Error
Send traffic from a subnet to the DMZ without NAT
Using ISA protect Exchange
Vista can't establish L2TP/IPSec connection to ISA error 809
VPN Connection through LinkSys Router and ISA Server

VPN on ISA

How to solve the dreaded "403 Forbidden" error in ISA and TMG

One of the most uninformative messages you can deliver to a user when publishing content through Microsoft’s ISA Server 2006 or Forefront TMG Server 2010 is the 403 Forbidden. In this article we shall take a look at what can cause this, how to troubleshoot it, and how to resolve the issue and get users their content. Of course, there will always be the unauthorized users out there to whom we want to deliver a 403, but they will usually tend to themselves.

 

First, let’s consider what the Makers (at least, of the HTTP protocol) intended when they came up with the HTTP response codes. A 403 message by itself simply indicates that the requested resource is one that the requestor is not allowed to view. Please note that it is entirely different from a 401.3 which indicates an authentication failure. A 403 means “you can’t have this,” no matter who you are. It is NOT the result of a permissions issue or authentication failure. Microsoft’s IIS has an entire sub-class of 403 responses, which can tell you more about the issue.

 

Microsoft’s 403.x response codes

403.1 - Execute access forbidden.

403.2 - Read access forbidden.

403.3 - Write access forbidden.

403.4 - SSL required.

403.5 - SSL 128 required.

403.6 - IP address rejected.

403.7 - Client certificate required.

403.8 - Site access denied.

403.9 - Too many users.

403.10 - Invalid configuration.

403.11 - Password change.

403.12 - Mapper denied access.

403.13 - Client certificate revoked.

403.14 - Directory listing denied.

403.15 - Client Access Licenses exceeded.

403.16 - Client certificate is untrusted or invalid.

403.17 - Client certificate has expired or is not yet valid.

 

To troubleshoot these issues, here is how to proceed:

1.  Get the actual response from the client’s browser. You may have to click the “more information” link, as many browsers are starting to hide the really useful information in response codes so they don’t scare regular people. View the error and note the specific response code. Consulting the table above can help you determine where to go next.
2. 
From the ISA/TMG server itself, attempt to request the same resource from the published server. If you receive the same error, then you need to move to the internal webserver, and consult its IIS logs or site configuration to determine your next steps. Again, the specific response code is key.
3.  
If you can access the resource internally, just not when published through ISA/TMG, it’s time to look at the ISA/TMG logs. Launch the management console, browse down to the Monitoring in ISA, or Logs & Reports in TMG.
4. Edit the filter to look at live logs and have the user try again, or filter on the time range to see the error. Add the “Filter by” criteria for HTTP Status Code, and set it equal to 403.


5. Run the query, and examine the results.

 

The most common ones you will come across with ISA/TMG have to do with the publishing rule settings for the website. Here are the ones that are most frequently on client systems:

In a publishing rule, you require SSL but the user did not specify that in their browser. To solve this you can tell the user to make sure they type https:// in front of the URL, but I prefer to create an HTTP rule that denies access with a redirect to the https URL, as shown in the image below:



·         * I never recommend using IP address restrictions because of the number of open proxies in the world, however it is done. A 403.6 is thrown to a client on the ‘naughty list.’ Here, you simply have to remove the client’s I.P. from the forbidden list, or add them to the allowed list.

·         * Requiring client certificates means extra setup on the client. I have seen plenty of 403.7 errors when the client uses a different browser or workstation that is not setup with a client certificate. Make sure that the client is using a browser on a workstation with the certificate installed in their personal store. Then, make sure they know how to select the certificate when prompted.

* On certain occasions I have seen admins limit the allowed connections. A 403.9 is what happens when that number is reached. To fix this you simply need to increase the maximum number of allowed connections, or remove the limit entirely. Remember, that is a property of the listener.


• The 403.16 happens when the issuing CA for client certs is not trusted by the ISA/TMG. Make sure that the ISA/TMG has the root CA of the client certificate’s chain installed as a trusted root CA, and that any intermediate CAs are also installed properly.

This guest post was provided by Ed Fischer on behalf of GFI Software Ltd. GFI is a leading software developer that provides a single source for network administrators to address their network security, content security and messaging needs. More information: GFI web filtering solution

All product and company names herein may be trademarks of their respective owners.

Post your questions, comments, feedbacks and suggestions

Related Topics

 

 

 

Bob Lin Photography services

Real Estate Photography services 

 

  This web is provided "AS IS" with no warranties.
Copyright © 2002-2017 ChicagoTech.net, All rights reserved. Unauthorized reproduction forbidden.