Sei sulla pagina 1di 111

611: NetScaler is the Gatekeeper.

Become the
Keymaster.

Hands-on Lab Exercise Guide

Christopher Rudolph

May 2015

|1 |
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

|2 |
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

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.

|3 |
Lab Guide Conventions
This symbol indicates particular attention must be paid to this step

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)

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

|4 |
List of Virtual Machines Used
VM Name IP Address Description / OS
Windows Server 2012 R2 Domain
AD.training.lab 192.168.10.11
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)
Windows Server 2008 R2 Sharepoint 2010
Sharepoint 192.168.10.20
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

|5 |
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 Server to add your physical XenServer to XenCenter.

|6 |
Step Action
3. Enter your physical XenServer parameters from your welcome screen.

IP Address 192.168.10.5
Username admin
Password Your XenServer password

You may find it easier to copy


and paste the password to
ensure it is entered correctly.

Click Add.

4.

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.

|7 |
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
NS_VPX_1 shortcut on the shortcut bar.

Log on using the default credentials:


User Name: nsroot
Password: nsroot

|8 |
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.

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.

|9 |
Step Action
4. Save the NetScaler configuration by clicking the Save icon in the top right corner of the
GUI.

Then click Yes at the Confirm prompt.

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.

| 10 |
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 appliance processes keeps track of the user sessions.

We will start slow and with the basics. If this is too basic, dont 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 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

| 11 |
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

Then click Done.

| 12 |
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)

| 13 |
Step Action
4. Click No Load Balancing Virtual Server Service Binding to add the services.

Under Service Binding, click Click to select.

Check the box next to svc_apache and click OK.

Click Bind, click OK, and then click Done.

| 14 |
Step Action
5. Save the NetScaler configuration by clicking the Save icon in the top right corner of the GUI.

Then click Yes at the Confirm prompt.

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.

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.

| 15 |
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 users 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.

| 16 |
Step Action
10. Lets 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.

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

| 17 |
Step Action
12. Now, lets define the Local configuration.
Navigate to: Security > AAA Application Traffic > Policies > Authentication > Basic
Policies > Local.
Click Add.

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.

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

Name: aaa-df-vs
IP Address: 192.168.10.70

Click OK.

| 18 |
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.

| 19 |
Step Action
16. Click the + icon under Basic Authentication Policies.

Click Continue.

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

| 20 |
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.

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.

| 21 |
Step Action
20. Click Authentication from the Advanced column on the right side of the window.

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.

| 22 |
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.

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

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!

| 23 |
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.

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

| 24 |
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

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.

| 25 |
Step Action
27. Click on the Policies button in the right column under Advanced.

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

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

Click Done.

| 26 |
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.

Then click Yes at the Confirm prompt.

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 sign-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.

| 27 |
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.

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

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.

| 28 |
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.

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.

| 29 |
Step Action
8. Save the NetScaler configuration by clicking the Save icon in the top right corner of the
GUI.

Then click Yes at the Confirm prompt.

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.

| 30 |
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, lets 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.

| 31 |
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.

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.

Click Bind and then click OK.

| 32 |
Step Action
4. Click Authentication from the Advanced column on the right side of the window.

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.

| 33 |
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:
http://apache2.training.lab/sugarcrm

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, lets 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, lets 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.

| 34 |
Step Action
9. 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.

| 35 |
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.

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

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:
http://apache.training.lab/phpmyadmin.
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:
http://apache2.training.lab/sugarcrm.

| 36 |
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, lets 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.

| 37 |
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.

| 38 |
Step Action
17. Under CS Policy Bound, click No Content Switching Policy Bound.

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

| 39 |
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.

| 40 |
Step Action
19. 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_apache and click OK. Then click Bind.

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

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

| 41 |
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.

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.

| 42 |
Step Action
24. Create a new virtual server using the following parameters:
Name: aaa-sf-vs
IP Address: 192.168.10.71

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.

| 43 |
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.

Click Continue.

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

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.

| 44 |
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.

| 45 |
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.

| 46 |
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
http://cs1.training.lab/phpmyadmin.
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/.

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/

Close Firefox and continue to the next step.

| 47 |
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)

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.

| 48 |
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.

| 49 |
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.

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:
http://cs1.training.lab/phpmyadmin

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:
http://cs1.training.lab/sugarcrm

| 50 |
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, lets 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.

Dont close your open session. You will be using it in the next exercise.

| 51 |
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.

| 52 |
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 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. Lets 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.

| 53 |
Step Action
2. Navigate to Security > AAA Application Traffic > Policies > Authorization.
Click Add.

| 54 |
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.

| 55 |
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.

| 56 |
Step Action
6. Under Advanced on the right side, click Policies.

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.

