CNS 225 1I en StudentExerciseWorkbook 1 3 Days v01

CNS-223-1I Citrix ADC 13.
x Essentials
CNS-223-1I Citrix ADC 13.x

Essentials
Getting Started
Lab Manual- Version 5
1
CNS-223-1I Citrix ADC 13.x Essentials
PUBLISHED BY
Citrix Systems, Inc.
851 West Cypress Creek Road Fort
Lauderdale, Florida 33309 USA
http://www.citrix.com
Copyright © 2020 by Citrix Systems, Inc.
All rights reserved. Citrix, the Citrix logo are trademarks of Citrix Systems, Inc. and/or one or more of its subsidiaries,
and may be registered with the U.S. Patent and Trademark Office and in other countries. [Citrix ADC.] All other marks
appearing herein are the property of their respective owners.
Citrix Systems, Inc. (Citrix) makes no representations or warranties with respect to the content or use of this
publication. Citrix specifically disclaims any expressed or implied warranties, merchantability or fitness for any
particular purpose. Citrix reserves the right to make any changes in specifications and other information contained
in this publication without prior notice and without obligation to notify any person or entity of such revisions or
changes.
No part of the publication may be reproduced or transmitted in any form or by any means, electronic or mechanical,
including photocopying, recording or information storage and retrieval systems, for any purpose other than the
purchaser’s personal use, without express written permission of.
2
Credits Page
Title Name
Architect Jesse Wilson
Product Managers Lissette Jimenez
Technical Solutions Developers Uma Upraity
Aman Sharma
Shruti V. Dhamale
Ravindra G Hunashimarad
Offering Manager Amit Ben-Chanoch

Instructional Designer Jayshree Nair
Graphics Designer Ryan Flowers
Publication Services Rahul Mohandas
3
Contents
Credits Page ............................................................................................................................................................ 3
Lab Manual Overview.............................................................................................................................................. 6
Lab Environment Overview ..................................................................................................................................... 7
Module 1: Getting Started ..................................................................................................................................... 10
Exercise 1-1: Performing an Initial Configuration (CLI) ........................................................................................ 11
Exercise 1-2: Performing Basic Administration (GUI) .......................................................................................... 18
Exercise 1-2: Performing Basic Administration (CLI) ........................................................................................... 21
Module 2: Basic Networking.................................................................................................................................. 27
Exercise 2-1: Configuring Networking (GUI) ....................................................................................................... 29
Exercise 2-1: Configuring Networking (CLI)......................................................................................................... 32
Module 4: High Availability.................................................................................................................................... 35
Exercise 4-1: Configuring an HA Pair (GUI) ......................................................................................................... 36
Exercise 4-2: Managing an HA Pair (GUI) ............................................................................................................ 42
Exercise 4-1: Configuring an HA Pair (CLI) .......................................................................................................... 45
Exercise 4-2: Managing an HA Pair (CLI) ............................................................................................................. 51
Module 5: Load Balancing ..................................................................................................................................... 54
Exercise 5-1: Load Balancing HTTP (GUI) ............................................................................................................ 55
Exercise 5-2: Load-Balancing DNS (GUI) ............................................................................................................. 67
Exercise 5-3: Load Balancing LDAP (GUI) ............................................................................................................ 73
Exercise 5-4: Load Balancing MYSQL Databases (GUI) ........................................................................................ 77
Exercise 5-1: Load Balancing HTTP (CLI) ............................................................................................................. 85
Exercise 5-2: Load Balancing DNS (CLI) ............................................................................................................... 90
Exercise 5-3: Load Balancing LDAP (CLI) ............................................................................................................. 94
Exercise 5-4: Load-Balancing MYSQL Databases (CLI) ......................................................................................... 96
Module 6: SSL Offload ......................................................................................................................................... 101
Exercise 6-1: Configuring SSL Certificates (GUI) ................................................................................................ 102
Exercise 6-2: Configuring SSL Offload (GUI) ...................................................................................................... 107
Exercise 6-3: Configuring End-to-End Encryption (GUI)..................................................................................... 109
Exercise 6-4: Configuring HTTP to HTTPS Redirect Using the Redirect URL (GUI) ............................................... 111
Exercise 6-1: Configuring SSL Certificates (CLI) ................................................................................................. 115
Exercise 6-2: Configuring SSL Offload (CLI) ....................................................................................................... 118
Exercise 6-3: Configuring End-to-End Encryption (CLI) ...................................................................................... 119
Exercise 6-4: Configuring HTTP to HTTPS Redirects Using Redirect URL (CLI) .................................................... 121
Module 7: Securing the Citrix ADC ....................................................................................................................... 124
Exercise 7-1: Configuring Local Authentication and Delegated Administration (GUI)......................................... 126
4
Exercise 7-2: Configuring External Authentication with LDAP (GUI) .................................................................. 129
Exercise 7-3: Admin Partitions (GUI) ................................................................................................................ 132
Exercise 7-1: Configuring Local Authentication and Delegated Administration (CLI) .......................................... 137
Exercise 7-2: Configuring External Authentication with LDAP (CLI) ................................................................... 140
Exercise 7-3: Admin Partitions (CLI) ................................................................................................................. 142
Module 8: Monitoring and Troubleshooting ........................................................................................................ 147
Exercise 8-1: Viewing Citrix ADC Logs and Network Traces (GUI) ...................................................................... 148
Exercise 8-2: Configuring External Syslog and Audit Policies (GUI) .................................................................... 155
Exercise 8-3: Configuring SNMP (GUI) .............................................................................................................. 158
Exercise 8-4: Troubleshooting (GUI)................................................................................................................. 161
Exercise 8-1: Viewing Citrix ADC Logs and Network Traces (CLI) ....................................................................... 174
Exercise 8-2: Configuring External Syslog and Audit Policies (CLI) ..................................................................... 180
Exercise 8-3: Configuring SNMP (CLI) ............................................................................................................... 182
Exercise 8-4: Troubleshooting (CLI) .................................................................................................................. 184
5
Lab Manual Overview

In this Lab Manual, you will get valuable hands-on experience with Citrix ADC and its features. This Lab Manual will
enable you to work with product components and perform the required steps for initial configuration, High
Availability, Load Balancing, and SSL Offload.
Lab exercises are provided for the both the Citrix ADC Configuration Utility (GUI) and the Citrix ADC CLI. Students
only need to perform one set of labs, either all GUI or all CLI for a given module. The other set of exercises may be
used for reference. Identify how to connect to the Citrix ADCs for each set of lab exercises.
We recommend that you use Chrome to connect to the Citrix ADC Configuration Utility when using the GUI to
perform labs
When testing web content, any browser may be used. However, you may find it simpler to make management
connections in one browser, such as Chrome, and perform application testing in another browser, such as Firefox.
When performing lab exercises from the CLI, you will need to connect to the Citrix ADC Management IPs (above)
using SSH. The lab environment uses PuTTY as the SSH client and WinSCP as the SFTP/SCP client.
Before starting exercises in each module, determine if you will be working in the GUI or CLI for that module. You
are encouraged to explore both versions of the lab exercises, but the exercises are written so that only one set of
exercises (GUI or CLI) can be performed at any one time, not both.
Each exercise will identify which Citrix ADC or Management IP to connect to and which account to use for logon if
not the default account (nsroot/nsroot). We also recommended that you save the configuration at the end of each
exercise unless the exercise states otherwise.
5
Lab Environment Overview
Virtual Machine Name Domain FQDN IP Address Description

NYC-ADS-001 NYC-ADS- 192.168.30.11 Domain Controller
001.workspacelab.com (Workspacelab.com)
NYC-ADS-002 NYC-ADS- 192.168.30.12 Domain Controller 2
002.workspacelab.com (Workspacelab.com)
NYC-LMP-001 NYC-LMP- 192.168.30.61 MYSQL Database Server
001.workspacelab.com
NYC-LMP-002 NYC-LMP- 192.168.30.62 MYSQL Database Server
002.workspacelab.com
NYC-WEB-RED NYC-WEB- 192.168.30.51 Web Server
RED.workspacelab.com
NYC-WEB-BLU NYC-WEB- 192.168.30.52 Web Server
BLUE.workspacelab.com
NYC-WEB-GRN NYC-WEB- 192.168.30.53 Web Server
GREEN.workspacelab.com
NYC-WEB-REMOTE NYC-WEB- 172.22.15.41 Web Server
REMOTE.workspacelab.com
6
Student Desktop - 192.168.10.254 Hyper-V host and landing desktop.

All labs performed from this
system.
Citrix ADC List
Virtual Machine NSIP Address Subnet IP (SNIP) Address Description

Name
NYC-ADC-001 192.168.100.1 /16 N/A Citrix ADC initial configuration starts
(Initial) as an “out-of-box” MPX appliance
with the default NSIP address
specified. This will be changed in the
first exercise.
NYC-ADC-001 192.168.10.101 SNIP1: 192.168.10.111 (traffic) NYC-ADC-001 is the principal Citrix
SNIP2: 192.168.10.103 (mgmt) ADC for most exercises. It will be in
an HA Pair with NYC-ADC-002, and
they will be managed using the
shared SNIP 192.168.10.103.
NYC-ADC-002 192.168.10.102 Secondary member of HA Pair with
NYC-ADC-001.
CREDENTIALS LIST: Training Domain Users and Groups
User Name Groups Password Description
administrator Domain Admins Password1 Domain administrator account which can

be used to access domain controllers.
Otherwise, not needed in class.
trainNSAdmin Training_NSAdmins Password1 Domain account used in Citrix ADC
delegated administration exercise.
trainNSOperator Training_NSOperators Password1 Domain account used in Citrix ADC
delegated administration exercise.
trainADUser Domain Users Password1 Domain account used as LDAP BindDN
service account.
training\Contractor Contractors Password1 Domain account available for Citrix ADC
demonstrations.
CREDENTIALS LIST: Citrix ADC Local Accounts
User Name Delegated Admin Password Description

Role
nsroot superuser nsroot Built-in Citrix ADC account that will be used
for all exercises.
testuser custom Password1 Test account for delegated administration.
padmin1 Partition Admin Password1 Test account for Admin Partitions exercise.
padmin2 Partition Admin Password1 Test account for Admin partitions exercise.
7
Module 1: Getting Started

Overview:
Company ABC has recently installed two additional Citrix ADCs in its primary office location. Your job as the
administrator is to complete the initial configuration of the appliances and prepare them for use in a high
availability configuration (implemented in later modules).
In this module, you will perform hands-on exercises to perform the initial configuration of the Citrix ADC and by
performing tasks like configuring the NSIP, SNIP, DNS server, hostname, and time synchronization. You will also
perform additional administrative tasks on the Citrix ADC like managing to license and viewing, editing, and backing
up the Citrix ADC configuration.
After completing this lab module, you will be able to:
• Identify the tasks required to complete the initial configuration and basic networking settings of a
Citrix ADC appliance.
• Upgrade the Citrix ADC.
• Manage the Citrix ADC licensing.
• Manage and save Citrix ADC configurations.
• Perform configuration backups
This module contains the following exercises using the Citrix ADC Configuration Utility GUI and the Citrix ADC CLI.
• Exercise 1-1: Performing an Initial Configuration

• Exercise 1-2: Performing Basic Administration
Before you Begin:

Estimated time to complete this lab module: 20 minutes
Virtual Machines required for this module

For Module 1, connect to your assigned Hyper-V Manager console and verify that the following virtual machines
are running. If any of the virtual machines are not running, use Hyper-V Manager to turn them on. Otherwise, the
Hyper-V Manager will not be needed for the rest of the module.
• NYC-ADC-001
• NYC-ADC-002
• NYC-ADS-001
The management URLs for the Citrix ADCs are:
• NYC-ADC-001 NSIP (initial): http://192.168.100.1

• NYC-ADC-001 NSIP (final): http://192.168.10.101
• NYC-ADC-002 (NSIP): http://192.168.10.102
• ADCMGMT SNIP (for NYC-ADC-001 and NYC-ADC-002): http://192.168.10.103.
8
Exercise 1-1: Performing an Initial Configuration (CLI)

Introduction:
In this exercise, you will perform the initial configuration and other related tasks from the
command-line interface over SSH. After this initial configuration, you will upgrade the existing
Citrix NetScaler to a Citrix ADC.
Citrix NYC-ADC-001 starts with the default NSIP address 192.168.100.1 with a /16 subnet mask.
During the initial configuration, you will change the NSIP from the default value to the assigned
NSIP address for this environment 192.168.10.101 with a /24 subnet mask.
In this exercise, you will perform the following tasks:
• Configure the initial NSIP and SNIP

• Configure DNS, Hostname, and Time Synchronization
• License the Citrix ADC Appliance
• Update from the Citrix NetScaler to the Citrix ADC
While normally the password for nsroot should also be changed, this password will not be
changed in the lab exercises.
Step Action
1. Connect to NYC-ADC-001 using the default NSIP address (192.168.100.1) using SSH (PuTTY):
Use the PuTTY shortcut on the desktop of your HOST desktop
OR
Start > Run > putty 192.168.100.1
Log on to the utility using the following credentials:
• User Name: nsroot

• Password: nsroot
Note: The default NSIP address will be changed in this exercise. As a result, the connection URL will
change to the permanent IP address in later steps.
2. Use the config ns command to begin the initial Citrix ADC configuration:
config ns
9
3. Configure NSIP, Subnet Mask, and Default Gateway.
Use config ns to configure the Initial NSIP address. It will then prompt for the subnet mask. Change
the default values to the new values required for the class.
• Enter option 1 to begin:

• Enter the Citrix ADC's IP address [192.168.100.1]:192.168.10.101
• Enter the Netmask (255.255.255.0): 255.255.255.0
• Enter option 7 to apply changes and exit.
• Do you want to save the new configuration? [Yes]: Enter Yes
• Do you want to reboot the system now?[NO], Enter Yes to restart now.
The Citrix ADC will restart. After the restart, the new NSIP (192.168.10.101) is effective.
4. Connect to NYC-ADC-001 using the new NSIP (192.168.10.101) using SSH (PuTTY):
Use the PuTTY shortcut on the desktop of your HOST desktop
Or
Start > Run > putty 192.168.10.101

Click Yes on Security Alert if prompted. Log On with the following
credentials:

5. Configure the default route and gateway:
Add a default gateway to the Citrix ADC for the 192.168.10.0/24 network:
add route 0.0.0.0 0.0.0.0 192.168.10.254
Note: We are using an internal route as our default because we are going to be setting up Mac Based
Forwarding.
6. Assign a SNIP (192.168.10.111):
add ns ip 192.168.10.111 255.255.255.0 -type SNIP
7. Upload a license file to the Citrix ADC:
• Open WinSCP using the shortcut on the Desktop. Connect to NYC-ADC-001
(192.168.10.101).
• If necessary Click Yes on the Security Warning, If needed and login with
nsroot/nsroot.
• In the left pane, browse to C:\Resources\Citrix ADC License, In the right
pane, browse to /nsconfig/license/.
• Copy the license file
Netscaler_VPX1_PLT_Citrix_Education_Expires_20221201.lic from
C:\Resources\Citrix ADC license\ to /nsconfig/license/ on the Citrix ADC.
10
8. Return to the PuTTY session and save the Citrix ADC Configuration:
save ns config
9. Perform a warm restart to apply license file changes:
reboot -warm
When prompted Are you sure you want to restart Citrix ADC (Y/N)? [N]:
enter Y
10. Reconnect to NYC-ADC-001 using the new NSIP (192.168.10.101) using SSH (PuTTY).

11
11. Verify that the license was applied:

show ns license
Almost all features should be available, including Load Balancing, SSL Offloading, Compression,
Responder, and Rewrite.
12. Configure the Citrix ADC hostname:
set ns hostname NYC-ADC-001
13. Configure the Citrix ADC with a DNS server (for name resolution):
add dns nameserver 192.168.30.11
12
14. Configure NTP Time Synchronization. Use the domain controller ad.workspacelab.com
(192.168.30.11) as the NTP Server.
Add the NTP Server:

add ntp server 192.168.30.11
Set as preferred server:

set ntp server 192.168.30.11 -preferredNtpServer YES
Enable NTP Synchronization:

enable ntp sync
Note: Settings for NTP synchronization are in the /nsconfig/ntp.conf file and are not in the Citrix ADC
running or saved configuration (/nsconfig/ns.conf).
15. Increase CLI Idle Timeout.
Change the global parameter (to affect all users):

set system parameter -timeout 43200
Change CLI mode display options and session timeout (user property for this user):
set cli mode -color on -page off -timeout 43200
CAUTION: This step is being done to simplify connection management for lab purposes only.
Extending the timeout will allow CLI sessions to remain connected for longer periods without
terminating. This will allow students to keep SSH sessions running between lab exercises. This
timeout may not be appropriate in a production environment as it could result in a security
vulnerability by allowing unauthorized users to get access to a Citrix ADC via an existing administrator
connected session.
16. Disable Citrix User Experience Improvement Program:
set system parameter -doppler disabled
17. Save the Citrix ADC configuration:
save ns config
Manually set the time on a Citrix ADC appliance

1. Connect to the NYC-ADC-001 via PuTTY to access the CLI
Open a PuTTY session to NYC-ADC-001.

• Launch the PuTTY.exe icon from the HOST desktop
• Select the NYC-ADC-001 and click Open.
• Login using nsroot/nsroot
13
2. Confirm the current date and time settings by entering the following commands:
shell
date
3. Manually adjust the time and date on the Citrix ADC to Match the time zone you selected.
Note: To change the time on a Citrix ADC appliance, use the date command with the +val (value)
parameter followed by the full date and time.
EXAMPLE: date YYMMDDHHMM

the date and time requested was 10/9/18 at 3:47 pm the command would look as
follows: date 1810091547
Where :
YY = Year
MM = Month
DD = Day
HH = Hour
MM = Minutes
Use the following command replacing the YYMMDDHHMM with the date and time zone information
you have selected in 24-hour format
date YYMMDDHHMM
4. Confirm the current date and time settings by entering the following commands:
Date
5. Save the Citrix ADC configuration
14
Upgrade the NetScaler to Citrix ADC

6. Open an SSH session using PuTTY:
Connect to Citrix NYC-ADC-001 (192.168.10.101) using SSH (PuTTY).
Log on as nsroot/nsroot.
7. NYC-ADC-001 - Upgrade Citrix ADC NYC-ADC-001
Extract Build Files:

Shell
cd /var/nsinstall/build_58_32
ls
tar –xzvf build-13.0-58.32_nc_64.tgz
Wait for few minutes to extract and then proceed with the next steps.
Note: If this command “cd /var/nsinstall/build_58_32” didn’t work, use tab button to complete the
step.
8. After the files are extracted, run the upgrade:
./installns
Once the install has completed select Y when directed to reboot.

9. Reconnect to Citrix ADC NYC-ADC-001 (192.168.10.101) using SSH (PuTTY).

Verify the version:

show ns version
Key Takeaways:
• From the command-line interface, the initial configuration tasks are handled as
individual tasks instead of using an all-in-one wizard, as in the GUI configuration.
• The NSIP can be configured from the CLI using the config ns utility. Changing the NSIP
requires a restart.
• All commands in the Citrix ADC are active and in use the moment they are configured as
part of the running configuration. Saving the configuration preserved the settings and
writes them to file. Saving the config is imperative for preserving the current settings.
15
• The saved Citrix ADC configuration, the licensing files, and NTP synchronization settings
are stored in flash in the /nsconfig/ and /nsconfig/licenses/ directories.
• The Initial Configuration Wizard can be used to change the NSIP address at any time.
The equivalent at the CLI is the config ns command. Changing the NSIP requires a
restart.
Exercise 1-2: Performing Basic Administration (GUI)

Introduction:
In this exercise, you will learn to perform essential administrative tasks using the Citrix ADC
Configuration Utility GUI. In this exercise, you will perform the following tasks:
• Enable Citrix ADC Features

• View Running and Saved Configurations and Configuration Differences
• Back-Up the Citrix ADC Configuration (/nsconfig)
About Citrix ADC Configuration Management
The running configuration refers to the Citrix ADC configuration in memory. Configuration
changes are active the moment they are executed and are part of the running configuration.
The running configuration can be viewed in the System > Diagnostics node or by running the
"show ns runningConfig" in the CLI. The Citrix ADC configuration utility GUI and the CLI all apply
changes against the current running configuration.
To preserve settings, a save configuration command must be issued in the GUI or CLI. The save
configuration command forces the Citrix ADC to write the running configuration to file. This file
is located on /nsconfig/ns.conf (in flash) and is referred to as the saved configuration file. When
a Citrix ADC restarts, the installed kernel is loaded into RAM and then settings from the saved
configuration file are applied as the new running configuration. Any unsaved changes are lost
during a system restart.
When making configuration changes, the running and saved configurations can be compared to
see which settings are new or have not yet been saved. This can be useful in troubleshooting.
This exercise demonstrates how to manage the saved configuration and compare saved and
running configurations on the Citrix ADC.
Enable Citrix ADC Features

Step Action
1. Connect to the NYC-ADC-001 Configuration Utility at http://192.168.10.101.
16
2. Enable Citrix ADC features (Basic):

• Browse to System > Settings in the left pane.
• Select Configure Basic Features in the right pane.
• Select the checkbox and Enable the following features:
o SSL Offloading
o Load Balancing
o Content Filter
o Rewrite
o HTTP Compression
o Content Switching
Click OK.
3. Enable Citrix ADC features (Advanced):
• Browse to System > Settings in the left pane.
• Select Configure Advanced Features in the right pane.
• Select (check) and Enable the following feature: Responder
• Click OK.
4. Do not save the configuration at this point.
View Running and Saved Configurations

Step Action
1. Browse to System > Diagnostics.
IMPORTANT: Do not save the configuration until instructed in this exercise.

2. Click Saved configuration to display the current saved configuration.
Notice that the command “enable ns feature” in line 4 only shows CH in the current saved
configuration.
3. Click Close.
4. Click Running configuration to display the current running configuration.
Notice that this time the "enable ns feature" includes a list of features enabled in the previous task.
5. Click Close.
6. Click Saved v/s running to compare the saved and running configurations.
Verify that the configurations are identical except for the "enable ns feature" command.
7. Click Close.
8. Save the Citrix ADC configuration and confirm.
9. Verify that saved and running configurations are the same:
• Browse to System > Diagnostics.
• Click Saved v/s running to compare the saved and running configurations.
• Verify "no difference found" is reported.
• Click OK.
• Click Close.
17
10. View Citrix ADC System Details:

• Browse to System.
• View System Information and Hardware Information in the right-pane.
Performing a Configuration Backup

Step Action
1. Backup method 1: Using the CLI from the configuration Utility and a manual tar command.
This method will use tar to create an archive of the entire /nsconfig directory.
Access the Citrix ADC CLI from the Configuration Utility:

• Click Command-line interface in the utility section.
• This allows access to a CLI session over SSH via the web browser window.
Alternatively, an SSH connection can be made using the PuTTY or alternate program to access the CLI.
2. Create an archive. Type the following command in the command field and click Go after each
command to submit:
shell
tar -cvzf /var/tmp/backup.tgz /flash/nsconfig/
3. Verify that the backup was created:
Continue using the Command-Line Interface (CLI) utility. Click Go after each command to submit.
cd /var/tmp/
ls
4. Click Close.
5. Use WinSCP to connect to Citrix ADC NYC-ADC-001 (192.168.10.101):
• Open WinSCP using the shortcut on the Desktop.
• Double-click the saved session NYC-ADC-001 to connect to 192.168.10.101.
Log on with the credentials below and accept the security warning when presented.

6. Copy the backup file from the Citrix ADC to the HOST desktop:
• In the right-pane, browse to the /var/tmp/ directory.
• Use the top icon to move up a directory level until you reach "/" (root), then browse to
/var/tmp/.
• In the left pane, browse to C:\Resources\ on the HOST desktop.
• Copy backup.tgz from the Citrix ADC to the HOST desktop by dragging the file from the right
pane to the left pane.
7. Close WinSCP and click OK to confirm.
18
8. Backup method 2
Using the Backup and Restore function in the Configuration Utility GUI.
• Browse to System > Backup and Restore.
• Click Backup/Import.
Specify a backup file to create:
• Type backup1 in the File Name field.
• Select Full in Level drop-down list box.
• Click Backup.
The built-in backup and restore option performs two-levels of backups: basic or full.
The “Basic” backup backs up only configuration files in /nsconfig/ and other files from selected
directories on /var/ and /netscaler/. It does not include the SSL certs or license files. The “Full” backup
includes these. See the Citrix ADC Administrator’s Guide for full details.
The backup is created in /var/ns_sys_backup/ on the Citrix ADC.

9. Right-click backup1.tgz and click Download.
10. View the downloaded folder.
• Depending on the browser, you should be able to select the download file and select Show in
folder.
OR
• Browse to the default downloads directory: C:\users\localuser\Downloads.
• Verify that the download exists.
Key Takeaways:
• All configuration changes are applied to the running configuration in memory. Unsaved
settings can be lost during a system restart.
• To preserve settings, the configuration must be saved. The saved configuration is
located in flash in /flash/nsconfig/ns.conf.
• Configuration backups should be performed to back up the saved configuration and
other essential settings.
Exercise 1-2: Performing Basic Administration (CLI)
Introduction:
In this exercise, you will learn to perform essential administrative tasks using the command-line
interface.
• Enable features.
• View running and saved configurations and configuration differences. Back
up the Citrix ADC configuration (/nsconfig).
19
About Citrix ADC Configuration Management
The running configuration refers to the Citrix ADC configuration in memory. Configuration
changes are active the moment they are configured are part of the running configuration. The
running configuration can be viewed in the System > Diagnostics node or by running the "show
ns runningConfig" in the CLI. The Citrix ADC Configuration Utility GUI and the CLI all apply
changes against the current running configuration.
To preserve settings, a save configuration command must be issued in the GUI or CLI. The save
configuration command forces the Citrix ADC to write the running configuration to file. This file
is located on /nsconfig/ns.conf (in flash) and is referred to as the saved configuration file. When
a Citrix ADC restarts, the installed kernel is loaded into RAM and then settings from the saved
configuration file are applied as the new running configuration. Any unsaved changes are lost
during a system restart.
When making configuration changes, the running and saved configurations can be compared to
see which settings are new or that have not been saved yet. This can be useful in
troubleshooting.
This exercise demonstrates how to manage the saved configuration and compare saved and
running configurations on the Citrix ADC.
Step Action
1. Connect to Citrix ADC NYC-ADC-001 (192.168.10.101) using SSH (PuTTY). Log on as nsroot/nsroot.
IMPORTANT: Do not save the configuration until instructed in this exercise.

2. The display features licensed on the Citrix ADCs:
show ns license
20
3. Display features enabled or disabled on the Citrix ADC:

show ns feature
4. Enable Citrix ADC Features:

• Load Balancing (LB)
• Content Switching (CS)
• HTTP Compression (CMP)
• SSL Offloading (SSL)
• Content Filtering (CF)
• Responder
• Rewrite
enable ns feature LB CS CMP SSL CF Responder Rewrite
21
5. View the current running configuration:

show ns runningConfig
Additional commands can be used to view or search the running configuration:

show ns runningConfig | more
show ns runningConfig -withDefaults | more
Grep can be used to search on the running-config. Grep is usually case-sensitive; -i forces a case-
insensitive search.
show ns runningConfig | grep feature

show ns runningConfig | grep route
show ns runningConfig | grep "ns ip" –i
Note: In case you need to abort the output press CTRL+C
6. View the current saved configuration:
show ns ns.conf
show ns ns.conf | more
7. Compare the current running and saved config (manually):
Running Config:
show ns runningConfig | grep feature
Saved Config:
show ns ns.conf | grep feature
8. Use the diff command to compare the running and saved config:
diff ns config -outtype cli

diff ns config -outtype cli | more
save ns config
10. Verify that there is no difference in the running and saved the configuration:
diff ns config -outtype cli
22
11. Identify Citrix ADC Hardware/Product Type:

show ns hardware
Results will be similar to:

Platform: Citrix ADC Virtual Appliance 450000
Manufactured on: 2/17/2009
CPU: 3500MHZ
Host Id: XXXXXXXXXXX
Serial no: XXXXXXXXXXX
Encoded serial no: XXXXXXXXXXXXXXXXXXX
Netscaler UUID: xxxxxxxx-xxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
12. Backup method 1: Using the CLI and manual tar command.
This method will use tar to create an archive of the entire /nsconfig directory.
Access the BSD shell: shell
View the /flash/nsconfig/ directory:

cd /flash/nsconfig/
ls
Create a tar archive of the /flash/nsconfig/ directory (and all subdirectories) in the /var/tmp/ directory:
tar -cvzf /var/tmp/backup.tgz /flash/nsconfig/
Note: All commands, paths, and filenames are case sensitive in BSD Shell.
13. Verify that the backup was created:
cd /var/tmp/
ls
Confirm that a file named backup.tgz exists.

14. Exit Shell and return to the CLI:
exit
Note: Running exit again will exit the CLI and terminate your SSH session, closing PuTTY.
23
15. Download the backup file from the Citrix ADC using WinSCP:
• Open WinSCP using the shortcut on the Desktop. Connect to NYC-ADC-001 (192.168.10.101)
and login with username nsroot and password nsroot.
• In the left pane, browse to C:\Resources\.
• In the right pane, browse to /var/tmp/.
• Copy the file backup.tgz from /var/tmp/ (right-pane) to C:\Resources\ (left-pane). Copy the
file by dragging it from one pane to the other.
Close WinSCP.
16. Backup method 2:
Using the system backup command.
This method is the same as using the Backup and Restore utility in the GUI.
create system backup backup1 -level full
About Backup and Restore Option performs two-levels of backups: basic or full.
Basic backs up only configuration files in /nsconfig/ and other files from select directories on /var/ and
/netscaler/. It does not include the SSL certs or license files. The Full backup includes these. See the
Citrix ADC Administrator’s Guide for full details.
Backup location: /var/ns_sys_backup

17. OPTIONAL - Download the backup file from the Citrix ADC using WinSCP:
• Open WinSCP using the shortcut on the Desktop. Connect to NYC-ADC-001 (192.168.10.101).
• Login with nsroot/nsroot credentials.
• In the left pane, browse to C:\Resources\
• In the right pane, browse to /var/ns_sys_backup/
• Copy the file backup1.tgz from /var/tmp/ (right-pane) to C:\Resources\ (left-pane). Drag the
file to copy it from one pane to the other.
Close WinSCP.
Key Takeaways:
• All configuration changes are applied to the running configuration in memory. Unsaved
settings can be lost during a system restart.
• To preserve settings, the configuration must be saved. The saved configuration is
located in flash in /flash/nsconfig/ns.conf.
• Configuration backups should be performed to back up the saved configuration and
other essential settings.
24
Module 2: Basic Networking

Introduction:
After the initial Citrix ADC configuration, you are tasked with configuring the Citrix ADC with
networking access. The Citrix ADC is configured with a two-interface inline configuration.
The Citrix ADC needs to be configured with a default gateway for the Citrix ADC
Management network (192.168.10.0/24). Through the management network, the Citrix ADC
will also have access to the Backend Network (192.168.30.0/24). Virtual IP addresses will be
hosted in the Frontend network (172.21.10.0/24).
In this environment, interface 1/1 is associated with the Frontend Network and interface 0/1 is
associated with the Management and Backend Networks.
Figure 1: Simplified Lab Network Diagram
During the networking configuration of the NYC-ADC-001, you need to address multiple
configuration objectives.
Initial networking already completed in Module 1:
• Configure a SNIP for application traffic (192.168.10.111/24).

• Configure a default route for the Citrix ADC Management Network (gateway
192.168.10.1).
Requirements for this scenario:
• Test connectivity to the Backend Network (192.168.30.0/24).
27
• Implement a VLAN configuration and prevent access to the NSIP address from
the Frontend Network and the associated interface (1/1).
• Enable MAC-based forwarding to ensure that traffic returns over the same
interface it was received.
About the VLAN Configuration:
This Citrix ADC is being deployed in an inline configuration where interface 1/1 will act as the
frontend interface with access to the 172.21.10.0/24 (Frontend) network and interface 0/1 will
act as the backend interface with access to the 192.168.10.0/24 (Management) and
192.168.30.0/24 (Backend) networks.
The NSIP will continue to be associated with the native VLAN (VLAN 1). But the frontend
interface (1/1) will be associated with VLAN 2, which will remove it from the native VLAN. This
will isolate interface 1/1 from accessing the NSIP. With only one interface remaining associated
with VLAN 1, this effectively isolates the NSIP (and other management SNIPs) to only being
accessible from VLAN 1 over interface 0/1.
Additional requirements for this scenario:
• Configure VLAN 2 on the Citrix ADC and restrict it to interface 1/1 only.
• Associate a network with VLAN 2 and interface 1/1 for frontend resources. The
Frontend Network will be hosting virtual IP addresses only, so no additional Subnet
IP addresses will be required. Instead, create an initial virtual IP address 172.21.10.101
with a 255.255.255.0 Netmask and bind it to VLAN 2. This will limit access to all virtual IP
addresses in the 172.21.10.0 /24 network that will be configured in later exercises to
interface 1/1 and VLAN 2 only.
VLAN Configuration Summary:
VLAN Interface IP Address and Details
Netmask
1 0/1 <Default> NSIP and SNIPs in 192.168.10.0 /24
network.
Accessible to backend resources
2 1/1 172.21.10.101 /24 Frontend VIP Network
28
• Configure interface, IP address, and route properties on the Citrix ADC.  Bind IP
addresses and interfaces to VLANs to manage traffic flow.
This module contains the following exercise using the Citrix ADC Configuration Utility GUI and
the Citrix ADC CLI:
• Exercise 2-1: Configuring Networking

