Sei sulla pagina 1di 111

611: NetScaler is the Gatekeeper. Become the Keymaster.

Hands-on Lab Exercise Guide

Christopher Rudolph

May 2015

Table of Contents

Table of Contents

2

Overview

3

Lab Preparation

6

Exercise 1: Initial Device Configuration

8

Exercise 2: Client-Side Authentication

11

Exercise 3: Preventing Brute-Force Password Attacks

28

Exercise 4: Authentication Profiles

31

Exercise

5: Authorization Policies

53

Exercise 6: Traffic vs. Session Policies

61

Exercise 7: Server-side SSO using NTLM and Form-Based Authentication

84

Exercise 8: SAML Client-Side Authentication

98

Overview

Hands-on Training Module

Objective

Multiple authentication mechanisms and different standards are proliferating in today's enterprises. Multiple logins, different credentials and different requirements make authentication one of the biggest challenges when deploying new applications. In this lab, attendees will learn how to use Citrix NetScaler to provide single-sign on services to common web applications with differing authentication mechanisms.

Prerequisites

Basic NetScaler administration experience.

Audience

Citrix Partners, Customers, Sales Engineers, Consultants, Technical Support.

Lab Environment Details

Consultants, Technical Support. Lab Environment Details The Student Desktop is accessed remotely using Citrix

The Student Desktop is accessed remotely using Citrix Receiver running on your laptop. All Windows applications such as the XenCenter (the XenServer GUI management tool), are accessed from the Student Desktop.

Lab Guide Conventions

This symbol indicates particular attention must be paid to this step

This symbol indicates particular attention must be paid to this step

Special note to offer advice or background information

Special note to offer advice or background information

reboot

Text the student enters or an item they select from a dropdown menu is printed like this

VMDemo

Filename mentioned in text or lines added to files during editing

Start

Bold text indicates reference to a button or object

Focuses attention on a particular part of the screen (R:255 G:20 B:147)

Focuses attention on a particular part of the screen (R:255 G:20 B:147)

Shows where to click or select an item on a screen shot (R:255 G:102 B:0)

Shows where to click or select an item on a screen shot (R:255 G:102 B:0)

List of Virtual Machines Used

VM Name

IP Address

Description / OS

AD.training.lab

192.168.10.11

Windows Server 2012 R2 Domain Controller/Certificate Authority/DNS

Apache

192.168.10.15

Debian 6.0 Apache Web Server

Exchange

192.168.10.25

Windows Server 2008 R2 Exchange 2010/OWA

NS_VPX_1

192.168.10.50

NetScaler VPX 3000 NetScaler 10.5 (Build 55.8)

NS_VPX_2

192.168.10.55

NetScaler VPX 3000 NetScaler 10.5 (Build 55.8)

Sharepoint

192.168.10.20

Windows Server 2008 R2 Sharepoint 2010 Foundations

SQLServer

192.168.10.12

Windows Server 2012 R2 MS SQL

Required Lab Credentials

The credentials required to connect to the environment and complete the lab exercises are shown within the step by step instructions and are summarized below:

VM Name

Username

Password

Description

AD.training.lab

Administrator

Citrix123

Domain Controller/Certificate Authority/DNS

NS_VPX_1

nsroot

nsroot

NetScaler VPX

NS_VPX_2

nsroot

nsroot

NetScaler VPX

Reserved IP Ranges

IP range

Description

192.168.10.60 - 192.168.10.100

NetScaler Virtual IP Range

List of DNS Entries

DNS Entry

IP Address

Corresponding VM

ad.training.lab

192.168.10.11

Active Directory Domain Controller

sqlserver.training.lab

192.168.10.12

Microsoft SQL Server

sp.training.lab

192.168.10.20

Microsoft Sharepoint 2010 Server

exchange.training.lab

192.168.10.25

Microsoft Exchange 2010 Server

ns1.training.lab

192.168.10.50

NetScaler VPX 1

ns2.training.lab

192.168.10.55

NetScaler VPX 2

apache.training.lab

192.168.10.60

NetScaler Load Balanced Virtual Server

apache2.training.lab

192.168.10.61

NetScaler Load Balanced Virtual Server

cs.training.lab

192.168.10.62

NetScaler Content Switching Virtual Server

sharepoint.training.lab

192.168.10.63

NetScaler Load Balanced Virtual Server

apache3.training.lab

192.168.10.65

NetScaler Load Balanced Virtual Server

aaa-df.training.lab

192.168.10.70

NetScaler AAA Virtual Server

aaa-sf.training.lab

192.168.10.71

NetScaler AAA Virtual Server

aaa-saml-sp.training.lab

192.168.10.72

NetScaler AAA Virtual Server

aaa-saml-idp.training.lab

192.168.10.73

NetScaler AAA Virtual Server

Lab Preparation

Attach XenCenter to Your XenServer

Overview

XenCenter is a graphical user interface application used for managing one or more XenServers. You will be using XenCenter to manage the XenServer needed for the lab.

Step by step guidance

Step Action 1. XenCenter will automatically launch when the Student Desktop launches. 2. Click Add
Step
Action
1.
XenCenter will automatically launch when the Student Desktop launches.
2.
Click Add Server to add your physical XenServer to XenCenter.

Step

3.

4.

Action

Enter your physical XenServer parameters from your welcome screen.

IP Address

192.168.10.5

Username

admin

Password

Your XenServer password

Username admin Password Your XenServer password Click Add. You may find it easier to copy and

Click Add.

admin Password Your XenServer password Click Add. You may find it easier to copy and paste
You may find it easier to copy and paste the password to ensure it is
You may find it easier to copy
and paste the password to
ensure it is entered correctly.
Your Physical XenServer name will be different.
Your Physical XenServer name will be different.

XenCenter will attach to your physical XenServer.

Summary

You have logged on to the lab environment and attached your XenServer to XenCenter.

Exercise 1: Initial Device Configuration

Overview

In this exercise, we will enable the required features and add a DNS suffix used throughout the lab exercises.

Step by step guidance

Estimated time to complete this exercise: 5 minutes.

Step Action 1. Open Google Chrome and navigate to the NetScaler Administration UI using the
Step
Action
1.
Open Google Chrome and navigate to the NetScaler Administration UI using the
NS_VPX_1 shortcut on the shortcut bar.
Log on using the default credentials:
User Name: nsroot
Password: nsroot

Step

Action

2.

First, you are going to need to enable the features that we are going to use for this lab. Navigate to System > Settings and click Configure Basic Features.

Check the box next to the following features: SSL Offloading, Load Balancing, Rewrite, Authentication, Authorization, and Auditing, and Content Switching. Then click OK.

and Auditing , and Content Switching . Then click OK . 3. Next, you are going

3.

Next, you are going to add a DNS suffix for the training.lab domain to the NetScaler.

Navigate to: Traffic Management > DNS > DNS Suffix and click Add.

Type training.lab in the DNS Suffix field and click Create.

Management > DNS > DNS Suffix and click Add . Type training.lab in the DNS Suffix

Step

Action

4.

Save the NetScaler configuration by clicking the Save icon in the top right corner of the GUI.

configuration by clicking the Save icon in the top right corner of the GUI. Then click

Then click Yes at the Confirm prompt.

configuration by clicking the Save icon in the top right corner of the GUI. Then click

Exercise Summary

We just completed the initial device configuration and enabled the necessary features used in this lab. We are ready to begin exploring the Traffic Management AAA functionality available in NetScaler 10.5.

Exercise 2: Client-Side Authentication

