Booches.nl

Coolest Error Message so far

I just saw the coolest error message I have every seen on the Cisco Blog.

CHECK IT OUT NOW!!!

NetScaler CAG Customisation

I wanted to change the login screen of a NetScaler CAG, but I didn’t know which files to change. Luckily my college from DigiPulse and member of the Dutch Citrix User Group (DUCUG) gave me the solution by pointing me to the following blog post.

Hey mensen,

Op verzoek van Edwin Houben hieronder een overzicht van aanpassingen die ik heb gedaan om de website van https://vpn.azlnet.nl te maken zoals hij nu is:

Design van de site is aan te passen in deze bestanden:
- /netscaler/ns_gui/vpn/index.html  (taal aanpassingen)
- /netscaler/ns_gui/vpn/login.js  (taal aanpassing gemaakt en custom error page)
- /netscaler/ns_gui/vpn/nsshare.js    (layout aanpassingen voor "vakken")
- /netscaler/ns_gui/vpn/images/caxtonstyle.css   (style codes)

Let er wel op dat als je de pagina’s aanpast dat deze na een reboot weer terug gezet worden naar de oude (fabrieksinstellingen), dit kun je voorkomen door de volgende instructie aan te houden:

Copieer de aangepaste documenten naar /var/vpn/custom/vpn/ (ook de images directory als je eventueel nieuwe plaatjes hebt toegevoegd) en as het script /flash/nsconfig/rc.netscaler aan door onderstaand commando toe te voegen:- cp /var/vpn/custom/vpn/*.html /netscaler/ns_gui/vpn/
- cp /var/vpn/custom/vpn/images/* /netscaler/ns_gui/vpn/images

Hierdoor worden je wijzigingen wel meegenomen bij een reboot.

Mijn excuses voor de korte uitleg, als ik ooit tijd heb maak ik een nieuwe handleiding voor zowel de 8.1 als de 9.0 netscalers.

Mochten jullie toch nog vragen of problemen hebben plaats ze hier of mail me op ceriel@ceriel.net

RSA 7.1 with On-Demand

RSA token security provides a way to strengthen the security on public services. Token authentication is most often implemented with hardware tokens. RSA 7.1 has additional methods of token authentication besides the hardware tokens:

• Token delivery by SMS;
• Token delivery by e-mail;

To enable the above features you have to install at least RSA 7.1 and obtain a On-Demand license, like shown below:

Next I will show you how to configure token authentication for the delivery of tokens through SMS and e-mail. My test environment contains a RSA Authentication Manager 7.1 with RADIUS server installed on a Windows 2003 R2 server under VMware. The RSA server has a LDAP mapping to Active Directory for authenticating users.

E-MAIL

The first method explained is configuring RSA to deliver tokens to an e-mail address. The first step is configuring a SMTP server on the RSA server. In this scenario I create a SMTP connection to a Windows Exchange 2003 server. In the Security Console, navigate to Setup – Instances and edit the instance you would like to use for the SMTP connection.

In the SMTP setup you need to configure the Hostname of the SMTP server and a “from” e-mail address. Some SMTP servers require authentication to use them as relay server. If your SMTP server requires authentication you can configure the appropriate user credentials. In my situation I only need to deliver mail to the @booches.nl domain, so I don’t need to configure authentication or assign relay rights to the RSA server on the Exchange server. If you would like to deliver e-mail to domains outside your mail environment, you have to configure authentication or relay access for the RSA server.

After configuring the SMTP server you have to enable the ability to deliver token codes by e-mail. Navigate to Setup – Component Configuration – Authentication Manager – On-Demand Tokencodes in the Security Console. Enable the option “Delivery by E-mail” and choose the User Attribute to Provide E-mail Destination. This User Attribute is obtained by default through LDAP. In my scenario I use the e-mail field within Active Directory to obtain the specific e-mail address from a user.

From now on you can enable the usage of e-mail token delivery to your users. To accomplish this navigate to Identity – Users – Manage Existing and search for a specific user. Go to Security Tokens for the specific user and enable “On-Demand Tokencodes” and the specific settings, like shown in the picture. I configured an initial PIN for the user. The user should be able to obtain a token code through SMS via the Self-Service console. This portal can be reach via the URL: https://<ip address / FQDN RSA server>:7004/console-selfservice.

On-Demand token codes have a PIN code associated to the delivered token code. This PIN code is different from the PIN code of normal hardware tokens. I normally enable the On-Demand feature for a user and specify the first initial PIN code. After the user logs in with this PIN code, the PIN code needs to be changes. There are two ways of doing this:

1. The user automatically receives a new PIN code, which is generated by the RSA server;
2. The user has the option to manually specify a new PIN code;

Most often system engineers let the customers choose there own PIN code. Toggling between both settings is possible by changing the Token Policy. Changing the Token Policy is possible by navigating to Authentication – Policies – Token Policies.

SMS

To configure SMS token delivery you need some kind of method to send SMS messages. RSA and Clickatell have partnered to enable delivery of SecurID tokencodes to mobile devices via SMS/text. RSA Authentication 7.1 has a build-in method for delivering SMS messages through Clickatell. Click here to obtain more info about the partnership between RSA and Clickatell and how to register a (trial) Clickatell account.

The first step is to link a User Attribute from the Active Directory to RSA. This User Attribute contains the phone number for delivering the SMS. To such link navigate to Identity – Identity Attribute Definition – Add New.

Within Active Directory you can configure multiple Telephone numbers for a user. Because the SMS is sent to the users mobile phone, I enter the appropriate phone number under the mobile Telephone number of the users.

The picture shows how to configure the the User Attribute mapping. The Attribute Name is a user friendly name to identify the mapping. I choose Personal as Category and the Entry Type is optional. The users mobile phone number is displayed under Personal when editing the user.

The Identity Source Mapping defines the LDAP attribute to use for obtaining the mobile phone number from the user. This value has to be exactly the same as the LDAP value for the mobile phone number in Active Directory. I use Softerra’s LDAP browser to obtain this value from Active Directory. Softerra LDAP browser is a useful tool for browsing LDAP directories.

The configuration of the SMS service provider can be found under Setup – Component Configuration – Authentication Manager – On-Demand Tokencodes.

You need to enable the option “Delivery by SMS”, choose the previously configured User Attribute, select your country code and provide the credentials for your Service Provider.

You can now switch between token code delivery by e-mail and SMS. A user has the option to choose the preferred delivery method via the Self-Service console. Users need access to the Self-Service console to request a token code. The Self-Service portal needs to be securely published to the internet. This can be achieved by using a reverse proxy or some comparable solution. The following PDF contains a quick howto for publishing the RSA environment securely to the internet.

Blogging from my iPhone

From now on I can blog from my iPhone. I found a nice little app in the App Store called WordPress 2.0.

With this app you can create and edit your posts, comments and pages. I see it as little version of Windows Live Writer.

Ofcourse it isn’t the ideal way to write large and detailed blog posts, but ot is for small posts like this. WordPress 2.0 is also useful to start writing a post and save it as draft on your website for futher editting.

ISA 2006 Web Chaining

ISA Web Chaining rules define how traffic will be handled by the proxy server. Web request to specific destination can be handled in different ways by ISA:

1. Retrieve directly from the destination / internet;
2. Forward to an upstream proxy server;
3. Redirect the request to a specific server / web page;

The most popular use for Web Chaining is to chain branch office ISA firewalls with main office ISA firewalls. But also combining two ISP connections is a commonly used scenario for Web Chaining. I often use Web Chaining from ISA server with some kind of upstream proxy server. A lot of organizations use ISA as proxy server and some kind of dedicated appliance (maybe in DMZ environment) as content scanner.

With Web Chaining you can forward all request to the upstream proxy server, which will retrieve the specified destination from the internet. Specific website could have problems with being forwarded to the upstream server. I normally use Web Chaining to directly retrieve these website from the internet without being forwarded to the upstream proxy.

To create a Web Chaing Rule, open the ISA Management Console and navigate to Networks. In the center of the Management Console you will find a tab called Web Chaining. The default Web Chaining rule is configured to forward all request to an upstream proxy server.

The following screenshots tell you how to configure an additional Web Chaining rule to directly retrieve the destination (www.4ip.nl) from the internet.

	Start the creation of a Web Chaining rule by clicking on Task – Create new Web Chaining rule. This will start the New Web Chaining Rule Wizard. Enter a valid name for the newly created Web Chaining Rule.
	Select the destination to which this Web Chaining Rule will apply. I configured an URL set containing the URL: http://www.4ip.nl/*
	On the Request Action page, you configure how you want the Web requests to that particular destination routed by the ISA firewall. The default setting is to route the request directly to the destination Web site. This is exactly what I would like to accomplish. The last step is Finishing the New Web Chaining Rule Wizard.

The newly created Web Chaining Rule is placed above the Default Web Chaining rule in the Web Chaining tab. The rules are matched sequentially, so now all traffic matching the configured URL set will be retrieved directly from the internet. All other traffic will be forwarded to the upstream proxy server.