Before you Begin:
Estimated time to complete this lab: 10 minutes

For Module 2, connect to your assigned Hyper-V Manager console and verify that the following
virtual machines are running. If any of the virtual machines are not running, use Hyper-V
Manager to turn them on. Otherwise, Hyper-V Manager will not be needed for the rest of the
module.
• NYC-ADC-001
Exercise 2-1: Configuring Networking (GUI)

Introduction:
In this exercise, you will learn to configure a Virtual IP, VLANs, and Mac-based Forwarding. You
will use the Citrix ADC Configuration Utility GUI to perform this exercise.
• Test network connectivity.

• Configure VLAN 2 and restrict access to interface 1/1 and the Virtual IP range.
• Enable MAC-based Forwarding mode.
Step Action
1. Connect to the Citrix ADC NYC-ADC-001 configuration utility at http://192.168.10.101.

29
2. Test Connectivity from the Citrix ADC to a backend network address:

• Click Ping (under Utilities).
Use the following parameters:
• Type 192.168.30.51 in Host name field.
• Type 3 in Count field.
• Click Run.
Wait a few seconds for the ping output to display and confirm connectivity with backend
addresses (in the 192.168.30.0/24 network).
• Click Close and Close to close the ping utility.
3. Configure a Virtual IP range using a virtual IP with a subnet mask.
Add a virtual IP:

• Browse to System > Network > IPs.
• Click Add.
Create an IP address (VIP1):
• Type 172.21.10.101 in the IP Address field.
• Type 255.255.255.0 in the Netmask field.
• Select Virtual IP from the IP Type drop-down list box.
• Deselect Enable Management Access control to support the below-listed
applications.
• Click Yes to confirm the setting.
• Click Create.
Note: All the virtual IP addresses in this Citrix ADC host will be in the 172.21.10.0 /24
subnet. This exercise adds the initial VIP 172.21.10.101 and defines the subnet. The subnet
is being configured for association with the VLAN in a later exercise.
4. Verify that the following IP addresses are displayed in the IPV4s IP Address list under
System > Network > IPs:
• 192.168.10.101 (NSIP)
• 192.168.10.111 (SNIP)
• 172.21.10.101 (VIP)
5. Create a VLAN for the Frontend Network where the VIPs reside and associate it with the
frontend interface 1/1.
• Browse to System > Network > VLANs.
• Click Add.
30
6. Create VLAN 2 and bind it to interface 1/1 and the IP subnet 172.21.10.101 /24:
• Enter 2 in the VLAN ID field.
• Select the 1/1 checkbox on the Interface Bindings tab. The Tagged field
checkbox should remain unselected.
• Click IP Bindings tab.
• Select 172.21.10.101 checkbox to associate the VIP and its subnet with the
VLAN.
• Click Create.
Note: Binding interface 1/1 with VLAN 2 removes it from the default VLAN 1 on the Citrix
ADC. Binding the virtual IP 172.21.10.101 /24 with the VLAN also forces all virtual IPs in this
network to be associated with the MAC address of interface 1/1 only.
If the wrong Interface or IP address is bound to VLAN 2 students may lose access to the
Citrix ADC management interface. Use Hyper-V Manager to access the console for NYC-ADC-
001 and remove the VLAN and reconfigure the correct VLAN from the CLI.
7. Verify VLAN configuration:
• View VLAN summary at System > Network > VLANs.
• Verify that VLAN 1 is associated with bound interfaces 0/1 and LO/1.
• Verify that VLAN 2 is associated with bound interface 1/1.
RESULT: The NSIP, SNIP, and VLAN 1 are accessible from the backend interface 0/1. All VIPs
and VLAN 2 are accessible via the frontend interface 1/1.
8. Enable MAC-based Forwarding (MBF) mode:
• Browse to System > Settings.
• Click Configure Modes.
• Select the MAC based forwarding checkbox.
• Leave existing modes selected.
• Click OK.
Note: We are enabling Mac Based Forwarding to simplify our routing table. MBF should only
be used in certain environments and specific network set up. Certain features like PBR will
not work with MBF.
9. Test Connectivity from the Citrix ADC to a backend network address:
• Click Ping (under Utilities).
Use the following parameters:
• Type 192.168.30.51 in Host Name field.
• Type 3 in the Count field.
• Click Run.
Wait a few seconds for the ping output to display and confirm connectivity with backend
addresses (in the 192.168.30.0/24 network).
• Click Close and Close to exit the ping utility.
31
Key Takeaways:
• A default route is specified to guarantee access to the NSIP and the management
network.
• IP addresses on the Citrix ADC are owned by all interface (by default). To restrict
access to specific IP addresses and a specific interface, use a VLAN.
• The NSIP is associated with the NSLAN. By default, the NSVLAN is the native
VLAN on the appliance, VLAN 1. While the NSVLAN can be changed, it is preferable to
keep it on VLAN1. Since all interfaces are also associated with VLAN 1, the NSIP is
accessible from all interfaces by default.
• An interface can only participate in a single port-based VLAN at a time. By
binding an interface with a VLAN, you can limit which interfaces do or do not have
access to the native VLAN. As a result, access to the NSIP can be limited to only specific
interfaces as appropriate.
Exercise 2-1: Configuring Networking (CLI)

Introduction:
In this exercise, you will learn to configure a virtual IP, VLANs, and MAC-based forwarding. You
will use the command-line interface to perform this exercise.
• Test network connectivity.

• Configure VLAN 2 and restrict access to interface 1/1 and the Virtual IP range.
• Enable MAC-based forwarding mode.
Step Action
1. Connect to NYC-ADC-001 using the new NSIP (192.168.10.101) using SSH (PuTTY).
User Name: nsroot

Password: nsroot
2. Test connectivity:
ping -c 3 192.168.30.51
32
3. Add a virtual IP address to the Citrix ADC:

add ns ip 172.21.10.101 255.255.255.0 -type VIP
Note: All of the virtual IP addresses this Citrix ADC will host will be in the 172.21.10.0 /24
subnet. This exercise adds the initial VIP 172.21.10.101 and defines the subnet. The subnet
is being configured for association with the VLAN in a later exercise.
4. Configure a VLAN:
• Create the VLAN: (for frontend network) add vlan 2

• Bind the VLAN to the frontend interface:
bind vlan 2 -ifnum 1/1
• Bind the Subnet IP address to this VLAN (to source traffic from the Citrix ADC to the
backend servers):
bind vlan 2 -ipAddress 172.21.10.101 255.255.255.0
RESULT: The NSIP, SNIP, and VLAN 1 are accessible from the "backend" interface (0/1).
All VIPs are accessible via the "frontend" interface (1/1).
Note: Binding interface 1/1 with VLAN 2 removes it from the default VLAN 1 on the Citrix
ADC. Binding the virtual IP 172.21.10.101 /24 with the VLAN also forces all Virtual IP
addresses in this network to be associated with the MAC address of interface 1/1 only.
If the wrong interface or IP address is bound to VLAN 2, students may lose access to the
Citrix ADC management interface. In that case, use Hyper-V Manager to access the console
for NYC-ADC-001 and remove the VLAN and reconfigure the correct VLAN from the CLI.
5. Verify the VLAN Configuration:
show vlan
Verify that interfaces 0/1 and the loopback interface (LO/1) are still part of VLAN 1.
Verify that interface 1/1 and the Subnet IP are associated with VLAN 2.
6. Enable MAC-based forwarding:
enable ns mode mbf
or
enable ns mode MACbasedforwarding
Note: We are enabling Mac Based Forwarding to simplify our routing table. MBF should
only be used in certain environments and specific network set up. Certain features like PBR
will not work with MBF.
7. Test the configuration:
ping -c 3 192.168.30.51
save ns config
Key Takeaways:
33
• A default route is specified to guarantee access to the NSIP and the management
network.
• IP addresses on the Citrix ADC are owned by all interfaces (by default). To restrict access
to specific IP addresses and a specific interface, use a VLAN.
• The NSIP is associated with the NSLAN. By default, the NSVLAN is the native VLAN on
the appliance, VLAN 1. While the NSVLAN can be changed, we recommend keeping it on
VLAN1. Since all interfaces are also associated with VLAN 1, the NSIP is accessible from
all interfaces by default.
• An interface can only participate in a single port-based VLAN at a time. By binding an
interface with a VLAN, you can limit which interfaces do or do not have access to the
native VLAN. As a result, access to the NSIP can be limited to only specific interfaces as
appropriate.
34
Module 4: High Availability

Introduction:
Now that NYC-ADC-001 is configured with an NSIP address, licensing, and is fully configured
on the Network, your job is to configure NYC-ADC-001 and NYC-ADC-002 in a
HighAvailability pair with NYC-ADC-001 as the primary Citrix ADC.
In this module, you will perform hands-on exercises to create a High-Availability pair.
Requirements for this scenario:
• Configure an HA Pair using NYC-ADC-001 (192.168.10.101) and NYC-ADC-002

(192.168.10.102).
• Use NYC-ADC-001 as the authoritative Citrix ADC during the initial creation of the
HA pair so that its settings are used as the primary configuration.
• Configure a management SNIP for the HA pair which can be used to administer
the current primary Citrix ADC in the pair. Restrict this SNIP to management
access only.
The purpose of the High-Availability exercise is to allow students to not just configure the
HA Pair but to also continue working with and administering the HA pair throughout the
rest of the course. Both members will be kept as active members of the HA pair during
upcoming exercises (except for during the troubleshooting exercise). You will not need to
break the HA Pair during the course.
• Configure an HA pair and manage which Citrix ADC is primary.

• Adjust HA settings to control failover, synchronization, and propagation. 
Manage an HA pair using a shared SNIP address.
The module contains the following exercises using the Citrix ADC Configuration Utility GUI
and the Citrix ADC CLI:
• Exercise: Configuring an HA Pair

• Exercise: Managing an HA Pair
Before you Begin:

For Module 4, connect to your assigned Hyper-V Manager console and verify that the
following virtual machines are running. If any of the virtual machines are not running, use
35
Hyper-V Manager to turn them on. Otherwise, Hyper-V Manager will not be needed for the
rest of the module.
• NYC-ADC-001
• NYC-ADC-002
Exercise 4-1: Configuring an HA Pair (GUI)
Introduction:
In this exercise, you will learn to configure an HA Pair. NYC-ADC-001 has initial
configurations related to networking that need to be preserved. The procedure in this
exercise will demonstrate how to create the HA Pair and control which system is identified
as Primary in the initial configuration. You will use the Citrix ADC Configuration Utility GUI to
perform this exercise.
In this exercise, you will perform the following tasks to configure the HA pair:
• Preparation: Ensure that both Citrix ADCs have an NSIP address configured and are
properly licensed. Also ensure that each Citrix ADC is of the same platform (VPX,
MPX, or SDX instance), model, and Citrix ADC firmware version.
• Set the intended secondary Citrix ADC to StaySecondary prior to creating the HA Pair.
• On the intended primary Citrix ADC, configure the HA Pair and point to the
secondary Citrix ADC's NSIP. Through the GUI, the secondary Citrix ADC is also
configured to join the pair.
• Verify that both Citrix ADCs are in the HA pair and that HA synchronization is
successful.
• Perform firmware upgrade of the HA pair.
• Remove the StaySecondary option from the secondary Citrix ADC and restore it to
normal HA participation (HA Status is enabled).
• Test failover to confirm HA operation. 
• Save the configuration.
At the end of this exercise, both members will be ongoing, participatory members in the HA
pair and failover could occur freely. For the next couple of exercises, take note of whether
you are connected to the Primary or Secondary member of the HA pair. Citrix ADC device in
the Secondary state will always give following pop up whenever the user logs in:
36
During this exercise, configuration commands will be issued to two different Citrix ADCs. Pay
attention to which system each lab step or group of steps refers to. For best results, open
two different browser windows and arrange them side-by-side or so that you can easily
switch back and forth between the Citrix ADCs.
Step Action
1. Open two different web browser windows:
• In the first browser, connect to the Citrix ADC NYC-ADC-001 Configuration
Utility at http://192.168.10.101. Log on as nsroot / nsroot.
• In the second browser, connect to the Citrix ADC NYC-ADC-002
Configuration Utility at http://192.168.10.102. Log on as nsroot / nsroot.
Note: If you get a pop up to save the password in Google Chrome, Click Save.
2. NYC-ADC-002 - Click Skip to exit the Citrix User Experience Improvement Program.
3. NYC-ADC-002 - The Initial Configuration Wizard is displayed since some essential
settings are not yet configured. Bypass the wizard:
Click Continue
4. NYC-ADC-001 - Prepare for HA by viewing initial settings:
Identify current Citrix ADC-owned IP addresses:
• Take note of the NSIP, SNIP, and VIP already configured.
View the current node state for a standalone Citrix ADC:

• Browse to System > High Availability > Nodes.
• Confirm that only one node is listed (Node 0) and this is assigned the NSIP of
NYCADC-001 (192.168.10.101).
37
5. NYC-ADC-002 - Prepare for HA by viewing initial settings:
Identify current Citrix ADC-owned IP addresses:

• Take note that the NSIP is the only configured IP address.
View the current node state for a standalone Citrix ADC:

• Browse to System > High Availability > Nodes
• Confirm that only one node is listed (Node 0) and this is assigned the NSIP of
NYCADC-002 (192.168.10.102).
6. NYC-ADC-002 - Configure Citrix ADC NYC-ADC-002 to
StaySecondary:
• Browse to System > High Availability > Nodes
• Select Node 0 (192.168.10.102) and click Edit.
• Select STAY SECONDARY (Remain in Listen Mode) in the High Availability Status
dropdown list box.
• Click OK.
Node State displays STAYSECONDARY.
The StaySecondary setting is used before joining the HA pair to ensure that this system
will not become the authoritative member of the configuration and overwrite settings
from NYC-ADC001. If an interface fails on the intended primary, the wrong Citrix ADC
could take over and an unexpected configuration could result. With StaySecondary
configured, if the intended primary does not take over in the Primary role, then no Citrix
ADC does until the issue is resolved. Alternatively, an administrator can choose to
configure the High Availability Status of the NYCADC-001 as STAY PRIMARY.
38
7. NYC-ADC-001 - Configure the HA Pair by adding NYC-ADC-002 to the NYC-ADC-001

configurations.
• Browse to System > High Availability > Node
• Click Add.
Create HA Node:
• Type 192.168.10.102 in the Remote Node IP Address field. (This is the NSIP
of NYC-ADC-002).
• Select Configure remote system to participate in High Availability setup
checkbox.
• Select Turn off HA Monitor interface/channels that are down checkbox.
• Clear Turn on INC (Independent Network Configuration) mode on self-
node checkbox.
• Type nsroot in the User Name field (under Remote System Login
Credential).
• Type nsroot in the Password field.
• Click Create.
In the GUI, the Create HA Node wizard can configure the partner system in one step
when the "Configure remote system to participate" setting is enabled. From the CLI, this
requires an "add ha node" command to be issued on each Citrix ADC separately.
8. Verify initial HA status.
The High-Availability summary page initially displays Node 1 (192.168.10.102) as

Unknown.
Click Refresh to update the display.
Verify that NYC-ADC-002 (192.168.10.102) is listed as:

• Master State: Secondary.
• Node State: STAYSECONDARY.
9. NYC-ADC-002 - Verify partner system.
Refresh the display of the System > High Availability > Nodes screen. Verify the
following:
• Both nodes in the HA pair are listed.
• Node 0: 192.168.10.102 (NYC-ADC-002) is listed as Staysecondary.
• Node 1: 192.168.10.101 (NYC-ADC-001) is listed as Primary.
39
10. NYC-ADC-002 - Verify that HA settings are synchronized:
View Features:
• Click Configure Basic Features.
•Verify that all features from the earlier configuration on NYC-ADC-001 are
enabled.
• Click OK.
View Modes:
• Click Configure Modes.
•Verify that MAC-based forwarding mode is enabled if it is not Enable now.
•Click OK.
View Routes:
• Browse to System > Network > Routes.
• Verify that the default route is present: 0.0.0.0 0.0.0.0 192.168.10.254
View Citrix ADC-owned IP addresses:

• Verify that the NSIP is still unique: 192.168.10.102.
• Verify that the NYC-ADC-002 has the VIP and SNIP from NYC-ADC-001.
11. NYC-ADC-001 - Test Failover (Attempt 1)

• Select Node 0 192.168.10.101
• Click Select Action > Force Failover.
• Click Yes to confirm.
Confirm: An error was received saying, "Operation is not possible due to invalid peer
state." Reason: A node-set to StaySecondary cannot take over as a Primary Citrix ADC,
even with the force failover command. Therefore, the current Primary will not
voluntarily failover.
12. NYC-ADC-002 - Disable STAYSECONDARY and enable normal HA
participation.
• Browse to System > High Availability > Node
• Select Enabled (Actively Participate in HA) in the High
Availability Status drop-down list box.
• Click OK.
13. NYC-ADC-002 - Test Failover (Attempt 2)
• Select Node 0 (192.168.10.102)
40
• Click Select Action > Force

Failover
• Click YES to confirm failover.
• Click OK in Failover started
successfully message.
Note: The Force Failover command can be issued from either Citrix ADC regardless of its
current role as Primary or Secondary. The command will always make the current
Secondary the new Primary unless the node state or node health prevents the failover.
14. Verify failover:
• Refresh the Citrix ADC Configuration Utility on both Citrix ADCs to verify failover
state.
• Either Citrix ADC will list 192.168.10.102 (NYC-ADC-002) as the current Primary
member of the HA pair.
15. NYC-ADC-001 - Perform failover again to restore NYC-ADC-001 to the Primary role:
• Click Action > Force Failover.
• Click Yes to confirm failover.
• Click OK in Failover started successfully message.
Verify that 192.168.10.101 (NYC-ADC-001) is restored as the Primary Citrix ADC in the HA
pair.
16. NYC-ADC-001 - Save the Citrix ADC configuration and confirm.
Right-click the Save icon in the right-hand corner of the Citrix ADC GUI
Click Yes when prompted.
Note: The save configuration command will propagate to the secondary system, saving
configurations on both Citrix ADCs.
Key Takeaways:
41
• Configuring an HA Pair will result in two Citrix ADCs with a shared

configuration that can be managed as a single entity from the Primary Citrix ADC.
• Using StaySecondary when creating the HA Pair can help administrators
guarantee which member is authoritative in the pair and prevent unexpected
failovers due to unforeseen issues during the initial setup phase.
• Once in an HA Pair, configuration changes will propagate from Primary to
Secondary, including commands like save ns config. As a result, administrators must
pay attention to which Citrix ADC is primary when performing administration using
the NSIP addresses.
Exercise 4-2: Managing an HA Pair (GUI)
Introduction:
In this exercise, you will learn to add a SNIP to the Citrix ADC HA Pair and restrict the SNIP to
management communication only. This is useful because the Management SNIP is a shared
IP address in the HA Pair and always connects to the current Primary node. You will use the
Citrix ADC Configuration Utility GUI to perform this exercise.
• Create a SNIP in the HA pair for management traffic (192.168.10.103/24).

• Enable management communication on this SNIP. Allow HTTP, HTTPS, and
SSH.
• Manage the HA Pair using this SNIP going forward to ensure connectivity to
the primary Citrix ADC.
Step Action
1. Keep both browsers open to the Citrix ADC Configuration Utilities of both Citrix ADCs.
• NYC-ADC-001: http://192.168.10.101
• NYC-ADC-002: http://192.168.10.102
42
2. NYC-ADC-001 (Primary) - Add a second SNIP enabled for Management Access. 

• Click Add.
Create an IP address:
• Type 255.255.255.0 in the Netmask field.
• Verify that Subnet IP is selected in the IP Type field.
Under Application Access Controls (at the bottom):

• Enable Enable Management Access to support the applications listed below.
• Disable Telnet and FTP.
• Enable SSH.
• Enable SNMP.
• Enable GUI.
• Enable Allow access only to management applications.
• Click Create.
• Click Network
Save the configuration and Confirm.

3. Connect to the Citrix ADC HA Pair Configuration Utility using the management SNIP
(ADCMGMT SNIP) at http://192.168.10.103.
User Name: nsroot

Password: nsroot
If you receive a popup asking Do you want Google Chrome to save the password for this site?
Click Save.
Starting 13.0, this error pop up when the RPC passwords are configured with default
passwords
The below steps are used to avoid error popup when RPC passwords are configured
• Browse to System > Network > RPC.
43
• Click 192.168.10.101 > Edit > enter ‘Password 1’ in Password and Confirm Password
fields.
• Click 192.168.10.102 > Edit > enter ‘Password 1’ in Password and Confirm Password
fields.
Click Save and confirm
4. Determine which Citrix ADC the management SNIP is active on:

Method1
• Go to the System Page in System Information section
• Check the NetScaler IP Address.
Method 2:
• Navigate to System > High Availability > Nodes.
• Identify which Citrix ADC is Node 0 (self-node).
The NSMGMT SNIP is always active on the current Primary member of the HA pair. Currently,
this is NYC-ADC-001 (192.168.10.101).
5. Force failover:
• Navigate System > High Availability > Nodes
• Click OK.
6. Click Refresh icon next to the save icon.
Click OK on the Error.
7. The ADC-MGMT SNIP (192.168.10.103) is now active on the NEW Primary (NYC-ADC-002). As a
result, your existing management session has expired and you must log on to the new console.
Reconnect to the Citrix ADC Configuration Utility using the ADCGMT SNIP:
http://192.168.10.103.
User Name: nsroot

Password: nsroot
If you receive a popup asking Do you want Google Chrome to save password for this site?
Click Save.
8. Determine which Citrix ADC the management SNIP is active on:
• Navigate to System > High Availability > Node

• Identify which Citrix ADC is Node 0 (self-node).
Method 2 :
44
• Navigate to System node (root node)

• Observe that the Citrix ADC IP Address is 192.168.10.102
The ADC-MGMT SNIP is now active on NYC-ADC-002 (192.168.10.102).

9. Perform a final HA failover to restore NYC-ADC-001 (192.168.10.101) as the primary Citrix ADC.
• Navigate to System > High Availability > Nodes (if not already done)
• Click OK.
10. Reconnect to the Citrix ADC Configuration Utility using the ADC-MGMT SNIP:
http://192.168.10.103.
User Name: nsroot

Password: nsroot
IMPORTANT: The Citrix ADCs NYC-ADC-001 and NYC-ADC-002 will remain in an HA pair for the rest
of this course. The reason is to allow students to administer an HA Pair as they would in
production. While NYC-ADC-001 should be the primary Citrix ADC for the rest of the course, this
cannot be guaranteed. As a result, you will need to use the shared management SNIP (NSMGMT
SNIP: 192.168.10.103) when connecting to the Citrix ADC GUI or CLI for the rest of the exercises,
unless instructed otherwise.
Key Takeaways:
• SNIPs can be set up for management communication in addition to application
traffic or they can be restricted to management access only.
• If a management SNIP is configured and restricted to management
communication only, then an additional SNIP or SNIPs for application traffic must
be configured as well.
• SNIPs are shared IP addresses in an HA configuration and therefore are always
active on the Primary Citrix ADC. As a result, a dedicated management SNIP is a
preferred method for making configuration changes, while in an HA Pair as it
guarantees an administrator is always connected to the current Primary Citrix
ADC.
• Node-specific settings should still be applied by connecting to the specific NSIP
address.
Exercise 4-1: Configuring an HA Pair (CLI)
Introduction:
45
In this exercise, you will learn to configure an HA Pair. NYC-ADC-001 has initial
configurations related to networking that need to be preserved. The procedure in this
exercise will demonstrate how to create the HA Pair and control which system is identified
as Primary in the initial configuration. You will use the command-line interface to perform
this exercise.
In this exercise, you will perform the following tasks to configure the HA pair:
• Preparation: Ensure both Citrix ADCs have NSIP address configured and are properly
licensed. Also ensure that each Citrix ADC is of the same platform (VPX, MPX, or SDX
instance), model, and Citrix ADC firmware version.
• Set the intended secondary Citrix ADC to StaySecondary prior to creating the HA
Pair.
• On the intended primary Citrix ADC, configure the HA Pair and point to the NSIP of
the secondary Citrix ADC. Through the GUI, the secondary Citrix ADC is also
configured to join the pair.
• Verify that both Citrix ADCs are in the HA pair and that HA synchronization is
successful.
• Remove the StaySecondary option from the Secondary Citrix ADC and restore it to
normal HA participation (HA Status is enabled).
• Test failover to confirm HA operation.
• Save the configuration.
At the end of this exercise, both members will be ongoing, participating members in the HA
pair and failover could occur freely. For the next couple of exercises, take note of whether
you are connected to the Primary or Secondary member of the HA pair.
Note: The Citrix ADC in secondary HA prompt will always give the following popup
whenever the user logs in to indicate that it is a secondary device in the HA pair and
configuration changes should not be performed on this device
During this exercise configuration, commands will be issued to two different Citrix ADCs. Pay
attention to which system each lab step or group of steps refers to. For best results, open two
SSH sessions using PuTTY and arrange them side-by-side or so that you can easily switch back
and forth between the Citrix ADCs.
Step Action
46
1. Open two SSH sessions using PuTTY:

• Connect to Citrix ADC NYC-ADC-001 (192.168.10.101) using SSH (PuTTY).
• Connect to Citrix ADC NYC-ADC-002 (192.168.10.102) using SSH (PuTTY).
For best results in this exercise, arrange the PuTTY windows side-by-side so you can switch
back and forth easily between sessions and compare settings as needed.
2. NYC-ADC-001 - Prepare for HA by viewing initial HA settings:
show ha node
Verify that NYC-ADC-001 is in a standalone configuration since it is the only node identified
(by NSIP).
Identify which interfaces are present on the Citrix ADC and which ones are critical
interfaces.
Notice that the current Node State and Master State are UP and Primary.
3. NYC-ADC-001 - Prepare for HA by viewing initial Citrix ADC-owned IP
addresses:
show ns ip
Identify the current configuration for:

• NSIP
• SNIP(s) if any
• VIP(s) if any
4. NYC-ADC-001 - Prepare for HA by verifying version:
show ns version
5. NYC-ADC-002 - Prepare for HA by viewing initial HA settings:
show ha node
Verify that NYC-ADC-001 is in a standalone configuration since it is the only node identified
(by NSIP).
Identify which interfaces are present on the Citrix ADC and which ones are critical
interfaces.
Notice that the current Node State and Master State are UP and Primary.
6. NYC-ADC-002 - Prepare for HA by viewing initial Citrix ADC-owned IP
addresses:
show ns ip
Identify the current configuration for:

• NSIP
• SNIP(s) if any
• VIP(s) if any
47
7. NYC-ADC-002 - Prepare for HA by verifying version:

show ns version
Verify that the version is the same as NYC-ADC-001.
8. NYC-ADC-002 - Set node to

STAYSECONDARY:
set ha node –haStatus
STAYSECONDARY
Verify node state:

show ha node
The StaySecondary setting is used before joining the HA pair to ensure that this system
will not become the authoritative member of the configuration and overwrite settings
from NYC-ADC-001. If an interface fails on the intended primary, the wrong Citrix ADC
could take over and an unexpected configuration could result. With StaySecondary
configured, if the intended primary does not take over in the Primary role, then no
Citrix ADC will until the issue is resolved.
9. NYC-ADC-001 - Configure the primary member of the HA pair and identify its partner
system:
add ha node 1 192.168.10.102
View HA Status:
show ha node
Verify node status:

• Verify Node ID 0 (192.168.10.101) is indicated as Primary.
• Notice that Node ID 1 (192.168.10.102) is still unknown. This will not change
status until the NYC-ADC-002 is also configured to participate in the HA pair.
10. NYC-ADC-002 - Join the HA Pair as a secondary
member:
add ha node 1 192.168.10.101
View HA status:
show ha node
Verify that status is received for both nodes (self-node, node 0) and partner node (node
1):
• NS_VPX_0 (192.168.10.101) is listed as Primary.
• NS_VPX_1 (192.168.10.102) is listed as Secondary with a Node State set to
STAYSECONDARY.
Sync State may be listed as “In Progress” until it completes sucessfully, in which case it
48
then displays success.
11. NYC-ADC-001 - Confirm HA configuration was

successful:
show ha node
12. Verify HA Settings are synchronized.
NYC-ADC-001 - Run the following commands to view configuration

details:
show ns ip
NYC-ADC-002 - Run the following commands to verify configuration details are in

sync:
show ns ip
Confirm that NYC-ADC-002 retains its unique NSIP address (192.168.10.102), but all
other SNIPs and VIPs are inherited from the NYC-ADC-001 configuration.
NYC-ADC-001 - Run the following commands to view

features:
show ns feature
NYC-ADC-002 - Run the following commands to verify that features are in

sync:
show ns feature
Confirm that NYC-ADC-002 has the same list of enabled features as NYC-ADC-001.
49
13. Test HA Failover.

Currently, NYC-ADC-001 is Primary. NYC-ADC-002 is StaySecondary.
NYC-ADC-001 - Attempt to force a failover:

force ha failover -force
Confirm - Following error is received
14. NYC-ADC-002 - Remove the StaySecondary setting and return the node to normal HA
participation: set ha node -hastatus ENABLED
Confirm settings:
show ha node
Verify that NYC-ADC-002 (192.168.10.102) is now identified with Node State UP and
Master State Secondary.
15. Test HA Failover (2).
This time, NYC-ADC-001 is still Primary. NYC-ADC-002 is Secondary.
NYC-ADC-001 - Attempt to force a failover:

Confirm - Failover occurs successfully without error.
Verify HA State:
show ha node
NYC-ADC-001 (192.168.10.101) is now Secondary; synchronization may be in progress.

NYC-ADC-002 (192.168.10.102) is now Primary.
50
16. Repeat failover to return NYC-ADC-001 to Primary role:
NYC-ADC-001 - Force a failover:

Confirm - Failover occurs successfully without error.
Verify HA State: show ha node
NYC-ADC-001 (192.168.10.101) is now Primary.

NYC-ADC-002 (192.168.10.102) is now Secondary.
17. Save the Citrix ADC configuration.
NYC-ADC-001 (192.168.10.101) as Primary:

save ns config
Note: The save configuration command will propagate to the secondary system, saving
configurations on both Citrix ADCs.
Key Takeaways:
• Configuring an HA Pair will result in two Citrix ADCs with a shared configuration that
can be managed as a single entity from the Primary Citrix ADC.
• Using the Staysecondary setting when creating the HA Pair can help administrators
guarantee which member is authoritative in the pair and prevent unexpected
failovers due to unforeseen issues during the initial setup phase.
• Once in an HA Pair, configuration changes will propagate from Primary to Secondary,
including commands like save ns config. As a result, administrators must pay
attention to which Citrix ADC is primary when performing administration using the
NSIP addresses.
Exercise 4-2: Managing an HA Pair (CLI)
Introduction:
In this exercise, you will learn to add a SNIP to the Citrix ADC HA Pair and restrict the SNIP to
management communication only. This is useful because the Management SNIP is a shared
IP address in the HA Pair and always connects to the current primary node. You will use the
command-line interface to perform this exercise.
• Create a SNIP in the HA pair for management traffic (192.168.10.103/24).
51
• Enable Management communication on this SNIP. Allow HTTP, HTTPS, and