Overview

In this exercise, we will configure single and dual factor client side authentication using the TM-AAA feature of the NetScaler appliance. We will explore how to setup an LDAP, Local, and Certificate authentication policy and verify how the NetScaler appli ance processes keeps track of the user sessions.

We will start slow and with the basics. If this is too basic, don’t worry, this will get more interesting as we go along.

Step by step guidance

Estimated time to complete this exercise: 20 minutes.

Step Action 1. First, create the necessary load-balancing configuration for the sample web applications we
Step
Action
1.
First, create the necessary load-balancing configuration for the sample web applications we will
use in the lab.
While still logged on to the NetScaler GUI, navigate to Traffic Management > Load Balancing
> Servers and then click Add.
Enter the following parameters for the web server and then click Create.
Server Name: apache
IP Address: 192.168.10.15

Step

Action

2.

Next, you are going to create the services for the servers that were just added to the NetScaler.

Navigate to Traffic Management > Load Balancing > Services and then click Add.

Create a new service using the following information and then click OK:

Service Name: svc_apache Existing Server: apache (192.168.10.15) Protocol: HTTP Port: 80

OK : Service Name: svc_apache Existing Server: apache (192.168.10.15) Protocol: HTTP Port: 80 Then click Done

Then click Done.

OK : Service Name: svc_apache Existing Server: apache (192.168.10.15) Protocol: HTTP Port: 80 Then click Done
Step Action 3. Then create the load-balancing virtual server. Navigate to Traffic Management > Load
Step
Action
3.
Then create the load-balancing virtual server. Navigate to Traffic Management > Load
Balancing > Virtual Servers and then click Add.
Create a new virtual server using the following parameters and click OK:
Name: lb_vsrv_apache
Protocol: HTTP (default)
IP Address: 192.168.10.60
Port: 80 (default)

Step

Action

4.

Click No Load Balancing Virtual Server Service Binding to add the services.

Virtual Server Service Binding to add the services. Under Service Binding, click Click to select .

Under Service Binding, click Click to select.

services. Under Service Binding, click Click to select . Check the box next to svc_apache and

Check the box next to svc_apache and click OK.

Click to select . Check the box next to svc_apache and click OK . Click Bind,

Click Bind, click OK, and then click Done.

Step

Action

5.

Save the NetScaler configuration by clicking the Save icon in the top right corner of the GUI.

clicking the Save icon in the top right corner of the GUI. Then click Yes at

Then click Yes at the Confirm prompt.

corner of the GUI. Then click Yes at the Confirm prompt. 6. Next, we are going

6.

Next, we are going to inspect the HTTP request/response headers to see what type of authentication the application is requesting. Open a Firefox browser window and click on the HTTP header viewer tool: LiveHTTPHeaders.

and click on the HTTP header viewer tool: LiveHTTPHeaders . The LiveHTTPHeaders plugin window will appear.

The LiveHTTPHeaders plugin window will appear.

7.

In the new browser tab, type the URL for the web application that is being load-balanced by the NetScaler: http://apache.training.lab/phpmyadmin. This FQDN resolves to the virtual IP. You should get prompted for authentication. This prompt comes from the web application.

FQDN resolves to the virtual IP. You should get prompted for authentication. This prompt comes from
Step Action 8. In the LiveHTTPHeaders window, check the request and response headers. Look for
Step
Action
8.
In the LiveHTTPHeaders window, check the request and response headers. Look for the type of
authentication requested by the website:
In the 401 response, the WWW-Authenticate header defines the type of authentication
required by the server, in this case it is just Basic authentication.
9.
Fill out the credentials fields. After successful log on, you should have access to the webpage.
Username: user1
Password: Citrix123
After logging on to the phpMyAdmin web application, close the Firefox window.
Basic authentication uses a base64 encoded string to represent the username and password
separated by a “:”. Anyone sniffing the wire can get access to the user’s credentials. In order to
secure the authentication process, either use SSL in combination with a stronger authentication
scheme.
To protect our application, we will use dual factor authentication using LDAP and LOCAL.

Step

Action

10.

Let’s create our LDAP configuration to authenticate the user against the Active Directory service.

Return to the NetScaler configuration utility and navigate to:

Security > AAA Application Traffic > Policies > Authentication > Basic Policies > LDAP.

Select the Servers tab and click Add.

> LDAP . Select the Servers tab and click Add . Create a new server profile

Create a new server profile using the following parameters:

Name: AD.training.lab

Server IP: Selected

IP Address: 192.168.10.11

Port: 389 Type: AD (default) Security Type: PLAINTEXT

Base DN: dc=training,dc=lab Administration Bind DN: administrator@training.lab

BindDN Password: Checked Administrator Password: Citrix123 Confirm Administrator Password: Citrix123 Server Logon Name Attribute: sAMAccountName Group Attribute: memberOf Sub Attribute Name: cn SSO Name Attribute: Select <<New>> then type sAMAccountName Authentication: Checked User Required: Checked

Click Create.

11.

Select the Policies tab. Click Add and congire the policy using the following parameters:

Name: LDAP_training

Server: AD.training.lab Expression: ns_true

Step

Action

12.

Now, let’s define the Local configuration.

Navigate to: Security > AAA Application Traffic > Policies > Authentication > Basic Policies > Local.

Click Add.

> Basic Policies > Local . Click Add . Name : LOCAL_training Expression: ns_true Click Create

Name: LOCAL_training

Expression: ns_true

Click Create.

13.

Now, we are going to create the AAA virtual server. Navigate to: Security > AAA Application Traffic > Virtual Servers. Click Add.

Application Traffic > Virtual Servers . Click Add . 14. In the create virtual server window,

14.

In the create virtual server window, use the following information:

Name: aaa-df-vs IP Address: 192.168.10.70

create virtual server window, use the following information: Name : aaa-df-vs IP Address : 192.168.10.70 Click

Click OK.

Step Action 15. Under Certificates, click No Server Certificate. Click Click to Select. Then select
Step
Action
15.
Under Certificates, click No Server Certificate.
Click Click to Select. Then select wildcard.training.lab.
Click OK, click Bind, and then click Continue twice.

Step

Action

16.

Click the + icon under Basic Authentication Policies.

Click the + icon under Basic Authentication Policies. Click Continue . Click Click to Select and

Click Continue.

icon under Basic Authentication Policies. Click Continue . Click Click to Select and then select LOCAL_training

Click Click to Select and then select LOCAL_training, then click OK and then click Bind.

Click Continue . Click Click to Select and then select LOCAL_training , then click OK and

Step

Action

 

17.

Click the + icon under Basic Authentication Policies again.

 

Select LDAP from the Choose Policy drop-down list box and then select Secondary from the Choose Type drop-down list box and click Continue.

the Choose Type drop-down list box and click Continue .   18. Click Click to Select
 

18.

Click Click to Select and then select LDAP_training, then click OK and then click Bind.

 
 

Click Continue and then click Done.

   

The reason we bound a Local policy as the primary and LDAP as the secondary is to prevent account lockout attacks. Since Local is usually used for OTP (one time password) authentication mechanisms, this protects the Active Directory account from any account lockouts that might occur from repeated authentication attempts.

 
 

19.

Now we need to enable authentication at the Load Balancing Virtual Server level.

 

Navigate to Traffic Management > Load Balancing > Virtual Servers.

Select lb_vsrv_apache and click Edit.

Navigate to Traffic Management > Load Balancing > Virtual Servers . Select lb_vsrv_apache and click Edit