| 57 |
Step Action
7. Under Policy Binding, click Click to select. Click the radio button next to
OnlyAllowContractors and click OK.

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.

| 58 |
Step Action
11. Now we can begin testing.
Open a new Firefox browser window and browse to the URL of the first website:
http://cs1.training.lab/phpmyadmin.
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

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

| 59 |
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.

| 60 |
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.

Click Close when finished. Do not change any parameters!

| 61 |
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. Lets 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.

| 62 |
Step Action
3. Create the Traffic Profile with the following parameters:
Name: SSO_webapps_traffic
Single Sign-On: ON
Click Create.

4. Click the Traffic Policies tab and then click Add.

| 63 |
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.

6. Lets 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.

| 64 |
Step Action
8. Highlight the SSO_webapps policy and click Unbind.

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.

| 65 |
Step Action
11. Under Policy Binding, click Click to select.
Select the radio button next to SSO_webapps_traffic and click OK.

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.

Verify this is the case.

| 66 |
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.

| 67 |
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.

| 68 |
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. Dont 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.

Close LiveHTTPHeaders and the Firefox tab.

| 69 |
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, lets 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.

| 70 |
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.

| 71 |
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.

| 72 |
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.

| 73 |
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.

| 74 |
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.

| 75 |
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.

| 76 |
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.

| 77 |
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.

| 78 |
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.

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.

| 79 |
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.

| 80 |
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.

| 81 |
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.

37. It is time to test.


Open a new Firefox tab.
Navigate to the URL for the phpMyAdmin application:
http://apache.training.lab/phpmyadmin.
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.

| 82 |
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.

| 83 |
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 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.

| 84 |
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

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

5.
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.

| 85 |
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.

| 86 |
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:

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.

| 87 |
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.

| 88 |
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

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")

The expression was derived from our analysis of the authentication process for the SugarCRM
application. Refer to steps 1-10.

Click Create.

17. Finally, we need to bind our policy in order to put it in action.


Navigate to Traffic Management > Load Balancing > Virtual Servers.
Highlight the lb_vsrv_apache2 virtual server and click Edit.

18. Under Policies, click the + button.


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

| 89 |
Step Action
19. Under Policy Binding, click Click to select.
Select the radio button next to sugarcrm_sso_pol and click OK.
Click Bind and then click Done.

20. Close Firefox and the LiveHTTPHeaders tool. Reopen Firefox and navigate to the SugarCRM
URL. http://apache2.training.lab/sugarcrm.
You should be redirected to the single factor authentication login page.

21. Login with the following credentials:


User name: user2
Password: Citrix123

Since this is the first time we access this application, the application takes about 10-20 seconds to
complete. This occurs because the database is being initialized during the first logon.

22. Single sign-on should be successful. Navigate the application and inspect that the currently
logged on user is user2.

23. Click the Log Out link right next to the username. Since this application uses a custom logout
page, we would perform similar steps to trap the logout and invalidate the AAA session active on
the NetScaler.
I leave this as an optional task.
HINT: Refer to the technique used in Exercise 6.
Continue to the next step.

24. Next, we will explore NTLMv2 SSO.


In Firefox, click on the LiveHTTPHeaders tool. Then open a new tab and navigate to the
Sharepoint Site URL: http://sp.training.lab/

25. You should get prompted for authentication. Login with the following credentials:
Username: TRAINING\user1
Password: Citrix123

| 90 |
Step Action
26. After the SharePoint site loads, return to the LiveHTTPHeaders window and scroll all the way
up.
Inspect the first request and response. You should see that the SharePoint site challenges the
user for credentials and requests NTLM authentication.

After inspecting the output, close Firefox and LiveHTTPHeaders, then continue to the next step.

27. We will configure a new server, service and virtual server object. Return to the NetScaler
Configuration Utility and navigate to Traffic Management > Load Balancing > Servers and click
Add.

| 91 |
Step Action
28. Create a new Server object for SharePoint. Use the following parameters:
Server Name: sharepoint
IP Address: 192.168.10.20

| 92 |
Step Action
29. Navigate to Traffic Management > Load Balancing > Services. Click Add.
Create a new Service object with the following parameters:
Service Name: svc_sharepoint
Existing Server: Checked
Server: sharepoint
Protocol: HTTP
Port: 80

Click OK. Then click Done.

30. Navigate to Traffic Management > Load Balancing > Virtual Servers and click Add.
Create a new virtual server using the following parameters:
Name: lb_vsrv_sharepoint
Protocol: HTTP
IP Address: 192.168.10.63
Port: 80
Click OK.

31. Click No Load Balancing Virtual Server Service Binding.


