JasonSamuel.com » IIS

Getting around Netscaler Client IP issues without having to use USIP

Jason Samuel — Fri, 16 Jul 2010 21:58:01 +0000

If you work with Netscalers, you already know how SNIPs and MIPs work. They are the IPs that communicate with your servers. Every packet from the outside world that passes through the Netscaler will hit your server as though it was coming from this IP. This is the default behavior on a Netscaler.

Unfortunately if your servers require the client’s true IP address, all you will see for every client will be the SNIP or MIP address you are using. Here are a few examples I have personally had to deal with:

- IIS requires client IP for IIS logs
- IIS requires client IP for ACL filtering
- Web application requires client IP for it’s own logging purposes
- Web application requires cilent IP for authentication

Now to get around this for IIS, you can install ISAPI filters and set your Netscaler to use a custom header to store the true client IP address and pass that along with every packet. The ISAPI filter in IIS would look for this particular header and log that instead of the SNIP/MIP. There’s a very nice Client IP extraction ISAPI filter with some great instructions located on this page from Citrix or you can even write your own:

http://support.citrix.com/article/CTX119347

This is great for logging but sometimes your web application may grab the IP address from web server variables. To return the IP address of the host making the request, the server variable that your ASP, ASP.NET, and PHP code will call is “REMOTE_ADDR”. Unfortunately REMOTE_ADR is going to have your SNIP IP and not the client IP when passing through the Netscaler. The good news is that if you have control of your code, you can make it call from a different location that includes the client IP your ISAPI filter is passing. So if your code currently uses:

Request.ServerVariables(“REMOTE_ADDR”)

then switch it to:

Request.ServerVariables(“http_client_ip”)

where “http_client_ip” is the real client IP address and not the SNIP. Everything will work fine after that.

Here’s a nice snippet of code you can run on your web server and hit from your client browser to see what all the Netscaler is passing to the server:

NS SNIP or MIP IP address:
<%Response.Write(Request.ServerVariables(“remote_addr”))%>

The NS Inserted Client IP:
<%Response.Write(Request.ServerVariables(“http_Client_ip”))%>

Accept Encoding:
<%Response.Write(Request.ServerVariables(“HTTP_ACCEPT_ENCODING”))%>

Cookies:
<%Response.Write(Request.ServerVariables(“HTTP_COOKIE”))%>

(***Note, I apologize in advance if WordPress messes up the code block above. It usually changes the quotes in the code around so if you have issues with it, I will host a .txt file here with the code. Just comment to this post if you need it.)

This is all well and good when you have access to the code and can make this change but what about web apps that are 3rd party and you cannot modify the code? Well then you have no choice but to use the USIP (Use Source IP) feature on the Netscaler. What this does is pass the client IP straight through the Netscaler to your backend server so that the SNIP or MIP you are using on your Netscaler is never seen by the server (except for monitor probes from the Netscaler itself of course). This option is disabled by default. It can be applied to the entire Netscaler or turned on and off per service.

Best practice is not to use it and avoid it as much as possible. The reason is that using the USIP feature means you are going to lose very important features on the Netscaler such as connection multiplexing and surge protection. It’s always better to use the Client IP header insertion instead. In fact to date I have personally never enabled USIP in any environment I have built so far.

Here’s a very excellent and recent article from Citrix on the pros and cons of using USIP mode:

http://support.citrix.com/article/CTX121974

I hope this helps anyone trying to get around Client IP address related issues. Please feel free to post a comment on your own experiences or suggestions.

Getting around Netscaler Client IP issues without having to use USIP is a post from: JasonSamuel.com

More of my posts you might like:

How to get the IUSR and IWAM user account passwords on an IIS server

Jason Samuel — Wed, 28 Apr 2010 19:19:12 +0000

IIS uses the IUSR_servername guest account to allow anonymous access to websites hosted on the server. You can always change this to a different account or even change the password for this account yourself. But sometimes you might be in a situation where you can’t or don’t want to change the password but need to know what password Windows has set for it when you installed IIS.

Here’s how the IUSR account works by the way:

1. User types in http://www.yoursite.com

2. IIS gets the page request, imitates the IUSR_servername account, then executes/accesses the webpage located in your home directory using this account. It checks NTFS permissions and such during this time as well. Please note that the IUSR account has the “Log on Locally” permission by default to accomplish all this.

3. If everything goes well, authentication is completed and the requested page is sent back to the user’s browser. If something doesn’t go well, such as anonymous access is disabled or NTFS permissions to your root directory don’t included the IUSR account, the user will typically get an “HTTP 403 Access Denied” error message.

Anyhow, you can find the IUSR account password without having to reset it by using the Adsutil.vbs tool. Open up command prompt and navigate to C:\Inetpub\AdminScripts. Then type:

cscript.exe adsutil.vbs get w3svc/anonymoususerpass

cscript.exe adsutil.vbs get w3svc/wamuserpass

to display the IUSR and IWAM account passwords respectively. You will notice that the passwords are just a bunch of asterisks. To make them cleartext, navigate to C:\Inetpub\AdminScripts and edit Adsutil.vbs in Notepad. Find this line:

IsSecureProperty = True

and change it to:

IsSecureProperty = False