Step

Action

20.

Click Authentication from the Advanced column on the right side of the window.

from the Advanced column on the right side of the window. Select Form Based Authentication ,

Select Form Based Authentication, type aaa-df.training.lab in the Authentication FQDN field and then select aaa-df-vs from the Authentication Virtual Server drop-down list box. Click OK then click Done.

field and then select aaa-df-vs from the Authentication Virtual Server drop-down list box. Click OK then

Step

Action

21.

Open a new Firefox window and navigate to: http://apache.training.lab/phpmyadmin

You should get automatically redirected to the AAA virtual server authentication page.

22.

Enter the following credentials:

Username: user1 Password 1: Citrix123 Password 2: Citrix123

Click Log On.

1 : Citrix123 Password 2 : Citrix123 Click Log On . If authentication passes these two

If authentication passes these two sources, you should be prompted for additional credentials.

sources, you should be prompted for additional credentials. This is being requested directly by the application.

This is being requested directly by the application. Ideally, the NetScaler appliance will be able to submit the necessary credentials to Single Sign-On to this application on behalf of the user. That is what we are going to do next!

Step

Action

23.

To verify that the user has access to the application, enter the user1 credentials.

Username: user1 Password: Citrix123

Close Firefox.

24.

We will now create a session policy to enable SSO. In a session policy, we can determine certain parameters that apply to the user session.

In the NetScaler configuration utility, navigate to:

Security > AAA Application Traffic > Policies > Session and then click Add.

Name the policy SSO_webapps and use an ns_true expression.

the policy SSO_webapps and use an ns_true expression. Click the + button next to Request Profile

Click the + button next to Request Profile to create a new Request Profile.

Step

Action

25.

Name the profile SSO_profile and enable the following options:

Single Sign-on to Web Applications: Checked Credential Index: Primary HTTPOnly Cookie: YES

: Checked Credential Index : Primary HTTPOnly Cookie : YES Click Create twice. 26. Now, bind
: Checked Credential Index : Primary HTTPOnly Cookie : YES Click Create twice. 26. Now, bind

Click Create twice.

26.

Now, bind the session policy to the AAA virtual server. Navigate to:

Security > AAA Application Traffic > Virtual Servers

Select the aaa-df-vs virtual server and click Edit.

Step

Action

27.

Click on the Policies button in the right column under Advanced.

on the Policies button in the right column under Advanced. Click the + button under Policies,

Click the + button under Policies, then select Session from the Choose Policy drop-down list box and then click Continue.

Choose Policy drop-down list box and then click Continue . Click Click to select , select

Click Click to select, select SSO_webapps and then click OK and then click Bind.

click Continue . Click Click to select , select SSO_webapps and then click OK and then

Click Done.

Step

Action

 

28.

Open a new Firefox window and navigate to http://apache.training.lab/phpmyadmin. You will be redirected to the AAA vserver. Enter the user credentials at the login page.

 

User name: user1 Password 1: Citrix123 Password 2: Citrix123

Click Log On.

   

You should not receive any prompt for additional credentials. Since the NetScaler is handling the SSO, it automatically responds to the 401 Unauthorized request with the necessary information the application is requesting.

 
 

29.

Close the Firefox browser window

 

Save the NetScaler configuration by clicking the Save icon in the top right corner of the GUI.

clicking the Save icon in the top right corner of the GUI. Then click Yes at

Then click Yes at the Confirm prompt.

corner of the GUI. Then click Yes at the Confirm prompt. Congratulations! You have configured Basic

Congratulations! You have configured Basic HTTP Authentication single sign-on. Continue to the next exercise.

Exercise Summary

In this exercise, we have configured a single and dual factor authentication with group extraction. We also configured a simple session policy to perform Basic HTTP authentication single si gn-on to web applications. In the next exercise, we will explore some of the protection features to prevent brute force password attacks and how to leverage the AAA NetScaler framework to protect your application.

Exercise 3: Preventing Brute-Force Password Attacks

Overview

In this exercise, we will configure the new AAA parameters to slow down any brute-force password attacks.

Step by step guidance

Estimated time to complete this exercise: 10 minutes.

Step

Action

1.

One of the AAA features in the NetScaler is the ability to define the maximum number of login attempts as well as a lockout timeout feature.

While logged on to the NetScaler GUI, navigate to Security > AAA Application Traffic > Virtual Servers.

Select the aaa-df-vs virtual server and click Edit.

2.

In the Basic Settings pane, click the pencil icon to edit the parameters of the virtual server.

pencil icon to edit the parameters of the virtual server. Define the Max Login Attempts. In

Define the Max Login Attempts. In this example we will allow up to 3 login attempts.

In this example we will allow up to 3 login attempts. 3. In the Failed Login

3.

In the Failed Login Timeout parameter, set it to 1. This will prevent any authentication requests from the same user within the next 60 seconds of the last failed attempt.

Click OK. Then click Continue three times, and then click Done.

Step

Action

4.

Open a new Firefox window and browse to http://apache.training.lab/phpmyadmin.

You should be redirected to the AAA virtual server login page. Enter the wrong credentials three times.

User name: user1 Password 1: 123 Password 2: 123

Click Log On.

5.

At this point, the account has been temporarily locked out. Now, enter the incorrect user credentials one more time. You should receive a message stating that you have exceeded the maximum number of attempts. Verify that this is the case.

maximum number of attempts. Verify that this is the case. 6. Close Firefox and reopen it.

6.

Close Firefox and reopen it. Browse to http://apache.training.lab/phpmyadmin and attempt to log on as user2:

User name: user2 Password 1: Citrix123 Password 2: Citrix123

You should be able to log on to the web application.

7.

Close Firefox. After the 60 seconds have elapsed, reopen Firefox and browse again to http://apache.training.lab/phpmyadmin. You should be able to log on using the user1 credentials at this point. Verify that this is the case and then close Firefox.

Step

Action

8.

Save the NetScaler configuration by clicking the Save icon in the top right corner of the GUI.

clicking the Save icon in the top right corner of the GUI. Then click Yes at

Then click Yes at the Confirm prompt.

corner of the GUI. Then click Yes at the Confirm prompt. 9. Congratulations! You have configured

9.

Congratulations! You have configured a simple account lockout mechanism using NetScaler. Continue to the next exercise.

Exercise Summary

We have learned how to configure the account protection features and lockout timeouts for an authentication virtual server. Next we will explore the new authentication profile feature and how to leverage it to further customize access to your application.

Exercise 4: Authentication Profiles

Overview

Authentication Profiles is a new feature introduced in NetScaler 10.x. In the past, there was a single authentication cookie assigned for each user session. As long as the client browser presented such cookie when contacting the NetScaler appliance, SSO was honored and the user was not prompted for credentials. With the introduction of authentication profiles, it is now possible to segregate authentication cookies per domain or virtual server. In this exercise, we will configure a simple policy that illustrates the usage of authentication profiles. This knowledge can be applied to other use cases according to your requirements.

Step by step guidance

Estimated time to complete this exercise: 20 minutes.

Step Action In order to illustrate authentication profiles, let’s first illustrate the problem. For this,
Step
Action
In order to illustrate authentication profiles, let’s first illustrate the problem. For this, we will
create another virtual server and enable it for AAA authentication.
1.
Navigate to Traffic Management > Load Balancing > Virtual Servers and click Add.

Step

Action

2.

In the Create Virtual Server window, enter the following parameters:

Name: lb_vsrv_apache2

Protocol: HTTP

IP address: 192.168.10.61