SSH.
• Manage the HA Pair using this SNIP going forward to ensure connectivity to
the primary Citrix ADC.
Step Action
1. Open two separate SSH sessions using PuTTY:
• Connect to Citrix ADC NYC-ADC-001 (192.168.10.101) using SSH (PuTTY). Log on as
nsroot/nsroot.
• Connect to Citrix ADC NYC-ADC-002 (192.168.10.102) using SSH (PuTTY). Log on as
nsroot/nsroot.
For best results in this exercise, arrange the PuTTY windows side-by-side so you can switch
back and forth easily between sessions and compare settings as needed.
2. Identify which Citrix ADC is Primary. show ha
node
Confirm it is NYC-ADC-001.
3. NYC-ADC-001 (Primary) - Add a second SNIP that will be enabled for management access:
add ns ip 192.168.10.103 255.255.255.0 -type SNIP -mgmtAccess enabled
restrictAccess enabled telnet disabled -ftp disabled
4. Connect to the Citrix ADC HA Pair using the management SNIP (ADC-MGMT SNIP) at
192.168.10.103 using SSH (PuTTY).
Warning: One or more RPC nodes are configured with default passwords. For enhanced
security, you must change the default RPC node password.
Run the following commands to change the rpcNode passwords
set ns rpcNode 192.168.10.101 –password Password1
set ns rpcNode 192.168.10.102 –password Password1
save ns config
5. Determine which Citrix ADC the session is connected to:
show ha node
The session is connected to the current primary member of the HA Pair. (NYC-
ADC001:192.168.10.101).
6. Force HA failover:
52
7. Reconnect to the Citrix ADC HA Pair using the ADC-MGMT SNIP (192.168.10.103) using SSH
(PuTTY).

8. Verify that you are connected to the NEW Primary Citrix ADC (NYC-ADC-002:192.168.10.102):
show ha node
9. Perform a final HA failover to return NYC-ADC-001 to the Primary role:
After forcing failover, you need to reconnect:
10. From the ADC-MGMT SNIP, save the config:
save ns config
IMPORTANT: The Citrix ADCs NYC-ADC-001 and NYC-ADC-002 will remain in an HA pair for the
rest of this course in order to allow students to administer an HA Pair as they would in
production. While NYC-ADC-001 should be the primary Citrix ADC for the rest of the course, this
cannot be guaranteed. As a result, you will need to use the shared management SNIP (ADC-
MGMT SNIP: 192.168.10.103) when connecting to the Citrix ADC GUI or CLI for the rest of the
exercises, unless instructed otherwise.
Key Takeaways:
• SNIPs can be set up for management communication in addition to application
traffic, or they can be restricted to management access only.
• If a management SNIP is configured and restricted to management communication
only, then an additional SNIP or SNIPs for application traffic must be configured as
well.
• SNIPs are shared IP addresses in an HA configuration and therefore are always active
on the Primary Citrix ADC. As a result, a dedicated management SNIP is a preferred
method for making configuration changes while in an HA Pair as it guarantees an
administrator is always connected to the current Primary Citrix ADC.
• Node-specific settings should still be applied by connecting to the specific NSIP
address.
53
Module 5: Load Balancing

Overview:
Company ABC is ready to use the Citrix ADC HA Pair to provide load balancing for four different
applications in the environment. Your job as the administrator is to configure load balancing for
a web application, the DNS Servers, LDAP authentication, and an MYSQL database.
Exercises in this module demonstrate core concepts of load balancing on the Citrix ADC:
• Load-balancing entities: servers, services, service groups, load balancing virtual servers, and
application-specific monitors.
• Load-balancing settings: load-balancing methods and persistence.  Advanced options: back
up virtual servers and redirect URLs.
In this module, you will perform hands-on exercises to configure load balancing for the web
application, DNS, LDAP, and the MySQL database. You will configure application-specific load
balancing methods, persistence, and monitor settings for each application.
• Configure load balancing for any application using servers, services, service groups, and
virtual servers.
• Adjust load-balancing methods and persistence settings.  Adjust monitors for
application-specific conditions.
This module contains the following exercises using the Citrix ADC Configuration Utility GUI and
the Citrix ADC CLI:
• Exercise: Load Balancing HTTP  Exercise: Load Balancing DNS

• Exercise: Load Balancing LDAP
• Exercise: Load Balancing MYSQL Databases
Before you Begin:


module.
• NYC-ADC-001
• NYC-ADC-002
54
• NYC-WEB-BLU
• NYC-WEB-RED
• NYC-WEB-GRN
• NYC-ADS-001
• NYC-ADS-002
• NYC-LMP-001
• NYC-LMP-002
Exercise 5-1: Load Balancing HTTP (GUI)

Introduction:
In this exercise, you will learn to load balance an HTTP application by creating servers, services,
and a load balancing virtual server. You will use the Citrix ADC Configuration Utility GUI to
• Create servers for HTTP.

• Create services for HTTP.
• Create a load-balancing virtual server for HTTP.
• Test the load-balancing virtual server.
• Configure and test persistence.
• Configure and test monitors for use with HTTP load balancing.
The load-balancing exercises for the HTTP web applications in this module are used to
demonstrate each of the entities and fundamental principles of load balancing below.
About Servers:
Server objects on the Citrix ADC are used to represent destinations for traffic. These
destinations are defined by the IP address. Server objects identify the IP address to which the
Citrix ADC will direct traffic when load balancing. Servers can be created as named entities on
the Citrix ADC, as done in this exercise, or they can be created and named after the destination
IP address. A single server can host multiple applications, and therefore can be used with
multiple services.
About Services:
Services represent the application running on the server. The service is a way for the Citrix ADC
to represent the type of traffic being load balanced by defining the IP address, port, and
protocol of the traffic. A service can be defined by pointing to an existing named server object
on the Citrix ADC (for the IP address/traffic destination) or the service can be defined by
supplying an IP address. Citrix ADC load-balancing virtual servers distribute traffic across the
55
services. The services, therefore, embody the concept of the type of traffic being load balanced.
The different traffic types (protocols) that can be identified on the Citrix ADC are used to
provide application-specific traffic handling.
In this exercise, you will perform HTTP load balancing. In later exercises, you will explore LDAP,
DNS, and MYSQL traffic types. Each service represents a unique IP:Port:Protocol combination. A
given server may be used to host multiple applications, therefore different services can be
created for each application, allowing services to be load balanced individually.
About Load-Balancing Virtual Servers:
Load-balancing virtual servers are the virtual entities that perform the traffic distribution for the
associated services. The load-balancing virtual servers are a client-side entity that receives
requests from the client.
Load-balancing virtual servers are defined by a virtual IP address, protocol, and port that
receives initiating requests. The specified load-balancing method and persistence settings
determine how the traffic is distributed across the available services. Different load-balancing
methods and settings are appropriate for different applications. Each load balancing virtual
server represents a unique IP address: Port combination. Multiple load balancing virtual servers
can use the same IP address as long as they are configured on different ports, allowing different
applications (ports) to be load balanced independently of each other.
Services are bound to load-balancing virtual servers. With the Citrix ADC acting as a reverse
proxy, the load-balancing virtual server represents the client-side connection and identifies the
entry point for traffic, traffic type, and client-side connect settings. The load-balancing virtual
server is also the traffic distribution engine. Using load-balancing methods and persistence, the
load-balancing virtual server determines where traffic is sent. The service represents the server-
side connection between the Citrix ADC and the destination server fulfilling the request.
About Load Balancing Monitors:
Monitors are probes or conditions the Citrix ADC uses to determine if a service is UP or DOWN.
Monitors are bound to services, not servers. Therefore, many monitors are application-specific.
Monitors allow the Citrix ADC to perform intelligent load balancing and only send traffic to a
service that can fulfill the request. In basic monitoring, a monitor is bound to a service with a set
condition to be met and details identifying how frequently to probe and other details. If the
probe succeeds and the condition is met, the service is UP; if the probe fails, then the service
DOWN. More advanced criteria can be used with monitors if needed.
This exercise will reinforce these concepts with the HTTP load-balancing configuration. Other
exercises will then apply these concepts with additional application-specific use-cases and
advanced load-balancing concepts.
56
Create Servers for HTTP

Step Action
1. Connect to the Citrix ADC HA Pair Configuration Utility using the ADC-MGMT SNIP at
http://192.168.10.103.

Note: If you get pop-up asking Do you want Google Chrome to save your password for this site?
Click Save.
If you get a pop-up asking to sign in to Google Chrome, Click No thanks.
2. Verify that the Load Balancing feature is enabled:
• Select Load Balancing if it is not selected.
• Click OK.
3. Create the Citrix ADC server object representing NYC-WEB-RED at 192.168.30.51 in the
environment.
Create Server for NYC-WEB-RED:

• Browse to Traffic Management > Load Balancing > Servers.
• Click Add.
• Type srv_red in the Name field.
• Type 192.168.30.51 in the IPAddress field.
• Click Create.
4. Create the Citrix ADC server object representing NYC-WEB-BLU at 192.168.30.52 in the
environment.
Create Server for NYC-WEB-BLU:
• Click Add.
• Type srv_blue in the Name field.
• Click Create.
5. Create the Citrix ADC server object representing NYC-WEB-GRN at 192.168.30.53 in the
environment.
Create Server for NYC-WEB-GRN:

• Click Add.
• Type srv_green in the Name field.
• Click Create.
57
Create Services for HTTP

Step Action
1. Create a service for web content (HTTP) on the NYC-WEB-RED server. Use the named server object
created in the previous task when creating the service object on the Citrix ADC.
Create Service for NYC-WEB-RED (HTTP):

• Browse to Traffic Management > Load Balancing > Services.
• Click Add.
• Type svc_red in the Service Name field.
• Select Existing Server.
• Select srv_red (192.168.30.51) from the Server menu.
• Verify that HTTP is selected for the Protocol.
• Verify that 80 is selected for the Port.
• Click OK
• Click Done.
Verify that the service appears in a UP state after it is created.

2. Create a service for web content (HTTP) on the NYC-WEB-BLU server using the named server from
the previous task.
Create Service for NYC-WEB-BLU (HTTP):

• Click Add.
• Type svc_blue in the Service Name field.
• Select srv_blue (192.168.30.52) from the Server menu.
• Click OK
• Click Done.
58
3. Create a service for web content (HTTP) on the NYC-WEB-GRN server using the named server from
the previous task.
Create Service for NYC-WEB-GRN (HTTP):

• Click Add.
• Type svc_green in the Service Name field.
• Select srv_green (192.168.30.53) from the Server menu.
• Click OK.
• Click Done.
Create Load-Balancing Virtual Servers for HTTP

Step Action
1. Configure the load-balancing virtual server for HTTP traffic that can distribute traffic across the
services for NYC-WEB-RED, NYC-WEB-BLU, and NYC-WEB-GRN resources. Load balance using a
round-robin load-balancing method.
Create the load-balancing virtual server:

• Browse to Traffic Management > Load Balancing > Virtual Servers.
• Click Add.
• Type lb_vsrv_rbg in the Name field.
• Click OK.
2. Binding services links the services to the virtual server and determines where the virtual server will
distribute the traffic to.
Bind services to the load-balancing virtual server:

• Click No Load Balancing Virtual Server Service Binding under the Services and Service
Groups section. The Service Binding dialog box opens.
• Click Click to Select under Select Service to bind an existing service. (The Add button
would allow you to create a newservice.)
• Select svc_red, svc_blue, and svc_green.
• Click Select.
• Click Bind.
• Click Continue.
59
Keep the Load Balancing Virtual Server dialog box open for lb_vsrv_rbg.
3. Set Load-balancing method:

• Click Method under Advanced Settings (right pane). This adds the category to the
configuration area (left panel).
• Select ROUNDROBIN from the Load Balancing Method drop-down list box.
• Click OK under Method to apply settings.
4. Click Done to close the Load Balancing Virtual Server load-balancing virtual server properties dialog
for lb_vsrv_rbg.
INFORMATION: Using the Citrix ADC GUI to configure and change Load Balancing Virtual Server
properties. When creating a load-balancing (or other) virtual server, the Citrix ADC 13 GUI
separates configuration into separate tasks, grouping certain settings within the GUI. As a result,
the creation of the load-balancing virtual server is separated into multiple tasks, whereas in the
CLI it can be created in one single command. The GUI, therefore, presents creating the load-
balancing virtual server in a wizard format. Administrators must supply initial configuration
settings and then continue to binding services before the rest of the virtual server properties are
available.
In the GUI, the initial procedure for creating a load-balancing virtual server includes the
following:
• The Basic Settings menu is displayed first. This allows the essential properties to be
configured: the virtual server name, VIP, protocol, and port and other basic settings.
• Then an option bind Services or Service Groups is displayed. This can be configured now,
or skip it and configure it later.
• Finally, all virtual server properties are available to edit or configure now or later.
The initial tasks must be completed before the rest of the virtual server properties are
displayed.
Once the virtual server has been created, the Citrix ADC 13 GUI separates many of the
properties into categories: Monitors, Protection, Method, and Persistence. After clicking
continue, the full property list is displayed. Configured settings will default to display in the left
60
pane. Available settings not yet configured are available by Category under Advanced Settings in
the right pane.
Setting categories can be displayed or hidden as needed. Hiding a category by removing it from
the left pane does not remove the configured settings or reset values to default. However,
when configuring or changing settings in a specific category, changes must be applied by clicking
the OK block in that section of the category, or the change is not applied. Multiple categories
can display their OK blocks at once. Remember that changes for each category must be
individually applied by clicking OK. Navigating away from the properties by clicking the Done
button at the bottom of the virtual server properties or clicking Back to return to the virtual
server summary view will discard any unapplied changes.
The GUI was designed to organize settings so that administrators can see only those settings
configured and/or settings specifically of interest to the administrator. Other nodes can be hidden
from view.
If this is your first time working with Citrix ADC 13.0 (or later), it is easy to not apply settings as
expected. You should become familiar with navigating the GUI and think in terms of how the
GUI is presenting the settings to work successfully.
By contrast, with the CLI, all properties of the virtual server can be edited at once. Many of the
configuration changes made in the GUI in multiple steps could have been performed in a single
CLI command.
Test the Load Balancing Virtual Server

