Novell Access Manager - "Detected URL Tampering"

over 10 years ago


There are several reasons that cause the NAM to detect URL Tampering. Most often it is a name resolution issue stemming from improper DNS or HOSTS file configuration in your environment. Still, even with proper configuration your users may, appropriately, get this message. The reason may stem from users having become accustomed to using web server host or "short names" to access the web server/app before it was protected by Access Manager. If that is the case, this article will show you when and how you can configure NAM to allow "short name" access using the Virtual Mult-homing feature.


The detection of URL Tampering is a security feature in NAM. When detected, NAM denies user access to the URL. Instead users are presented with the following message:

While deploying NAM, you may have come across a situation where users try to use just the host "short name" for their web server URLs and instead must use the full DNS name including the domain name. Trying to use the short name (only the host portion of the DNS name) will result in a message from NAM indicating that "URL Tampering" has been detected and that the user access is Forbidden. What we need is a way to define multiple "host identifiers" / "Published DNS Names" for each proxy service in NAM. Given the right circumstances, this can be achieved through simple configuration using the Virtual Multi-homing feature in NAM. There are also other times that the Virtual Multi-homing feature is useful. See the NAM documentation for more information

There are several reasons that cause the NAM to detect URL Tampering. Most often it is simply related to improper DNS or HOSTS file configuration in your environment (See Novell TID: Access Manager URL Tampering Detected). Still, even with proper configuration your users may, and appropriately so, get this message because they are accustomed to using web server "short names" to access the web server/app before it was protected by Access Manager. This happens when the client workstation is configured with the same DNS domain as the web server. The workstation automatically appends the DNS domain to the host name during the name resolution process for the IP address. This seems like a nice convenience until you try to use HTTPS or need to stop this behavior due to security risks when all your users are accustomed to not typing full names. An obvious solution is to train your users to stop using short names and instead use fully distinguished names in their URLs. This will undoubtedly annoy your users and result in numerous help desk calls during the transition. As long as you do not need HTTPS to access the application, NAM's Virtual Multi-homing feature will allow your users to continue to use short names. This following example shows you how to do this.

Lets say we have a web server/application we will call Demo hosted inside the firewall. Demo is a simple PHP based web app hosted on Apache. The consumers of this application are employees so they will access it only from within the internal network. Without NAM, accessed the Demo application using the URL: http://demo/demo instead of its real and fully distinguished DNS name and path. After NAM is used to protect the Demo application users could no longer use this URL and instead had to used the full and proper URL for the web server as it was configured in NAM: To allow these users to continue to use http://demo/demo with a minimum of work, the Virtual Multi-homing feature in NAM provides a solution. An important caveat here is that note we have been using HTTP and not HTTPS. Using the Virtual Multi-homing feature will not allow the use of HTTPS because the SSL certificate will match only the primary published DNS name which is not an exact match for only the host / short name. So as long as you can use HTTP for your application you can employ this solution.

Building a typical Reverse Proxy in NAM for the Demo app is simple and like any other web app. Here is what our "demo" proxy service looks like:

From the above we see that we meet the pre-requisite of using HTTP ("Enable SSL between Browser and Access Gateway" is not enabled). Next we need to create an additional Proxy Service by clicking "New...". In the resulting dialog box fill in and select the appropriate values as shown in the following example:

Note that when you choose "Virtual" as your multi-homing type you are warned that SSL is not available in this mode.

After clicking OK you will have two proxy services defined: "demo" and "demo-short". Notice that our original "demo" proxy service included several "Protected Resource" configuration elements. Here is where I have some bad news and some good news. The bad news: since "demo-short" is independent of "demo", it policies are not inherited. So as not to bypass our policies, we need to be sure to apply the Protected Resource configuration from "demo" to "demo-short" - Yuk! The good news: this is easier to do than it sounds. Instead of applying the same set of policies to "demo", we can use a single Authorization Policy to redirect users from http://demo/demo to Now all your policies will be effective for both "demo" and "demo-short" and you will not have to maintain two sets of policies in synch. The Authorization Policy to do this is very simple and is displayed below:

Be sure to enable the above policy for all relevant paths on your "demo-short" proxy service.

The result will be a Proxy Service List like the following:

Next, "Update" your NAM configuration and test. Remember for this to work, the client workstation's DNS resolution configuration must be able to resolve "demo" to the correct IP address for your proxy service by auto-appending the DNS domain during name resolution.


How To-Best Practice
Comment List
Related Discussions