Port: 80

Click OK.

HTTP IP address: 192.168.10.61 Port: 80 Click OK. 3. Click No Load Balancing Virtual Server Service

3.

Click No Load Balancing Virtual Server Service Binding to add the services. Click Click to select. Check the box next to svc_apache and click OK.

the services. Click Click to select . Check the box next to svc_apache and click OK

Click Bind and then click OK.

Step

Action

4.

Click Authentication from the Advanced column on the right side of the window.

from the Advanced column on the right side of the window. Select Form Based Authentication ,

Select Form Based Authentication, type aaa-df.training.lab in the Authentication FQDN field and then select aaa-df-vs from the Authentication Virtual Server drop-down list box. Click OK.

and then select aaa-df-vs from the Authentication Virtual Server drop-down list box. Click OK . Then

Then click Done.

Step

 

Action

5.

Since we are using the same backend service, we will access a new web application hosted on the same server. Open a new Firefox browser window and browse to this new virtual server address:

 

6.

You should have been redirected to the AAA login page. Log on using the following credentials:

 

User name: user1 Password 1: Citrix123 Password 2: Citrix123

 

At this point, you have authenticated with the appliance and redirected to the SugarCRM

application login form. We will configure form-based SSO in a later exercise. For now, let’s just

focus on the face that you have already authenticated with the AAA virtual server and the session cookie has been created. Unfortunately, this cookie is used globally for any virtual server configured for AAA authentication.

7.

From the same browser session, open a new tab and attempt to navigate to the first web- application FQDN: http://apache.training.lab/phpmyadmin.

 

Since the authentication cookie is globally valid, the user is logged on to the first web-application without any credential prompt, even when login through a different virtual server.

Close the Firefox browser window.

8.

Now, let’s assume that you would like to use the same TM-AAA virtual server, but prevent users from navigating to other virtual servers without proper authentication. For this we will use authentication profiles.

 

In the NetScaler configuration utility, navigate to Security > AAA Application Traffic > Authentication Profile.

 

Click Add.

 
 

Step

9.

Action

We will create two profiles, one for each virtual server (or group of virtual servers) where we want to segment authentication.

Use the following information to create the two authentication profiles:

 

Profile 1

Profile 2

Name

apache_profile

apache2_profile

Authentication VServer Name

aaa-df-vs

aaa-df-vs

Authentication Host

aaa-df.training.lab

aaa-df.training.lab

Click Create after each profile.

aaa-df-vs Authentication Host aaa-df.training.lab aaa-df.training.lab Click Create after each profile.
aaa-df-vs Authentication Host aaa-df.training.lab aaa-df.training.lab Click Create after each profile.

Step

Action

10.

Navigate to Traffic Management > Load Balancing > Virtual Servers and select lb_vsrv_apache then click Edit.

Under Authentication, click the pencil icon to edit the authentication parameters.

click the pencil icon to edit the authentication parameters. Under Authentication Profile, select apache_profile and

Under Authentication Profile, select apache_profile and then click OK. Then click Done.

apache_profile and then click OK . Then click Done . 11. Repeat the same process with

11.

Repeat the same process with lb_vsrv_apache2 using apache2_profile.

12.

Open a new Firefox window and browse to the first virtual server:

Log on using the following credentials:

User name: user1 Password1: Citrix123 Password2: Citrix123

You should see the protected area webpage.

13.

Open a new tab in Firefox and browse to the second virtual server:

Step

Action

14.

Since we are now using a different AAA cookie for each virtual server using the selected authentication profile, you are now prompted for credentials. Login with a different user account.

User name: user2 Password 1: Citrix123 Password 2: Citrix123

After successfully logging on and seeing the SugarCRM logon screen, close Firefox

 

Now, let’s build a more compelling use case for the usage of authentication profiles.

 

Imagine that you have to implement different authentication mechanisms for the different applications

and restrict access based on group membership.

Application 1 requires dual-factor authentication and application 2 requires single-factor.

In addition, users of the contractors group are only authorized to access application 1. Users of the sales

group are only authorized to access application 2.

All access to these applications is done over a single externally accessible FQDN.

To satisfy these requirements, we will build another AAA virtual server with only single factor

authentication and modify our authentication profile and virtual server configuration to complete the

implementation.

15.

Since we have to support both applications through the same FQDN, we need to perform Content Switching based on the application virtual directory.

Return to the NetScaler configuration utility and navigate to Traffic Management > Content Switching > Virtual Servers. Click Add.

configuration utility and navigate to Traffic Management > Content Switching > Virtual Servers . Click Add
Step Action 16. In the Create Virtual Server window, enter the following parameters: Name: cs1
Step
Action
16.
In the Create Virtual Server window, enter the following parameters:
Name: cs1
Protocol: HTTP
IP Address: 192.168.10.62
Port: 80
Click OK.

Step

Action

17.

Under CS Policy Bound, click No Content Switching Policy Bound.

CS Policy Bound, click No Content Switching Policy Bound . Next to Select Policy, click the

Next to Select Policy, click the + button to create a new Content Switching policy.

No Content Switching Policy Bound . Next to Select Policy, click the + button to create
Step Action 18. In the Create Content Switching Policy pane, name the policy phpmyadmin and
Step
Action
18.
In the Create Content Switching Policy pane, name the policy phpmyadmin and then enter the
following expression into the Expression window:
HTTP.REQ.URL.STARTSWITH(“/phpmyadmin”)
Then click Create.

Step

Action

19.

You are now back on the Policy Binding screen. In the Target Load Balancing Virtual Server box, click Click to select.

Load Balancing Virtual Server box, click Click to select . Select the radio button next to

Select the radio button next to lb_vsrv_apache and click OK. Then click Bind.

20.

Under CS Policy Bound, click 1 Content Switching Policy and then click Add Binding.

1 Content Switching Policy and then click Add Binding . Next to Select Policy, click the

Next to Select Policy, click the + button to create a new CS policy.

Step

Action

21.

In the Create Content Switching Policy pane, name the policy sugarcrm and then enter the following expression into the Expression window:

HTTP.REQ.URL.STARTSWITH(“/sugarcrm”)

Then click Create.

Then click Create . 22. You are now back on the Policy Binding screen. In the

22.

You are now back on the Policy Binding screen. In the Target Load Balancing Virtual Server box, click Click to select.

Select the radio button next to lb_vsrv_apache2 and click OK. Then click Bind and then click Close.

Click OK and then click Done to complete the creation of the CS virtual server.

We will come back to this virtual server, as we need to create more Content Switching policies in order to get the correct authentication information sent to the corresponding target virtual server.

23.

Next, we need to create an additional virtual server for single-factor authentication.

Navigate to Security > AAA Application Traffic > Virtual Servers and click Add.

Step

Action

24.

Create a new virtual server using the following parameters:

Name: aaa-sf-vs IP Address: 192.168.10.71

parameters: Name : aaa-sf-vs IP Address : 192.168.10.71 Click OK . 25. Under Certificates, click No

Click OK.

25.

Under Certificates, click No Server Certificate.

Click Click to Select. Then select wildcard.training.lab and click OK.

Click Bind and then click Continue twice.

26.

Click the + icon under Basic Authentication Policies again.

Select LDAP from the Choose Policy drop-down list box and then select Primary from the Choose Type drop-down list box and click Continue.

Choose Policy drop-down list box and then select Primary from the Choose Type drop-down list box

Step

Action

27.

Under Policy Binding, click Click to select. Then select the radio button next to LDAP_training and click OK and then click Bind.