Under Service Binding, click Click to select.
Check the box next to svc_sharepoint and click OK and then click Bind.
Click OK and then click Done.

32. Open a new tab in Firefox. Navigate to the new virtual server FQDN.
http://sharepoint.training.lab

| 93 |
Step Action
33. You should get prompted for authentication. Login with the following credentials:
Username: TRAINING\user1
Password: Citrix123

34. The SharePoint site should load properly. Close Firefox and return to the NetScaler
Configuration utility.

35. In the Traffic Management > Load Balancing > Virtual Servers section, click on
lb_vsrv_sharepoint, and then click Edit.

| 94 |
Step Action
36. On the right side, under Advanced, click Authentication.

For simplicity, we will configure single factor authentication for this new SharePoint virtual server.
Configure the following parameters:
Form Based Authentication: Checked
Authentication FQDN: aaa-sf.training.lab
Authentication vserver: aaa-sf-vs

Click OK and then click Done.

37. Next, we will create a new session policy to enable NTLM SSO.
Navigate to Security > AAA Application Traffic > Policies > Session.
Click on the Session Profiles tab and then click on Add.

| 95 |
Step Action
38. Create a Session profile with the following parameters:
Name: SSO_NTLM_sharepoint
Default Authorization: ALLOW
Single Sign-on to Web Applications: Checked
Credential Index: Primary
HTTPOnly Cookie: YES

Click Create.

39. Next, we need to create the Session Policy.


Click on the Session Policies tab and then click Add.

40. Configure a new Session policy using the following parameters:


Name: SSO_NTLM_sharepoint
Request Profile: SSO_NTLM_sharepoint
Expression: ns_true
Click Create.

41. Now, it is time to bind our new session policy to the AAA virtual server we are using for
authentication.
Navigate to Security > AAA Application Traffic > Virtual Servers.
Highlight the aaa-sf-vs virtual server and click Edit.

42. Under Advanced, on the right, click Policies.


Then click the + button under Policies.

| 96 |
Step Action
43. Select Session from the Choose Policy drop-down list box and click Continue.
Under Policy Binding, click Click to select and select the radio button next to
SSO_NTLM_Sharepoint and click OK.
Click Bind and then click Done.

44. It is time to test our configuration. Open a new Firefox window. Browse to the Sharepoint virtual
server: http://sharepoint.training.lab
You should get redirected to the single factor login page. Login with the following credentials:
Username: user1
Password: Citrix123

45. The session should be SSOed into the SharePoint site. Verify this is the case by inspecting the
currently logged on user on the top right corner.

Close the Firefox window.

Form-based SSO and NTLMv1/v2 are one of the most common authentication mechanisms for
enterprise applications in Microsoft environments. In the next exercises, we will explore new client and
server side authentication mechanisms and how to leverage the NetScaler to protect your applications
and consolidate your authentication layer.

46. Congratulations! You have configured form-based and NTLM SSO successfully.
Save your configuration by clicking on the Save icon on the top right.
Continue to the next exercise.

Exercise Summary
Form-based and NTLM authentication are some of the most common authentication mechanisms used by web
applications today. In this exercise, we learned how to analyze a web application in order to create the
necessary traffic policy to perform single sign-on services. Next, we will explore more advanced authentication
mechanisms supported by the NetScaler, not only on the client-side, but server side SSO.

| 97 |
Exercise 8: SAML Client-Side
Authentication
Overview
At a glance SAML 2.0 is a set of open standards leveraging XML to transport authentication and authorization
data between trusted endpoints. The most adopted use case is web single sign on or SSO. SAML 2.0
addresses the authentication challenges over the internet opposed to an intranet.
Citrix NetScaler latest release 10.5 offers support for both SAML 2.0 endpoints. Service Provider (SP) &
Identity Provider (IdP)
In this exercise, we will walk through a how to setup Citrix NetScaler as both SP & IdP completing the SAML
trust fabric.

Step by step guidance


Estimated time to complete this exercise: 20 minutes.

Step Action
1. First, we are going to create the SAML Service Provider (SP) Profile on NetScaler NS_VPX_1.
Navigate to Security > AAA Application Traffic > Policies > Authentication > Basic Policies >
SAML.
Select the Servers tab at the top and click Add.

| 98 |
Step Action
2. Configure the SAML Server using the following parameters:
Name: saml_sp
IDP Certificate Name: wildcard.training.lab
Redirect URL: http://aaa-saml.training.lab
Signing Certificate Name: wildcard.training.lab
Issuer Name: aaa-saml.training.lab

Leave all other fields with their default value.


Click Create.

| 99 |
Step Action
3. Next, we are going to create a SAML SP policy.
Select the Policies tab and click Add.