Step Action
1. Verify that lb_vsrv_rbg is listed with both State and Effective State as UP.
(Refresh the Citrix ADC GUI if still DOWN.)
2. Test load-balancing configuration:
• Open a browser and go to http://172.21.10.101/home.php
• For best results, we recommend using Chrome for configuration changes and testing web
content in Firefox.
• Refresh the page a couple of times to verify the load-balancing activity. With round-robin
specified as the load-balancing method, content should rotate through the Red, Blue, and
Green home pages.
IMPORTANT: The web servers in the backend are running on Apache web servers on Linux.
As a result, all paths are case sensitive:
http://172.21.10.101/home.php will work.
http://172.21.10.101/Home.php will not work.
Pay careful attention to the URLs provided in the exercise as mistakes with the case will cause
issues.
61
3. Return to the Citrix ADC Configuration Utility (http://192.168.10.103). View the load balancing
statistics to verify that traffic is coming from all three services.
• Select lb_vsrv_rbg and click Statistics.
• The statistics pane for this virtual server is displayed.
Scroll to the bottom and verify that the Service hits and Requests are evenly distributed across all
three bound services.
4. Exit the statistics view to return to the Virtual Servers pane by using the breadcrumbs navigation
trail above the Statistics pane.
Click Virtual Servers in the navigation trail:
Traffic Management > Load Balancing > Virtual Servers > Statistics.
Configure and Test Persistence

Step Action
1. Configure Persistence on the load-balancing virtual server.
• Select lb_vsrv_rbg and click Edit.
• Click Persistence in the Advanced Settings section to add it to the configuration area.
• Select COOKIEINSERT
• Click OK
• Click Done.
• Open a browser and go to http://172.21.10.101/home.php.
• Refresh the page a couple of times to verify the load-balancing activity. With persistence
enabled, only one server color should be displayed.
3. Return to the Citrix ADC Configuration Utility (http://192.168.10.103). View the load balancing
statistics to verify traffic is coming from a single service.
• Select lb_vsrv_rbg and click Statistics.
• The statistics pane for this virtual server is displayed.
Scroll to the bottom and verify the Service hits and Request statistics being reported. Traffic from
one service should be significantly higher than that of the other services. Between refreshes, only
traffic from one service should increase.
4. Exit the Statistics view when done and return to the Load Balancing > Virtual Servers node.
5. Change persistence to none:
• Click Edit icon (Pencil) in the Persistence field.
• Select OTHERS and NONE drop-down list box.
• Click OK.
• Click Done.
Configure and Test Monitors for use with HTTP Load Balancing
62
Step Action
http://192.168.10.103.
2. Create a load-balancing HTTP monitor for RBG services. This monitor verifies that a web server
provides a 200 OK response is received for the requested content. This provides basic verification
that web content is being generated by examining the response code received in the header.
• Browse to Traffic Management > Load Balancing > Monitors.
• Click Add.
Create Monitor:
• Type mon_rbg_http in the Name Field.
• Click Click to select and select HTTP from the list.
• Click Create.
This monitor will use the default values, configured parameters are summarized below for
reference:
Standard Parameters: (Keep default values)

• Interval: 5 sec
• Response Timeout: 2 sec
Special Parameters (Keep default values)
• HTTP Request: HEAD /
• Response Codes: 200
Under Advanced Parmeters
• Down Time: 30 sec
• Retries: 3
• Success Retries: 1
• Enabled
3. Create a load-balancing HTTP-ECV monitor for RBG services. This monitor confirms that a specific
value is generated in the response body, providing a more detailed verification that web content is
being fully generated.
• Click Add.
Create Monitor:
• Type mon_rbg_httpecv in the Name Field.
• Click on Click to Select
• Select HTTP-ECV
Under Basic Parameters
• Type Get /home.php in the Send String field.
• Type serverinfo in the Receive String field.
63
• Click Create.
4. Create a load-balancing HTTP-ECV monitor for RBG services that will fail:
• Click Add.
Create Monitor:
• Type mon_rbg_httpecv_bad in the Name Field.
• Click on Click to Select
• Select HTTP-ECV
Under Basic Parameters.
• Type Get /home.php in the Send String field.
• Type badstring in the Receive String field.
• Click Create.
This monitor is expected to fail when bound to service since it is looking for a string that is not
present on the page. This will be used to simulate a service failure due to monitor.
5. Bind the HTTP monitor to the Red service:

• Select svc_red and click Edit.
• Click 1 Service to Load Balancing Monitor Binding under Monitors.
• Click Add Binding.
• Click Click to Select under Select Monitor.
• Select mon_rbg_http and click Select.
• Click Bind and click Close.
• Click Done.
6. Verify svc_red remains in a UP state after binding the monitor.
7. Bind the HTTP-ECV monitor to the Blue service:
• Select svc_blue and click Edit.
• Browse to Page 2
64
• Select mon_rbg_httpecv and click Select.

• Click Done.
8. View Monitor state for a service:
• Click 1 Service to Load Balancing Monitor Binding under Monitors. This will display all
bound monitors.
• View the monitor state.
Note: When the HTTP-ECV response succeeds, it returns a success stating "Success - Pattern found
in response.”
9. Change monitor for svc_blue:
• Select mon_rbg_httpecv and click Unbind. Click Yes to confirm. (The default monitor is
automatically rebound; ignore it).
• Click Click to select under Select Monitor.
• Browse to Page 2
• Select mon_rbg_httpecv_bad and click Select.
• Click Done.
10. Wait a few seconds for probes to be sent. The svc_blue should appear in a downstate. (You may need
to refresh the Citrix ADC Configuration Utility a few times.)
11. View Monitor state for a service:
• View the monitor state.
• Click Close.
• Click Done.
Note: When the HTTP-ECV response fails, it returns a reason stating "Failure - Pattern not found in
response."
65
12. Open HTTP Header Live:
• In Firefox, Open HTTP Header Live: Click on the blue button on the right corner.
• Verify that Record Data is enabled on the Headers tab.

• Click Clear to clear the capture windows as needed.
The Add-on HTTP Header Live will be used with Firefox during this exercise. For convenience, HTTP
Header Live is also added to the Chrome browser in the lab; however, lab steps will not reference
this configuration explicitly. For best results, use one browser to access the Citrix ADC GUI to make
configuration changes and a separate browser type to test web pages and view header information.
13. Test load balancing:
• Open a new tab in Firefox and Browse http://172.21.10.101/home.php
• Refresh a few times.
• Open a new tab in Firefox and Browse http://172.21.10.101/
• Refresh a few times.
Neither test will not display content from svc_blue (no blue-colored server banners).
Depending on the browser, you may or may not see Red/Green alternate on the /home.php page.
14. View the header output in HTTP Header Live:
• Each response contains a custom header Served-By which indicates the source server that
served the content.
• Verify that none of the recent requests contain "Blue" while the service is DOWN.
15. View virtual server Statistics:

• Select lb_vsrv_rbg.
• Click Statistics.
• View the Bound Service(s) Summary at the bottom. The Service Hits are increasing for
svc_red and svc_green. No traffic is being sent to svc_blue so its hits are not increasing
while the monitor is marking the service DOWN.
66
16. Unbind the monitor to restore access to svc_blue:

• Click 1 Service to Load Balancing Monitor Binding under Monitors. This will display all
bound monitors.
• Select mon_rbg_httpecv_bad and click Unbind.
• Click Yes and click Close.
• Click Done.
17. Bind the HTTP monitor to the Blue service (to be consistent with the Red service):
• Click Done.
18. Bind the HTTP monitor to the Green service (to be consistent with the Red and Blue Services):
• Select svc_green and click Edit.
• Click Done.
Key Takeaways:
• Understand how to create a server, services, and load-balancing virtual servers.
• Layer 7 monitors such as HTTP and HTTP-ECV are almost always better suited for use
with web applications than TCP monitors.
• Load-balancing methods and persistence are specific to an application and control.
• Viewing monitor results is useful to help identify issues with services.
• The Citrix ADC GUI provides tools to view properties of servers, services, and virtual
servers which are useful for diagnosing issues and gaining an understanding of the Citrix
ADC configuration.
Exercise 5-2: Load-Balancing DNS (GUI)

Introduction:
67
In this exercise, you will learn to load balance DNS servers by creating DNS service groups, DNS
monitors, and a DNS (UDP) load-balancing virtual server. You will use the Citrix ADC
Configuration Utility GUI to perform this exercise.
About DNS Load Balancing:
DNS Load Balancing allows administrators to load balance DNS queries across multiple DNS
servers. The load-balancing method is usually round-robin and persistence is not required. A
ping monitor can be used for basic up-state detection. However, the Citrix ADC DNS monitor
allows administrators to determine DNS Server availability based on whether a DNS query
returns a successful result. The monitor should be configured to look for name resolution for a
component that will always be present and whose IP address is unlikely to change.
While not demonstrated in the exercise, when the Citrix ADC is configured as a DNS load
balancer (also known as a DNS Proxy), the Citrix ADC will also cache DNS requests.
This exercise configures DNS load balancing using the DNS protocol which supports DNS
(UDP:53) responses less than 512 bytes. The Citrix ADC can also support DNS (TCP:53) packets
using the DNS_TCP protocol, which supports responses over 512 bytes in size. DNS load
balancing can be configured with both a DNS and DNS_TCP virtual server in production in much
the same way a web application can be configured for HTTP and HTTPS. DNS_TCP is not
demonstrated in this exercise.
About Service Groups:
This exercise also introduces the use of service groups.
Services represent the type of application running on a given server; services are defined as a
destination IP and Protocol: Port indicating the type of traffic on the destination. In the previous
exercise for HTTP, a unique service was created for each Red, Blue, Green server. Each service
though had to be individually configured with service settings and monitors.
A service group allows management of all settings for a related group of services once at the
service group level. The individual service group members identify the application type and
traffic destinations (IP:Protocol: Port). Properties and monitors can be bound once at the service
group level, but apply to each member in the group.
• Create a Service Group for DNS.

• Create a load-balancing virtual server for DNS.
• Test DNS load balancing.
• Configure monitors for DNS load balancing.
Create a Service Group for DNS

68
Step Action
http://192.168.10.103.
2. Create a Service Group for the DNS servers. The service group will identify the two domain
controllers which are running DNS as the service group members:
• Browse to Traffic Management > Load Balancing > Service Groups.

Click Add.
3. Configure load-balancing service group basic settings:

• Enter svcg_domain_dns in Name field.
• Select DNS from the Protocol drop-down list box.
• Click OK.
4. Bind members to service group:
• Click No Service Group Member.
• Select IP Based.
• Enter 192.168.30.11-12 in the IP Address/IP Address Range field.
• Enter 53 in the Port field.
• Click Create
• Click OK.
• Click Done.
The IP addresses 192.168.30.11-12 are the IP address of the two domain controllers running DNS
services in the lab environment. Both are being added to the service group as members by IP
address (instead of by creating named servers).
5. Click Refresh and verify the service group svcg_domain_dns is UP (green), indicating all members
are in a UP state.
6. Select svcg_domain_dns and click Manage Members to view individual member status.
7. Click Close.
Create a Load-Balancing Virtual Server for DNS

Step Action
1. Create a load-balancing virtual server for the DNS servers AD.workspacelab.com and
AD02.workspacelab.com. Configure load balancing using the round-robin method.
• Click Add.
69
2. Configure load-balancing virtual server basic settings for the DNS virtual server.
• Enter lb_vsrv_dns in the Name field.
• Select DNS from the Protocol drop-down list box.
• Enter 172.21.10.102 in the IP Address field.
• Verify that the port is 53.
• Click OK.
3. Bind the service group for the DNS services to the load-balancing virtual server:
• Click No Load Balancing Virtual Server ServiceGroup Binding.
• Click Click to select under Select Service Group Name.
• Select svcg_domain_dns and click Select.
• Click Bind.
• Click Continue.
Keep the Load Balancing Virtual Server properties dialog box open.
4. Configure the load-balancing method:
• Click Method under Advanced Settings (right pane).
5. Click Done.
Test DNS Load Balancing

Step Action
1. Open a CMD prompt on the HOST desktop: Search for CMD then click it to start: Start > Command
Prompt.
2. Use nslookup to test DNS resolution with the load-balancing virtual server:
nslookup NYC-WEB-RED.workspacelab.com 172.21.10.102
Verify that a successful response is returned and resolves NYC-WEB-RED.workspacelab.com to the IP

address 192.168.30.51.
3. Return to the Citrix ADC Configuration Utility (http://192.168.10.103).
4. View the load-balancing statistics:
• Select lb_vsrv_dns and click Statistics.
• Confirm that DNS requests are being load balanced.
Note: You may need to repeat the nslookup command rapidly 6-8 times to generate data to view in
this step. The DNS requests are very short in duration and the statistics quickly expire.
And you need to drill down into the service group members.
For best results, arrange the windows so you can repeat the nslookup commands in the CMD
prompt. Then, switch focus to the Statistics screen in the Citrix ADC Configuration Utility.
70
Click the Refresh button to update the display quickly.
Configure Monitors for DNS Load Balancing

Step Action
1. Create a load-balancing DNS monitor:

• Click Add.
2. Configure Monitor Type and Standard Parameters:
• Enter mon_dns in the Name field.
• Select DNS from the Type drop-down list box.
Keep the default values for Basic Parameters. Essential settings are summarized below:
• Interval: 5 sec
• Retries: 3
• Enabled
3. Configure Monitor Special Parameters:
Under Basic Parameters tab.
• Enter NYC-WEB-RED.workspacelab.com in the Query field.
• Verify Address is selected from the Query Type drop-down list box.
• Enter 192.168.30.51 in the IP Address field and click "+" to add it to the configured list.
• Click Create.
The DNS monitor functions by identifying a DNS query for the monitor to perform and the IP
address or addresses that should be returned by the DNS server. If no response is received, or the
returned IP address does not match the return value list in the monitor, the probe fails.
71
4. Bind the monitor to the service group:

• Select svcg_domain_dns and click Edit.
• Click Monitors under Advanced Settings (right pane).
• Click No Service Group to Monitor Binding under Monitors.
• Navigate to page 2 of the list
• Select mon_dns and click Select.
• Click Bind.
• Click Done.
5. Verify that the service group svcg_domain_dns remains UP after binding the new monitor.
6. View the monitor state for members of a service group. The procedure is slightly different from that
of standalone services.
• Select svcg_domain_dns in the Service Groups node and click Edit.
• Click 2 Service Group Members under the Service Group Members category.
• Select 192.168.30.11 in the Service Group members list and click Monitor Details.
• Close the window then click Done.
This summarizes the number of probes sent, total failed probes, and last response status for each
member in the service group.
8. Confirm that DNS Load Balancing still works after changing the monitor:
Open a CMD prompt on the HOST desktop: Search for CMD then click it to start: Right-click Start >
Command Prompt.
nslookup NYC-WEB-BLUE.workspacelab.com 172.21.10.102
Verify that a successful response is returned and resolves NYC-WEB-BLU.workspacelab.com to the IP

address 192.168.30.52.
Verify that a successful response is returned and resolves NYC-WEB-RED.workspacelab.com to the IP

address 192.168.30.51.
Key Takeaways:
• Service Groups can be used in place of individual services when load balancing.
Properties that affect individual services can all be managed once at the Service Group level.
Monitors can be bound once at the group level and be used for all member services.
72
• Viewing properties, member status, and monitor results in Service Groups are slightly
different than viewing service details in the GUI; however, all the same information is
present.
• DNS monitors are used to verify a successful DNS query and IP address resolution. The
monitor should be configured with a DNS name and IP address for an entity in the
environment that is unlikely to change often.
• DNS load balancing requires the creation of servers, services or Service Groups, and
load-balancing virtual servers, just like HTTP load balancing. The process is the same, but
the details such as load-balancing methods and persistence may vary according to
application.
Exercise 5-3: Load Balancing LDAP (GUI)

Introduction:
In this exercise, you will learn to load balance LDAP authentication servers (Domain Controllers)
by creating LDAP service groups, LDAP monitors, and an LDAP load-balancing virtual server. You
About LDAP Load Balancing:
LDAP load balancing is used to provide redundancy for authentication services. This exercise
focuses on LDAP authentication using Microsoft Active Directory Domain Controllers, but
authentication load balancing can be configured for other authentication services such as
Radius. If a domain controller is offline, authentication requests can be directed to another
domain controller.
The LDAP load-balancing virtual server will be used in later exercises when external
authentication is integrated with the Citrix ADC system authentication as part of the delegated
administration configuration.
• Create a Service Group for LDAP.

• Create a load-balancing virtual server for LDAP.
• Configure monitors for LDAP load balancing.
Create a Service Group for LDAP
73
Step Action
http://192.168.10.103.

2. Create a Service Group for LDAP authentication using the domain controllers as the service group
members:
• Click Add.
3. Configure load-balancing Service Group basic settings:
• Enter svcg_domain_ldap in Name field.
• Select TCP from the Protocol drop-down menu.
• Click OK.
• Click No Service Group Members.
• Select IP Based.
• Enter 192.168.30.11-12 in the IP Address/IP Address Range field.
• Click Create, then OK.
• Click Done.
5. Click Refresh and verify that the service group svcg_domain_ldap is UP (green), indicating that all
members are in a UP state.
6. Select svcg_domain_ldap and click Manage Members to view individual member status.
7. Click Close.
Create a Load-Balancing Virtual Server for LDAP

Step Action
1. Create a load-balancing virtual server for the LDAP servers AD.workspacelab.com and
AD02.workspacelab.com. Configure load balancing using the round-robin method.
• Click Add.
2. Configure load-balancing virtual server basic settings:
• Enter lb_vsrv_ldap in the Name field.
• Select TCP from the Protocol drop-down list box.
• Click OK.
74
3. Bind a service group to the load-balancing virtual server:

• Click No Load Balancing Virtual Server ServiceGroup Binding.
• Select svcg_domain_ldap and click Select.
• Click Bind.
• Click Continue.
Keep the Load Balancing Virtual Server dialog box opens.
4. Configure the load-balancing method:
5. Click Done.
Configure Monitors for LDAP Load Balancing

Step Action
1. Create a load-balancing LDAP monitor to verify that authentication services are running on the
target LDAP server:
• Click Add.
2. Configure Monitor Type and Standard Parameters:
• Enter mon_ldap in the Name field.
• Select LDAP from the Type drop-down list box.
Keep the default values for Standard Parameters. Essential settings are summarized below:
• Interval: 5 sec
• Retries: 3
• Enabled
75
3. Configure Monitor Special Parameters:

• Click Advanced Parameters menu.
• Select nsldap.pl from the Script Name drop-down list box.
Scroll up to Basic Parameters
• Enter dc=workspacelab,dc=com in the Base DN field.
• Enter trainADUser@workspacelab.com in the Bind DN field.
• Enter cn=Builtin in the Filter field.
• Enter memberOf in the Attribute field.
• Enter Password1 in the Password field.
• Click Create.
The monitor performs an LDAP authentication using the supplied service account to test if the LDAP
server is responding to requests. The account must exist in the LDAP directory service.
Note: This monitor will fail if the service account used is disabled or password changes.
The filter parameter is used to limit the number of objects returned by the monitor query. This
action helps to avoid a delay in the monitor response in environments with large numbers of
directory services objects.
4. Change the number of monitor objects to display per page in the Monitors list.
• Click Refresh to update the Citrix ADC view.
• Select 250 Per Page from the objects per page drop-down list box at the bottom of the
pane. The default is 25.
• This preference will persist.
Note: The Citrix ADC GUI only shows 25 monitors per page by default, and this is now the 29th
monitor in the list. Use the "next page" option or change maximum items to display per page to see
the rest of the available monitor. You also can use the Search option to filter on monitors starting
with mon_. The items per page value are remembered as a site preference (via a cookie) and will
persist between sessions.
5. Bind the monitor to the Service Group:
• Select svcg_domain_ldap and click Edit.
• Click Monitors under Advanced Settings (right pane).
• Click No Service Group to Monitor Binding under Monitors.
• Select mon_ldap and click Select.
• Click Bind.
• Click Done.
6. Verify the service group svcg_domain_ldap remains UP after binding the new monitor.
This confirms that the authentication parameters in the monitor are working correctly.
The authentication virtual server will be tested during a later lab exercise.
76
Key Takeaways:
• The Citrix ADC does not have a predefined application type for LDAP so configuring load-
balancing virtual servers and services or Service Groups as TCP:389 will work for LDAP
communication.
• The custom LDAP monitor can be used to verify the UP state of authentication servers by
performing a test authentication query. The service account must have a minimum of
domain user permissions to enumerate objects in the domain.
Exercise 5-4: Load Balancing MYSQL Databases (GUI)

Introduction:
In this exercise, you will learn to configure basic load balancing for MYSQL database servers. The
load-balancing configuration in this exercise is based on a read-only database where all queries
can be distributed actively across both database servers. Load-balancing database traffic also
requires the configuration of a database account. Database monitoring requires configuration of
SQL queries. You will use the Citrix ADC Configuration Utility GUI to perform this exercise.
The exercise begins with configuring active-active load balancing across two database servers,
similar to the other load-balancing exercises in this module. Then the exercise demonstrates
configuring an active/passive load balancing configuration for the database servers using a
primary virtual server with a backup virtual server example.
• Create a database user and server objects for MYSQL.

• Create services for MYSQL.
• Create a load-balancing virtual server for MYSQL.
• Test MYSQL load balancing.
• Configure monitors for MYSQL load balancing.
• Configure database load balancing with a backup virtual server.
Create Database User and Server Objects for MYSQL
Step Action
77
http://192.168.10.103.

2. Create a database user on the Citrix ADC:
• Browse to System > User Administration > Database Users.
• Click Add.
• Enter netscalersql in the User Name field.
• Enter netscaler in the Password field and the Confirm Password field.
• Click Create.
3. Create server for NYC-LMP-001:
• Click Add.
• Type srv_NYC-LMP-001 in the Name field.
• Clear Enable after Creating checkbox to disable the server.
• Click Create.
IMPORTANT: Create server objects in a disabled state until services with PING monitors are
configured. This avoids creating a scenario in which the default TCP monitor probe creates an error
on the MYSQL servers when the servers only see a three-way handshake and treat the probe as a
connection error. Servers will be enabled after monitors have been properly configured.
4. Create server for NYC-LMP-002:
• Click Add.
• Type srv_NYC-LMP-002 in the Name field.
• Clear Enable after Creating checkbox to disable the server.
• Click Create.
5. Confirm that server objects for NYC-LMP-001 and NYC-LMP-002 are disabled.
If you missed the step to disable the servers when creating them, disable them now to prevent
connection issues later. The NYC-LMP-001 and NYC-LMP-002 servers can be restarted in Hyper-V
Manager during later exercises, if necessary.
To disable the servers:

• Select srv_NYC-LMP-001, srv_NYC-LMP-002 or both in the Server list.
• Click Action > Disable.
Create Services for MYSQL

Step Action
1. Create service for NYC-LMP-001 (MySQL):
78

• Click Add.
• Type svc_NYC-LMP-001 in the Service Name field.
• Select srv_NYC-LMP-001 (192.168.30.61) from the Server menu.
• Select MYSQL for the Protocol.
• Select 3306 for the Port.
• Click OK to complete the basic settings.
Keep the Load Balancing Service properties dialog box open.
2. Bind a ping monitor to the service:
• Click 1 Service to Load Balancing Monitor Binding.
• Select ping from the Monitors Name list and click Select. Do not use ping-default.
• Click Done.
3. Create Service for NYC-LMP-002 (MySQL):
• Click Add.
• Type svc_NYC-LMP-002 in the Service Name field.
• Select srv_NYC-LMP-002 (192.168.30.62) from the Server menu.
• Select MYSQL for the Protocol.
• Select 3306 for the Port.
• Click OK to complete the basic settings.
Keep the Load Balancing Service properties dialog box open.
4. Bind a ping monitor to the service:
• Click 1 Service to Load Balancing Monitor Binding.
• Select ping from the Monitor List and click Select. Do not use ping-default.
• Click Done.
5. Enable the Server objects for NYC-LMP-001 and NYC-LMP-002:
• Select both srv_NYC-LMP-001 and srv_NYC-LMP-002 in the Server list.
• Click Action > Enable.
• Click Yes to Confirm.
Now that the ping monitor has been bound to replace the tcp_default monitor, the servers can be
enabled.
79
6. Confirm Services are now UP:

• Verify that the state for both svc_NYC-LMP-001 and svc_NYC-LMP-002 is UP.
Note: if the Services are not in UP state after enabling, switch on the Virtual Machines (NYC-LMP-
001 and NYC-LMP-002) in Hyper-V.
Create a Load-Balancing Virtual Server for MYSQL

Step Action
1. Create a load-balancing vServer that will be associated with the NYC-LMP-001 and NYC-LMP002
database servers. Load balance the services using the Least Connection load-balancing method.
• Click Add.
• Enter lb_vsrv_mysql in the Name field.
• Select MYSQL from the Protocol drop-down list box.
• Click OK.
3. Bind the services to the load-balancing virtual server:
• Click No Load Balancing Virtual Server Service Binding.
• Click Click to select under Select Service.
• Select svc_NYC-LMP-001.
• Select svc_NYC-LMP-002.
• Click Select.
• Click Bind.
• Click Continue.
Keep the Load Balancing Virtual Server properties dialog box open.
4. Set the load balancing method:
• Select LEASTCONNECTION from the Load Balancing Method drop-down list box. This is the
default load-balancing method if one is not configured.
5. Click Done to close the Load Balancing Virtual Server properties dialog box for lb_vsrv_mysql.
Test MYSQL Load Balancing

Step Action
80
1. Test MySQL Load Balancing

Open HeidiSQL using the shortcut on the Desktop. (If you receive any pop-up to update HeidiSQL,
Click Skip to continue with exercise)
• Select MySQLTest in the left pane.
• Network type: MySQL (TCP/IP)
• Hostname / IP: 172.21.10.104 (This is for the VIP lb_vsrv_mysql)
• User: netscalersql
• Password: netscaler
• Databases: imdb
• Click Open.
The HeidiSQL should connect successfully to the database using the load-balancing virtual server.
2. Test Database connection:
The connection pane will display MySQLTest > imdb. Database tables are displayed in the left pane.
• Select imdb in the left pane. Select the Query tab in the right pane.
• Enter the following query in the Query pane to test the connection:
select * from actors where actors.last_name = "Tazova"
• Click Play button on the taskbar (above the query pane).
• Verify that the query returns 1 record for the actor.
Keep Heidi SQL open and reuse this connection for later tests. You will replay this query multiple
times.
Configure Monitors for MySQL Load Balancing

Step Action
1. Create a load-balancing MySQL monitor:
• Click Add.
2. Configure Monitor Type and Basic Parameters:
• Enter mon_mysql in the Name field.
• Select MYSQL-ECV from the Type drop-down list box (scroll UP to click Select).
Keep the default values for parameters other than described below:
Basic Parameters
• Interval: 5 sec
• User Name: netscalersql
• Database: imdb
• Query: select * from actors where actors.last_name = "Tazova"
(This is the same query used in the HeidiSQL test, so copy the query)
Expression: Enter the following Expression (you may enter manually or use the Expression Editor to
build the expression):
MYSQL.RES.ATLEAST_ROWS_COUNT(1)
81
3. Configure the Monitor Advance Parameters:

Advanced Parameters
• Retries: 3
• Check Enabled
• Click Create.
Note: Verify that the expression is correct before continuing to the next step.
The expression is based on Citrix ADC default policy syntax and is used to verify that the SQL query
returns at least 1 row to determine that the database is functioning. The policy syntax will be
explained in detail in a later exercise. The expression can be entered manually using the in-line
editor which will supply syntax options each time the period (".") is entered. For a more structured
approach, click Expression Editor and build the expression with the dropdown list boxes.
The final expression will look like the above result when entered correctly.
Explanation:
This monitor is going to execute a query (Select * from users …) against the Database (IMDB) and
then uses the expression (MYSQL.RES.ATLEAST_ROWS_COUNT(1)) to determine if the query
executed and returned a valid response, which in this case is at least one row returned. However,
the Query parameter cannot be configured in the GUI in this build and will be added in the next step.
4. Bind the MYSQL monitor and unbind the ping monitor for service NYC-LMP-002:
• Browse to Traffic Management > Load Balancing > Services
• Select svc_NYC-LMP-002 and click Edit.
• Click 1 Service Load Balancing Monitor Binding under Monitors.
• Select mon_mysql and click Select.
• Click Bind.
Select ping click Unbind and Yes to confirm.
• Click Close.
• Click Done.
5. Verify that the node is NYC-LMP-002 is UP
Note: If the node is showing as down, change the below setting in the monitor mon_mysql:
• Interval: 20 sec
Due to many networks in the Lab, the connection to the MySQL server might take more than
10 seconds. To address it we are changing the Interval and Response timeout in the monitor.
6. Test MySQL Load Balancing (Test 2)
Return to HediSQL: Reconnect to MySQLTest and the imdb database, if not still connected.
• Click Play to repeat the following Query, re-entering it if necessary:

82
Configure Database Load Balancing with a Backup Virtual Server

Step Action
1. Configure load balancing vServer lb_vsrv_mysql to point to a single primary database (NYCLMP-
001).
• Select lb_vsrv_mysql and click Edit.
• Click 2 Load Balancing Virtual Server Service Bindings under Services and Service
Groups.
• Select svc_NYC-LMP-002 and click Unbind.
• Click Yes.
• Verify that svc_NYC-LMP-001 is still bound and click Close.
• Click Done.
2. Create a new load-balancing virtual server to point to the backup database (NYC-LMP-002).
• Click Add.
• Enter lb_vsrv_mysql_backup in the Name field.
• Select MYSQL from the Protocol drop-down list box.
• Select Non-Addressable from the IP Address type drop-down list box.
• Click OK.
A non-addressable virtual server has no VIP or port assigned. It is an internal-only entity on the
Citrix ADC.
4. Bind the services to the load-balancing virtual server:
• Click Click to select under Select Service.
• Select svc_NYC-LMP-002 and click Select.
• Click Bind.
• Click Continue.
• Click Done.
83
5. Configure lb_vsrv_mysql_backup as the backup virtual server for lb_vsrv_mysql (primary).

• Select lb_vsrv_mysql and click Edit.
• Click Protection under Advanced Settings (right-pane).
• Select lb_vsrv_mysql_backup from the Backup Virtual Server drop-down list box and
Click OK.
• Click Done.
6. Disable server NYC-LMP-001 to simulate an outage:
• Select srv_NYC-LMP-001 and click Action > Disable.
• Click OK.
7. Verify the state of the lb_vsrv_mysql and lb_vsrv_mysql_backup:
• lb_vsrv_mysql State is DOWN but Effective State is UP.
• lb_vsrv_msyql_backup State is UP and Effective State is UP.
Note: If Effective State shows Down, ignore this error and continue with the next step.
8. Test MySQL Load Balancing (Test 3)
Return to HeidiSQL: Reconnect to MySQLTest and the imdb database, if not still connected.
• Click Play to repeat the following Query, re-entering if necessary:

9. Enable server svc_NYC-LMP-001:

• Select srv_NYC-LMP-001 and click Action > Enable.
11. Close HeidiSQL.If you receive a pop-up to Save the content of tab “Query*”? Click No. If not
continue to the next step.
Key Takeaways:
• Database load balancing allows for TCP connection multiplexing for database traffic
similar to TCP connection multiplexing for HTTP traffic.
• Connections to MYSQL (and MSSQL) databases require the Citrix ADC to be configured
with a valid database account. Even when not using a database-specific monitor, the
Citrix ADC authenticates to establish a valid connection for the service. Database user
account names and passwords are both case sensitive.
• The backup virtual server property of a load-balancing virtual server is invoked when the
primary virtual server is in a DOWN state because services are not available. A
configured backup virtual server in a UP state can cause the primary virtual server
effective state to remain UP and provide seamless failover for traffic directed to the
primary virtual server.
84
Exercise 5-1: Load Balancing HTTP (CLI)

Introduction:
In this exercise, you will learn to load balance an HTTP application by creating servers, services,
and load-balancing virtual server entities. You will use the command-line interface to perform
this exercise.
In this exercise you will perform the following tasks:
• Configure Servers, Services, and Load-Balancing Virtual Servers for HTTP.

• Configure and Test Persistence.
• Configure and Test Monitors for Use with HTTP Load Balancing.
The load-balancing exercises for the HTTP web applications in this module are used to
demonstrate entities and fundamental principles of load balancing.
About Servers:
Server objects on the Citrix ADC are used to represent destinations for traffic. These
destinations are defined by the IP address. Server objects identify the IP address to which the
Citrix ADC will direct traffic when load balancing. Servers can be created as named entities on
the Citrix ADC, as done in this exercise or they can be created and named after the destination
IP address. A single server can host multiple applications and therefore can be used with
multiple services.
About Services:
Services represent the application running on the server. The service is a way for the Citrix ADC
to represent the type of traffic being load balanced by defining the IP address, port, and
protocol of the traffic. A service can be defined by pointing to an existing named server object
on the Citrix ADC (for the IP address/traffic destination) or the service can be defined by
supplying an IP address. Citrix ADC load-balancing virtual servers distribute traffic across the
services. The services, therefore, embody the concept of the type of traffic being load balanced.
The different traffic types (protocols) that can be identified on the Citrix ADC are used to
provide application-specific traffic handling.
In this exercise, HTTP load balancing will be performed. In later exercises, we will explore LDAP,
DNS, and MYSQL traffic types. Each service represents a unique IP:Port:Protocol combination. A
given server may be used to host multiple applications. Therefore, different services can be
created for each application, allowing services to be load balanced individually.
About Load-Balancing Virtual Servers:
85
Load-Balancing virtual servers are the virtual entities that perform the traffic distribution for the
associated services. The load-balancing virtual server is a client-side entity that receives
requests from the client.
Load-balancing virtual servers are defined by a virtual IP address, protocol, and port that
receives initiating requests. The specified load-balancing method and persistence settings
determine how the traffic is distributed across the available services. Different load-balancing
methods and settings are appropriate for different applications. Each load balancing virtual
server represents a unique IP Address: Port combination. Multiple load-balancing virtual servers
can use the same IP address as long as they are configured on different ports, allowing different
applications (ports) to be load balanced independently of each other.
Services are bound to load-balancing virtual servers. With the Citrix ADC acting as a reverse
proxy, the load-balancing virtual server represents the client-side connection and identifies the
entry point for traffic, traffic type, and client-side connect settings. The load-balancing virtual
server is also the traffic distribution engine. Using load-balancing methods and persistence, the
load-balancing virtual server determines where traffic is sent. The service represents the server-
side connection between the Citrix ADC and the destination server fulfilling the request.
About Load Balancing Monitors:

Monitors are probes or conditions the Citrix ADC uses to determine if a service is UP or DOWN.
Monitors are bound to services (not servers). Therefore, many monitors are application-specific.
Monitors allow the Citrix ADC to perform intelligent load balancing and only send traffic to a
service that can fulfill the request. In basic monitoring, a monitor is bound to a service with a set
condition to be met and details identifying how frequent to probe and other details. If the probe
succeeds and the condition is met, the service is UP; if the probe fails, then the service is DOWN.
More advanced criteria can be used with monitors if needed.
This exercise will reinforce these concepts with the HTTP load-balancing configuration. Other
exercises will then apply these concepts with additional application-specific use-cases and
advanced load-balancing concepts.
Configure Servers, Services, and Load-Balancing Virtual Servers for

HTTP
Step Action
1. Connect to the Citrix ADC HA Pair using the ADC-MGMT SNIP (192.168.10.103) using SSH (PuTTY).

86
2. Enable load-balancing feature:

enable ns feature LB
3. Create server objects representing each of the destination web servers in the environment: NYC-
WEB-RED (192.168.30.51), NYC-WEB-BLU (192.168.30.52), and NYC-WEB-GRN (192.168.30.53)
Create servers for NYC-WEB-RED, NYC-WEB-BLU, and NYC-WEB-GRN:

add server srv_red 192.168.30.51
add server srv_blue 192.168.30.52
add server srv_green 192.168.30.53
4. Create services for web content (HTTP) on the NYC-WEB-RED, NYC-WEB-BLU, and NYC-WEBGRN
servers. Use the named server objects created in the previous task when creating the services.
These services represent the type of traffic being load balanced.
Create HTTP services for NYC-WEB-RED, NYC-WEB-BLU, and NYC-WEB-GRN:

add service svc_red srv_red http 80
add service svc_blue srv_blue http 80
add service svc_green srv_green http 80
5. Configure the load-balancing virtual server for HTTP traffic that can distribute traffic across the
services for NYC-WEB-RED, NYC-WEB-BLU, and NYC-WEB-GRN resources. Load balance using a
round-robin load-balancing method.
Create the load-balancing virtual server:

add lb vserver lb_vsrv_rbg HTTP 172.21.10.101 80 -lbMethod ROUNDROBIN
Bind the Services:

bind lb vserver lb_vsrv_rbg svc_red
bind lb vserver lb_vsrv_rbg svc_blue
bind lb vserver lb_vsrv_rbg svc_green

• Open a browser and find http://172.21.10.101/
• Refresh the page a couple of times and note the results.
• In the browser, find http://172.21.10.101/home.php  Refresh the page a couple of times
and note the results.
Note: Try using Chrome in Incognito Mode and refreshing the page to see the behavior without any
caching.
stat lb vserver
stat lb vserver lb_vsrv_rbg
Configure and Test Persistence

Step Action
1. Enable persistence:
set lb vserver lb_vsrv_rbg -persistenceType COOKIEINSERT -timeout 2
87

• Open a browser and find http://172.21.10.101/
• Refresh the page a few times and note the results.
• In the browser, find http://172.21.10.101/home.php
• Refresh the page a few times and note the results.
In Firefox and Chrome, the lab has LiveHTTPHeaders installed which will allow you to view
headers, such as the Persistence Cookie that is set by the Citrix ADC (and the Served by Header)
In IE, the plugin is DisplayIEHeaders.
stat lb vserver
Notice that only one service is being taxed while persistence is in use, instead of all three.
4. Disable persistence on the load-balancing vServer:

set lb vserver lb_vsrv_rbg -persistenceType NONE
5. Save the configuration:
save ns config
Configure and Test Monitors for Use with HTTP Load Balancing
Step Action
1. Create a load-balancing HTTP monitor for the RBG Services:
add lb monitor mon_rbg_http HTTP -respCode 200 -httpRequest "Head /" -LRTM DISABLED -
interval 5 SEC -respTimeout 2 sec -downTime 30 sec -retries 3
This monitor verifies that the web server provides a 200 OK response for the requested content.
This provides basic verification that web content is being generated by examining the response code
received in the header.
2. Create a load-balancing HTTP-ECV monitor for the RBG Services:
add lb monitor mon_rbg_httpecv HTTP-ECV -send "Get /home.php" -recv "serverinfo" LRTM
Disabled -interval 5 -respTimeout 2 -downTime 30 -retries 3
This monitor confirms that a specific value is generated in the response body, providing a more
detailed verification that web content is being fully generated.
3. Create a load-balancing HTTP-ECV monitor for the RBG Service that will fail:
add lb monitor mon_rbg_httpecv_bad HTTP-ECV -send "Get /home.php" -recv "badstring" LRTM
Disabled -interval 5 -respTimeout 2 -downTime 30 -retries 3
4. Bind the HTTP monitor to the Red service:
bind service svc_red -monitorName mon_rbg_http
88
5. Verify that Red service is still UP after changing the monitors:

show service svc_red
Verify the Service State.
Verify the Monitor State, Probes Sent, and Probes Failed.
6. Bind the HTTP-ECV monitor to the Blue service:
bind service svc_blue -monitorName mon_rbg_httpecv
7. Verify that Blue service is still UP after changing the monitors:
show service svc_blue
Verify the Service State.
Verify the Monitor State, Probes Sent, and Probes Failed.
8. • Open a web browser and find http://172.21.10.101/home.php.
• Refresh the page a few times and verify that you see content from all three servers: Red,
Blue, and Green.
9. Unbind the HTTP-ECV monitor from the Blue service:
unbind service svc_blue -monitorName mon_rbg_httpecv
10. Bind the bad monitor to the Blue service:
bind service svc_blue -monitorName mon_rbg_httpecv_bad
11. Verify that the Blue service is now DOWN:
show service svc_blue
Verify the Service state and the Monitor State, probes sent, and failed probes.
You may have to repeat the command several times, as the initial probes fail and the monitor state is
reported as Unknown before the minimum retries have been met and the monitor is marked down
along with the service.
12. View the stats for the load-balancing virtual server:
13. Open HTTP Header Live:
• In Firefox, Open HTTP Header Live: Click on the blue button on the right corner.
• Verify that Record Data is enabled on the Headers tab.

• Click Clear to clear the capture windows as needed.
The Add-on HTTP Header Live will be used with Firefox during this exercise. For convenience, HTTP
Header Live is also added to the Chrome browser in the lab; however, lab steps will not reference this
configuration explicitly.
For best results, use one browser to access the Citrix ADC GUI to make configuration changes and a
separate browser type to test web pages and view header information.
89
14. In the Firefox browser and browse http://172.21.10.101/home.php.

Refresh the page a few times. Note that you do not see content from the Blue server.
In the Firefox browser and browse http://172.21.10.101/.

Refresh the page a few times. Note that you do not see content from the Blue server.
Neither test will display content from svc_blue (no blue-colored server banners).
Depending on the browser, you may or may not see Red/Green alternate on the /home.php page.
15. View the header output in HTTP Header Live:
• Each response contains a custom header Served-By, which indicates the source server.
• Verify that none of the recent requests contain "Blue" while the service is DOWN.
Note: The "Served-by" header was a custom header configured on the Red, Blue, and Green web
servers for lab demonstration purposes.
16. View the stats for the load-balancing virtual server:
Verify that both the Red and Green services have increased hit counts from the previous stat
command. Verify that no additional hits are recorded for the Blue service while it is DOWN.
17. Unbind the bad monitor from the Blue service:
unbind service svc_blue -monitorName mon_rbg_httpecv_bad
18. Update services for Blue and Green to use the HTTP monitor (the same as Red):
Bind mon_rbg_http to svc_blue:

bind service svc_blue -monitorName mon_rbg_http
Bind mon_rbg_http to svc_green:

bind service svc_green -monitorName mon_rbg_http
save ns config
Key Takeaways:
• Load balancing consists of creating a server, services, and load-balancing virtual servers.
• Layer 7 monitors such as HTTP and HTTP-ECV are almost always better suited for use
with web applications than TCP monitors.
• Load-balancing methods and persistence are specific to an application and control.
• The stat and show commands are useful for viewing load-balancing, service, and
monitoring statistics to verify traffic distribution across services.
Exercise 5-2: Load Balancing DNS (CLI)
Introduction:
90
In this exercise, you will learn to load balance DNS servers by creating DNS service groups, DNS
monitors, and a DNS (UDP) load-balancing virtual server. You will use the commandline
interface to perform this exercise.
About DNS Load Balancing:
DNS Load Balancing allows administrators to load balance DNS queries across multiple DNS
servers. The load-balancing method is usually round-robin and persistence is not required. A
ping monitor can be used for basic UP-state detection. However, the Citrix ADC DNS monitor
allows administrators to determine DNS server availability based on whether a DNS query
returns a successful result. The monitor should be configured to look for name resolution for a
component that will always be present and whose IP address is unlikely to change.
While not demonstrated in the exercise, when the Citrix ADC is configured as a DNS load
balancer (also known as a DNS Proxy), the Citrix ADC will also cache DNS requests.
This exercise configures DNS load balancing using the DNS protocol which supports DNS
(UDP:53) responses that are smaller than 512 bytes. The Citrix ADC can also support DNS
(TCP:53) packets using the DNS_TCP protocol, which supports responses of greater than 512
bytes in size. DNS load balancing can be configured with both a DNS and DNS_TCP virtual server
in production in much the same way that a web application can be configured for HTTP and
HTTPS. DNS_TCP is not demonstrated in this exercise.
About Service Groups:
This exercise also introduces the use of service groups.
Services represent the type of application running on a given server; services are defined as a
destination IP and Protocol: Port indicating the type of traffic on the destination. In the previous
exercise for HTTP, a unique service was created for each Red, Blue, Green server. Each service,
though, had to be individually configured with service settings and monitors.
A service group allows management of all settings for a related group of services once at the
service group level. While the individual service group members identify the application type
and traffic destinations (IP:Protocol: Port), monitors can be bound once at the service group
level, but apply to each member in the group.
Step Action
91
2. Create a service group for the Domain Controllers for DNS:

• AD.workspacelab.com: 192.168.30.11
• AD02.workspacelab.com: 192.168.30.12
Service groups can reference existing named server objects or can point to unnamed servers by IP
address. For this exercise, create the service group by referencing the servers by IP address instead
of by server object name.
Create a service group:

add serviceGroup svcg_domain_dns DNS
Bind the traffic destinations to the service group:

bind serviceGroup svcg_domain_dns 192.168.30.11 53
bind serviceGroup svcg_domain_dns 192.168.30.12 53
Alternate method: Bind the multiple consecutive traffic destinations to the service group in one step
using the ranged notation (for consecutive IP address ranges):
bind serviceGroup svcg_domain_dns 192.168.30.[11-12] 53
3. View service group configuration:
show serviceGroup svcg_domain_dns
View service group configuration commands:
show ns runningconfig | grep svcg_domain_dns -i
4. Create a load-balancing vserver for the DNS service group:
add lb vserver lb_vsrv_dns DNS 172.21.10.102 53 -lbMethod ROUNDROBIN
Bind the service group:

bind lb vserver lb_vsrv_dns svcg_domain_dns
5. Test DNS Load Balancing:
Open a CMD prompt from the HOST desktop. Use nslookup to test a DNS lookup against the DNS
virtual server. Run the following command:
By supplying the DNS virtual server VIP in the request, nslookup will direct the lookup against this
specific DNS server and not another DNS server available to the HOST desktop.
6. Return to the SSH session for the Citrix ADC.
7. View the stats for the DNS virtual server:
show lb vserver lb_vsrv_dns
stat lb vserver lb_vsrv_dns
92
8. Create a DNS monitor:

This monitor performs a DNS lookup against monitored services using the value in the query
parameter and confirms that a response is received and that it matches the results of the IP address
parameter. If no response is received or the returned IP address does not match the return value list
in the monitor, the probe fails.
add lb monitor mon_dns DNS -query NYC-WEB-RED.workspacelab.com -queryType Address -
IPAddress 192.168.30.51 -LRTM DISABLED -interval 5 respTimeout 2 -downTime 30 -retries 3
9. Bind the Monitor to the service group:

bind serviceGroup svcg_domain_dns -monitorName mon_dns
10. View the Service Group and members to verify that the monitor is functioning:
show serviceGroup svcg_domain_dns
Notice how the monitor is associated with each member of the Service Group.
Also, confirm that both DNS service members are UP due to the monitor and not failing.
11. Test DNS Load Balancing:
Open a CMD prompt from the HOST desktop. Use nslookup to test a DNS lookup against the DNS
virtual server. Run the following command:
nslookup NYC-WEB-BLUE.workspacelab.com 172.21.10.102
By supplying the DNS vserver VIP in the request, nslookup will direct the lookup against this specific
DNS server and not another DNS server available to the HOST desktop.
save ns config
Key Takeaways:
• Service Groups can be used in place of individual services when load balancing.
• Properties that affect individual services can all be managed once at the Service
Group level. Monitors can be bound once at the group level and be used for all
member services.
• Viewing properties, member status, and monitor results in service groups are slightly
different than viewing service details in the GUI; however, all the same, information
is present.
• DNS monitors are used to verifying a successful DNS query and IP address resolution.
The monitor should be configured with a DNS name and IP address for an entity in
the environment that is unlikely to change often.
• DNS load balancing requires the creation of servers, services or service groups, and
load-balancing virtual servers, just like HTTP load balancing. The process is the same,
but the details such as load-balancing methods and persistence may vary according
to application.
93
Exercise 5-3: Load Balancing LDAP (CLI)

Introduction:
In this exercise, you will learn to load balance LDAP authentication servers (Domain Controllers)
by creating LDAP service groups, LDAP monitors, and an LDAP load-balancing virtual server. You
About LDAP Load Balancing:
LDAP load balancing is used to provide redundancy for authentication services. This exercise
focuses on LDAP authentication using Microsoft Active Directory Domain Controllers, but
authentication load balancing can be configured for other authentication services such as
Radius. If a domain controller is offline, authentication requests can be directed to another
domain controller.
The LDAP load-balancing virtual server will be used in later exercises when external
authentication is integrated with the Citrix ADC system authentication as part of the delegated
administration configuration.
• Create a Service Group for LDAP.

• Create a Load Balancing Virtual Server for LDAP.
• Configure Monitors for LDAP Load Balancing.
Step Action

94
2. Create a service group for the Domain Controllers for LDAP authentication. The service group for
LDAP authentication is separate from the service group for DNS, even though they are referencing
the same server destinations. Each service group is for a different application (server IP address,
protocol, and port).
Create Service Group:

add serviceGroup svcg_domain_ldap TCP
Bind service group member (individually):

bind serviceGroup svcg_domain_ldap 192.168.30.11 389
bind serviceGroup svcg_domain_ldap 192.168.30.12 389
Or bind service group members (using ranged notation):

bind serviceGroup svcg_domain_ldap 192.168.30.[11-12] 389
3. View service group configuration:

show serviceGroup svcg_domain_ldap
View service group configuration commands:

show ns runningConfig | grep svcg_domain_ldap
4. Create a load-balancing vserver for the LDAP service group:
add lb vserver lb_vsrv_ldap TCP 172.21.10.103 389 -lbMethod ROUNDROBIN
Bind the service group:
bind lb vserver lb_vsrv_ldap svcg_domain_ldap
5. Create the LDAP monitor:

add lb monitor mon_ldap LDAP -scriptName nsldap.pl –baseDN "dc=workspacelab,dc=com" -
bindDN trainADUser@workspacelab.com -filter cn=Builtin -attribute memberOf -password
Password1 -LRTM DISABLED
This monitor will attempt to connect to the LDAP authentication server using a supplied service
account. The account must exist in the LDAP directory service.
Note: This monitor will fail if the service account used is disabled or password changes.
The filter parameter is used to limit the number of objects returned by the monitor query to avoid
issues with the monitor response taking too long to return in environments with a large number of
directory services objects.
If not specified, default values are:

Probe interval: 5 sec
Response Timeout: 2 sec
Down time: 30 sec
Retries: 3 will be used
6. Bind the LDAP monitor to the service Group:
bind serviceGroup svcg_domain_ldap -monitorName mon_ldap
95
7. View the service group and members to verify that the monitor is functioning:
show serviceGroup svcg_domain_ldap
LDAP authentication with the LDAP vServer will be demonstrated in a later exercise.
save ns config
Key Takeaways:
• The Citrix ADC does not have a predefined application type for LDAP, so configuring
load-balancing virtual servers and services/service groups as TCP:389 will work for LDAP
communication.
• The custom LDAP monitor can be used to verify the UP state of authentication servers by
performing a test authentication query. The service account must have a minimum of
domain user permissions to enumerate objects in the domain.
Exercise 5-4: Load-Balancing MYSQL Databases (CLI)

Introduction:
In this exercise, you will learn to configure basic load balancing for MYSQL database servers. The loadbalancing
configuration in this exercise is based on a read-only database in which all queries can be distributed actively across
both database servers. Load balancing database traffic also requires the configuration of a database account.
Database monitoring requires configuration of SQL queries. You will use the command-line interface to perform
this exercise.
The exercise begins with configuring active-active load balancing across two database servers, similar to the other
load-balancing exercises in this module. Then the exercise demonstrates configuring an active-passive load
balancing configuration for the database servers using a primary virtual server with a backup virtual server
example.
• Create Database User, Services, and Load-Balancing Virtual Server for MYSQL.
• Configure Database Load Balancing with a Backup Virtual Server.
Create Database User, Services, and Load-Balancing Virtual Server for MYSQL
Step Action
1. Connect to the Citrix ADC HA Pair using the ADC-MGMT SNIP (192.168.10.103) using SSH
(PuTTY).

2. Create the SQL account as a DB user credential on the Citrix ADC:
add db user netscalersql -password netscaler
96
3. Create server objects for the MySQL servers:

NYC-LMP-001: 192.168.30.61
add server srv_NYC-LMP-001 192.168.30.61 -state DISABLED
NYC-LMP-002: 192.168.30.62
add server srv_NYC-LMP-002 192.168.30.62 -state DISABLED
IMPORTANT: Create server objects in a disabled state until services with PING monitors are
configured. This avoids creating a scenario in which the default TCP monitor probe creates an
error on the MYSQL servers because the servers only see a three-way handshake and treat the
probe as a connection error. Servers will be enabled after monitors have been properly configured
for the services.
4. Create services for NYC-LMP-001 and NYC-LMP-002:
add service svc_NYC-LMP-001 srv_NYC-LMP-001 MYSQL 3306
add service svc_NYC-LMP-002 srv_NYC-LMP-002 MYSQL 3306
These servers are running MySQL, not MSSQL.
5. Create a load-balancing vserver for the MySQL services:
add lb vserver lb_vsrv_mysql MYSQL 172.21.10.104 3306 -lbmethod leastconnection
Bind services to the load-balancing vServer:

bind lb vserver lb_vsrv_mysql svc_NYC-LMP-001
bind lb vserver lb_vsrv_mysql svc_NYC-LMP-002
6. Bind ping monitors to the lamp services:
bind service svc_NYC-LMP-001 -monitorName ping
bind service svc_NYC-LMP-002 -monitorName ping
7. Enable the server objects:

enable server srv_NYC-LMP-001
enable server srv_NYC-LMP-002
Now that the ping monitor has been bound to replace the tcp_default monitor, the servers can be
enabled.
8. Verify that the services are UP:
show service svc_NYC-LMP-001
show service svc_NYC-LMP-002
9. Test MySQL Load Balancing:
• Open HeidiSQL using the shortcut on the Desktop.
• Select MySQLTest in the left pane.
• Click Open.
• The HeidiSQL should connect successfully to the database using the load-balancing
virtual server.
MySQLTest Connection Settings (for Reference):
• MySQL (TCP/IP)
• Hostname/IP: 172.21.10.104 (This is the VIP for lb_vsrv_mysql)
97
• User: netscalersql
• Password: netscaler
• Databases: imdb
• Open and Click NO on the popup window
10. Test Database connection:
The connection pane will display MySQL > imdb. Database tables are displayed in the left pane.
• Select imdb in the left pane. Select Query tab in the right pane.
• Enter the following query in the Query pane to test the connection:
• Click the Play button on the taskbar (above the query pane).
Keep Heidi SQL open and reuse this connection for later tests. You will replay this query several
times.
11. Return the SSH connection to NSMGMT SNIP (192.168.10.103).
12. Create a MySQL Monitor:
add lb monitor mon_mysql_ecv MYSQL-ECV -userName netscalersql -lrTM disABLED
database imdb -sqlQuery 'select * from actors where actors.last_name = "Tazova"'
evalRule "mysql.RES.ATLEAST_ROWS_COUNT(1)"
13. Bind MYSQL Monitor to Services.
Bind monitor to service svc_NYC-LMP-001:
bind service svc_NYC-LMP-001 -monitorName mon_mysql_ecv
bind service svc_NYC-LMP-002 -monitorName mon_mysql_ecv
14. Unbind PING Monitor from Services.
unbind service svc_NYC-LMP-001 -monitorName ping
unbind service svc_NYC-LMP-002 -monitorName ping
15. Verify that the monitor is correct:
show lb vserver lb_vsrv_mysql
Verify, in the service list, that both services are UP.
Note: If the service is showing as down, change the below setting in the monitor mon_mysql
from GUI: Connect to http://192.168.10.103. Go to Traffic Management > Load Balancing >
Monitors > mon_mysql Change the below settings:
• Interval: 20 sec
Due to multiple network latency in the Lab, sometimes the connection to the MySQL server might
take more than 10 seconds. To address it we are changing the Interval and Response timeout in
the monitor.
98
16. Test MySQL Load Balancing (Test 2):

• Reconnect to MySQLTest and the imdb database if not still connected.
• Click Play to repeat the following Query. (Re-enter if necessary).
17. Return to the SSH session for ADC-GMT SNIP (192.168.10.103).
18. View load balancing stats:
stat lb vserver lb_vsrv_mysql
Configure Database Load Balancing with a Backup Virtual Server
Step Action
1. Connect to the Citrix ADC HA Pair using the NSMGMT SNIP (192.168.10.103) using SSH (PuTTY).
2. Unbind svc_NYC-LMP-002 from lb_vsrv_mysql:
unbind lb vserver lb_vsrv_mysql svc_NYC-LMP-002
The lb_vsrv_mysql is now bound to a single service svc_NYC-LMP-001.
3. Create a new load-balancing virtual server as a backup virtual server for the database
connection.
add lb vserver lb_vsrv_mysql_backup mysql
This is a non-addressable virtual server. No VIP or PORT is assigned. This will act as a Citrix ADC
internal-only entity.
4. Bind svc_NYC-LMP-002 to the load-balancing virtual server as a backup database.
bind lb vserver lb_vsrv_mysql_backup svc_NYC-LMP-002
5. Verify the load-balancing virtual server configuration:
show lb vserver lb_vsrv_mysql_backup
Verify that each virtual service only has a single service bound (svc_NYC-LMP-001 and svc_NYC-
LMP-002, respectively).
6. Configure the backup virtual server on lb_vsrv_mysql:

set lb vserver lb_vsrv_mysql -backupvServer lb_vsrv_mysql_backup
• Reconnect to MySQLTest and the imdb database if not still connected.
• Click Play to repeat the following Query. (Re-enter if necessary)
Repeat the query several times.
99
8. Verify service hits:

stat lb vserver lb_vsrv_mysql_backup
Stats are reported for svc_NYC-LMP-001 on lb_vsrv_mysql. No stats (hits) are reported for
svc_NYC-LMP-002 on lb_vsrv_mysql_backup.
9. Disable server NYC-LMP-001 to simulate an outage:

disable server srv_NYC-LMP-001
10. Verify that the load-balancing virtual server states:
Verify the following on lb_vsrv_mysql that state is DOWN and effective State is UP:
show lb vserver lb_vsrv_mysql_backup
Verify on lb_vsrv_mysql_backup that state is UP.
• Reconnect to MySQLTest and the imdb database, if not still connected.
• Click Play to repeat the following Query: (Re-enter if necessary)
This test was handled by svc_NYC-LMP-002 via the lb_vsrv_mysql_backup. The HeidiSQL
connection to 172.21.10.104 (lb_vsrv_mysql) did not even need to be closed and re-opened.
12. Verify service hits:
stat lb vserver lb_vsrv_mysql_backup
Stats are reported for svc_NYC-LMP-002 on lb_vsrv_mysql_backup. No new stats (hits) are
occurring for svc_NYC-LMP-001 on lb_vsrv_mysql.
13. Save the Citrix ADC configuration
save ns config
Key Takeaways:
• Database load balancing allows for TCP connection multiplexing for database traffic
similar to TCP connection multiplexing for HTTP traffic.
• Connections to MYSQL (and MSSQL) databases require the Citrix ADC to be configured
with a valid database account. Even when not using a database-specific monitor, the
Citrix ADC authenticates to establish a valid connection for the service. Database user
account names and passwords are both case sensitive.
• The backup virtual server property of a load-balancing virtual server is invoked when the
primary virtual server is in a DOWN state because no services are available. A configured
backup virtual server in a UP state can cause the primary virtual server effective state to
remain UP and provide seamless failover for traffic directed to the primary virtual server.
100
Module 6: SSL Offload

Overview:
Company ABC needs you to configure access to a web application over HTTPS. Your job as the
administrator will be to use the Citrix ADC certificate tools to generate the initial SSL certificate
and private key for the new web application. Configure SSL Offload using frontend SSL only and
then update the configuration to an end-to-end SSL configuration. Finally, configure a redirect
for all HTTP traffic to the HTTPS virtual server using a load-balancing virtual server with a
redirect URL.
• Configure and manage SSL Certificates.

• Configure SSL offload and end-to-end encryption with load-balancing virtual servers. 
Configure HTTP requests to redirect to HTTPS.
the Citrix ADC CLI:
• Exercise: Configuring SSL Certificates

• Exercise: Configuring SSL Offload
• Exercise: Configuring End-to-End Encryption
• Exercise: Configuring HTTP to HTTPS Redirect Using Redirect URL
Before you Begin:

module.
• NYC-ADC-001
• NYC-ADC-002
• NYC-WEB-BLU
• NYC-WEB-RED
• NYC-WEB-GRN
101
Exercise 6-1: Configuring SSL Certificates (GUI)

Introduction:
In this exercise, you will learn to use the Citrix ADC self-signing certificate tools to create SSL
keys, Certificate Signing Requests, and Certificate files. The exercise will also demonstrate how
to create the SSL cert key object (certificate-private key pair) to make the certificate available
for use on the Citrix ADC. You will use the Citrix ADC Configuration Utility GUI to perform this
exercise.
All SSL operations will be conducted while the Citrix ADC is in an active High Availability pair. As
a result, synchronization of certificate files and SSL configurations will also be demonstrated.
• Create an RSA Key.

• Create a Certificate Signing Request.
• View a Certificate Request (to Submit to a Certificate Authority).
• Create a Certificate.
• Configure a Certificate-Key pair.
Creating an RSA Key

Step Action
1. Connect to the Citrix ADC HA Pair configuration utility using the ADC-MGMT SNIP at
http://192.168.10.103.
2. Create an RSA Key:

• Browse to Traffic Management > SSL.
• Click Server Certificate Wizard in the SSL Pane under Getting Started.
• The Create Key dialog box opens.
3. Select RSA. Enter colors.key in Key Filename field.
Note: The RSA key file is generated in the /nsconfig/ssl/ default if no path is specified. All filenames
and paths are case-sensitive on the Citrix ADC. Be sure to reference the name used in this step in
future tasks.
4. Enter 2048 in the Key Size (bits) field.
5. Select F4 from the Public Exponent Value drop-down list box.
6. Select PEM from the Key Format drop-down list box.
7. Select AES256 as the PEM Encoding Algorithm.
102
8. Enter Password1 in the PEM Passphrase and Confirm PEM Passphrase fields.
Note: For lab purposes, the passwords and passphrases used with most accounts are simplified to
Password1. Always use strong passwords and secure passphrases when protecting access to SSL
private keys.
9. Click Create.
Creating a Certificate Signing Request

Step Action
1. Create a Certificate Signing Request:
• Create Certificate Singing Request (CSR) wizard step 2 opens.
This task will reference the RSA Key generated in the previous task.
2. Enter CSR parameters:
• Enter colors.csr in the Request File Name field. (This is the output file for this task.)
3. Select the Private Key (colors.key) for the Key Filename field:
• Expand Browse and click Appliance.
• Select colors.key and click Open.
4. Select PEM under Key Format.
5. Enter Password1 in the PEM Passphrase field.
6. Select SHA256 under Digest Method.
7. Complete the Distinguished Name Fields for the Certificate Request. This identifies to the Certificate
Authority the details of the certificate to issue:
• Country: United States
• State or Province: California
• Organization Name: Colors Training
• Common Name: colors.workspacelab.com
8. Enter Password1 in the Challenge Password (for the CSR).
9. Click Create.
Generating the SSL Certificate

Step Action
1. The Certificate creation wizard is next.
• Enter colors.cer in the Certificate File Name field.

This will be the certificate generated by the Citrix ADC at the end of this task.
2. Select PEM under Certificate Format.
3. Under Auditing Type should state Server.
4. The Certificate Request File Name field should already contain colors.csr.
The full path to the file is displayed: /nsconfig/ssl/colors.csr.
103
5. Select the Certificate Authority issuing the certificate. This will be the Citrix ADC's Root CA certificate
file.
• Under CA Certificate File Name, click Choose File, select Appliance.

• Select ns-root.cert and click Open.
6. Select the Certificate Authority Key File for the Citrix ADC Root CA:
• Under CA Key File Name, click Choose File, select Appliance.
• Select ns-root.key and click Open.
• Verify PEM under CA Key File Format.
• Leave PEM Passphrase <blank>
104
7. Select the Certificate Authority Serial Number for the Citrix ADC Root CA:
• Under CA Serial File Number, click Choose File
• Select ns-root.srl, Click Open and Click Create
See Example:
Creating a Certificate-Key Pair

Step Action
105
1. Step 4 Install Certificate wizard.
Note: The Install Certificate dialog box opens. This dialog box can be used to create SSL certkey
objects (Certificate-Private Key pairs) from certificate files and private keys already uploaded to the
Citrix ADC or it can be used to upload files from the local workstation to the Citrix ADCs. Any
uploaded certificates and key files are stored in the /nsconfig/ssl/ directory. Certificate actions
perform from the GUI (and corresponding CLI commands) will automatically trigger file
synchronization with the partner Citrix ADC in an HA Pair.
2. Enter colors.workspacelab.com in the Certificate-Key Pair Name field.
3. Enter Password1 in the Password field.
Note: If the Password* field is not visible, click the down arrow under Key File Name, select
Appliance, the colors.key, and click Open.
4. Click Create.
5. Click Done.
6. Synchronize HA files:
• Browse to Traffic Management > SSL.
• Click Start SSL certificate, key file synchronization for HA under Tools in the right pane.
• Verify SSL Certificates and Keys is selected.
• Click OK.
Explicitly synchronizing certificate files between Citrix ADCs in an HA pair helps avoid waiting for
the next synchronization event.
7. Save the Citrix ADC Configuration and confirm.
Viewing a Certificate Request (to Submit to Certificate Authority) OPTIONAL

Step Action
1. Click Manage Certificates / Keys / CSRs in the SSL Pane (under Tools).
2. Select colors.csr and click View.
3. The Certificate Signing Request is Displayed.
Note: The Citrix ADC Configuration Utility can be used to view, upload, or download Certificates and
CSRs straight from the Citrix ADC. By viewing the CSR, you can copy the contents of the request to
paste into a Certificate request form. The CSR can also be downloaded from the Citrix ADC for
delivery to a Certificate Authority. This exercise will continue with generating a signed certificate
from the Citrix ADC's built-in SSL Tools as a self-signed certificate. In production, this utility could be
used to download the CSR to complete the Certificate Request process with a Domain CA or other
third-party public CA as appropriate.
Click Close to close the CSR View File dialog box.

4. Click Close to close the Manage Certificates pane.
Key Takeaways:
106
• Managing SSL certificate tasks using the Citrix ADC GUI will automatically result in
necessary certificate files and SSL settings being propagated or synchronized to the
secondary Citrix ADC in an HA pair.
• Manual file synchronization for SSL certificates and keys can be triggered, needed.
• The Citrix ADC contains a full range of SSL tools to enable the generation of RSA and DSA
private keys, Certificate Signing Requests, and SSL Certificate files. These tools can be
used to generate self-signed certificates by the Citrix ADC or as part of a certificate
request process using domain or third-party certificate authorities.
Exercise 6-2: Configuring SSL Offload (GUI)
Introduction:
In this exercise, you will learn to configure a load-balancing virtual server for SSL Offload
(frontend SSL only). You will use the Citrix ADC Configuration Utility GUI to perform this
exercise.
During the SSL Offload configuration, a load-balancing virtual server of type SSL is created and
bound to HTTP services. This will allow client-to-Citrix ADC (VIP) communication to be encrypted
but will leave Citrix ADC (SNIP)-to-server communication unencrypted.
The Citrix ADC is the SSL termination point for the traffic and, as a result, will decrypt and can
then inspect or even modify the requests. The Citrix ADC can perform advanced security
inspections and filtering on the traffic using features such as App Firewall, Responder, Rewrite,
Content Switching, and Content Filtering. The Citrix ADC can also perform optimizations such as
compression and caching.
For SSL Offload to be configured, the SSL feature must be enabled and a certificate must be
bound to the virtual server.
Finally, the exercise demonstrates how to disable SSLv3 at the virtual server level, since it is on
by default. Disabling SSLv3 is a security recommendation to avoid vulnerabilities associated with
the SSLv3 protocol.
• Create a load-balancing virtual server for SSL and bind to HTTP services.
• Bind an SSL certificate to the virtual server.
• Test the SSL connection.
Step Action
http://192.168.10.103.
107
2. Create a load-balancing virtual server for SSL Offload (Frontend SSL; Backend HTTP).
• Click Add.

• Enter ssl_vsrv_rbg in the Name field.
• Select SSL from the Protocol drop-down list box.
• Click OK.
Note: This SSL virtual server will be used in conjunction with a separate HTTP virtual server than
lb_vsrv_rbg (172.21.10.105) in later exercises.
4. Bind HTTP Services to the SSL load-balancing virtual server:
• Click Click to Select under Select Service.
• Select svc_red.
• Select svc_blue.
• Select svc_green.
• Click Select.
• Click Bind.
• Click Continue.
5. Bind the SSL Certificate to the vServer:
• Click No Server Certificate under Certificates.
• Click Click to Select and under Select Server Certificate.
• Select colors.workspacelab.com and click Select.
• Click Bind.
• Click OK if you receive the warning message that command propagation failed on
secondary. (See note below).
• Click Continue.
Note: While in an HA Pair, if command propagation from Primary to Secondary fails to apply on the
secondary system, a warning is generated. As a result, the Citrix ADC forces synchronization to occur
to make sure that file sync has occurred for the /nsconfig/ssl/ directory and then the full running-
config has been pushed to the partner system. In the lab, this does not indicate an issue as the
synchronization process still ensures that the commands replicate. If you are concerned, verify that
synchronization completed successfully: Verify that the SSL certificates are in the /nsconfig/ssl
directory on the secondary Citrix ADC. Verify that the SSL certkey is present in the configuration on
the secondary Citrix ADC. Verify that the certificate is bound to the load-balancing virtual server on
the secondary Citrix ADC.
IMPORTANT: Do not break the HA Pair if you receive a propagation error. The course assumes that
NYC-ADC-001 and NYC-ADC-002 remain in an HA pair for the rest of the exercises. Breaking the HA
pair without following proper procedures could result in IP address conflicts and other issues.
108
6. Disable SSLv3:
• Click Edit next to SSL Parameters.
• Clear the SSLv3 checkbox.
• Click OK.
• Click Done to close the Load Balancing Virtual Server load-balancing virtual server
properties.
Verify that the load-balancing virtual server ssl_vsrv_rbg is UP.
8. Test SSL Offload:
• Open a web browser and find https://172.21.10.105/home.php.
You will receive a warning that Firefox detected a potential security risk. Tell the browser to proceed
with the connection anyway.
• In Chrome: Click Advanced and select Proceed with connection anyway.
• In Firefox: Click Advanced and select Accept the Risk and Continue.
Refresh the web site several times. Load balancing with the Red, Blue, and Green content occurs.
The client-to-Citrix ADC communication is secured over SSL. Citrix ADC-to-Server communication is
still HTTP.
Key Takeaways:
• SSL communication can be integrated with load balancing, content switching, SSLVPN,
and traffic management virtual servers on the Citrix ADC. The procedures for binding an
SSL certificate to a load-balancing virtual server can be used with other virtual servers on
the Citrix ADC.
• SSL Offload provides a performance benefit by having the Citrix ADC handle all
encryption and decryption tasks client-side while leaving the server-side communication
unencrypted. While this provides security between the client and the Citrix ADC, this
may not be suitable for all traffic types if end-to-end encryption is required.
• SSL certificates and private key files associated with active certkey objects must be
present on the secondary Citrix ADC in an HA pair. Otherwise, in the event of an HA
failover, any dependent SSL entities will be offline if the required certificates are missing.
• SSlv3 is a security risk and can be disabled on each virtual server. There is no global
setting to disable the use of SSv3.
Exercise 6-3: Configuring End-to-End Encryption (GUI)
Introduction:
In this exercise, you will learn to configure a load-balancing virtual server for end-to-end SSL
(frontend and backend SSL). You will use the Citrix ADC Configuration Utility GUI to perform this
exercise.
109
In this case, the existing SSL virtual server from the previous exercise will be updated to use SSL
services on the backend. This will keep all communication client-to-Citrix ADC (VIP) and Citrix
ADC (SNIP)-to-server encrypted.
The Citrix ADC will still be the SSL termination point, so a certificate for the traffic is still required
on the Citrix ADC for the load-balancing virtual server. While this does not provide the same
performance benefits as SSL Offload, TCP multiplexing is still possible. SSL end-toend provides
advanced traffic processing on the Citrix ADC while maintaining end-to-end security. Features
such as App Firewall, Responder, Rewrite, Compression, and others can still be used the same as
with the SSL Offload scenario.
• Create an SSL service group for Red, Blue, Green web servers.
• Update the load balancing virtual server to use the SSL service group.  Test the load-
balancing virtual server.
Step Action
http://192.168.10.103.

2. Create an SSL Service Group for Red, Blue, Green:
• Click Add. The Load Balancing Service Group dialog box opens.
3. Configure load-balancing Service Group basic settings:
• Enter svcg_rbg_ssl in Name field.
• Select SSL from the Protocol drop-down list box.
• Click OK.
• Click No Service Group Member.
• Select Server Based. (Named servers for Red, Blue, and Green already exist)
• Click Click to Select under Select Server.
• Select srv_red, srv_blue, srv_green and click Select.
• Click Create then OK.
• Click Done.
5. Click Refresh and verify that the Service Group svcg_rbg_ssl is UP (green), indicating all members
are in a UP state.
110
6. Update the load-balancing virtual server ssl_vsrv_rbg to use the SSL Service Group instead of the
HTTP services for end-to-end SSL encryption.
Browse to Traffic Management > Load Balancing > Virtual Servers.
Select ssl_vsrv_rbg and click Edit.
7. Unbind the existing HTTP services from ssl_vsrv_rbg:
• Click 3 Load Balancing Virtual Server Service Bindings under Services and Service Groups.
• Select svc_red, svc_blue, and svc_green and click Unbind.
• Click Yes and click Close.
8. Bind a Service Group to the load-balancing virtual server:
• Click No Load Balancing Virtual Server ServiceGroup Binding under Services and Service
Groups.
• Select svcg_rbg_ssl and click Select.
• Click Bind.
• Click Done.
9. Verify that ssl_vsrv_rbg State is still UP.
11. Test End-to-End SSL Load Balancing:
Refresh the web site several times. Load balancing with the Red, Blue, and Green content occurs.
Now both the client-to-Citrix ADC and the Citrix ADC-to-server communication are secured over
SSL.
Key Takeaways:
• End-to-end SSL requires the configuration of both SSL load-balancing virtual servers and
SSL services.
• End-to-end SSL configurations do not provide the same level of performance benefits as
SSL Offload since the backend servers must still perform encryption and decryption
operations. However, the ability to maintain encryption for all points of communication
for sensitive traffic mitigates any performance impact associated with SSL on the
backend servers.
• The Citrix ADC can still be used to perform traffic optimization and filtering functions on
traffic since it is still the SSL termination point. Features such as App Firewall, Rewrite,
Content Switching, Compression, and others can be used.
Exercise 6-4: Configuring HTTP to HTTPS Redirect Using the
Redirect URL (GUI)
Introduction:
In this exercise, you will learn to redirect requests sent to HTTP to HTTPS. You will use the Citrix
ADC Configuration Utility GUI to perform this exercise.
111
A load-balancing virtual server listens on a specific IP: Port combination. When you configured
the SSL load-balancing virtual server (ssl_vsrv_rbg), the current virtual server configuration will
only respond to requests sent to HTTPS:443. If a user attempts to connect to HTTP instead of
HTTPS for this web site, their request will fail. To solve this problem, you will create an
additional load-balancing virtual server on HTTP:80 that will redirect users to HTTPS.
This exercise will use a DOWN load-balancing virtual server on HTTP as a listener to redirect
traffic to HTTPS. In this case, no unencrypted communication is accepted, but users who forget
to include https:// in the URL will not have failed connections.
The redirect URL property of a virtual server is only used when the virtual server is in a DOWN
state. Later exercises will demonstrate an alternate method to handle HTTP to HTTPS redirects.
• Create a load-balancing virtual server for the HTTP traffic without bound services.
• Configure the redirect URL.
• Test the HTTP to HTTPS redirect.
Step Action
1. Create a new load-balancing virtual server for HTTP traffic using VIP: 172.21.10.105:
• Click Add.
• Enter lb_vsrv_rbg_sslredirect in the Name field.
• Select HTTP from the Protocol drop-down list box.
• Click OK.
• Click Continue.
• Click Done.
This virtual server will have no services associated with it, so it will remain in a DOWN state.
3. Open a web browser and try to find http://172.21.10.105/home.php.
Expected Result: The request will fail. The browser will time out when there is no response from
the vserver.
112
4. Configure the redirect URL to send traffic to HTTPS:

• Select lb_vsrv_rbg_sslredirect and click Edit.
• Click Protection under Advanced Settings to add the protection settings category to the
left pane.
• Enter https://172.21.10.105/home.php in the Redirect URL field.
• Click OK.
• Click Done.
Note: Redirects to HTTPS should be done using an FQDN instead of an IP address so that the
connection will match the FQDN of the SSL certificate allowing the redirect to HTTPS to be
trusted. This is being skipped in this exercise.
113
5. Test the redirect URL. Open a web browser and test the following URLs:
• http://172.21.10.105/
• http://172.21.10.105/home.php
• http://172.21.10.105/remote.php?a1=b1&a2=b2
Expected Result: All three test URLs will be redirected to https://172.21.10.105/home.php. The
redirect path "/home.php" overrides the paths specified in the original HTTP request.
6. Modify the redirect URL to allow the redirect to preserve the original request path and query
parameters:
• Select lb_vsrv_rbg_sslredirect and click Edit.
• Click the Edit icon (pencil) next to Protection to edit the protection settings.
• Enter https://172.21.10.105 in the Redirect URL.
• Click OK.
• Click Done.
114
It is important in this example that the redirect URL only contains the protocol and server portion
of the URL. Do not include any path elements including a final trailing slash "/".
7. Test the modified redirect URL. Open a web browser and test the following URLs:
• http://172.21.10.105/
• http://172.21.10.105/home.php
• http://172.21.10.105/remote.php?a1=b1&a2=b2
Expected Result: All links are successfully redirected to HTTPS. This time, all traffic is redirected to
the same path and query as in the original request to https://172.21.10.105/.
Key Takeaways:
• Redirect URLs are one of two backup methods associated with virtual servers. Redirect
URLs can only be used with virtual servers of type HTTP and HTTPS.
• A Redirect URL is only used when the virtual server state and effective state are DOWN.
When using the redirect URL for an HTTP to HTTPS redirect, the HTTP virtual server is
kept in a DOWN state.
• For the HTTP to HTTPS example, the Redirect URL needs to be configured with an
absolute path to https://<FQDN>. When redirecting to HTTPS://, a fully qualified domain
name that the client can resolve is required to avoid the client making an untrusted
connection to a server that does not match the FQDN of the certificate.
• If the redirect URL is configured without the path portion of the URL, the redirect will
preserve the original path and query elements of the request in the new redirect
destination.
Exercise 6-1: Configuring SSL Certificates (CLI)
Introduction:
In this exercise, you will learn to use the Citrix ADC self-signing certificate tools to create SSL
keys, Certificate Signing Requests, and Certificate files. The exercise also will demonstrate how
to create the SSL certkey object (certificate-private key pair) to make the certificate available for
use on the Citrix ADC. You will use the command-line interface to perform this exercise.
All SSL operations will be conducted while the Citrix ADC is in an active High Availability pair. As
a result, synchronization of certificate files and SSL configurations will also be demonstrated.
115
• Create an RSA Key.

• Create a Certificate Signing Request.
• View a Certificate Request (to Submit to a Certificate Authority).
• Create a Certificate.
• Configure a Certificate-Key pair.
Creating SSL Private Key, Certificate Signing Request, and Certificate Files
Step Action

2. Create an RSA private key with the following details:
• Filename: colors.key
• Key Size: 2048
• Key Type: RSA
• Encoding Algorithm: AES256
create ssl rsakey colors.key 2048 -exponent F4 -aes256 -keyform PEM -password Password1
3. Create a Certificate Signing Request (CSR) with the following details:
• File name (output): colors.csr
• Command name: colors.workspacelab.com
create ssl certReq colors.csr -keyFile colors.key -keyform PEM -PEMPassPhrase Password1
countryName US -stateName California -organizationName "Colors Training" commonName
colors.workspacelab.com -challengePassword Password1
4. Use WinSCP to download or view the certificate request.
• Open WinSCP and connect to 192.168.10.103. Log on as nsroot / nsroot.
• In the right-pane, browse to /nsconfig/ssl.
• Double-click colors.csr to open.
• Press CTRL+A to select the entire contents of the file and CTRL+C to copy the contents of the
file.
• Close the editor.
If the Certificate Signing Request needs to be submitted to a separate Certificate Authority, the above
procedure will allow you to copy and paste the CSR contents to the certificate request form (such as
with Active Directory-integrated CAs) or the CSR file can be downloaded and submitted to the
appropriate CA.
116
5. Generate the SSL Certificate using the Citrix ADC built-in SSL certificate tools:
create ssl cert colors.cer colors.csr SRVR_CERT -days 1825 -CACert ns-root.cert CAKey ns-root.key
CASerial ns-root.srl
When using the create ssl cert (and other certificate management commands), if no path is specified
for the private key, CSR, or cert files supplied the default path /nsconfig/ssl/ is assumed.
Installing the Certificate and Configuring a Certificate-Key Pair

Step Action
1. View Certificate files on the Citrix ADC:
shell
cd /nsconfig/ssl/
ls
2. Verify that the following files were created:

• colors.key
• colors.csr
• colors.cer
3. Exit shell to return to the CLI: exit
4. Create the SSL Certkey (private key-certificate pair):
add ssl certkey colors.workspacelab.com -cert colors.cer -key colors.key -password Password1
Note: A certkey is a Citrix ADC CLI object which acts as a pointer to the private key and certificate on
the file system. Entities on the Citrix ADC can be linked to the certkey, which in turn references the
appropriate private key and certificate pair.
5. Show ssl certkey object:

show ssl certkey
Key Takeaways:
• Generating SSL certificates using the certificate commands in the CLI (create ssl rsakey,
create ssl dsakey, create ssl certreq, and create ssl cert) commands will automatically
result in necessary certificate files being propagated or synchronized to the secondary
Citrix ADC in an HA pair.
• Manually uploading certificates to the Citrix ADC's /nsconfig/ssl directory using
o SCP/SFTP will not trigger automatic file synchronization, and instead, the sync ha
o files ssl command may need to be run manually to ensure that synchronization of
the /nsconfig/ssl node occurs.
• The Citrix ADC contains a full range of SSL tools to enable the generation of RSA and DSA
private keys, Certificate Signing Requests, and SSL Certificate files. These tools can be
used to generate self-signed certificates by the Citrix ADC or as part of a certificate
request process using domain or third-party certificate authorities. In the CLI, use the
"create ssl <object>" commands as wrappers around the built-in OpenSSL tools.
117
Exercise 6-2: Configuring SSL Offload (CLI)

Introduction:
In this exercise, you will learn to configure a load-balancing virtual server for SSL Offload
(frontend SSL only). You will use the command-line interface to perform this exercise.
During the SSL Offload configuration, a load-balancing virtual server of type SSL is created and
bound to HTTP services. This will allow client-to-Citrix ADC (VIP) communication to be encrypted
but will leave Citrix ADC (SNIP)-to-server communication unencrypted.
The Citrix ADC is the SSL termination point for the traffic and as a result will decrypt and can
then inspect or even modify the requests. The Citrix ADC can perform advanced security
inspections and filtering on the traffic using features such as App Firewall, Responder, Rewrite,
Content Switching, and Content Filtering. The Citrix ADC can also perform optimizations such as
compression and caching.
For SSL Offload to be configured, the SSL feature must be enabled and a certificate must be
bound to the virtual server.
Finally, the exercise demonstrates how to disable SSLv3 at the virtual server level, since it is on
by default. Disabling SSLv3 is a security recommendation to avoid vulnerabilities associated with
the SSLv3 protocol.
• Create a load-balancing virtual server for SSL and bind to HTTP services.
• Bind an SSL certificate to the virtual server.
• Test the SSL connection.
Step Action
2. Create a load-balancing virtual server for SSL Offload (SSL frontend only):
add lb vserver ssl_vsrv_rbg SSL 172.21.10.105 443
3. Bind HTTP services for Red, Blue, Green to the load-balancing virtual server:
bind lb vserver ssl_vsrv_rbg svc_red
bind lb vserver ssl_vsrv_rbg svc_blue
bind lb vserver ssl_vsrv_rbg svc_green
4. Bind the SSL Certificate to the vServer:

bind ssl vserver ssl_vsrv_rbg -certkeyName colors.workspacelab.com
118
5. Verify vServer state:

show lb vserver ssl_vsrv_rbg
show ssl vserver ssl_vsrv_rbg
The load-balancing virtual server command shows all the load-balancing settings: UP or DOWN
state, load-balancing method and persistence, and bound services.
The ssl vServer command shows all settings associated with the SSL configuration: cipher suites,
SSL protocols, and certkeys bound.
6. Disable SSLv3 on the vServer:
set ssl vServer ssl_vsrv_rbg -ssl3 disabled
SSLv3 is enabled by default. Due to a security vulnerability, it should be disabled. See

http://support.citrix.com/article/CTX200238
save ns config
8. Test SSL Offload:
You will receive a warning that the certificate is untrusted or that the FQDN does not match the
Certificate. Tell the browser to proceed with the connection anyway.
• In Chrome: Click Advanced and select Proceed with connection anyway.
• In Firefox: Click Advanced and select Add exception > Confirm Security Exception.
Refresh the web site several times. The client-to-Citrix ADC communication is secured over SSL.
Citrix ADC-to-Server communication is still HTTP.
Key Takeaways:
• SSL communication can be integrated with load balancing, content switching, SSLVPN,
and traffic management virtual servers on the Citrix ADC. The procedures for binding an
SSL certificate to a load-balancing virtual server can be used with other virtual servers on
the Citrix ADC.
• SSL Offload provides a performance benefit by letting the Citrix ADC handle all
encryption and decryption tasks on the client-side while leaving the server-side
communication unencrypted. While this provides security between the client and the
Citrix ADC, this may not be suitable for all traffic types if end-to-end encryption is
required.
• SSL certificates and private key files associated with active certkey objects must be
present on the secondary Citrix ADC in an HA pair. Otherwise, in the event of an HA
failover, any dependent SSL entities will be offline if the required certificates are missing.
• SSlv3 is a security risk and can be disabled on each virtual server. There is no global
setting to disable the use of SSv3.
Exercise 6-3: Configuring End-to-End Encryption (CLI)
Introduction:
119
In this exercise, you will learn to configure a load-balancing virtual server for end-to-end SSL
(frontend and backend SSL). You will use the command-line interface to perform this exercise.
In this case, the existing SSL virtual server from the previous exercise will be updated to use SSL
services on the backend. This will keep all communication client-to-Citrix ADC (VIP) and Citrix
ADC (SNIP)-to-server to be encrypted.
The Citrix ADC will still be the SSL termination point, so a certificate for the traffic is still required
on the Citrix ADC for the load-balancing virtual server. While this does not provide the same
performance benefits as SSL Offload, TCP multiplexing is still possible. SSL end-to -end provides
advanced traffic processing on the Citrix ADC while maintaining end-to-end security. Features
such as App Firewall, Responder, Rewrite, Compression, and others can still be used, just as with
the SSL Offload scenario.
• Create SSL service group for Red, Blue, and Green web servers.
• Update the load-balancing virtual server to use the SSL service group.
• Test the load-balancing virtual server.
Step Action
2. Create an SSL (443) Service Group for Red, Blue, Green:
add serviceGroup svcg_rbg_ssl SSL
Bind traffic destinations to the Service Group (using the existing named server objects):
bind serviceGroup svcg_rbg_ssl srv_red 443
bind serviceGroup svcg_rbg_ssl srv_blue 443
bind serviceGroup svcg_rbg_ssl srv_green 443
3. Verify service group configuration:

show serviceGroup svcg_rbg_ssl
Verify that all members are in a UP state.

4. Unbind the HTTP services from ssl_vsrv_rbg:
unbind lb vserver ssl_vsrv_rbg svc_red
unbind lb vserver ssl_vsrv_rbg svc_blue
unbind lb vserver ssl_vsrv_rbg svc_green
5. Bind the SSL service group to ssl_vsrv_rbg, enabling end-to-end encryption:
bind lb vserver ssl_vsrv_rbg svcg_rbg_ssl
save ns config
120
7. Test End-to-End SSL Load Balancing:

Refresh the web site several times. Now, both the client-to-Citrix ADC communication and the Citrix
ADC-to-Server communication are secured over SSL.
Key Takeaways:
• End-to-end SSL requires the configuration of both SSL load-balancing virtual servers and
SSL services.
• End-to-end SSL configurations do not provide the same level of performance benefits as
SSL Offload since the backend servers must still perform encryption and decryption
operations. However, the ability to maintain encryption for all points of communication
for sensitive traffic mitigates any performance impact associated with SSL on the
backend servers.
• The Citrix ADC can still be used to perform traffic optimization and filtering functions on
traffic since it is still the SSL termination point. Features such as App Firewall, Rewrite,
Content Switching, Compression, and others can be used.
Exercise 6-4: Configuring HTTP to HTTPS Redirects Using
Redirect URL (CLI)
Introduction:
In this exercise, you will learn to redirect requests sent to HTTP to HTTPS. You will use the
A load-balancing virtual server listens on a specific IP: Port combination. When you configured
the SSL load-balancing virtual server (ssl_vsrv_rbg), the current virtual server configuration will
only respond to requests sent to HTTPS:443. If a user attempts to connect to HTTP instead of
HTTPS for this web site, the user request will fail. To solve this problem, you will create an
additional load-balancing virtual server on HTTP:80 that will redirect users to HTTPS.
This exercise will use a DOWN load-balancing virtual server on HTTP as a listener to redirect
traffic to HTTPS. In this case, no unencrypted communication is accepted, but users who forget
to include https:// in the URL will not have failed connections.
The redirect URL property of a virtual server is only used when the virtual server is in a DOWN
state. Later exercises will demonstrate an alternate method to handle HTTP to HTTPS redirects.
• Create a load-balancing virtual server for the HTTP traffic with no bound services.
• Configure the redirect URL.
• Test the HTTP to HTTPS redirect.
121
Step Action
2. Create a new load-balancing virtual server for HTTP traffic using VIP 172.21.10.105:
add lb vserver lb_vsrv_rbg_sslredirect HTTP 172.21.10.105 80
This virtual server will have no services associated with it so it will remain in a DOWN state.
3. Open a web browser and try to find http://172.21.10.105/
Expected Result: The request will fail. The browser will time out when there is no response from the
virtual server.
4. Configure the redirect URL to send traffic to HTTPS:
set lb vserver lb_vsrv_rbg_sslredirect –redirectUrl "https://172.21.10.105/home.php"
The redirect URL will allow this vServer when DOWN to redirect traffic to an alternate URL as a
backup option.
5. Test the redirect URL. Open a web browser and test the following URLs:
http://172.21.10.105/
http://172.21.10.105/home.php
http://172.21.10.105/remote.php?a1=b1&a2=b2
Expected Result: All three test URLs will be redirected to https://172.21.10.105/home.php.

The redirect path "/home.php" overrides the paths specified in the original HTTP request.
6. Modify the redirect URL to allow the redirect to preserve the original request path and query
parameters:
set lb vserver lb_vsrv_rbg_sslredirect -redirectUrl "https://172.21.10.105"
It is important in this example that the redirect URL only contains the protocol and server portion of
the URL. Do not include any path elements including a final trailing slash "/".
7. Test the modified redirect URL. Open a web browser and test the following URLs:
http://172.21.10.105/
http://172.21.10.105/home.php
http://172.21.10.105/remote.php?a1=b1&a2=b2
Expected Result: All links are successfully redirected to HTTPS. This time, all traffic is redirected to the
same path and query as in the original request to https://172.21.10.105/.
save ns config
Key Takeaways:
• Redirect URLs are one of two backup methods associated with virtual servers. Redirect
URLs can only be used with virtual servers of type HTTP and HTTPS.
122
• A Redirect URL is only used when the virtual server state and effective state are DOWN.
When using the redirect URL for an HTTP to HTTPS redirect, the HTTP virtual server is
kept in a DOWN state.
• For the HTTP to HTTPS example, the Redirect URL needs to be configured with an
absolute path to https://<FQDN>. When redirecting to HTTPS://, a fully qualified domain
name that the client can resolve is required to avoid the client making an untrusted
connection to a server that does not match the FQDN of the certificate.
• If the redirect URL is configured without the path portion of the URL, the redirect will
preserve the original path and query elements of the request in the new redirect
destination.
123
Module 7: Securing the Citrix ADC

Overview:
Company ABC wants to enable delegated administration on the Citrix ADC using their Active
Directory Domain accounts. Your job as the administrator is to configure external authentication
using LDAP and manage the initial group permission assignments. Afterward, you will configure
the initial Admin Partitions for future projects.
In this module, you will perform hands-on exercises to configure basic Citrix ADC system
authentication. Delegated administration will be examined, starting with local system accounts
and the built-in command policies, followed by integration with LDAP using external
authentication policies and group extraction. You will also configure an initial Admin Partitions
setup to create separate administration boundaries within a single appliance (while in an HA
Pair). Partition-level networking will not be configured.
• Configure delegated administration.

• Configure external authentication and group extraction.
• Configure Admin Partitions.
the Citrix ADC CLI:
• Exercise: Configuring Local Authentication and Delegated Administration

• Exercise: Configuring External Authentication with LDAP
• Exercise: Admin Partitions
module.
• NYC-ADC-001
• NYC-ADC-002
• NYC-WEB-BLU
• NYC-WEB-RED
• NYC-WEB-GRN
• NYC-ADS-001
• NYC-ADS-002
124
Before you Begin:

Active Directory Authentication Infrastructure
Active Directory Value
AD Domain Controller 192.168.30.11
AD2 Domain Controller 192.168.30.12
Administrator BindDN trainaduser@workspacelab.com
BindDN Account Password Password1
Active Directory Groups and Accounts for Citrix ADC Delegated Administration
GROUP USER PASSWORD Policy
Training_NSAdmins trainNSAdmin Password1 Superuser
Training_NSOperators trainNSOperator Password1
Contractors contractor Password1 show_only
Domain Users trainADuser Password1
Note: During this exercise, all Group Names are case sensitive when performing group
extraction on the Citrix ADC.
125
Exercise 7-1: Configuring Local Authentication and Delegated

Administration (GUI)
Introduction:
In this exercise, you will learn to create local system accounts, assign passwords, and change
delegated administration permissions by using built-in and custom command policies. You will
use the Citrix ADC Configuration Utility GUI to perform this exercise.
All administrative access to the Citrix ADC is handled by system users or system groups. Local
accounts can be created on the Citrix ADC, where the Citrix ADC is the local credential authority.
User accounts, passwords, and group members belong to local objects on the Citrix ADC.
All administrative permissions on the Citrix ADC are controlled by command policies. Command
policies define regular expressions (using PCRE regex syntax) that identify commands that are
allowed or denied to run. Any command not explicitly allowed is automatically denied by the
default permissions. The built-in command policies provide basic administrative controls for
regular administrators and partition administrators. But custom command policies can be
configured and bound to system users or system groups. The permissions granted by the
command policies determine which information is visible within the GUI and which actions can
be performed in the GUI or CLI.
Local authentication is simple to set up. The accounts will be synchronized amongst an HA pair.
However, most environments will integrate with external authentication for more robust
account, credential, and group management.
• Creating a Local System Account.

• Creating a Custom Command Policy.
Creating a Local System Account
Step Action
http://192.168.10.103.
2. Create a new local system user:
• Browse to System > User Administration > Users.
• Click Add.
126
3. Create a local account called "testuser" with read-only permissions:

• Enter testuser in the User Name field.
• Enter Password1 in the Password and Confirm Password fields.
• Click Continue.
Note: Do not create local accounts named "test" or some other variation on the Citrix ADC.
Require that any account used to authenticate to the Citrix ADC meet minimum complexity
requirements for passwords. If configuring accounts for test purposes, do not forget to disable and
remove the accounts when done. Do not grant delegated administrators accounts of higher
permissions than necessary. These leftover accounts, with easily guessed user names or
passwords, could inadvertently provide unpermitted access to an appliance.
4. Assign read-only permissions to the testuser account:
• Click No System Command Policy.
• Click Click to Select under Select Policy.
• Select read-only and click Select in the Command Policies dialog box.
• Click Bind.
• Click Save.
• Click Done.
Creating a Custom Command Policy

Step Action
http://192.168.10.103.
2. Examine the built-in command policies:

• Browse to System > User Administration > Command Policies.
3. Select superuser and click Edit. (The command will not be changed).
Note the regular expression listed in the Command Spec (command specification) field. This regex
allows accounts with superuser rights to run all commands. This is equivalent to nsroot account
permissions.
Click Close to exit without applying changes.
127
4. Select read-only and click Edit.
Note the regular expression listed in the Command field. This regex grants permissions to run:
• All commands starting with man. (All man page commands).
• All commands starting with stat. (All statistics commands for any object).
• Most show commands are allowed. The syntax explicitly restricts certain show commands
such as commands starting with: show system, show configstatus, show ns ns.conf).
• Any command not explicitly allowed in the regex is automatically denied.
Click Close to exit without applying changes.

5. Create a custom command policy named show_only. This policy will grant access to all commands
starting with "show".
• Click Add to create a new command policy.
• Enter show_only in the Policy Name field.
• Verify Allow in the Action field.
• Enter the following regex in the Command Spec field (case matters): (^show\s+.*)
• Click Create.
6. Bind the command policy show_only to the testuser account:
• Select testuser and click Edit.
Unbind the existing Command Policy:
• Click 1 System Command Policy under Bindings.
• Select read-only and click Unbind and Yes to confirm.
Bind new Command Policy:
• Click on Click to select and select show_only in the Command Policies dialog box.
• Click Bind.
• Click Close.
• Click Done.
8. Click Logout to log out of the Citrix ADC Configuration Utility as nsroot.
9. Test the new administrator account: testuser.
Connect to the Citrix ADC HA Pair configuration utility using the NSMGMT SNIP at
http://192.168.10.103.

• User Name: testuser
• Password: Password1
128
10. Test show-only permissions:

• Select a feature to enable and click OK. The user has read-only permissions, so the
command fails.
• Close the Error message.
• Click Close.
11. Click Logout to log off from the current session as testuser.
Key Takeaways:
• System users and groups are used to authenticate and access management points on
the Citrix ADC such as the NSIP and management-enabled SNIPs.
• Permissions can be managed at the system user account level. Or, system users can be
placed into system groups and permissions managed at the group level.
• Nsroot is a local account with automatic superuser rights. It cannot be deleted or
disabled; therefore, a strong password should be configured after the initial Citrix ADC
setup.
• Command Policies determine the level of permissions (role-based access control)
available to an account or group in the GUI and the CLI. Any command not explicitly
allowed by a command policy is automatically denied due to the default authorization
on the Citrix ADC.
• Regular Expressions are powerful, but be careful when defining custom command
policies as it is easy to grant too many or too few permissions and create a security
issue. Review all custom policies thoroughly.
• The Citrix ADC can be administered by creating local accounts. Most environments will
integrate Citrix ADC administration with external authentication.
Exercise 7-2: Configuring External Authentication with LDAP
(GUI)
Introduction:
In this exercise, you will learn to configure and integrate external authentication using LDAP
with Active Directory with the Citrix ADC. The exercise will demonstrate configuring external
authentication policies and configuring system groups and managing delegated administrator
rights using group extraction. You will use the Citrix ADC Configuration Utility GUI to perform
this exercise.
• Integrate External Authentication with Citrix ADC System Access using LDAP policies.
129
• Manage permissions using Group Extraction.

Step Action
http://192.168.10.103.
2. Create system groups that correspond to the Groups in Active Directory. Group names are case
sensitive on the Citrix ADC.
• Browse to System > User Administration > Groups.
• Click Add.
3. Create a System Group Training_NSAdmins with superuser permissions.
• Enter Training_NSAdmins in the Group Name field.
• Click Bind under Command Policies.
• Select superuser to make it active and click Insert.
• Click Create.
4. Create a System Group Training_NSOperators with operator permissions.
• Click Add to add a new system group.
• Enter Training_NSOperators in the Group Name field.
• Click Bind under Command Policies.
• Select operator to make it active and click Insert.
Click Create.
5. Create an Authentication Action for external authentication using LDAP:

• Browse to System > Authentication > Basic Policies.
• Click LDAP.
• Click Servers tab.
• Click Add.
130
6. Configure the authentication LDAP action with the following settings:

• Name: auth_ldap_srv
• Select Server IP
• IP Address: 172.21.10.103 (This is the VIP for lb_vsrv_ldap).
• Port: 389
• Server Type: AD
Connection Settings:
• Base DN: dc=workspacelab,dc=com.
• Administrator Bind DN: trainaduser@workspacelab.com
• Administrator Password and Confirm Administrator Password: Password1
• Click Test Network connectivity
Other Settings:
• Server Logon Name Attribute: Select sAMAccountName from the drop-down.
• Group Attribute: Select memberOf from the drop-down.
• Sub Attribute Name: Select cn from the drop-down
Click Create.
7. Create an Authentication Policy for LDAP authentication:
• Click the Policies tab.
• Click Add.
• Enter auth_ldap_policy in the Name field.
• Select auth_ldap_srv from the Server drop-down list.
• Enter ns_true in the Expression box. (Authentication policies use classic policy
expression syntax).
Click Create.
Click OK on the warning.
8. Bind the policy to the system global object for system authentication:
• Click Global Bindings.
• Click Click to Select under Policy Binding.
• Select auth_ldap_policy and click Select.
• Click Bind.
• Click Done.
The LDAP policy is now bound to the System Global object. Access to management IP addresses
on the Citrix ADC (NSIP and management enabled SNIPs) will attempt to authenticate using the
bound LDAP policy. However, system access will still fall through to local accounts if the
authentication policy fails. (The superuser and other local accounts are still active).
10. Click Logout to log off from the Citrix ADC Configuration Utility as nsroot.
131
11. Test the new administrator account - trainNSAdmin:

Connect to the Citrix ADC HA Pair Configuration Utility using the NSMGMT SNIP at
http://192.168.10.103.
• User Name: trainNSAdmin
Select OK to close the error window if any.
12. Test superuser permissions assigned from LDAP group extraction:

• Click Configure Advanced Features.
• Enable Global Server Load Balancing
• Click OK. Command is accepted.
• Click Save to save the Citrix ADC configuration. Command is also accepted.
13. Click Logout to log off from the current session as trainNSAdmin.
Key Takeaways:
• Authentication policies bound to the system global bind point; control authentication is
bound to management points.
• Group extraction is supported with LDAP and Radius external authentication
• With group extraction, only the groups need to be created on the Citrix ADC
(corresponding to the group names in the remote directory service). Command policies
can be bound to the AAA groups. Individual system users do not need to be created on
the Citrix ADC.
• Citrix ADC system authentication supports single factor or single-factor cascade only. If
multiple policies are bound, they will be attempted in priority order. For system access,
if no authentication policies match, the system will automatically fall back to local
authentication. This results in the nsroot account and any other local system account
always being valid for management access.
Exercise 7-3: Admin Partitions (GUI)
Introduction:
In this exercise, you will learn to create and administer Admin Partitions on the Citrix ADC. You
Admin Partitions allow a Citrix ADC to be subdivided into separate configuration and
administrative boundaries. Each partition can be assigned its own networking via VLANs, and
each partition maintains a separate running and saved the configuration.
132
The Citrix ADC default partition will contain all configuration settings made in the course up until
this exercise. During this exercise, two new partitions will be created which will contain
independent settings from the default partition: features, modes, services, virtual servers,
policies, and more.
The nsroot account will have full administrative rights on the default partition and all Admin
Partitions created. The nsroot account can switch between partitions in both the GUI and the
CLI.
Delegated administrators can be designated with partition-only rights on one or more

partitions. These delegated partition administrators, upon connecting to the Citrix ADC GUI or
CLI, can only administer and see the partition or partitions on which they have permissions.
In this exercise, you will configure Admin Partitions with the following settings:
• Partition1 will be managed by padmin1 (local account).

• Each administrator will be a partition administrator with rights to only their single
assigned partition.
This exercise demonstrates the basic setup and configuration of Admin Partitions and partition
administrators. The partitions are used to demonstrate basic configuration management within
the partitions. The Admin Partitions will not be set up for full networking or used beyond this
exercise.
• Create Partition Admins.

• Create Partitions.
• Configure Resources with Partitions.
Create Partition Admins
Step Action
http://192.168.10.103.
2. Create a new local system user - padmin1:
• Click Add.
133
3. Create a local account called "padmin1":

• Enter padmin1 in the User Name field.
• Click Continue.
4. Assign read-only permissions to the padmin1 account:
• Select partition-admin and click Select in the Command Policies dialog box.
• Click Bind.
• Click Save.
• Click Done.
5. Create a new local system user - padmin2:
• Click Add.
6. Create a local account called "padmin2":
• Enter padmin2 in the User Name field.
• Click Continue.
7. Assign read-only permissions to the padmin2 account:
• Select partition-admin and click Select in the Command Policies dialog box.
• Click Bind.
• Click Save.
• Click Done.
Create Partitions
Step Action
134
1. Create an Admin Partition - Partition1:

• Browse to System > Partition Administration > Partitions.
• Click Configure.
Configure Partition:
• Enter Partition1 in the Name field.
• Click Continue.
Network Isolation:
• Click Continue under Network Isolation.
• At this time, do not bind a VLAN.
Users:
• Click No User under Users to add a new partition administrator.
• Click Click to Select under Select User.
• Select padmin1 and click Select.
• Click Bind to bind the user to the Admin Partition.
• Click Continue.
Click Done to finish creating Partition1.

2. Create an Admin Partition - Partition2:
• Browse to System > Partition Administration > Partitions.
• Click Add.
Configure partition:
• Enter Partition2 in the Name field.
• Click Continue.
Network Isolation:
• Click Continue under Network Isolation.
• At this time do not bind a VLAN.
Users:
• Click No User under Users to add a new partition administrator.
• Click Click to Select under Select User.
• Select padmin2 and click Select.
• Click Bind to bind the user to the admin partition.
• Click Continue.
Click Done to complete creating Partition2.
Configure Resources within Partitions

Step Action
1. Switch to Partition 1:
• Select Partition1 from the Partition drop-down list box at the top of the Citrix ADC GUI
(next to the HA Status and Logout button).
• Click Yes to confirm switching to Partition1.
135
2. View Partition Features:

• Verify that no features are currently enabled.
• Click OK.
3. View Traffic Management entities:
• Verify that no services are listed in Partition1.
4. Create a service for the NYC-WEB-RED server in Partition1:
• Click Add.
• Enter svc_red in the Service Name field.
• Click OK.
• Click Done.
Note: The service svc_red will be DOWN since networking is not yet enabled with the Admin
Partition; no VLAN is bound. Due to limitations in the lab configuration, we will not demonstrate a
fully functional Admin Partition. However, Partition1 has features, networking, services, and other
configuration settings that are separate from the default partition. A duplicate service, svc_red, can
be created without causing a conflict with the default partition or other partitions.
6. Switch to the default partition:
• Select default from the partition drop-down list box at the top of the Citrix ADC GUI.
Note that the nsroot account has full access to the default partition and all other Admin Partitions.
7. Click Logout to log off from the Citrix ADC as nsroot.
8. Connect to the Citrix ADC HA Pair Configuration Utility using the NSMGMT SNIP at
http://192.168.10.103.
Log on to the utility using the following credentials.
• User Name: padmin2
9. Verify that you are connected to the configuration for Partition2 only.
View the Partition drop-down list box at the top of the Citrix ADC GUI. Verify that only Partition2 is
listed, and padmin2 is not able to switch to the default partition or any other partition.
10. Browse to System > Partition Administration > Partitions.
Verify that the only partition available to switch to is Partition2.

11. Create a service for the NYC-WEB-BLU server in Partition2:
136
• Click Add.
• Enter svc_blue in the Service Name field.
• Enter 192.168.30.52 in the IP Address field. 
• Click OK.
• Click Done.
Note: This only saves the configuration for Partition2 and not any other partition.
13. Click Logout to log off from the Citrix ADC as padmin2.
14. Connect to the Citrix ADC HA Pair Configuration Utility using the ADCMGMT SNIP at
http://192.168.10.103.
Resume administration of the default partition for the rest of the course.
Key Takeaways:
• Admin Partitions allow separate Citrix ADC configuration boundaries to be managed and
maintained on a single appliance (or HA Pair) are independent of the default and other
partitions.
• Administrators can be granted access to one or more Admin Partitions, with partition-
level delegated administration.
• The nsroot account has access to the default partition and all Admin Partitions.
• Some settings, such as High Availability, can only be managed at the default partition
level.
• Partition configurations are separate from the default configuration. The GUI and CLI
allow switching between partitions.
• When looking for the saved configuration file, remember that the partition names are
case sensitive. The saved configuration files are found here: o Default partition saved
configuration file: /nsconfig/ns.conf
o Admin Partitions saved configuration files: /nsconfig/partitions/<partition
name>/ns.conf
Exercise 7-1: Configuring Local Authentication and Delegated

Administration (CLI)
Introduction:
137
In this exercise, you will learn to create local system accounts, assign passwords, and change
delegated administration permissions by using built-in and custom command policies. You will
use the command-line interface to perform this exercise.
All administrative access to the Citrix ADC is handled by system users or system groups. Local
accounts can be created on the Citrix ADC, where the Citrix ADC is the local credential authority.
User accounts, passwords, and group members belong to local objects on the Citrix ADC.
All administrative permissions on the Citrix ADC are controlled by command policies. Command
policies define regular expressions (using PCRE regex syntax) that identify commands that are
allowed or denied to run. Any command not explicitly allowed is automatically denied by the
default permissions. The built-in command policies provide basic administrative controls for
regular administrators and partition administrators. But custom command policies can be
configured and bound to system users or system groups. The permissions granted by the
command policies determine which information is visible within the GUI and which actions can
be performed in the GUI or CLI.
Local authentication is simple to set up. The accounts will be synchronized amongst an HA pair.
However, most environments will integrate with external authentication for the more robust
account, credential, and group management.
• Create a Local System Account.

• Create a Custom Command Policy.
Creating a Local System Account:
Step Action
2. Create a new local system account called "testuser" with read-only permissions:
add system user testuser Password1
Note: Do not create local accounts named "test" or some other variation on the Citrix ADC. Require
that any account used to authenticate to the Citrix ADC meets minimum complexity requirements
for passwords. If configuring accounts for test purposes, do not forget to disable and remove the
accounts when done. Do not grant delegated administrator accounts higher permissions than
necessary. These leftover accounts, with easily guessed user names or passwords, could
inadvertently provide unpermitted access to an appliance.
3. View available Command Policies (for Citrix ADC RBAC/Delegated Administration):
show system cmdPolicy
138
4. Bind the read-only command policy to the testuser system account:

bind system user testuser read-only 1
5. Test the new system account:
Use PuTTY to make a new connection to 192.168.10.103. Log on as testuser.
6. From the Testuser SSH Session:
Attempt to run any of the following commands allowed by read-only permissions:
show ns feature
show lb vserver
stat service svc_red
man add route
Verify that the above commands are executed successfully and return the expected results.
7. From the Testuser SSH Session, attempt to run any of the following commands denied by the read-
only permissions:
enable ns feature lb
show ns runningConfig
save ns config
shell
All of the above commands are denied.
8. Log off or exit the session as testuser. Return to the first Putty session for the nsroot user.
Creating a Custom Command Policy

Step Action
1. Display default system command policies:
show system cmdPolicy
2. Display permissions (cmdspec) for the superuser policy:
show system cmdPolicy superuser
3. Display permissions (cmdspec) for the read-only policy:
show system cmdPolicy read-only
4. Create a new custom command policy that only allows show commands:
add system cmdPolicy show_only ALLOW "(^show\s+.*)"
5. Unbind the existing read-only policy from the testuser account:
unbind system user testuser read-only
6. Bind the custom policy to the testuser account:
bind system user testuser show_only 10
save ns config
139
9. Verify that testuser can view configuration details. All of the following will succeed:
show ns feature
show ns ip
show lb vserver
show ns runningconfig
Verify that testuser cannot change configuration settings. All of the following will fail:
save ns config
shell
enable ns feature ssl
rm service svc_red
10. Close the session for testuser.
Key Takeaways:
• System users and groups are used to authenticate and access management points on
the Citrix ADC such as the NSIP and management enabled SNIPs.
• Permissions can be managed per system user account or system users can be placed
into system groups and permissions managed at the group level.
• Nsroot is a local account with automatic superuser rights. It cannot be deleted or
disabled; therefore, a strong password should be configured after the initial Citrix ADC
setup.
• Command Policies determine the level of permissions (role-based access control)
available to an account or group in the GUI and the CLI. Any command that is not
explicitly allowed by a command policy is automatically denied because of the default
authorization on the Citrix ADC.
• Regular expressions are powerful, but be careful when defining custom command
policies as it is easy to grant too much or too little permissions and create a security
issue. Review all custom policies thoroughly.
• The Citrix ADC can be administered by creating local accounts, most environments will
integrate the Citrix ADC administration with external authentication.
Exercise 7-2: Configuring External Authentication with LDAP
(CLI)
Introduction:
140
In this exercise, you will learn to configure and integrate external authentication using LDAP
with Active Directory with the Citrix ADC. The exercise will demonstrate configuring external
authentication policies and configuring system groups and managing delegated administrator
rights using group extraction. You will use the command-line interface to perform this exercise.
• Integrate External Authentication with Citrix ADC System Access using LDAP policies.
Manage permissions using Group Extraction.
Step Action
2. Create system groups that correspond to the group names in Active Directory. Group names on the
Citrix ADC must exactly match (including case) the group name in Active Directory.
add system group Training_NSAdmins
add system group Training_NSOperators
add system group Contractor
3. Configure Training_NSAdmins with super user permissions:

bind system group Training_NSAdmins -policyName superuser 1
4. Configure Training_NSOperators with show_only permissions:
bind system group Training_NSOperators -policyName show_only 10
5. Create an authentication action for external authentication using LDAP against the Domain
Controllers:
add authentication ldapaction auth_ldap_srv -serverIP 172.21.10.103 -ldapBase

"DC=workspacelab,DC=com" -ldapBindDN trainADuser@workspacelab.com
ldapBindDNPassword Password1 -ldaploginName sAMAccountName -groupAttrName
memberOf -subAttributeName CN
The authentication policy uses the lb_vsrv_ldap virtual server as the destination for the
authentication traffic.
6. Create an authentication policy for the LDAP server with expression ns_true: add
authentication ldapPolicy auth_ldap_policy ns_true auth_ldap_srv
7. Bind the policy to the global system bind point. This enables external authentication for the
management access points on the Citrix ADC - NSIP and Management-enabled SNIPs:
bind system global auth_ldap_policy -priority 100
141
8. Test system authentication with a domain account in a new session:

Connect to the Citrix ADC HA Pair using the NSMGMT SNIP (192.168.10.103) using SSH (PuTTY).
9. From the trainNSAdmin SSH Session:
Attempt to run any of the following commands. All are allowed with super-user permissions:
show ns feature
save ns config
shell
Verify that the above commands are executed successfully and return the expected results.
10. Log off or exit the session as trainNSAdmin. Return to the first PuTTY session for the nsroot user.

save ns config
Key Takeaways:
• Authentication policies bound to the system global bind point and control
authentication is bound to management points.
• Group extraction is supported by LDAP and Radius external authentication.
• With group extraction, only the groups need to be created on the Citrix ADC
(corresponding to the group names in the remote directory service). Command policies
can be bound to the AAA groups. Individual system users do not need to be created on
the Citrix ADC.
• Citrix ADC system authentication supports single-factor or single-factor cascade only. If
multiple policies are bound, they will be attempted in priority order. For system access,
if no authentication policies match, the system will automatically fall back to local
authentication. This results in the nsroot account and any other local system account
always being valid for management access.
Exercise 7-3: Admin Partitions (CLI)
Introduction:
In this exercise, you will learn to create and administer Admin Partitions on the Citrix ADC. You
Admin Partitions allow a Citrix ADC to be subdivided into separate configuration and
administrative boundaries. Each partition can be assigned its own networking using VLANs and
each partition maintains a separate running and saved the configuration.
142
The Citrix ADC default partition will contain all configuration settings made in the course to this
point. During this exercise, two new partitions will be created which will contain independent
settings from the default partition: features, modes, services, virtual servers, policies, and
more.
The nsroot account will have full administrative rights on the default partition and all Admin
Partitions created. The nsroot account can switch between partitions in both the GUI and the
CLI.
Delegated admins can be designated with partition-only rights on one or more partitions. These
delegated partition admins, upon connecting to the Citrix ADC GUI or CLI, can only administer
and see the partition or partitions on which they have permission.
In this exercise, you will configure Admin Partitions with the following settings:

• Each administrator will be a partition admin with rights to only their single assigned
partition.
This exercise demonstrates the basic setup and configuration of Admin Partitions and partition
administrators. The partitions are used to demonstrate basic configuration management within
the partitions. The Admin Partitions will not be set up for full networking or used beyond this
exercise.
• Create Partition Admins.

• Create Partitions.
• Configure Resources with Partitions.
Create Partitions and Partition Admins
Step Action
2. Create Admin Partition Partition1:
add ns partition Partition1
3. Create Admin Partition partition2:
add ns partition Partition2
143
4. Create a local account for partition admin: padmin1 with partition-admin rights:
add system user padmin1 Password1
bind system user padmin1 partition-admin 10
bind system user padmin1 -partitionName Partition1
5. Create a local account for partition admin named padmin2 with partition-admin rights:
add system user padmin2 Password1
bind system user padmin2 partition-admin 10
bind system user padmin2 -partitionName Partition2
6. View the partitions:

show ns partition
show ns partition Partition1
show ns partition Partition2
7. View the system users:

show system user padmin1
save ns config
Configure Resources within Partitions

Step Action
1. Switch to partition 1 while still connected as nsroot.
switch ns partition Partition1
2. nsroot@Partition1: View the current configuration for Partition 1
View features:
show ns feature
View services:
show service
Notice that there are no existing settings in partition1. Features and services are separate from the
default partition. The running-config also is separate.
3. Create a service for NYC-WEB-RED in partition 1:
add service svc_red 192.168.30.51 http 80
Show service:
show service svc_red
The service svc_red will appear DOWN since networking is not fully configured for this partition.
4. Save the Citrix ADC configuration within partition 1:
save ns config
144
5. Switch to the default partition:

switch ns partition default
6. View the saved configuration on the file system for the default partition:
shell
cd /nsconfig
ls
The saved configuration and certificates for the default partition are located here: /nsconfig/ns.conf
/nsconfig/ssl/
7. View the saved configuration on the file system for Partition1:

cd /nsconfig/partitions/ ls
cd Partition1 ls
more ns.conf
The saved configuration and certificates for partition1 are located here:
/nsconfig/partitions/Partition1/ns.conf
/nsconfig/partitions/ssl/
The saved configuration file for Partition1 contains svc_red.

8. Exit shell to return to the Citrix ADC CLI:
exit
9. Open a second SSH session using PuTTY to ADC-MGMT SNIP (192.168.10.103) using SSH (PuTTY).
• User Name: padmin2
This will connect padmin2 to Partition2 since this account only has rights on Partition2.
10. padmin2@Partition2 - View partition configuration:
View features:
show ns feature
View Services:
show service
Notice that there are no existing settings in Partition2. Features and services are separate from the
default partition. The running-config also is separate.
11. View partitions:
show ns partition
Only Partition2 is available to padmin2. This account has no access to the default partition of
Partition1.
145
12. Configure a service for the NYC-WEB-BLU server in Partition2:

add service svc_blue 192.168.30.52 http 80
13. Save the Citrix ADC configuration (for this partition):
save ns config
14. Exit and log off from the ssh session for padmin2:
exit
15. Return to the regular SSH session using the ADC-MGMT SNIP for the nsroot user.
16. Confirm that the Citrix ADC configuration is saved:
save ns config
Note: If the configuration is already saved, you will receive a warning that the running configuration
has not changed. This is informational and to be expected when the configuration is already saved.
Key Takeaways:
• Admin Partitions allow separate Citrix ADC configuration boundaries to be managed and
maintained on a single appliance (or HA Pair). Entities in each Admin Partition are
independent of the default and other partitions.
• Administrators can be granted access to one or more Admin Partitions, with partition-
level delegated administration.
• The nsroot account has access to the default partition and all Admin Partitions.
• Some settings, such as High Availability, can only be managed at the default partition
level.
• Partition configurations are separate from the default configuration. The GUI and CLI
allow switching between partitions.
• When looking for the saved configuration file, remember that partition names are case
sensitive:
o Default partition saved configuration file: /nsconfig/ns.conf
o Admin Partitions saved configuration files: /nsconfig/partitions/<partition
name>/ns.conf
146
Module 8: Monitoring and Troubleshooting

Overview:
In Company ABC, configuration changes made to the Citrix ADC must be audited and SNMP alert
notification should be enabled in order to respond proactively to the environment. Your job as
the administrator is to familiarize yourself with the logs on the Citrix ADC.
This module reviews logs, log management, alerting, and troubleshooting on the Citrix ADC.
At the end of this module, you will be asked to participate in a troubleshooting lab by loading a
new configuration on to the Citrix ADC and resolving its issues.
• View Citrix ADC syslog and nslog files.

• Generate and view a network trace.
• Configure SNMP alerting.
• Apply configuration experience to troubleshoot a Citrix ADC configuration.
This module contains the following exercises using the Citrix ADC Configuration Utility (GUI) and
the Citrix ADC CLI:
• Exercise: Viewing Citrix ADC Logs and Network Traces

• Exercise: Configuring External Syslog and Audit Policies
• Exercise: Configuring SNMP
• Exercise: Troubleshooting
module.
• NYC-ADC-001
• NYC-ADC-002
• NYC-WEB-BLU
• NYC-WEB-RED
• NYC-WEB-GRN
• NYC-ADS-001
• NYC-ADS-002
147
Before you Begin:

Estimated time to complete this lab: 35-70 minutes.
Exercise 8-1: Viewing Citrix ADC Logs and Network Traces

(GUI)
Introduction:
In this exercise, you will learn to gather log and troubleshooting information. You will use the
Citrix ADC Configuration Utility GUI to perform this exercise.
• View the syslog fie (/var/log/ns.log) and its events.

• View the nslog file (/var/nslog/newnslog) and view log file duration, events, and console
messages.
• Generate a network trace using the nstrace console in the Citrix ADC GUI.
View Syslog (/var/log/ns.log)

Step Action
http://192.168.10.103.
2. View current recent syslog events:

• Browse to System > Auditing.
• Click Recent audit messages.
• Select ALL for log levels.
• Enter 20 for the number of audit messages to be shown.
• Click Run.
• Select the checkbox for Word Wrap to view the messages in the proper format.
This will display the last 20 messages in the current syslog file.
The output will mostly consist of GUI or CLI CMD_EXECUTED events, which reflects changes made
to the configuration and navigation of the GUI. You may see EVENT DEVICEUP or DEVICEDOWN
messages as well.
3. Click Close and Close again to return to the Auditing node.
148
4. View full current syslog file:

• Click Syslog messages.
This will display the in-browser syslog viewer based on the current syslog file: /var/log/ns.log.
149
5. Filter syslog on events or entities.

Filter on events:
• Expand Module and select an Event such as AAA, CLI, GUI from the Module drop-down list
box and click Apply.
• Click Clear next to Filter By to remove the filter.
Filter based on Severity:
• Expand Severity under Filter By.
• Select Emergency, Alert, Critical, Err, Warn, and Debug.
• Leave the Info and Notice checkboxes cleared.
• Click Apply.
This will display events other than configuration changes (CMD_EXECUTED), if present. You may
observe entities going UP or DOWN or other issues that occurred during configurations.
• Remove the applied filters to return to the full log.
Use the Filter By section to filter events being displayed by Module, Event Type, or Severity. If there
are not enough events in the current log, try viewing a past log file, using the procedure in the next
step.
6. View past syslog files:
• View the past log files by expanding the drop-down list box under File in the rightpane.
• Choose any of the past syslog files from the last 24 hours.
7. Click Back icon to return to the Auditing node.
View NSLOG (/var/log/newnslog)

Step Action
150
1. View Nslog in GUI:

The links available under Manage Logs and Troubleshooting Data are shortcuts to various nslog
events. You can use these instead of running explicit commands. The GUI makes it easy to view
events, statistics, and metrics, from the current log file and past log files.
Under Manage Logs, the GUI contains shortcuts to most of the commonly used nsconmsg
commands. These commands can be executed against the current nslog file or an archive:  View
Log File Duration
• View Events
• View Console Messages
• View Events from Specific Time
• Trim Log Files
Under Troubleshooting Data, additional nslog commands provide access to:

• Memory usage
• View dmesg.boot
The next lab steps will demonstrate a few of these tasks.

2. View log file duration for current log:
• Click View log file duration under Manage Logs.
• Select the current log file: /var/nslog/newnslog (default)
• Click Run.
Note that the command to get the log file duration is displayed:
nsconmsg -K /var/nslog/newnslog -d setime
Identify the time for this log.
Click Close and return to the Logfile Duration dialog box.
151
3. View the log file duration for a past log:

• Click Choose File under the Log File field.
• Select a previous file, newnslog.##.tar.gz, in the /var/nslog/ directory from earlier in this
week and click Open.
• Click Run.
Note the start and end time of this log. The file was extracted and is no longer zipped on the Citrix
ADC.
4. Click Close. Return to the Logfile Duration dialog box. Click Close
again to return to the Diagnostics node.
5. Click View events from the current Nslog:

• Click View events under Manage Logs.
• Use the current Logfile (or browser for a previous one).
• Click Run.
Review the events displayed.
Click Close and close to return to the Diagnostics dialog box.

6. Click View console messages from the current Nslog:
• Click View console messages under Manage Logs.
• Use the current Logfile (or browser for a previous one).
• Click Run.
Review the messages displayed.
Click Close and close to return to the Diagnostics dialog.

7. Download nslog files from the GUI:
• Click Delete/Download log files under Maintenance.
Any of the log files in the /var/nslog/ directory can be downloaded.
Click Close.
Generate a Network Trace with nstrace

Step Action
http://192.168.10.103.
152
2. Start a network trace using the nstrace utility:

• Click Start new trace under Technical Support Tools.
3. Start a trace with the following criteria:
• Packet Size: Enable Capture trace in .pcap format.
• Enable Trace filtered connection's peer traffic (under the expression box and the Merge
drop-down list).
• Keep defaults for other values.
Configure the filter expression to trace traffic coming from the HOST desktop
(192.168.10.254) only. This is useful in a production environment if you need to isolate the trace to
only one specific client:
CONNECTION.IP.EQ(172.21.10.254)&&CONNECTION.IP.EQ(172.21.10.101)
Click Start and then click OK.
Note: In the version below 11.1 do not click OK until you are ready to stop the trace. Capture is in
progress. This command will generate a trace for only traffic between the HOST desktop and the
RBG VIP; this will exclude all the management communication since we are running GUI
connections from the HOST desktop to the NSIP/SNIP addresses, as well. The "trace filtered
connections peer traffic" option ensures that all backend traffic associated with the request and
response flow will also be captured.
Note about syntax: In the GUI, the Boolean operator "&&" must be adjacent to the two
expressions, without a space between the expressions and the operator. This is particular to the
nstrace expression dialog box in the GUI.
4. Generate test traffic:
• Open a web browser and find http://172.21.10.101/home.php.
• Refresh the page a few times.
• Open a web browser and find http://172.21.10.105/
5. Return to the Citrix ADC GUI and stop the trace:
• Click Stop and Download to stop the currently running trace.
• Click Close to exit the Delete/Download Trace Files dialog box.
The download directories vary slightly depending on which browser you use. To standardize the
steps, WinSCP will be used to download the trace file.
153
6. Use WinSCP to download the trace:

• Open WinSCP and connect to ADC-MGMT SNIP (192.168.10.103).
• If you receive a warning from WinSCP to add the host key to a cache, Click Yes to
continue.
• In the right-pane, browse to /var/nstrace/.
• The trace is generated in a folder named after the date/time.
• In the left pane, Browse to C:\resources\.
• Copy the appropriate nstrace (usually: nstrace1.pcap) in the right pane to the
C:\resources\ directory in the left pane.
• Close WinSCP.
7. On the Host desktop, browse to C:\resources\. Double-click the .pcap file to open in Wireshark.
8. In the Trace, look for the following:
• Find the first reference to a request for Get /home.php.
• (You can use filter http.request.uri=="/home.php" and
http.request.method=="GET")Identify the Source IP address as the HOST desktop
(172.21.10.254).
o Identify the Destination IP address as the VIP (172.21.10.101)
• Then use the trace to identify which SNIP the Citrix ADC used to send the traffic to the
backend servers and which server (Red, Blue, or Green) responded with the object.
Key Takeaways:
• Nslog and Syslog details are available in both the GUI and the CLI.
• Syslog is the audit log for the Citrix ADC and contains all configuration changes made to
the appliance. Other specific events are logged by features and subsystems on the Citrix
ADC, which means that it can be useful for troubleshooting.
• Nslog contains all the statistics, metrics, and debug counters on the Citrix ADC in
addition to events and console messages.
• Statistics and metric information can be retrieved from nslog or by using the stat
command in the CLI, the statistics command in the GUI, or the Dashboard view in the
GUI.
• Nslog also contains useful troubleshooting information such as events, console
messages, log file duration, dmesg output, and memory usage. All of these counters can
be retrieved manually through the CLI or by using the built-in shortcuts in the GUI. The
GUI is the preferred method for retrieving this information for daily operations.
154
• Nstrace is the built-in Citrix ADC trace utility. It can be run from the CLI or the GUI and
can easily be used to capture a network trace with required parameters for a subset of
the traffic of interest using the expression and link options.
Exercise 8-2: Configuring External Syslog and Audit Policies

(GUI)
Introduction:
In this exercise, you will learn to configure audit policies to enable external logging of the local
syslog file to an external syslog server. You will use the Citrix ADC Configuration Utility GUI to
The audit policies will be configured so that the Citrix ADC continues to log all events to the
local syslog file in /var/log/ns.log. Logging to the external syslog server is done in addition to
the local logging, and not in place of.
For this exercise, the audit policy will be bound to the global system object so that all syslog
events are logged to the external server. Audit policies could be bound to specific virtual
servers, AAA groups, or AAA users to capture syslog data related to these entities only.
Kiwi Syslog Daemon running on the HOST desktop will act as the external Syslog server.
• Configure Kiwi Syslog Daemon to Receive Syslog Messages.

• Configure External Audit Policies for Syslog.
• View Audit Message in the Remote Server (Kiwi).
Configure Kiwi Syslog Daemon to Receive Syslog Messages
Step Action
1. Start Kiwi Syslog Daemon:
• Double-click the Kiwi Syslog Daemon shortcut on the desktop.
Or
• Run C:\Program Files\Syslogd\Syslogd.exe.
155
2. Configure Kiwi to receive Syslog messages (UDP 514):

• Click File and select Setup.
• Expand Inputs and select UDP.
• Verify that Listen for UDP Syslog is selected and that the UDP Port is set to 514.
• Leave all other settings at their default values.
• Click OK.
3. Keep Kiwi running for this exercise.
Configure External Audit Policies for Syslog

Step Action
http://192.168.10.103.
2. Create a new syslog server (policy action) that will log to the HOST desktop (192.168.10.254).
• Browse to System > Auditing > Syslog
• Click Servers tab
• Click Add
• Enter ext_kiwi in the Name field
• Enter 192.168.10.254 in the IP Address field. This is the IP address of the external Syslog
server to log
• Verify that the Port is 514.
• Select Custom and then select the following under Log Levels: EMERGENCY, ALERT,
CRITICAL, ERROR, WARNING, NOTICE, INFORMATIONAL. (Exclude DEBUG).
• Select Local0 as Log Facility.
• Click Create.
3. Create the syslog policy:

• Click Policies tab.
• Click Add.
• Enter ext_kiwi_policy in the Name field.
• Select ext_kiwi from the Server drop-down list box.
• Click Create.
• Click OK on the Warning.
156
4. Bind the policy to the System Global bind point.

• Browse to System > Auditing > Syslog.
• Click Select Action drop-down menu > Classic Policy Global Bindings.
• Select ext_kiwi_policy and click Select.
• Click Bind.
• Click Done.
Note: The default audit parameters (System > Auditing > Change Auditing Syslog Settings and the
Change Auditing Nslog Settings) enable local logging to syslog at /var/log/ns.log and nslog at
/var/nslog/newnslog.
Binding audit policies to the System Global bind point enables logging to an external audit server of
all the global events that are captured in the local log files. Audit policies employ a policy cascade
(similar to authentication policies), and the bound policies are processed in priority order followed by
the global parameters logging setting. Therefore, audit policies can be used to set additional logging
locations without eliminating local logging.
Audit policies can also bind to virtual servers (lb, cs, vpn, and others), AAA groups, and AAA Users.
Policies bound to entities other than System Global will only log events (configuration changes and
other audited events) for these entities only.
View Audit Messages on the Remote Server (in Kiwi)

Step Action
1. Switch to Kiwi Syslog.
2. View syslog messages from the Citrix ADC in Kiwi.
Return to the Citrix ADC and generated audited events:

• Save the Citrix ADC configuration and confirm.
• Browse to different nodes of the GUI; all show commands are audited.
3. Unbind the policy from the System Global to disable external logging to this destination.
• Browse to System > Auditing > Syslog.
• Click Select Action > Classic Policy Global Bindings.
• Select ext_kiwi_policy and click Unbind.
157
• Click Close.
Note: If the Unbind process does not work from the GUI use the PuTTY icon on the HOST
desktop to connect to the Citrix ADC.
Log in with nsroot/nsroot and enter the command unbind system global ext_kiwi_policy.
Key Takeaways:
• Audit policies enable sending syslog and nslog data to an external server. Usually, this is
done to maintain logs for longer retention periods than what the Citrix ADC allows or to
protect audit logs from loss in the event of appliance failure. The Citrix ADC syslog is in
standard syslog format and can be sent to any syslog server.
• Audit policies follow a similar policy cascade as authentication policies. If multiple audit
policies are bound, then logging can occur to multiple logging destinations.
• By binding audit policies to the global system object, the remote log will contain all the
same information as the local syslog on the Citrix ADC. While audit policies can also be
bound to the virtual server, AAA groups, and AAA Users, binding policies to the global
system object is the only way to capture all events on the Citrix ADC and all audited
configuration changes made by system users.
Exercise 8-3: Configuring SNMP (GUI)
Introduction:
In this exercise, you will learn to configure SNMP integration on the Citrix ADC to allow both
SNMP polling and alerting. This exercise will configure SNMP community strings, SNMP
managers, SNMP trap destinations, and SNMP Alerts. Kiwi Syslog Daemon running on the HOST
desktop will be the SNMP trap destination for this scenario. You will use the Citrix ADC
Configuration Utility GUI to perform this exercise.
• Configure Kiwi Syslog Daemon to Receive SNMP Alerts.

• Configure SNMP Settings.
• View SNMP Alerts in the Remote Server (Kiwi).
Configure Kiwi Syslog Daemon to Receive SNMP Alerts
158
Step Action
1. Disable syslog in Kiwi:
• Clear the Listen for UDP Syslog messages check box.
2. Enable SNMP Traps in Kiwi:
• Expand Inputs and select SNMP.
• Select Listen for SNMP Traps and verify that 162 appears in the UDP Port field.
• Click OK.
3. Clear Display in Kiwi:
• Click View > Clear Display.
Configure SNMP Settings

Step Action
http://192.168.10.103.

2. Configure SNMP community string:
• Browse to System > SNMP > Community.
• Click Add.
• Enter ctxtrainsnmp in the Community String field.
• Select All in the Permission drop-down list box.
• Click Create.
3. Configure an SNMP manager. Use the HOST desktop (192.168.10.254) as the management server.
• Browse to System > SNMP > Managers.
• Click Add.
• Select Management Network.
• Keep Netmask set to 255.255.255.255. This configures the allowed manager as a single
host instead of a network.
• Click Create.
159
4. Configure an SNMP trap destination for Generic trap types:

• Browse to System > SNMP > Traps.
• Click Add.
• Select Generic under Type.
• Verify V2 under Version.
• Enter 192.168.10.254 as the Destination IP Address.
• Leave Source IP <blank>. The Citrix ADC will default sending traps from its NSIP address.
• Enter ctxtrainsnmp in the Community Name field.
• Click Create.
5. Configure an SNMP trap destination for Specific trap types:
• Click Add.
• Select Specific under Type.
• Verify V2 under Version.
• Enter 192.168.10.254 as the Destination IP Address.
• Leave Source IP <blank>. The Citrix ADC will default sending traps from its NSIP address.
• Enter ctxtrainsnmp in the Community Name field.
• Click Create.
Note: Minimum Severity is left blank, so all alerts will be sent. Severity levels can be adjusted to suit
the level of visibility.
6. Configure an SNMP alarm to generate traps on configuration save events:
• Browse to System > SNMP > Alarms.
• Change the number of items to display per page from 25 per page to 250 per page (at
bottom of Alarms pane) or you may use the Search option.
• Click the Alarm header to sort by name.
• Select CONFIG-SAVE alarm and click Edit.
• Verify that Logging is Enabled.
• Verify that State is Enabled.
• Click OK.
7. Configure an SNMP alarm to generate traps for CPU exceeding threshold values:
• Select CPU-USAGE alarm and click Edit.
• Enter 85 for Alarm Threshold (85% CPU usage).
• Enter 80 for Normal Threshold (80% CPU usage).
• Select Major under Severity.
• Verify that Logging is Enabled.
• Verify that State is Enabled.
160
• Click OK.
View SNMP Alerts on the Remote Server (in Kiwi)

Step Action
1. Switch to Kiwi Syslog.
2. Generate SNMP alerts on the Citrix ADC to send to Kiwi Syslog Daemon.
Return to the Citrix ADC and generated SNMP Traps:

• Disable service svc_red: ENTITY_STATE alarm.
• Re-enable service svc_red: ENTITY_STATE alarm.
• Save the Citrix ADC configuration: CONFIG_SAVE alarm.
3. Close Kiwi Syslog Daemon.
Key Takeaways:
• The Citrix ADC can be configured to accept SNMP polling and to submit SNMP alerts for
various events as they occur. This allows the Citrix ADC to report issues as part of an
existing SNMP management infrastructure.
• If no SNMP managers are specified, the Citrix ADC will respond to any manager that
requests polling information.
• SNMP responses are enabled by default on NSIP, SNIP, and VIP addresses. SNMP can be
disabled on individual addresses.
• Citrix ADC supports SNMP v1, v2, and v3 alerts.
• When configuring a Citrix ADC trap destination, if the source IP address is blank, the
NSIP is used. Otherwise a specific SNIP can be selected.
• The Citrix ADC comes with a number of SNMP alerts enabled by default. The SNMP
alerts and alert thresholds and other settings can be adjusted as necessary.
Exercise 8-4: Troubleshooting (GUI)
Introduction:
161
In this exercise, you will learn to apply what you have learned about the Citrix ADC
configuration and troubleshoot issues in a different Citrix ADC configuration file. You will use
the Citrix ADC Configuration Utility GUI to perform this exercise.
While this exercise is identified as part of the Citrix ADC Configuration Utility GUI-based
exercises, some use of the CLI will be required to execute the break and fix scripts. All other
troubleshooting steps will be presented based on information available in the GUI where
possible.
• Prepare for Troubleshooting.

• Troubleshoot Scenario 1: Unable to Connect to Management SNIP.
• Troubleshoot Scenario 2: Unable to Access Citrix ADC with Domain Account.
• Troubleshoot Scenario 3: Users Unable to Access Resources.
• Restore Configuration.
Prepare for Troubleshooting
Step Action
1. Prepare for Troubleshooting Lab:
Follow the steps in this section to prepare the HA Pair for the troubleshooting configuration. To
simplify management of the configuration, NYC-ADC-002 will be shut down (when instructed) and
only NYC-ADC-001 will be used.
Note: This task will require some CLI.

2. Connect to NYC-ADC-001 and NYC-ADC-002 using separate SSH sessions (PuTTY) using each NSIP.
Do not use the NSMGT SNIP (192.168.10.103) for this exercise until instructed.
• Connect to Citrix NYC-ADC-001 (192.168.10.101) using SSH (PuTTY).
• Connect to Citrix NYC-ADC-002 (192.168.10.102) using SSH (PuTTY).
3. NYC-ADC-001 - Save the Citrix ADC configuration before proceeding:
save ns config
162
4. NYC-ADC-002 -
Set HA node to StaySecondary:

set ha node -hastatus STAYSECONDARY
Save local configuration:

save ns config
5. Use Hyper-V Manager to shut down NYC-ADC-002:
• Open Hyper-V Manager.
• Right-click NYC-ADC-002 and click Shutdown.
6. Return to the SSH Session (Putty) for NYC-ADC-001 for the remainder of the exercise until
instructed.
7. Prepare NYC-ADC-001 for troubleshooting lab.
Save Citrix ADC Configuration:

save ns config
8. Run the Break script to begin troubleshooting lab:
batch -filename /var/labstuff/troubleshoot/break.txt
The Citrix ADC should restart automatically.
Note: After restart, a file /nsconfig/ts_status.txt will be present and contain the contents "break".
Troubleshoot Scenario 1
An environment presents the following issue, and you have been asked to identify the cause
and fix the issue. Try to identify the issue before proceeding to the resolution.
Issue 1:
• Connections to ADC-MGMT SNIP at 192.168.10.103 are failing for GUI and SSH.
Administrators are testing with nsroot.
Before you Begin:
• What are the possible causes of the issue as described?

• What requirements must be met for management connections to be successful against
a SNIP?
163
To diagnose this issue for Scenario 1:

Step Action
1. For this exercise, you will need to make two separate browser windows available:
Open the first browser and connect to http://192.168.10.101. Log on as nsroot/nsroot. We will call
this your nsoot@192.168.10.101 session.
This will be used for managing the configuration.

2. Use a second browser and attempt to reproduce the issue by connecting to the ADC-MGMT SNIP at
http://192.168.10.103.
We will call this your nsroot@192.168.10.103 session.
Does the attempt to connect succeed or fail? ______________________________

3. From a CMD prompt on the HOST desktop:
Can you ping 192.168.10.103?
4. From nsroot@192.168.10.101
Is the SNIP (192.168.10.103):

• Enabled?
• Configured as a SNIP
• Correct Subnet Mask
• Is USNIP mode enabled?
Use the GUI to investigate the above settings.

5. Do you have enough information to resolve the issue?
What are the settings for?

• Management Access
• Restrict Access
To resolve the issue for Scenario 1:

Step Action
164
1. Re-enable management access on the SNIP 192.168.10.103:

• Select 192.168.10.103 and click Edit.
Change the following settings under Application Access control:
• Enable Enable Management Access control to support the below listed applications.
• Verify that access to SSH and the GUI are enabled.
• Enable Allow access only to management applications.
• Click OK.
3. Verify that the issue is resolved:
Connect to the Citrix ADC HA Pair using the ADC-MGMT SNIP (192.168.10.103) using SSH (PuTTY).
Expected Result: Connection succeeds.
4. Close this session: nsroot@192.168.10.103

Try to identify the issue before proceeding to the resolution.
Issue 2:
• Connections to ADC-MGMT SNIP at 192.168.10.103 are now working for administrators

authenticating with local system accounts like nsroot, but attempts to connect to either
management IP (NSIP or SNIP) with domain accounts (trainNSAdmin) are failing.
For this scenario, use the same domain account information that was used in Module 7:
Securing the Citrix ADC.
Before you Begin:
• What are the possible causes of the issue described?

• What are the requirements for using domain accounts to access management IP
addresses on the Citrix ADC?
• This scenario contains several issues, and the diagnosis table gives a thorough
assessment of authentication. You may find the issues sooner using other methods.
165
To diagnose the issue for Scenario 2:

Step Action
1. Connect to the NYC-ADC-001 at http://192.168.10.101.
We will call this your nsroot@192.168.10.101 session.
Keep this session running to perform troubleshooting and to change configuration details
when a fix is identified.
2. Reproduce the issue - Connect to the NYC-ADC-001 at http://192.168.10.101.

We will call this your trainnsadmin@192.168.10.101 session.
Note: This session will fail to connect until the issue is resolved. You will need to test
connections several times until the issue is resolved.
3. nsroot@192.168.10.101 - View authentication issue in syslog:

• Click Run.
In the syslog output, you should be able to see failed authentication events for
trainNSAdmin. The event indicates that authentication failed for the user, but this is not
enough information to know the cause of the issue for certain.
4. Determine if external authentication is occurring.
There are a few ways to do this:
• Look at the authentication policies on the system and determine if they are bound
already and if policy hits are occurring.
• From the CLI, observe if external authentication calls are occurring using aaad.debug
(which can be useful if you're not sure where to start.) This step is covered in the CLI
exercise but not in the GUI version.
166
5. Diagnose looking at policy bindings and policy hits:

On nsroot@192.168.10.101 Identify the following:
• Are any ldap authentication policies present?
• Are the ldap authentication policies configured with the correct ldap action (server)?
• Is the expected policy bound?
6. To view authentication policy details:
Browse to System > Authentication > Basic Policies > LDAP.
7. Resolve (2.1) - Bind authentication policy to the global system object:
• Browse to System > Authentication > Basic Policies > LDAP if not already there.
• Click Bind.
• Click Done.
This issue must be resolved before additional troubleshooting can proceed.
8. Determine if this fixes the issue:
Attempt to connect to NYC-ADC-001 at http://192.168.10.101.

Did authentication succeed or fail this time? ___________________________________
167
9. nsroot@192.168.10.101 - View authentication issue in syslog again:

• Click Run.
In the syslog output, you should be able to see failed authentication events for
trainNSAdmin. These are the same events from earlier and still indicate an invalid username
or password.
However, there is another event before the message for "user trainnsadmin" that indicates
an issue with AAA (external authentication):
AAA Message 402

"In update_aaa_cntr: Failed policy for trainnsadmin = auth_ldap_srv".
This message is still vague (the aaad.debug events are more detailed), but it does indicate
that something in the authentication policy or action may be affecting the user
authentication.
10. Verify the ldap action configuration: auth_ldap_srv:
• Determine if the IP address for the domain controller is correct?
• Verify the Administrator Bind DN account and Password.
• Verify whether other authentication settings look correct?
• Determine if the Feature is Enabled.
When in doubt, suspect an incorrect password.

11. Resolve the Bind DN Account:
• Browse to System > Authentication > Basic Policies > LDAP.
• Click the Servers tab.
• Select auth_ldap_srv and click Edit.
• Verify that the administrator Bind DN is trainaduser@workspacelab.com.
Change the Bind DN Password:

• Check BindDN password.
• Enter Password1 in the Administrator Password and Confirm Administrator
Password fields.
Click OK.
168

Attempt to connect to NYC-ADC-001 at http://192.168.10.101.

Did authentication succeed or fail this time? ______________________

13. Issue resolved. Close session trainNSAdmin@192.168.10.101.
14. nsroot@192.168.10.101:
Save the Citrix ADC configuration and confirm.
To Resolve:
Step Action
1. Use these steps if you did not complete the resolutions during the diagnosis phase.
2. Issue 2.1 - Authentication policy is not bound to the System Global object:
• Browse to System > Authentication > Basic Policies > LDAP if not already there.
• Click Bind.
• Click Done.
3. Issue 2.2 - Authentication policy is misconfigured with a bad credential for the BindDN account:
• Browse to System > Authentication > Basic Policies > LDAP.
• Click the Servers tab.
• Select auth_ldap_srv and click Edit.
• Verify that the administrator Bind DN is trainaduser@workspacelab.com.
Change the Bind DN Password:

• Enter Password1 in the Administrator Password and Confirm Administrator Password
fields.
• Click OK.
Credentials being updated:

• User Name: trainADUser@workspacelab.com
169
The following issue has been encountered and you have been asked to identify the cause and
fix the issue or issues affecting the configuration. Try to identify the issue before proceeding to
the resolution.
Issue 3:
• Users can no longer access resources on http://172.21.10.101 (lb_vsrv_rbg) or

https://172.21.10.101 (ssl_vsrv_rbg).
To Diagnose:
Step Action
1. Reproduce Issue:
• Open a Web browser and attempt to connect to http://172.21.10.101/home.php
• Open a Web browser and attempt to connect to https://172.21.10.101/home.php
For this exercise, you are only troubleshooting lb_vsrv_rbg and ssl_vsrv_rbg.
2. Things to test:
• Is the load-balancing feature enabled?
• Are services UP or DOWN?
• Are associated load-balancing virtual servers UP or DOWN?
Things to keep in mind:

• What is required for a service to appear UP or DOWN?
• If HTTP is UP and SSL is DOWN, what are the different dependencies in the configuration?
Continue for exact troubleshooting steps.

3. Identify feature state:
Is Load Balancing Enabled or Disabled? _________________________

Is SSL Offload Enabled or Disabled? ___________________________
170
4. If you made changes, did this resolve the issue:

Did this test succeed or fail?

5. View load-balancing virtual server configurations:
• Which load balancing virtual servers are UP or DOWN
Are the Services or Service Groups UP or DOWN?

• Browse to Traffic management > Load Balancing > Services.
• Are Services or Service Groups offline?
View virtual server details for lb_vsrv_rbg:

• Are Services or Service Groups bound?
View virtual server details for ssl_vsrv_rbg:

• Are Services or Service Groups bound?
• Is SSL Certificate available? ___________________________________
• Is an SSL certificate bound? ____________________________________
6. Proceed to resolve the issues identified.
7. Test resolution:
Verify the following:
• Both URLs are accessible.
• You see actual load balancing (Red/Blue/Green) color content at end.
To Resolve:
Step Action
171
1. Enable LB Feature:
• Select Load Balancing and click OK.
2. Bind services to lb_vsrv_rbg:
• Click No Load Balancing Virtual Server Service Binding under Services and Service
Groups.
• Click Click to Select under Select Service.
• Select svc_red, svc_blue, and svc_green and click Select.
• Click Bind.
• Click Done.
3. Bind SSL Certificate to ssl_vsrv_rbg:
• Select ssl_vsrv_rbg and click Edit.
• Click No Server Certificate under Certificates.
• Click Click to Select under Select Server Certificate.
• Select colors.workspacelab.com and click Select.
• Click Bind.
• Click Done.
Restore Configuration
Use the following procedure to restore the Citrix ADC configuration to either the configuration
before the Troubleshooting exercise or to the alternate configurations as instructed by the
instructor.
Step Action
1. Connect to the NYC-ADC-001 (192.168.10.101) using SSH (PuTTY).

172
2. From the CLI, run the following command (as instructed by the Instructor).
Restore configuration after lab:
• Fix1 - to restore from your previous configuration (ns.conf.student.good).
batch -filename /var/labstuff/troubleshoot/fix1.txt
• Fix2 - to restore to End of Part 1 Day 3 (part1final.ns.conf)
The device will restart after executing the script.
If not sure which restoration point to use, use the Fix2.txt script to restore to the end of Part 1- Day
3.
3. Wait for NYC-ADC-001 to restart.
Verify that the Citrix ADC is still the primary member of the HA Pair before continuing. You may have
to wait a minute or two after the restart for NYC-ADC-001 to be primary.
View the HA status to confirm:
show ha node
4. Use Hyper-V Manager to Startup NYC-ADC-002:
• In the left pane, right-click NYC-ADC-002 and click Start.
Wait for NYC-ADC-002 to start up.
5. NYC-ADC-001 (Primary) -
Force synchronization with NYC-ADC-002 (StaySecondary):
force ha sync
Wait for HA Synchronization to complete:

show node
6. NYC-ADC-001 (Primary) - Save Citrix ADC Configuration:
save ns config

8. NYC-ADC-002 (StaySecondary): Staysecondary) -
Disable the StaySecondary option on NYC-ADC-002 and return to normal HA participation:
set ha node -hastatus enabled
Key Takeaways:
173
• To troubleshoot the Citrix ADC, begin by defining the issue and reproducing it when
possible. Verify the configuration requirements for a given feature. Always begin by
verifying that features are licensed and properly enabled. Then break down the
configuration requirements for a given feature and make sure all requirements are met.
o For virtual servers - Are services UP, are services bound, and are virtual servers
configured with correct settings?
o For policy-based features - Are policies bound to the correct bind point and are
policy hits occurring? o For networking issues - what is required for the network
to pass traffic? Check interfaces, routes, vlans, and test basic network
connectivity before moving to more complicated troubleshooting issues.
• Syslog and Nslog can assist with troubleshooting. Other logs and utilities, such as
aaad.debug and nstrace, may provide additional insight into troubleshooting.
• Sometimes the CLI provides more, and different, troubleshooting information than the
GUI.
Exercise 8-1: Viewing Citrix ADC Logs and Network Traces (CLI)
Introduction:
In this exercise, you will learn to gather log and troubleshooting information. You will use the
• View the syslog file (/var/log/ns.log) and its events.

• View the nslog file (/var/nslog/newnslog) and to view log file duration, events, and
console messages.
• Generate a network trace using the nstrace console in the Citrix ADC GUI.
View Syslog (/var/log/ns.log)
Step Action

174
2. View audit messages in CLI:

show audit messages
show audit messages -numOfMesgs 25
Displays the most recent audit messages from the audit log (syslog file). Returns, at most, the last
256 events.
3. View recent syslog files:
shell
cd /var/log
ls
The current syslog file is named ns.log.

Archived log files are named ns.log.0.gz-ns.log.25.gz.
4. View syslog events -
View current syslog:
more /var/log/ns.log
Search for events or messages in syslog using grep:
more /var/log/ns.log | grep svc_red -i
more /var/log/ns.log | grep error -i
Use grep to exclude events or messages with the -v option:

more /var/log/ns.log | grep CMD_EXECUTED -v
5. View recent events from the current syslog file -
Display the last 10 entries in the current syslog file:

tail /var/log/ns.log
Display recent log events that contain the phrase "error":

tail /var/log/ns.log | grep error -i
Display events as they occur by keeping the ns.log as an open filehandle:

tail -f /var/log/ns.log
175
6. View events from archived syslog files -

Identify a recent syslog archive: ns.log.##.gz:
ls -l ns.log*
View the contents of the log file without having to extract it first:
zcat /var/log/ns.log.##.gz | more
If the file has already been extracted (no .gz extension), use more/tail/grep normally:
more /var/log/ns.log.##
7. View Syslog in GUI:
• Recent Syslog Messages: System > Auditing.
• Click Run
• Full syslog files: System > Auditing.
• Click Syslog Messages.
View Nslog (/var/nslog/newnslog) (CLI/GUI)

Step Action
2. View nslog files on Citrix ADC:
shell
cd /var/nslog/
ls
The current nslog is newnslog.
Archived nslog files are newnslog.0.gz-newnslog.99.gz.
176
3. View the current or archived nslog file and identify:

• Log File Duration (Start/End Time)
• Events
• Console Messages
Note: nsconmsg is case sensitive.
• -K (big) designates an input file
• -k (little) designates an output field; you do not normally use this if viewing a log.
View current Log File Duration and identify:

nsconmsg -K /var/nslog/newnslog -d setime
View Events:
nsconmsg -K /var/nslog/newnslog -d event
View Console Messages:

nsconmsg -K /var/nslog/newnslog -d consmsg
4. View Nslog in GUI:
Under Manage Logs, the GUI contains shortcuts to most of the commonly used nsconmsg
commands. These commands can be executed against the current nslog file or an archive:  View
Log File Duration
• View Events
• View console Messages
• View Events from Specific Time
• Trim Log Files
Under Troubleshooting Data, additional nslog commands provide access to:

• Memory Usage
• View dmesg.boot
Generate a Network Trace with nstrace (CLI)

Step Action
177
2. Verify that you are in the Citrix ADC CLI (instead of SHELL).
3. View syntax for nstrace -
Display basic help:

help start nstrace
Display full main page:

man start nstrace
Note: Use of the manual nstrace command is deprecated in NetScaler 11.0. Start nstrace and Stop
nstrace should be used instead.
4. Start a trace with the following criteria:
Size 0 (full packet regardless of size).
• Capture trace in PCAP form.
• Trace traffic originating from the HOST desktop.
• Trace all peer traffic (-link):
start nstrace -size 0 -traceformat pcap -
filter "connection.ip.eq(172.21.10.254)&&connection.ip.eq(172.21.10.101)" -link enabled
This command will generate a trace only for traffic between the HOST desktop and the RBG VIP; this will
exclude all the management communication since we are running SSH and GUI connections from the
HOST desktop to the NSIP/SNIP addresses as well. The link enabled option ensures that all backend
traffic associated with the request and response flow will also be captured.
Note about syntax: In the CLI, the compound operator can be adjacent to the expressions as listed or
listed as <space>&&<space>. Both formats are valid. In the GUI, the expression must be adjacent without
a space between the operator in the nstrace dialog box.
5. Generate test traffic -
• Open a web browser and go to http://172.21.10.101/home.php
• Refresh the page a few times.
• Open a web browser and go to http://172.21.10.105/
6. Return to the Citrix ADC CLI (Putty) and stop the trace:
stop nstrace
178
7. Use WinSCP to download the trace:

• Open WinSCP and connect to ADC-MGMT SNIP (192.168.10.103).
• If you receive a warning from WinSCP to add the host key to a cache, click Yes to continue.
• In the right-pane, browse to /var/nstrace/.
• The trace is generated in a folder named after the date/time.
• In the left pane, browse to C:\resources\.
• Copy the appropriate nstrace (usually: nstrace1.pcap) in the right pane to the C:\resources\
directory in the left pane.
• Close WinSCP.
8. On the HOST desktop, browse to C:\resources\. Double-click the .pcap file to open in Wireshark.
9. In the trace, look for the following:
• Find the first reference to a request for Get /home.php.
o Identify the Source IP address as the HOST desktop (172.21.10.254).
o Identify the Destination IP address as the VIP (172.21.10.101).
• Then use the trace to identify which SNIP the Citrix ADC used to send the traffic to the backend
servers and which server (Red, Blue, or Green) responded with the object.
Key Takeaways:
• Nslog and Syslog details are available in both the GUI and the CLI.
• Syslog is the audit log for the Citrix ADC and contains all configuration changes made to
the appliance. Other specific events are logged by features and subsystems on the Citrix
ADC, which means it can be useful for troubleshooting.
• Nslog contains all the statistics, metrics, and debug counters on the Citrix ADC in
addition to events and the console message.
• Statistics and metric information can be retrieved from nslog or by using the stat
command in the CLI, the statistics commands in the GUI, or the Dashboard view in the
GUI.
• Nslog also contains useful troubleshooting information such as events, console
messages, log file duration, dmesg output, and memory usage. All of these counters can
be retrieved manually through the CLI or using the built-in shortcuts in the GUI. The GUI
is the preferred method for retrieving this information for daily operations.
• Nstrace is the built-in Citrix ADC trace utility. It can be run from the CLI or the GUI and
can easily be used to capture a network trace with required parameters for a subset of
traffic of interest using the expression and link options.
179
Exercise 8-2: Configuring External Syslog and Audit Policies

(CLI)
Introduction:
In this exercise, you will learn to configure audit policies to enable external logging of the local
syslog file to an external syslog server. You will use the command-line interface to perform this
exercise.
The audit policies will be configured so that the Citrix ADC continues to log all events to the
local syslog file in /var/log/ns.log. Logging to the external syslog server is in addition to the local
logging and not in place of.
For this exercise, the audit policy will be bound to the global system object so that all syslog
events are logged to the external server. Audit policies could be bound to specific virtual
servers, AAA groups, or AAA users to capture syslog data related to these entities only.
Kiwi Syslog Daemon running on the HOST desktop will act as the external Syslog server.
• Configure Kiwi Syslog Daemon to Receive Syslog Messages.

• Configure External Audit Policies for Syslog.
• View Audit Message in the Remote Sever (Kiwi).
Configure Kiwi Syslog Daemon to Receive Syslog
Step Action
1. Start Kiwi Syslog Daemon -
• Double-click the Kiwi Syslog Daemon shortcut on the desktop.
OR
• run C:\Program Files\Syslogd\Syslogd.exe.
2. Configure Kiwi to receive Syslog messages (UDP 514) –

• Verify that Listen for UDP Syslog is selected and that UDP Port is set to 514.
• Leave all other settings at their default values.
• Click OK.
180
Configure External Audit Policies for Syslog

Step Action

2. Configure a syslog server (policy action) to enable external auditing to the Syslog manager on the
HOST desktop (Kiwi Syslog Daemon). The HOST desktop IP address is 192.168.10.254.
add audit syslogAction ext_kiwi 192.168.10.254 -serverPort 514 -logLevel EMERGENCY ALERT
CRITICAL ERROR WARNING NOTICE INFORMATIONAL -dateFormat MMDDYYYY -logFacility
LOCAL0 -tcp NONE -acl DISABLED -timeZone GMT_TIME -userDefinedAuditlog NO -appflowExport
DISABLED -lsn DISABLED -alg DISABLED -transport UDP -dns DISABLED
3. Create a syslog policy to log to the specific syslog server (policy action):
add audit syslogPolicy ext_kiwi_policy ns_true ext_kiwi
4. Bind syslog policy to the global system object to enable audit logging to the external server:
bind system global ext_kiwi_policy -priority 10
5. Changes in the configuration will be audited and reported to Kiwi -
Disable service svc_red:
disable service svc_red
Enable service svc_red:
enable service svc_red
save ns config
7. Verify that audit messages are displayed in Kiwi Syslog Daemon.
Messages will include:
• CMD EXECUTED messages which audit configuration changes made by GUI or CLI.
• EVENT messages related to the service going UP and DOWN, monitors returning to a UP
state and config save events.
8. Unbind the syslog policy to disable audit logging to the Kiwi server:
unbind system global ext_kiwi_policy
This stops syslog audit messages from being sent from the Citrix ADC to the Syslog Manager, so the
same utility can be used for SNMP alerting in the next exercise.
save ns config
181
Key Takeaways:
• Audit policies enable sending syslog and nslog data to an external server. Usually, this is
done to maintain logs for longer retention periods than what the Citrix ADC allows or to
protect audit logs from loss in the event of appliance failure. The Citrix ADC syslog is in
standard syslog format and can be sent to any syslog server.
• Audit policies follow a similar policy cascade as authentication policies. If multiple audit
policies are bound, then logging can occur to multiple logging destinations.
• By bind audit policies to the global system object, the remote log will contain all the
same information as the local syslog on the Citrix ADC. While audit policies can also be
bound to the virtual server, AAA groups, and AAA Users, binding policies to the global
system object is the only way to capture all events on the Citrix ADC and all audited
configuration changes made by the system users.
Exercise 8-3: Configuring SNMP (CLI)
Introduction:
In this exercise, you will learn to configure SNMP integration on the Citrix ADC to allow both
SNMP polling and alerting. This exercise will configure SNMP community strings, SNMP
managers, SNMP trap destinations, and SNMP Alerts. Kiwi Syslog Daemon running on the HOST
desktop will be the SNMP trap destination for this scenario. You will use the command-line
interface to perform this exercise.
• Configure Kiwi Syslog Daemon to Receive SNMP Alerts.

• Configure SNMP Settings.
• View SNMP Alerts in the Remote Server (Kiwi).
Configure Kiwi Syslog Daemon to Receive SNMP Alerts
Step Action
1. Disable syslog in Kiwi:
• Deselect Listen for UDP Syslog messages.
182
2. Enable SNMP Traps in Kiwi:

• Expand Inputs and select SNMP.
• Select Listen for SNMP Traps and verify that 162 appears in the UDP Port field
• Click OK.
3. Clear Display in Kiwi:
• Click View > Clear Display.
Configure SNMP Settings

Step Action
2. Configure the SNMP Manager using the HOST desktop IP address (192.168.10.254):
add snmp manager 192.168.10.254
3. Configure the SNMP Community with ALL Permissions:
add snmp community ctxtrainsnmp ALL
4. Configure the HOST desktop (192.168.10.254) as both a generic and specific SNMPv2 trap
destination.
Configure the specific trap destination:

add snmp trap specific 192.168.10.254 -version v2 -communityName ctxtrainsnmp
Configure the generic trap destination:
add snmp trap generic 192.168.10.254 -version v2 -communityName ctxtrainsnmp
5. Configure an SNMP alarm of type CONFIG-SAVE, that will generate an alert on every save config
event.
set snmp alarm CONFIG-SAVE -state ENABLED
6. Configure an SNMP alarm of type CPU-USAGE that will generate an alert when CPU usage exceeds
a specific threshold. This alarm has both a high alert threshold and a return to normal threshold:
set snmp alarm CPU-USAGE -thresholdValue 85 -normalValue 80 -severity Major -logging
enabled -state enabled
7. View additional available SNMP alarms:
show snmp alarm
View SNMP Alerts on the Remote Server (in Kiwi)

Step Action
183
1. Generate SNMP alerts on the Citrix ADC to send to Kiwi Syslog Daemon.
Return to the Citrix ADC and generate SNMP Traps -
Disable service svc_red: ENTITY_STATE alarm:
disable service svc_red
Re-enable service svc_red: ENTITY_STATE alarm:
enable service svc_red
Save the Citrix ADC configuration: CONFIG_SAVE alarm:
save ns config
2. Switch Kiwi Syslog Daemon and view displayed SNMP traps.
3. Close Kiwi Syslog Daemon.
4. View SNMP stats:
stat snmp
Key Takeaways:
• The Citrix ADC can be configured to accept SNMP polling and to submit SNMP alerts for
various events as they occur. This allows the Citrix ADC to report issues as part of an
existing SNMP management infrastructure.
• If no SNMP managers are specified, the Citrix ADC will respond to any manager that
requests polling information.
• SNMP responses are enabled by default on NSIP, SNIP, and VIP addresses. SNMP can be
disabled on individual addresses.
• Citrix ADC supports SNMP v1, v2, and v3 alerts.
• When configuring a Citrix ADC trap destination, if the source IP address is blank, the
NSIP is used. Otherwise, specific SNIP can be selected.
• The Citrix ADC comes with several SNMP alerts enabled by default. The SNMP alerts and
alert thresholds and other settings can be adjusted as necessary.
Exercise 8-4: Troubleshooting (CLI)

Introduction:
In this exercise, you will learn to apply what you have learned about the Citrix ADC
configuration and troubleshoot issues in a different Citrix ADC configuration file. You will use
the command-line interface to perform this exercise.
This exercise includes the following tasks:
184
• Prepare for Troubleshooting.

• Troubleshoot Scenario 1: Unable to connect to management SNIP.
• Troubleshoot Scenario 2: Unable to access Citrix ADC with domain account.
• Troubleshoot Scenario 3: Users unable to access resources.
• Restore Configuration.
Prepare for Troubleshooting
Step Action
1. Prepare for Troubleshooting Lab:
Follow the steps in this section to prepare the HA Pair for the troubleshooting configuration. To
simplify management of the configuration, NYC-ADC-002 will be shut down (when instructed) and
only NYC-ADC-001 will be used.
2. Connect to NYC-ADC-001 and NYC-ADC-002 using separate SSH sessions (PuTTY) using each
individual NSIP. Do not use the NSMGT SNIP (192.168.10.103) for this exercise until instructed.
• Connect to Citrix NYC-ADC-001 (192.168.10.101) using SSH (PuTTY). Log on as
nsroot/nsroot.
• Connect to Citrix NYC-ADC-002 (192.168.10.102) using SSH (PuTTY). Log on as
nsroot/nsroot.
3. NYC-ADC-001 -
Save the Citrix ADC configuration before proceeding:
save ns config
4. NYC-ADC-002 -
Set HA node to StaySecondary:
set ha node -hastatus STAYSECONDARY
Save local configuration:

save ns config
5. Use Hyper-V Manager to shut down NYC-ADC-002:
• In the left pane, right-click NYC-ADC-002 and click Shutdown.
6. Return to the SSH Session (Putty) for NYC-ADC-001 for the remainder of the exercise until
instructed.
7. Prepare NYC-ADC-001 for troubleshooting lab.

save ns config
185
8. Run the Break script to begin troubleshooting lab:

batch -filename /var/labstuff/troubleshoot/break.txt
The Citrix ADC should restart automatically.
Note: After restart, a file /nsconfig/ts_status.txt will be present and contain the contents "break".
Troubleshooting Scenario 1
An environment presents the following issue, and you have been asked to identify the cause
and fix the issue. Try to identify the issue before proceeding to the resolution.
Issue 1:
• Connections to ADC-MGMT SNIP at 192.168.10.103 are failing for GUI and SSH.
• Administrators are testing with nsroot.
Before you Begin:
• What possible causes for the issue are described?

• What requirements must be met for management connections to be successful against
a SNIP?
Step Action
We will call this your nsroot@192.168.10.101

2. Attempt to connect to the ADC-MGMT SNIP (192.168.10.103) using SSH (PuTTY).

Does the attempt succeed or fail: ______________________?

3. From a CMD prompt on the HOST desktop:
Can you ping 192.168.10.103?
186
4. From nsroot@192.168.10.101 -
Is the SNIP (192.168.10.103):

• Enabled?
• Configured as a SNIP?
• Correct Subnet Mask?
• Is USNIP mode enabled?
show ns ip
show ns ip 192.168.10.103
show ns mode
5. What are the connection restrictions and permissions on the SNIP?
show ns ip 192.168.10.103
Or
compare the actual configuration command:
show ns runningconfig | grep 192.168.10.103
What are the settings for?
• Management Access
• Restrict Access
To resolve the issue for Scenario 1:

Step Action
1. Re-enable management access on the SNIP 192.168.10.103:
set ns ip 192.168.10.103 -mgmtAccess enabled
2. Attempt to connect to the ADC-MGMT SNIP (192.168.10.103) using SSH (PuTTY).
Expected Result: Connection succeeds.

3. Close this session: nsroot@192.168.10.103
the resolution.
187
Issue 2:
• Connections to ADC-MGMT SNIP at 192.168.10.103 are now working for administrators

authenticating with local system accounts like nsroot, but attempts to connect to either
management IP (NSIP or SNIP) with domain accounts (trainNSAdmin) are failing.
• For this scenario, use the same domain account information that was used in Module 7:
Securing the Citrix ADC.
Before you Begin:
• What are the possible causes of the issue described?

• What are the requirements for using domain accounts to access management IP
addresses on the Citrix ADC?
• Several issues are included in this scenario. The diagnosis table gives a thorough
assessment of authentication. You may find the issues sooner using other methods.
Step Action
1. Connect to the Citrix NYC-ADC-001 (192.168.10.101) using SSH (PuTTY).
We will call this your nsroot@192.168.10.101
Keep this session running to do troubleshooting and to change configuration details when a fix is
identified.
2. Reproduce the issue: Attempt to connect to the Citrix NYC-ADC-001 (192.168.10.101) using SSH
(PuTTY).

We will call this session trainNSAdmin@192.168.10.101
Note: This session will fail to connect until the issue is resolved. You will need to attempt to start
sessions multiple times during testing.
188
3. Determine if external authentication is occurring.

There are a few ways to do this:
• Look at the authentication policies on the system and determine if they are bound already
and if policy hits are occurring.
Or
• observe if external authentication calls are occurring using aaad.debug; this can be useful if
you are not sure where to start.
4. Diagnose with aaad.debug -
On nsroot@192.168.10.101, view aaad.debug:

shell cd /tmp
ls
cat aaad.debug
While this command is running, restart your trainNSAdmin@192.168.10.101 session (Putty). If the
previous window is still open, right-click the menu bar and click restart session. If not, start a new
session to 192.168.10.101 and attempt to log on as trainNSAdmin / Password1.
Return to nsroot@192.168.10.101 and determine if any events occurred.

• Ignore timer firing events (for this discussion).
• If no events occurred, that means the External Authentication system is not being invoked.
This likely indicates that no external authentication policies are bound to the global system
object.
5. On nsroot@192.168.10.101:
• Enter CTRL+C to stop the "cat aaad.debug" output.
• Enter exit to return to the CLI.
189
6. Diagnose looking at policy bindings and policy hits -

On nsroot@192.168.10.101, identify the following:
• Are any ldap authentication policies present?
• Are the ldap authentication policies configured with the correct ldap action (sever)?
• Is the expected policy bound?
Identify if Authentication Policies and Actions exist: show

authentication ldapAction show authentication
ldapPolicy
Use the policy Name to see if it is bound anywhere on the Citrix ADC:
show ns runningConfig | grep auth_ldap_policy
Are any bind commands returned referencing this policy? _______________

Alternate methods of finding policies, when you do not know what you are looking for:
show ns runningConfig | grep ldap -i
show ns runningConfig | grep authentication -i
7. Resolve (2.1) - Bind the authentication policy to the global system object:
bind system global auth_ldap_policy -priority 10
This issue must be resolved before additional troubleshooting can proceed.

On nsroot@192.168.10.101, view aaad.debug:
shell cd /tmp
ls
cat aaad.debug
While this command is running, restart your trainNSAdmin@192.168.10.101 session (Putty). If the
previous window is still open, right-click the menu bar and click restart session. If not, start a new
session to 192.168.10.101 and attempt to log on as trainNSAdmin / Password1.
Did authentication succeed or fail? __________________________________
Return to nsroot@192.168.10.101 and determine if any events occurred.

• Ignore timer firing events (for this discussion).
• Bind events should be observed.
• Do not exit this session as we will be using this output for additional troubleshooting.
190
9. On nsroot@192.168.10.101:
• Enter CTRL+C to stop the "cat aaad.debug" output.
• Do not exit, as we need to look at the output.
10. This time the logon-generated output in the aaad.debug file, which means the external authentication
policy was attempted. Either the user is typing in credentials wrong or the policy action is
misconfigured some way. In general, the output of aaad.debug can be useful in identifying the
following:
• Is the Authentication policy going to the right destination?
• Is the Authentication policy connecting to the directory service? BindDN event failures
indicate possible issues with credentials in the policy the Citrix ADC is using.
• If the Authentication policy bind appears successful, then the output may identify if user
credentials are invalid or if there are issues with group extraction.
Log output indicates an issue with the BindDN account credentials in the policy action
(auth_ldap_srv):
Relevant lines:
ns ldap check result checking LDAP result. Expecting…(LDAP_RES_BIND) LDAP action failed: Invalid
Credentials
11. View the ldapAction:

show authentication ldapAction auth_ldap_srv
Verify that the username appears correct: trainaduser@workspacelab.com (usernames are not case
sensitive).
At this point, assume that the password is wrong and reconfigure the action.
191
12. Resolve BINDDN Account:

set authentication ldapAction auth_ldap_srv -ldapBindDN
trainaduser@workspacelab.com
-ldapBindDNPassword Password1
13. Return to nsroot@192.168.10.101 and determine if any events occurred.
Did authentication succeed? ______________-

Does user have administrative rights (save config)? _________________
14. Issue resolved. Close session trainNSAdmin@192.168.10.101.
To Resolve:
Step Action
1. Use these steps if you did not complete the resolutions during the diagnosis phase.
2. Issue 2.1 - Authentication policy is not bound to the System Global object:
bind system global auth_ldap_policy
3. Issue 2.2 - Authentication policy is misconfigured with bad credentials for the BindDN account. Fix
the authentication action with corrected credentials:
set authentication ldapAction auth_ldap_srv -ldapBindDN
trainaduser@workspacelab.com
-ldapBindDNPassword Password1
• User Name: trainADUser@
the resolution.
Issue 3:
Users can no longer access resources on http://172.21.10.101 (lb_vsrv_rbg) or

•
https://172.21.10.101 (ssl_vsrv_rbg).
To Diagnose:
Step Action
1. Reproduce Issue:
192
2. Things to test:
• Is the load-balancing feature enabled?
• Are services UP or DOWN?
• Are associated load-balancing virtual servers UP or DOWN?
Things to keep in mind:

• What is required for a service to appear UP or DOWN?
• If HTTP is UP and SSL is DOWN, what are the different dependencies in the configuration?
Continue for exact troubleshooting steps.

3. Identify feature state:
show ns feature
Is load balancing enabled or disabled? _________________________

4. View load-balancing virtual server configurations -
Show all load balancing virtual servers:

show lb vserver -summary
Are all load-balancing virtual servers UP or DOWN? ___________

Show virtual server details for lb_vsrv_rbg:
show lb vserver lb_vsrv_rbg
Are Services or Service Groups bound? ____________________________

Are Services or Service Group members healthy? ____________________
Show virtual server details for ssl_vsrv_rbg:

show lb vserver ssl_vsrv_rbg
Are Services or Service Groups bound? _____________________________

Are Services or Service Group members healthy? _____________________
For SSL, is a certificate bound? ____________________________________
5. Proceed to resolve the issues identified.
193
6. Test resolution:
Verify the following:
• Both URLs are accessible.
• You see actual load balancing (Red/Blue/Green) color content at end.
To Resolve:
Step Action
1. Enable LB Feature:
2. Bind Service lb_vsrv_rbg:

bind lb vserver lb_vsrv_rbg svc_red
bind lb vserver lb_vsrv_rbg svc_blue
bind lb vserver lb_vsrv_rbg svc_green
3. Bind SSL Certificate to ssl_vsrv_rbg:
bind ssl vserver ssl_vsrv_rbg -certkeyname colors.workspacelab.com
Restore Configuration
Use the following procedure to restore the Citrix ADC configuration to either the configuration
before the Troubleshooting exercise or to the alternate configurations as instructed by the
instructor.
Step Action
194
2. From the CLI, run the following command (as instructed by the Instructor):
Restore configuration after lab:
• Fix1 - to restore from your previous configuration (ns.conf.student.good):
• Fix2 - to restore to End of Part 1 Day 3 (part1final.ns.conf):
Confirm restart when prompted.
If not sure which restoration point to use, use the Fix2.txt script to restore to the end of Part 1 - Day
3.
3. Wait for NYC-ADC-001 to restart.
Verify that the Citrix ADC is still the primary member of the HA Pair before continuing. You may have
to wait a minute or two after the restart for NYC-ADC-001 to be primary.
View the HA status to confirm:

show ha node
4. Use Hyper-V Manager to start up NYC-ADC-002:
• In the left pane, right-click NYC-ADC-002 and click Start.
Wait for NYC-ADC-002 to start up.
5. NYC-ADC-001 (Primary) –
Force synchronization with NYC-ADC-002 (StaySecondary):
force ha sync
Wait for HA Synchronization to complete:
show ha node
6. NYC-ADC-001 (Primary) –
save ns config
8. NYC-ADC-002 (StaySecondary): Staysecondary-
Disable the StaySecondary option on NYC-ADC-002 and return to normal HA participation:

set ha node -hastatus enabled
195
Key Takeaways
• To troubleshoot the Citrix ADC, begin by defining the issue and reproducing it when
possible. Verify the configuration requirements for a given feature. Always begin by
verifying that features are licensed and properly enabled. Then break down the
configuration requirements for a given feature and make sure that all requirements are
met.
o For virtual servers: Are services UP? Are services bound? And are virtual
servers configured with correct settings?
o For policy-based features: Are policies bound to the correct bind point and are
policy hits occurring? o For networking issues: What is required for the
network to pass traffic? Check interfaces, routes, vlans, and test basic network
connectivity before moving to more complicated troubleshooting issues.
• Syslog and Nslog can assist with troubleshooting. Other logs and utilities, such as
aaad.debug and nstrace, may provide additional insight into troubleshooting.
• Sometimes the CLI provides more, and different, troubleshooting information than the
GUI.
196

CNS 225 1I en StudentExerciseWorkbook 1 3 Days v01

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CNS 225 1I en StudentExerciseWorkbook 1 3 Days v01

Uploaded by

Copyright:

Available Formats

CNS-223-1I Citrix ADC 13.

CNS-223-1I Citrix ADC 13.x

Lab Manual- Version 5

Copyright © 2020 by Citrix Systems, Inc.

Offering Manager Amit Ben-Chanoch

Lab Manual Overview

Lab Environment Overview

Virtual Machine Name Domain FQDN IP Address Description

Student Desktop - 192.168.10.254 Hyper-V host and landing desktop.

Virtual Machine NSIP Address Subnet IP (SNIP) Address Description

User Name Groups Password Description

administrator Domain Admins Password1 Domain administrator account which can

User Name Delegated Admin Password Description

Module 1: Getting Started

After completing this lab module, you will be able to:

• Exercise 1-1: Performing an Initial Configuration

Before you Begin:

Virtual Machines required for this module

• NYC-ADC-001 NSIP (initial): http://192.168.100.1

Exercise 1-1: Performing an Initial Configuration (CLI)

In this exercise, you will perform the following tasks:

• Configure the initial NSIP and SNIP

Start > Run > putty 192.168.100.1

Log on to the utility using the following credentials:

• User Name: nsroot

3. Configure NSIP, Subnet Mask, and Default Gateway.

• Enter option 1 to begin:

Start > Run > putty 192.168.10.101

• User Name: nsroot

Log on to the utility using the following credentials:

• User Name: nsroot

11. Verify that the license was applied:

Add the NTP Server:

Set as preferred server:

Enable NTP Synchronization:

Change the global parameter (to affect all users):

Manually set the time on a Citrix ADC appliance

Open a PuTTY session to NYC-ADC-001.

EXAMPLE: date YYMMDDHHMM

Upgrade the NetScaler to Citrix ADC

Extract Build Files:

Once the install has completed select Y when directed to reboot.

Log on to the utility using the following credentials:

• User Name: nsroot

Verify the version:

Exercise 1-2: Performing Basic Administration (GUI)

• Enable Citrix ADC Features

Enable Citrix ADC Features

2. Enable Citrix ADC features (Basic):

View Running and Saved Configurations

IMPORTANT: Do not save the configuration until instructed in this exercise.

10. View Citrix ADC System Details:

Performing a Configuration Backup

Access the Citrix ADC CLI from the Configuration Utility:

• User Name: nsroot

The backup is created in /var/ns_sys_backup/ on the Citrix ADC.

Exercise 1-2: Performing Basic Administration (CLI)

In this exercise, you will perform the following tasks:

About Citrix ADC Configuration Management

IMPORTANT: Do not save the configuration until instructed in this exercise.

3. Display features enabled or disabled on the Citrix ADC:

4. Enable Citrix ADC Features:

enable ns feature LB CS CMP SSL CF Responder Rewrite