to LDAP_training and click OK and then click Bind . Click Continue . 28. Under Advanced,

Click Continue.

28.

Under Advanced, click Policies. Then click the + icon in the new Policies pane that displays.

click the + icon in the new Policies pane that displays. Select Session from the Choose

Select Session from the Choose Policy drop-down list box and click Continue.

Under Policy Binding, click Click to select. Select the radio box next to SSO_webapps and click OK.

Click Bind and then click Done.

Step Action 29. Next, we need to modify the authentication profile we configured in a
Step
Action
29.
Next, we need to modify the authentication profile we configured in a previous step to setup up the
second virtual server for single factor authentication.
Navigate to Security > AAA – Application Traffic > Authentication Profiles. Click on the
apache2_profile and click Edit.
Step Action 30. Change the values to point to the new FQDN and AAA virtual
Step
Action
30.
Change the values to point to the new FQDN and AAA virtual server:
Authentication Vserver Name: aaa-sf-vs
Authentication Host: aaa-sf.training.lab
Authentication Level: 1
Make sure the authentication level is set to 1 to force the NetScaler to prompt for credentials when
navigating to an application set to authenticate with this profile.

Step

Action

31.

We are not quite finished yet as there are other request and responses we need to divert to the correct target virtual server in order for the entire authentication process to work.

To illustrate what needs to be done, open a new Firefox window and navigate to

You should be redirected to the login page using the dual factor authentication configured for this site. Attempt to login. Use the following credentials:

User name: user1 Password 1: Citrix123 Password 2: Citrix123

Unfortunately, after attempting to log on, we receive and error when the request is redirected to /cgi/selfauth/.

and error when the request is redirected to /cgi/selfauth/. Since there is no content switching policy

Since there is no content switching policy that handles this type of traffic, the appliance responds with this error. Next, we will create the necessary policies to account for this type of traffic.

32.

Optionally, you can open a new tab and verify that the authentication request to the other web- application (SugarCRM) is sent to the alternate AAA virtual server configured for single factor authentication. Open a new tab in Firefox and navigate to http://cs1.training.lab/sugarcrm/

a new tab in Firefox and navigate to http://cs1.training.lab/sugarcrm/ Close Firefox and continue to the next

Close Firefox and continue to the next step.

Step

Action

33.

Navigate to Traffic Management > Content Switching > Policies and click Add.

Configure a policy using the following parameters:

Name: self-auth-dual

Expression:

HTTP.REQ.URL.PATH.SET_TEXT_MODE(IGNORECASE).STARTSWITH(“/cgi/selfauth”) &&

HTTP.REQ.BODY(3000).CONTAINS(“apache_profile”)

HTTP.REQ.BODY(3000).CONTAINS(“ apache _profile”) Click Create . 34. Additionally, create another policy
HTTP.REQ.BODY(3000).CONTAINS(“ apache _profile”) Click Create . 34. Additionally, create another policy

Click Create.

34.

Additionally, create another policy to handle the single factor authentication traffic.

Select the self-auth-dual policy and click Add. Then, change the following parameters:

Name: self-auth-single

Expression:

HTTP.REQ.URL.PATH.SET_TEXT_MODE(IGNORECASE).STARTSWITH("/cgi/selfauth") &&

HTTP.REQ.BODY(3000).CONTAINS("apache2_profile")

Then click Create.

35.

Now, we need to bind these policies to the Content Switching virtual server.

Navigate to Traffic Management > Content Switching > Virtual Servers, select cs1 and click Edit.

Step Action 36. Under CS Policy Binding, click 2 Content Switching Policies. Click Add Binding.
Step
Action
36.
Under CS Policy Binding, click 2 Content Switching Policies.
Click Add Binding. Under Policy Binding, click Click to select then select the radio button next to
self-auth-dual and click OK.
Next, under Target Load Balancing Virtual Server, click Click to select.
Select the radio button next to lb_vsrv_apache and click OK and then click Bind.

Step

Action

37.

Click Add Binding again. Under Policy Binding, click Click to select then select the radio button next to self-auth-single and click OK.

Next, under Target Load Balancing Virtual Server, click Click to select.

Select the radio button next to lb_vsrv_apache2 and click OK and then click Bind.

to lb_vsrv_apache2 and click OK and then click Bind . Click Close and then click Done

Click Close and then click Done to commit the changes.

38.

We are ready to test our initial configuration. Open a new Firefox window and browse to:

You should get redirected to the dual factor authentication login page.

39.

Log on using the following credentials:

User name: user1 Password 1: Citrix123 Password 2: Citrix123

40.

Your session should be authenticated and single sign-on as user1 to the phpmyadmin application on the Apache server.

Open a new Firefox tab and navigate to the second application URL:

Step Action 41. You should have been redirected to the single factor authentication login page.
Step
Action
41.
You should have been redirected to the single factor authentication login page.
Log on with the following credentials:
Username: user2
Password: Citrix123
Your session is authenticated and the page redirected to the web application login page. In a later
exercise, we will configure form-based single sign-on.
42.
For now, let’s just recap:
We have satisfied 2 out of 3 requirements:
- Used the same FQDN for both applications, by leveraging Content Switching
- Different authentication mechanisms for each web application, by leveraging Authentication
Profiles
Now we need to focus on preventing unauthorized access based on group membership. We will
configure additional authorization policies to ensure no malicious user can navigate to other URL
without proper authentication.
In the next exercise, we will complete the necessary configuration to accomplish this third
requirement.
43.
Save your configuration by clicking on the Save icon on the top right.
Don’t close your open session. You will be using it in the next exercise.

Exercise Summary

In this exercise, we learn how to apply different authentication profiles to different virtual servers. This new feature is a major change in the AAA infrastructure as the NetScaler appliance can now keep track of multiple sessions to different applications.

Also, by applying authentication profiles, the administrator can bundle applications so that SSO applies to a group of virtual servers, while still maintaining some authentication independence for those applications that require it.

Next, we will explore authorization policies and how you can further customize access to your application.

Exercise 5: Authorization Policies

Overview

Authorization policies are used to restrict access to resources protected by the NetScaler appliance. Since we have full access to the AppExpert policy engine when creating authorization policies, specific expressions can be defined to allow access to specific resources under the right conditions. In this exercise, we will configure examples of authorization policies using different PI elements to illustrate how to use this feature in a production environment.

Step by step guidance

Estimated time to complete this exercise: 15 minutes.

Step Action Recap: The previous scenario required that only users from certain groups access certain
Step
Action
Recap: The previous scenario required that only users from certain groups access certain URL
paths. In exercise 4, we enforce initial authentication when accessing the corresponding virtual
servers serving applications; however, there is still a requirement that we have not addressed.
If a malicious user attempts to navigate to a different URL pattern after authenticating successfully,
he might still get unauthorized access to another application as the user session is valid and the
user account exists in the directory service used for account validation.
If you closed the previous session by mistake, refer to Steps 38-41 of the previous exercise.
1.
Let’s create the necessary groups for the desired restrictions.
In the NetScaler configuration utility, navigate to: Security > AAA – Application Traffic >
Groups and click Add.
In the Group Name field, type Contractors.
Then click OK and then click Done.
Repeat the same process to create another group named Sales.
Step Action 2. Navigate to Security > AAA – Application Traffic > Policies > Authorization.
Step
Action
2.
Navigate to Security > AAA – Application Traffic > Policies > Authorization.
Click Add.
Step Action 3. Configure an authorization policy to allow only members of the Contractors group
Step
Action
3.
Configure an authorization policy to allow only members of the Contractors group to access
the first web site already set up for dual-factor authentication.
Use the following parameters:
Name: OnlyAllowContractors
Action: ALLOW
Expression: HTTP.REQ.USER.IS_MEMBER_OF(“Contractors”)
Click Create.
Step Action 4. Configure another authorization policy to allow only members of the Sales group.
Step
Action
4.
Configure another authorization policy to allow only members of the Sales group. Click
Add again.
Use the following parameters:
Name: OnlyAllowSales
Action: ALLOW
Expression: HTTP.REQ.USER.IS_MEMBER_OF(“Sales”)
Click Create.
5.
We need to bind these new policies to the corresponding Load Balancing virtual servers
handling these applications.
Navigate to Traffic Management > Load Balancing > Virtual Servers.
Select lb_vsrv_apache and click Edit.