Type saml_sp in the Name field, then select saml_sp from the Server drop-down list box, and then
type ns_true in the Expression field.
Click Create.

4. Now we can create the AAA virtual server for the SAML service provider on NS_VPX_1.
Navigate to Security > AAA Application Traffic > Virtual Servers and click Add.

| 100 |
Step Action
5. Configure the AAA virtual server using the following parameters:
Name: aaa-saml-sp
IP Address: 192.168.10.72
Click OK.

6. Under Certificates, click No Server Certificate.

Under Server Certificate Binding, click Click to select and select the radio button next to
wildcard.training.lab and click OK and then click Bind.

Click Continue twice.

| 101 |
Step Action
7. Under Basic Authentication Policies, click the + button to add a policy.
Select LDAP from the Choose Policy drop-down list box and click Continue.

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

Click Bind.

| 102 |
Step Action
8. Under Basic Authentication Policies, click the + button again to add another policy.
Select SAML from the Choose Policy drop-down list box and then click Continue.

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

Click Bind.
Click Continue and then click Done.

9. Next, navigate to Traffic Management > Load Balancing > Virtual Servers and select
lb_vsrv_apache and click Edit.

| 103 |
Step Action
10. Click the pencil icon next to Authentication to edit the AAA settings of the virtual server.

Then change the following settings:


Authentication FQDN: aaa-saml-sp.training.lab
Authentication Virtual Server: aaa-saml-sp
Authentication Profile: Change to blank (no profile)
Then click OK.

Then click Done.

| 104 |
Step Action
11. Now we are going to switch over to NS_VPX_2 and configure the SAML IdP side of the
authentication.
Open a new Google Chrome tab and click the NS_VPX_2 shortcut in the shortcut bar.
Log on using the following credentials:
User Name: nsroot
Password: nsroot

12. First, we are going to create the SAML IdP Profile.


Navigate to: Security > AAA Application Traffic > Policies > Authentication > Basic Policies >
SAML IdP.
Select the Profiles tab and click Add.

| 105 |
Step Action
13. Configure the SAML IdP profile using the following parameters:
Name: saml_idp
SP Certificate Name: wildcard.training.lab
IdP Certificate Name: wildcard.training.lab
Issuer Name: aaa-saml.training.lab
Audience: http://apache.training.lab

Click Create.

| 106 |
Step Action
14. Next, we are going to create the SAML IdP Policy.
Select the Policies tab and click Add.

| 107 |
Step Action
15. Configure the SAML IdP plocy using the following parameters:
Name: saml_idp
Action: saml_idp
Expression: HTTP.REQ.URL.CONTAINS(saml)
Click Create.

| 108 |
Step Action
16. Now we are going to create the AAA virtual server for the SAML IdP.
Navigate to Security > AAA Application Traffic > Virtual Servers and click Add.

17. Configure the AAA virtual server using the following parameters:

Name: aaa-saml-idp
IP Address: 192.168.10.73
Click OK.

18. Under Certificates, click No Server Certificate.


Under Server Certificate Binding, click Click to Select. Then select the radio button next to
wildcard.training.lab and click OK.
Click Bind and then click Continue twice.

19. Under Basic Authentication Policies, click the + button.


Select LDAP from the Choose Policy drop-down list box and click Continue.
Under Policy Binding, click Click to Select and select the radio button next to LDAP_training and
click OK and then click Bind.

| 109 |
Step Action
20. Under Basic Authentication Policies, click the + button again.
Select SAMLIDP from the Choose Policy drop-down list box and click Continue.

Under Policy Binding, click Click to Select and select the radio button next to saml-idp and click OK
and then click Bind.

Click Continue and then click Done.

21. Save your NetScaler configuration on both NetScalers.


We are now ready for testing.
Open a new browser window and browse to http://apache.training.lab/colors/home.php
It should forward to the AAA virtual server.
Log on using the following credentials:
User name: user1
Password: Citrix123

22. If you see the colors homepage, than you have completed the configuration correctly.

| 110 |
Revision: Change Description Updated By Date
1.0 Original Version Christopher Rudolph May 2015

About Citrix
Citrix (NASDAQ:CTXS) is leading the transition to software-defining the workplace, uniting
virtualization, mobility management, networking and SaaS solutions to enable new ways for
businesses and people to work better. Citrix solutions power business mobility through secure, mobile
workspaces that provide people with instant access to apps, desktops, data and communications on
any device, over any network and cloud. With annual revenue in 2014 of $3.14 billion, Citrix solutions
are in use at more than 330,000 organizations and by over 100 million users globally. Learn more
at www.citrix.com.

| 111 |

Potrebbero piacerti anche