PinSafe is a form of multi-factor authentication which is easier to deploy and more cost effective than its token based competitors.  It also integrates seamlessly with the NetScaler for both SSL VPN and AAA for Web Applications.

It works by providing the user a customized "one time" image on the login page.  The image employs character rotation and will use a range of fonts and backgrounds to provide resistance to OCR attacks.  Contained within the image, is a security string which can be made up of numbers, characters or even a mixture of the two.   Place holders in the image help the user to extract their one-time image code.  So in the example below, a PIN of 4359 would yield a one-time code of 3125.

The default image has place holders to help the user extract the one-time code, but other, pattern based images can also be used.  The examples below show the numeric (eg telephone) keypad pattern as well as a more random pattern.  These images can even be branded for individual customers requirements.

For more information goto http://www.swivelsecure.com/

If you need to perform a search of a particular piece of data in the SUBJECT or ISSUER fields of a client's SSL certificate, the CONTAINS and NOCONTAINS Operators will serve you well.  However, if you want to be more granular in your approach, you will likely get frustrated by using the offset values of the Classic AppExpert Expression.

Problems occur when administrators rely on IE's reporting of the certificate values to determine the offset position within these fields rather than using openssl.  The reason you need to use openssl is because IE (and other browsers and operating systems) tend to incorrectly display the values of these parameters, messing up both the format and the order of the values.  So if you're going to set offsets, do NOT get your position information from IE!  Use openssl instead.

For example, take a look at my test certificate:

See how IE makes it look as if you should be reading this list (the top half) from left to right? Or (the bottom half) top to bottom?   Unfortunately, these are completely backwards.  Worse, there aren't any spaces or commas between the substrings.

So if you rely on what IE is telling you when you try to search in a specific location for "Rick.Davis@" you might use an offset of zero.  Or three.  But neither of those is correct.  OpenSSL will show you that the offset is actually 73!  

It's completely contrary to what you might expect because this is how the subject field is read by the NetScaler:
subject= /C=US/ST=Missouri/O=davis3.lab/OU=Access/CN=Rick.davis3.lab/emailAddress=Rick.Davis@davis3.lab

Proceedure

In order to accurately calculate the offset, you will need to use the openssl command.  Here's how:

1. Upload the client certificate to the NetScaler.
2. Use OpenSSL to view the SUBJECT or ISSUER fields from the NetScalers CLI: 

> shell
cd /flash/nsconfig/ssl
openssl x509 -noout -in client.cer -subject
subject= /C=US/ST=Missouri/O=davis3.lab/OU=Access/CN=Rick.davis3.lab/emailAddress=Rick.Davis@davis3.lab

The fields use ordinal numbering, so the first "/" character is number zero.  Here's the location map: 

/C=US/ST=Missouri/O=davis3.lab/OU=Access/CN=Rick.davis3.lab/emailAddress=Rick.Davis@davis3.lab
0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123
0         1         2         3         4         5         6         7         8         9

References

CTX116431 How to Create and Use Client Certificates on the NetScaler 

CLIENT.CERT
CLIENT.CERT.SUBJECT
CLIENT.CERT.ISSUER
CLIENT.CERT.SIGALGO
CLIENT.CERT.VERSION
CLIENT.CERT.VALIDFROM
CLIENT.CERT.VALIDTO
CLIENT.CERT.SERIALNUMBER
CLIENT.CIPHER.TYPE
CLIENT.CIPHER.BITS
CLIENT.SSL.VERSION 

Everyone should know by now that the NetScaler standard is the best practice for XenApp delivery.  So why do folks still see "Access Gateway" on the NetScaler's cool carbon fiber login page?

Do your prospects a favor and provide a consistent message that NetScaler is the solution they are testing! 

One small way you can address this is by changing the "Access Gateway" graphic in the VPN login page to read "NetScaler".   I bet you didn't even know Citrix already put the logo on the device, did you?

Proceedure

1. Log in to the command line interface using any of the available methods:
   1. Web GUI: System > Diagnostics > Command Line Interface
   2. Console port 
   3. SSH client
2. Issue the following commands:

> shell
# cp -r /netscaler/ns_gui/vpn/* /var/vpn/vpn
# cd /var/vpn/vpn/images
# mv ctxHeader01.gif ctxHeader01ForAGEE.gif
# cp ctxHeader01ForTM.gif ctxHeader01.gif

Notes

 Used NetScaler 9.0

A customer asked me to reduce the complexity of having both single and multi factor CAG login pages and create a more seamless access experience for users with and without RSA tokens.

Because the customer wants folks who have been issued a token to receive full VPN access and be directed to a custom Web Interface (WI) site tailored for elevated permissions, I had to use two CAG vips.  One for single factor authentication (access.company.com) and the other for multi-factor authentication (rsa.access.company.com)  Those who do not have a token, or do not have it readily available, can still log in and be attached to a different WI site with restricted application access.

To get the more seamless experience, I direct everyone to the single factor login page.  Then I presented a link to give RSA users an opportunity to plug in their RSA token values.  The problem though, is that all CAG vservers share the same HTML login page, so I had to insert the link programmatically by modifying the JavaScript so that it selectively inserts an html link based on which vserver the user is logged into.

While this may be sufficient for your use, please know you can further customize the HTML, JavaScript, and Style Sheet pages to conform to your vision of a seamless user experience.

Example Screen Shots

The Original CAG Login page:

The New page with RSA Token link:

If the user follows the link, the RSA token field is presented:

Proceedure

Edit file /netscaler/ns_gui/vpn/login.js as necessary:

function ns_showpwd()
{
 var pwc = ns_getcookie("pwcount");
 document.write('<TR><TD align=right style="padding-right:10px;"><SPAN class=CTXMSAM_LogonFont>Password');
 document.write(':</SPAN></TD>');
 document.write('<TD colspan=2 style="padding-right:8px;"><input class=CTXMSAM_ContentFont type="Password" title="Enter password" name="passwd" size="30" maxlength="32" style="width:100%;"></TD></TR>');
 if ( pwc == 2 ) {
 document.write('<TR><TD align=right style="padding-right:10px;"><SPAN class=CTXMSAM_LogonFont>RSA Token:</SPAN></TD><TD colspan=2 style="padding-right:8px;"><input class=CTXMSAM_ContentFont type="Password" title="Enter RSA Token" name="passwd1" size="30" maxlength="32" style="width:100%;"></TD></TR>');
 } else { document.write('<A href="https://rsa.access.company.com/">Click HERE if you have been issued an RSA token.</A>');}
 UnsetCookie("pwcount");
}

References

CTX115756 - How to Modify the Logon Form Field Labels

Notes

Used NetScaler 9.0

Both CAG vServers used the same wildcard SSL certificate.