Step

Action

6.

Under Advanced on the right side, click Policies.

6. Under Advanced on the right side, click Policies . Click the + button to add

Click the + button to add a policy.

Select Authorization from the Choose Policy drop-down list box, then select Request from the Choose Type drop-down list box and click Continue.

the Choose Policy drop-down list box, then select Request from the Choose Type drop-down list box

Step

Action

7.

Under Policy Binding, click Click to select. Click the radio button next to OnlyAllowContractors and click OK.

radio button next to OnlyAllowContractors and click OK . Click Bind and then click Done .

Click Bind and then click Done.

8.

Repeat the same process to bind the OnlyAllowSales authorization policy to

lb_vsrv_apache2.

Before we start testing, we need to change the Default Authorization Action in order to enforce authorized access with the Authorization Policies that we configured in the previous step.

Since the Default Authorization Action is Allow, we need to override such parameter either globally or at the virtual server level in order to apply more granular access through the new Authorization policies.

In our particular example, the best place to adjust this parameter is in the Session Profile that we previously configured to perform HTTP Basic Authentication SSO.

9.

Navigate to Security > AAA Application Traffic > Policies > Session.

Click the Session Profiles tab and then select the SSO_profile policy and click Edit.

10.

For Default Authorization Action, click Override Global and set it to DENY. Then click OK.

click Edit . 10. For Default Authorization Action , click Override Global and set it to

Step

Action

11.

Now we can begin testing.

Open a new Firefox browser window and browse to the URL of the first website:

You should be redirected to the dual-factor authentication page.

Since user1 is a member of the Contractors group, log on using the following credentials:

User name: user1 Password 1: Citrix123 Password 2: Citrix123

12.

Once the page loads, attempt to change the URL for the second web application, then hit Enter: http://cs1.training.lab/sugarcrm

13.

You are redirected to the authentication page. Login with the same credentials:

Username: user1 Password1: Citrix123

same credentials: Username: user1 Password1: Citrix123 You should not have been authorized to access this URL

You should not have been authorized to access this URL pattern based on your group membership.

Step Action 14. Close Firefox and reopen it. Browse to the second URL: http://cs1.training.lab/sugarcrm. Since
Step
Action
14.
Close Firefox and reopen it. Browse to the second URL: http://cs1.training.lab/sugarcrm.
Since user2 is a member of the sales group, log on with the following credentials:
Username: user2
Password: Citrix123
You should be able to access the second web-application.
15.
Attempting to change URLs while authenticated as user2 and accessing the first URL
(/phpmyadmin), it is disallowed by the authorization policy.
Try it!
Authorization policies gives us a lot of control to ensure users only access authorized resouces;
however, this authorization message is not the best user experience. We can enhance this by
leveraging Responder policies to redirect the user to the appropriate authentication page if
certain conditions are not met. The same policy engine expressions can be used to test for group
membership and a valid session.
16.
Save your configuration by clicking the Save icon on the top right corner.

Exercise Summary

In the previous exercise, we learn how to leverage authorization policies to protect resources behind NetScaler and ensure only authorized accounts get access to the correct resources. Since you have full access to the policy engine when creating authorization policies, you have granular control of these resources.

Exercise 6: Traffic vs. Session Policies

Overview

In this exercise, we will explore the differences and similarities between Traffic and Session policies and how we can use this type of configuration to apply a specific set of parameters.

Step by step guidance

Estimated time to complete this exercise: 15 minutes.

Step

Action

1.

In a previous exercise, we leveraged session policies to apply certain parameters to a user session. In our example, we enabled HTTP Basic Authentication SSO, set the Default Authorization to DENY, and enabled the HTTP Only option for the authentication cookie for enhanced security.

Navigate to: Security > AAA Application Traffic > Policies > Session.

Click on the Profiles tab and select the SSO_profile to view the settings applied.

tab and select the SSO_profile to view the settings applied. Click Close when finished. Do not

Click Close when finished. Do not change any parameters!

Step Action A session policy is a set of expressions and settings applied to users,
Step
Action
A session policy is a set of expressions and settings applied to users, groups, or virtual
servers. It is used for configuring specific settings for client connections, such as which
type of credentials to use when attempting SSO, default authorization status, timeouts
and SSO domains for HTTP authentication.
Traffic Policies extend this functionality and provide more flexibility to perform SSO for
other authentication mechanisms such as Kerberos, form-based authentication, or SAML
SSO as well as provide similar functionality to session policies. In the next section we will
configure a traffic profile to perform a simple SSO function for HTTP Basic
authentication, replacing the functionality of session policy we create before.
In a later exercise, we will leverage a Form-SSO profile in conjunction with a traffic policy
to perform SSO into an application that uses an HTML form for authentication.
2.
Let’s create an SSO profile to be used with a traffic policy.
Navigate to Security > AAA – Application Traffic > Policies > Traffic.
Select the Traffic Profiles tab, and then click on Add.

Step

Action

3.

Create the Traffic Profile with the following parameters:

Name: SSO_webapps_traffic

Single Sign-On: ON Click Create.

SSO_webapps_traffic Single Sign-On: ON Click Create . 4. Click the Traffic Policies tab and then click

4.

Click the Traffic Policies tab and then click Add.

Step

Action

5.

Create a new policy.

Since we will attempt to SSO for all traffic, use a true expression. Potentially, this can be tailored to a particular URL pattern, or specific condition.

Name: SSO_webapps_traffic

Profile: SSO_webapps_traffic

Expression: HTTP.REQ.IS_VALID

Click Create.

Expression: HTTP.REQ.IS_VALID Click Create . 6. Let’s unbind the current session policy in order to

6.

Let’s unbind the current session policy in order to use our traffic policy instead.

Navigate to Security > AAA Application Traffic > Virtual Servers.

Highlight the aaa-df-vs and click Edit.

7.

Under Policies, click 1 Session Policy.

> Virtual Servers . Highlight the aaa-df-vs and click Edit . 7. Under Policies, click 1

Step

Action

8.

Highlight the SSO_webapps policy and click Unbind.

8. Highlight the SSO_webapps policy and click Unbind. Click Yes to confirm. Click Close and then

Click Yes to confirm.

Click Close and then click Done.

Repeat the same process on the aaa-sf-vs AAA virtual server.

9.

Next, we need to bind the Traffic policy. This is done at the Load Balancing virtual server level.

Navigate to Traffic Management > Load Balancing > Virtual Servers.

Select lb_vsrv_apache and click Edit.

10.

Under Policies, click the + button.

Select Traffic from the Choose Policy drop-down list box and then click Continue.

Policies, click the + button. Select Traffic from the Choose Policy drop-down list box and then

