There is often a need to access a certain resource protected by Access Manager by using more than one possible name. One example could be merging of two separate web sites into one, with some users used-to access the content with one name, and others with a different name.
Access Manager normally requires that you to set the "Published DNS Name" field in a Proxy Service configuration, so this Proxy Service only accepts requests for this one specific "official" DNS name. You can, however change this behaviour by unchecking the "Error on DNS Mismatch" check box, which tells Access Manager to allow access to the content behind this Proxy Server using any DNS name you want.
However, in a Domain based Multi-Homing configuration, the setting of "Error on DNS Mismatch" is not really effective, since Access Manager needs to KNOW what DNS name you are referring to in order to fetch the correct content via this Multi-Homed service.
This means that if we want to allow access using multiple DNS names to the same resource, we should create a proxy service for each of the desired DNS names.
However, if you need to be able to use multiple DNS names for the same web site, there are some shortcuts you can take.
For example, suppose you need access to the same web site using all of these possible names:
Let's first look at the first three alternatives; The easiest way to allow access to the same resource using all possible names is:
Create a Proxy Service with a Published DNS name of mySite.ecma.com.
Treat that Proxy Service as the only Proxy Service for this web site, and as such, create all relevant policies under this Proxy Service (Authorization, Form Fill, Identity Injection, etc.)
Now, create an additional Proxy Service for each of the other two names (myNewSite.ecma.com, myOtherName.ecma.com). The only reason we want these Proxy Services is that Access Manager will:
recognize the DNS name as a valid name
redirect the user to our "main" Proxy Service (mySite.ecma.com in this example)
So for each of these new Proxy Services, the only things you really need to fill in are:
- Published DNS Name
- Web Server List (fill in the exact list of back-end web servers you used in the "main" Proxy Service)
- A "dummy" protected resource with Public access
The "dummy" protected resource is just our mechanism for redirecting the user to the "main" Proxy Service.
Do that using an Authorization Policy that does (general form pseudo-code):
If URL Host equals "myNewSite.ecma.com"
Then Redirect to URL: "https://mySite.ecma.com"
That's the first part...
Next, we had another requirement in the above list of possible names, and that was "myNewSite". Just like that, without a proper DNS suffix.
There is a "limitation" with Access Manager, in that it enforces properly formatted DNS names for the Published DNS Name of a Proxy Service... This means we cannot take the path we took above in this case.
If we try to access one of the above Proxy Services using this name ("myNewSite"), Access Manager will return the famous 403 error with the "Host name received is not for this web site" description.
For example: if the user browsed to http://myNewSite, this code will redirect the browser to:
On the LAG server, go to the following directory:
First - backup the file we are about to modify:
Now edit the this file, and add the following code just below the <head> tag:
if ( hostStr.indexOf(".")== -1)
window.location = hostStr+domainSuffix;
Change the value of the domainSuffix variable to match the desired domain name.
Save the file, and restart the relevant NAM services:
Some final notes:
- It is possible that future Access Manager Service Packs will install new or updated error page template files, like the one we have just edited. However, the current mechanism for installing patches on LAG, first backs-up the existing files under /var/novell/errorpagesconfig/current (it copies them to the /var/novell/errorpagesconfig/.backup directory) - so you can see and copy from the backup to the new error page templates.
- This solution applies to NAM 3.0 SP3 and above. Note that versions prior to SP3 did not use Error page HTML templates, so this solution does not apply in such cases.
Disclaimer: As with everything else at Cool Solutions, this content is definitely not supported by Novell (so don't even think of calling Support if you try something and it blows up).
It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test, test, test before you do anything drastic with it.