Now run the script commands above again and you will see the passwords in clear text. Make sure to put Adsutil.vbs back to the way it was because it’s not best practice in my opinion to leave your tool with clear text enabled.

Please note that with IIS 7, this has all changed:

1. The IUSR built-in account replaces the IUSR_Servername and IWAM_Servername accounts. It also no longer has a password since it is a local service account and not a user account so this blog post does not apply to IIS 7 at all.

2. The IIS_IUSRS built-in group replaces the IIS_WPG group (worker process group)

How to get the IUSR and IWAM user account passwords on an IIS server is a post from: JasonSamuel.com

More of my posts you might like:

Changing the host header for an already existing Sharepoint site/application

Jason Samuel — Tue, 11 Aug 2009 20:11:37 +0000

So let’s say you have http://originalurl and you want to change it to http://newurl. Don’t do it through IIS!!! Pretty much everything you will ever need to manage a Sharepoint farm will always be found in CA. Here’s how you accomplish this simple task:

1. Login to CA
2. Click the Operations tab
3. Click on “Alternate Access Mappings” under Global Configuration
4. In the top right, the default view is “Show All”. Just choose the web application you want to change.
5. Click Edit Public URLs and change the URL to whatever you want it to.

Done! Test it out and verify it works.

Changing the host header for an already existing Sharepoint site/application is a post from: JasonSamuel.com

More of my posts you might like:

Sharepoint Warmup Tool – Speed up your Sharepoint loading time

How to tell which w3wp.exe worker process belongs to what IIS application pool

Jason Samuel — Wed, 10 Jun 2009 17:08:54 +0000

Have you ever had an IIS worker process (w3wp.exe) that was taking up a lot of memory and wanted to know exactly which application pool it was tied to? Run this script located at C:\WINDOWS\system32 from command prompt:

cscript iisapp.vbs

This will tell you you the process ID of each worker process as well as the application pool ID it is running under. This can help troubleshoot exactly which website or application is causing the memory spike.

How to tell which w3wp.exe worker process belongs to what IIS application pool is a post from: JasonSamuel.com

More of my posts you might like:

SSL certificate chains explained

Jason Samuel — Thu, 12 Mar 2009 21:42:07 +0000

Today I would like to clear up some confusion about SSL Chained Certificates. For this example, I will use Network Solutions as the Certificate Authority (CA) you are buying the cert from. This is information you will have to know when you purchase a new SSL cert or renew an existing SSL cert for your Exchange server, IIS web server, or any other external facing server or appliance.

Network Solutions does not issue you a single cert. They issue you an SSL chained cert. So for example, if you are buying a cert for:

widgets.com

They will validate and issue you the cert, but when you download and open the zip file from their website, you will see the following certificate bundle:

AddTrustExternalCARoot.crt
NetworkSolutions_CA.crt
WIDGETS.COM.crt
UTNAddTrustServer_CA.crt

Let’s analyze these certs in your chain. The first one is AddTrustExternalCARoot.crt which is called the “root certificate”. This is the first cert in your chain. This root cert is installed to the Trusted Root Certification Authorities store on your server or network appliance.

The second cert in your chain is NetworkSolutions_CA.crt and the UTNAddTrustServer_CA.crt which are “intermediate certificates”. An intermediate cert is essentially a certificate issued by the Trusted Root CA specifically designed to issue SSL Certificates to you. The reason for this is because if the CA root cert were to ever be compromised, the entire chain fails. It is good security practice to use an “intermediary” to issue the certs from to prevent your root CAs from being exposed from the signing process. If an intermediate were to ever be compromised, you can always regenerate those unlike the root certs. This intermediate certificate sits between your website cert and the root cert. This intermediate cert is installed to the Intermediate Certification Authorities store on your server or appliance.

The last cert in your chain is WIDGETS.COM.crt which is your actual SSL cert. This is also known as your “domain certificate”. This domain cert is installed to the Personal store on your server or appliance.

So the end result is chain of certs that begins at the trusted root CA, runs through the intermediary, and finally ends with the SSL certificate issued to you for your website or appliance (widgets.com).

In most cases, any sever or appliance out there will already have the trusted root cert for Network Solutions installed. You can just install your SSL cert and not have to worry about anything else in most cases. Depending on where you buy your cert from and what you are trying to install your cert to, you may have to go through the steps of installing the Trusted Root cert and Intermediate cert first before installing your SSL cert. With some web browsers like Internet Explorer 7 for example, you can get away with not having to install any Intermediate Certificate because IE7 will automatically go out automatically download the intermediate cert the first time a user visits your website. This makes things easy for the lazy admin but it’s always best practice to go a head and add the Intermediate cert on your end instead of depending on the client and their browser’s ability to do this. There is no point in risking a certificate error for the end user when the fix is so easy.

To verify the chain, go to any site you know that uses SSL (https://) and then click on the lock in Internet Explorer, it will let you view the SSL cert info. Click the “Certificate Path” tab and you can see the chain we described above:

Trusted Root —> Intermediate —> SSL Certificate

You can then click on each one of these certs and hit the “View Cert” button to view each cert in the chain individually. Good luck and post a comment if you have any questions.

SSL certificate chains explained is a post from: JasonSamuel.com