Step

Action

11.

Under Policy Binding, click Click to select.

Select the radio button next to SSO_webapps_traffic and click OK.

radio button next to SSO_webapps_traffic and click OK . Click Bind and then click Done .

Click Bind and then click Done.

12.

It is time to test to see if our traffic policy performs the same basic SSO functions as the previous session policy.

Open Firefox and navigate to http://cs1.training.lab/phpmyadmin.

13.

You should be redirected to the dual factor authentication page. Use the following credentials:

User name: user1 Password1: Citrix123 Password2: Citrix123

14.

The user session should be authenticated and SSO is attempted in the same fashion as before. You should be logged on to the website as user1.

SSO is attempted in the same fashion as before. You should be logged on to the

Verify this is the case.

Step

Action

15.

SSO works the same as before. However, there is still one problem:

Since we are performing SSO functions, attempting to logout of the application does not trigger a NetScaler AAA-TM session logoff. This can be seen as a security risk as the user just needs to refresh the page to get back into the application as an authorized user.

Try this for yourself: Click the logout button and observe the behavior.

Step

Action

16.

The web application session is terminated and the application triggers a 401 for the user to enter the corresponding credentials. However, since we are automatically performing SSO, all we need to do is to gain access to the application is click on Cancel and then refresh the page.

performing SSO, all we need to do is to gain access to the application is click
performing SSO, all we need to do is to gain access to the application is click
performing SSO, all we need to do is to gain access to the application is click

Step

 

Action

17.

As a final step on this section, we will work on improving this Single Logout process. We will leverage Rewrite to accomplish this.

 

We have to focus on two items:

 

Expiring the application session using its own native mechanism

Expire the TM-AA cookie for the user to be prompted for credentials

We can use Rewrite to capture the request when the user clicks on the logout button, and then issue a Set-Cookie to expire the current AAA session cookie being used.

 

18.

In Firefox, open a new tab and browse to http://cs1.training.lab/phpmyadmin and log on using the user1 credentials.

 

Click on the LiveHTTPHeaders button.

19.

Go back to the web application and click the logout button. You should now be prompted for credentials. Don’t click on any button.

20.

Go back to the LiveHTTPHeaders window. Scroll up and inspect the first request and the URL target when we clicked the Logout button.

 

21.

 
     
 

Notice the logout mechanism the application is using:

Send a GET request to main index document in the application URL base path

including the current user token and an additional parameter specifying which user

to expire:

GET /phpmyadmin/index.php?token=xyz&old_usr=username

We can tag along using Rewrite to this request structure and expire our own AAA cookie in order to perform a single logout.

structure and expire our own AAA cookie in order to perform a single logout. Close LiveHTTPHeaders

Close LiveHTTPHeaders and the Firefox tab.

Step Action The approach we will take is the following: Create a rewrite Action and
Step
Action
The approach we will take is the following:
Create a rewrite Action and Policy to expire the AAA cookie by issuing a Set-Cookie header
with an expiration date in the past.
Since the response to the logout request is a 401 response, some browsers do not honor
cookies set in a 401. We will use Rewrite again to change this 401 into a 302 and redirect to
the original URL.
In addition, we will create these rewrite policies:
a. Rewrite the response to change the STATUS code from 401 to 302
b. Rewrite the response to change the STATUS MESSAGE from Unauthorized to
“Moved Temporarily”
c. Insert a Location header in order to redirect the client browser to the original URL
path.
22.
First, let’s create a rewrite policy and corresponding action in order to expire the AAA cookie
used by the appliance for authentication.
Navigate to AppExpert > Rewrite > Actions. Click Add.
Step Action 23. Create an action using the following parameters: Name: expire_tmaa_cookie Type: INSERT_HTTP_HEADER
Step
Action
23.
Create an action using the following parameters:
Name: expire_tmaa_cookie
Type: INSERT_HTTP_HEADER
Header Name: Set-Cookie
String expression for header value: "NSC_TMAA=xyz;Path=/;expires=Thu, 19 Nov
1981 08:52:00 GMT;Secure"
Click Create.
Step Action 24. Navigate to AppExpert > Rewrite > Policies. Click Add. Create a policy
Step
Action
24.
Navigate to AppExpert > Rewrite > Policies. Click Add.
Create a policy using the following parameters:
Name: expire_tmaa_cookie
Action: expire_tmaa_cookie
Expression: HTTP.REQ.URL.PATH_AND_QUERY.CONTAINS("old_usr")
Click Create.
Step Action 25. Next, we will create 3 more actions and corresponding policies. The first
Step
Action
25.
Next, we will create 3 more actions and corresponding policies. The first one changes the
401 response status to a 302.
Go back to the AppExpert > Rewrite > Actions node. Click Add and create an action with
the following parameters:
Name: res_302_status
Type: REPLACE
Expression to choose target text reference: HTTP.RES.STATUS
String expression for replacement text: 302
Click Create.
Step Action 26. The second action changes the status message from ‘Unauthorized” to “Moved Temporarily”
Step
Action
26.
The second action changes the status message from ‘Unauthorized” to “Moved
Temporarily” as specified by RFC for a 302 response.
Click Add and create another action with the following parameters:
Name: res_302_status_msg
Type: REPLACE
Expression to choose target text reference: HTTP.RES.STATUS_MSG
String expression for replacement text: “Moved Temporarily”
Click Create.
Step Action 27. Finally, we need to insert a Location header for the client browser
Step
Action
27.
Finally, we need to insert a Location header for the client browser to follow.
Click Add and create an action with the following parameters:
Name: res_302_location
Type: INSERT_HTTP_HEADER
Header Name: Location
String expression for header value: HTTP.REQ.URL.PATH
Bypass Safety Check: Checked
Click Create.
Step Action 28. Next we need to create the corresponding policies. Navigate to AppExpert >
Step
Action
28.
Next we need to create the corresponding policies.
Navigate to AppExpert > Rewrite > Policies. Click on Add and configure a policy with the
following parameters:
Name: res_302_status
Action: res_302_status
Expression: HTTP.REQ.URL.PATH_AND_QUERY.CONTAINS("old_usr")
Click Create.
Step Action 29. Click Add and configure the second policy using the following parameters: Name:
Step
Action
29.
Click Add and configure the second policy using the following parameters:
Name: res_302_status_msg
Action: res_302_status_msg
Expression: HTTP.REQ.URL.PATH_AND_QUERY.CONTAINS("old_usr")
Click Create.
Step Action 30. Click Add and configure the third and final policy using the following
Step
Action
30.
Click Add and configure the third and final policy using the following parameters:
Name: res_302_location
Action: res_302_location
Expression: HTTP.REQ.URL.PATH_AND_QUERY.CONTAINS("old_usr")
Click Create.
31.
Navigate to Traffic Management > Load Balancing > Virtual Servers, select
lb_vsrv_apache and click Edit.

Step

Action

32.

Under Policies, click the + button.

Select Rewrite from the Choose Policy drop-down list box and then select Response from the Choose Type drop-down list box. Then click Continue.

the Choose Type drop-down list box. Then click Continue . Under Policy Binding, click Click to

Under Policy Binding, click Click to select. Select the radio button next to expire_tmaa_cookie and click OK.

33.

Under Binding Details, select NEXT from the Goto Expression drop-down list box and click Bind.

and click OK . 33. Under Binding Details, select NEXT from the Goto Expression drop-down list
Step Action 34. Under Policies, click 1 Rewrite Policy. Click Add Binding to add another
Step
Action
34.
Under Policies, click 1 Rewrite Policy.
Click Add Binding to add another rewrite policy.
Under Policy Binding, click Click to select.
Select the radio button next to res_302_status and click OK.
Under Binding Details, select NEXT from the Goto Expression drop-down list box and click
Bind.
Step Action 35. Click Add Binding to add another rewrite policy. Under Policy Binding, click
Step
Action
35.
Click Add Binding to add another rewrite policy.
Under Policy Binding, click Click to select.
Select the radio button next to res_302_status_msg and click OK.
Under Binding Details, select NEXT from the Goto Expression drop-down list box and click
Bind.

Step

Action

36.

Click Add Binding to add another rewrite policy.

Under Policy Binding, click Click to select.

Select the radio button next to res_302_location and click OK.

Click Bind and then click Close.

and click OK . Click Bind and then click Close . 37. It is time to

37.

It is time to test.

Open a new Firefox tab.

Navigate to the URL for the phpMyAdmin application:

You should be redirected to the dual factor login page.

38.

Login with the following credentials:

User name: user1 Password1: Citrix123 Password2: Citrix123

Your session is now authenticated, SSO occurs and you should be logged in the application.

39.

Click the LiveHTTPHeaders button.

Return to the main Firefox window and click the logout button.

Step Action 40. You should see the dual factor login page. Return to the LiveHTTPHeaders
Step
Action
40.
You should see the dual factor login page. Return to the LiveHTTPHeaders and scroll all
the way up. Observe the output of the first request and response. The response should be
changed to a 302, the NSC_TMAA cookie should be expired, and the Location header set.
41.
Return to the main Firefox window and login with again with user1 credentials:
User name: user1
Password1: Citrix123
Password2: Citrix123
You should have been logged on to the application as user1 and a new AAA cookie is set.
42.
Return to LiveHTTPHeaders and verify this is the case.
Close Firefox and the LiveHTTPHeaders window.
43.
Congratulations! You have secured your application.
Save your configuration by clicking on the Save icon on the top right.

Exercise Summary

In this exercise, we explore the difference between a session and a traffic policy. Both of these elements can provide SSO services; however, traffic policies allow you to apply additional controls for traffic profiles when performing single sign-on services. In our next exercise, we continue expanding on the usage of traffic profiles when performing form-based authentication SSO.

Exercise 7: Server-side SSO using NTLM and Form-Based Authentication

Overview

In this exercise, we will explore the true single sign-on capabilities of the NetScaler appliance. We will configure for SSO to web applications using HTTP basic authentication and form based authentication. Since form based authentication is specific to the type of application front-ended by NetScaler, we will configure SSO to different web-applications to illustrate how to apply this knowledge to other production applications.

Step by step guidance

Estimated time to complete this exercise: 25 minutes.

Step Action 1. In previous exercises, we configured simple SSO for Basic HTTP authentication using
Step
Action
1.
In previous exercises, we configured simple SSO for Basic HTTP authentication using a session
and traffic policies. This type of authentication is one of the simplest methods and it is rarely
required by enterprise applications. In most environments, different authentication mechanisms
are required such as NTLMv1, NTLMv2, and form-based authentication.
To explore form-based SSO, we will start with our SugarCRM application. In order to automate
this type of single sign-on mechanism, we need to understand how the authentication for
application works, before we attempt any configuration.
Open Firefox and navigate to http://192.168.10.15/sugarcrm.
The login form should be displayed.
The following steps require some knowledge of HTML and HTTP. Skip this section (steps 2-10) if you
are unfamiliar with these concepts.
However, if you would like to configure Form-based SSO for your own web applications, it is best to
start experimenting with these topics using a simple example such as this one.
2.
Hit Ctrl + U to display the page source.

Step

Action

3.

In the “Source of” window, hit Ctrl + F to locate the relevant User Name and Password input elements.

Enter “User Name” in the “Find in page” box

Enter “User Name” in the “Find in page” box 4. The label User Name will be

4.

The label User Name will be highlighted. Locate this line and the 5 consecutive lines of HTML code:

Locate this line and the 5 consecutive lines of HTML code: 5. In order to fill

5.

In order to fill out the necessary parameters in our form-based SSO profile, we need
In order to fill out the necessary parameters in our form-based SSO profile, we need to
find out what are the names of the fields representing the Username and Password. Most
likely, application developers will name these input fields username / password;
however, these values vary from application to application.
Luckily, the SugarCRM web-dev team used familiar labels. Locate the name of the text
field for each input element. In the HTML code, inspect the <input line for the username
and password.
They are named user_name and user_password.
 

Record this information, we will need it later.

Close the Source of window.

6.

You should be back in the login form. Before clicking on any link or attempting to login, click on the LiveHTTPHeaders tool.

7.

Return back to the main Firefox window and login using the following credentials:

User Name: user2 Password: Citrix123

Click Log In.

Step Action 8. Return to the LiveHTTPHeaders window. Scroll all the way up and inspect
Step
Action
8.
Return to the LiveHTTPHeaders window. Scroll all the way up and inspect the first request. Two
pieces of information are key in this step:
 The application submits the credentials in a POST along with many other parameters.
 The POST is sent to /sugarcrm/index.php
We need to record this information. Select the line including the POST data and right-click, then
Copy.
9.
Open Notepad and paste this line of text. Leave it in the background as we will need this
information later when defining our Form-based SSO profile.

Step

Action

10.

Next, we need to inspect the application response to this POST. In LiveHTTPHeaders, scroll to the 302 response after the initial POST request. Notice the Location header value.

This is indicating the client browser that the session was successfully authenticated and redirects to the main home page:

authenticated and redirects to the main home page: Highlight the Location header. Right-click and then select

Highlight the Location header. Right-click and then select Copy. We will need this information later.

If you are curious, inspect what happens when a failed authentication attempt occurs. Since every application behaves differently, we have to inspect the success and failure use cases in order to determine the correct expressions for our Form SSO profile configuration.

11.

Return to the NetScaler configuration utility.

Navigate to Security > AAA Application Traffic > Policies > Traffic. Click on the Form SSO Profiles tab and then click on Add.

AAA – Application Traffic > Policies > Traffic . Click on the Form SSO Profiles tab
Step Action 12. In the Create Form SSO Profile window, configure using the following parameters:
Step
Action
12.
In the Create Form SSO Profile window, configure using the following parameters:
Name: sugarcrm_SSO
Action URL: /sugarcrm/index.php
User Name Field: user_name
Password Field: user_password
SSO Success Rule:
HTTP.RES.HEADER("Location").CONTAINS("index.php?module=Home&action=index")
Response Size: 16192
Extraction: DYNAMIC
Submit Method: POST
Click Create.

Step

Action

13.

Click on the Traffic Profiles tab, and then click on the Add button.

14.

Select the Profile tab. Create a Traffic Profile, with the following parameters:

Name: sugarcrm_SSO_prof

Single Sign-on: ON Form SSO Profile: sugarcrm_SSO

Single Sign-on: ON Form SSO Profile: sugarcrm_SSO Click Create . 15. Select the Traffic Policies tab

Click Create.

15.

Select the Traffic Policies tab and then click Add.

16.

We need to define the conditions when the form-based SSO routine is executed. Create a Traffic policy using the following parameters:

Name: sugarcrm_SSO_pol

Profile: sugarcrm_SSO_prof Expression:

HTTP.REQ.URL.PATH_AND_QUERY.EQ("/sugarcrm/index.php?action=Login&module=Users")