Category: NetScaler 11

Navigation

• Overview
• AAA Virtual Server
  • Create AAA vServer
  • AAA Portal Theme
  • AAA Client Certificate Authentication
• Login Schema
  • Login Schema XML File
  • Login Schema Profile
  • Login Schema Policy
• Advanced Authentication Policies
  • Create Advanced Authentication Policy
  • Bind Advanced Authentication Policy to AAA
  • LDAP Group Extraction
• Authentication Policy Label
  • Create Authentication Policy Label
  • Bind Authentication Policy Label
• nFactor for NetScaler Gateway
  • AAA Authentication Profile
  • Gateway Client Certificate Authentication
  • nFactor Single Sign-on to StoreFront
• Sample Configurations
  • Certificate auth: If Success, LDAP only. If fails, LDAP+RADIUS

Overview

nFactor lets you configure an unlimited number of authentication factors. You are no longer limited to just two factors. Each authentication factor performs the following tasks:

• nFactor requests credentials from the user. These credentials can be anything supported by NetScaler including:
  • SAML
  • Certificate
  • oAuth
  • Kerberos
  • Forms-based authentication (traditional web-based logon page) for LDAP, RADIUS, etc.
    • Multiple passwords can be collected with one form.
    • Or prompt the user multiple times throughout the authentication chain.
    • The logon page can contain a domain drop-down.
• nFactor evaluates the credentials. The results can be:
  • Authentication success
  • Authentication failure
  • Group extraction
  • Attribute extraction from SAML, Certificate, etc.
• Based on the evaluation results, do one of the following:
  • Allow access
  • Use authentication evaluation results to select next factor
  • Deny access
• Multiple factor evaluations can be chained together. The chosen next factor is based on the results of the prior factor. This can continue indefinitely. The next factor can do one of the following:
  • Prompt the user for more credentials
  • Evaluate the already entered next set of credentials
  • Use policy expression to select another next factor (no authentication). This is typically used with group extraction so that groups determine the next factor.

Here are some nFactor use cases, but the combinations are almost limitless:

• Authentication method based on Active Directory group: Logon screen asks for user name only. Extract user’s groups from Active Directory. Based on user’s Active Directory groups, either ask user for certificate, or ask user for LDAP password. If LDAP, the username doesn’t need to be entered again.
• Ask for Certificate first:
  • If certificate, perform LDAP
  • If no certificate, perform LDAP + RADIUS
• Two-factor with passwords checked in specific order: Logon screen with two password fields. Check the first password. If the first password succeeds, then check the second password. This lets you check RADIUS before LDAP.

In NetScaler 11.0 build 62 and newer, you can configure nFactor on AAA authentication servers.

In NetScaler 11.0 build 66 and newer, you can configure nFactor in the AAA feature and bind it to NetScaler Gateway Virtual Servers. Thus NetScaler Enterprise Edition is required.

• Note: nFactor works with browser clients, but it does not work with Receiver Self-Service (native Receiver).

nFactor configuration summary (detailed instructions below):

• The first factor (Advanced Authentication Policy and Login Schema) is bound directly to a AAA Virtual Server.
• Next factors are Authentication Policy Labels that are chained to Advanced Authentication Policies in prior factors.
• Authentication Profile links AAA nFactor with NetScaler Gateway.

AAA Virtual Server

Create AAA Virtual Server

To use nFactor with NetScaler Gateway, you first configure it on a AAA Virtual Server. Then you later bind the AAA Virtual Server to the NetScaler Gateway Virtual Server.

1. If AAA feature is not already enabled, go to Security > AAA, right-click AAA and Enable Feature.
   
2. Go to Security > AAA > Virtual Servers.
   
3. On the right, click Add.
   
4. Give the Virtual Server a name.
5. If you are only using this AAA Virtual Server for NetScaler Gateway, then you can change the IP address Type to Non Addressable. It’s also possible to content switch to AAA.
6. Enter an Authentication Domain and click OK.
   
7. In the Certificates section, click where it says No Server Certificate.
   
8. Click to select.
   
9. Select a certificate for the AAA Virtual Server and click Select. Since this AAA Virtual Server is not directly addressable, the chosen certificate doesn’t matter.
   
10. Click Bind.
    
11. Click Continue.
    
12. You probably don’t have any Advanced Authentication Policies yet so just click Continue.
    

AAA Portal Theme

If this AAA Virtual Server is used not just for NetScaler Gateway, but also for traffic management (Load Balancing, Content Switching), then you might want to change the AAA Portal theme.

1. Go to NetScaler Gateway > Portal Themes and add a theme.
   
2. After adjusting it as desired, at the top of the portal theme editing page, Click to Bind and View Configured Theme.
   
3. Change the selection to Authentication.
4. Use the Authentication Virtual Server Name drop-down to select the AAA Virtual Server and click Bind and Preview.
   

Client Certificate Authentication

If one of your authentication Factors is certificate, then you must perform some SSL configuration on the AAA Virtual Server:

1. Go to Traffic Management > SSL > Certificates and install the root certificate for the issuer of the client certificates. Root certificates do not have a key file.
   
2. Go to Security > AAA > Virtual Servers and edit an existing AAA Virtual Server.
   
3. On the left, in the SSL Parameters section, click the pencil icon.
   
4. Check the box next to Client Authentication.
5. Make sure Client Certificate drop-down is set to Optional, and click OK.
   
6. On the left, in the Certificates section, click where it says No CA Certificate.
   
7. Click to select.
   
8. Select the root certificate for the issuer of the client certificates and click Select.
   
9. Click Bind.
   

Login Schema

Login Schema XML File

Login Schema is an XML file providing the structure of forms-based authentication logon pages.

nFactor implies multiple authentication Factors that are chained together. Each Factor can have different Login Schema pages/files. In some authentication scenarios, users could be presented with multiple logon screens.

Or you can have one Factor gather information that can be passed on to later Factors so that the later Factors don’t need to display another Login Schema. This is particularly useful for traditional two-password logon screens (LDAP + RADIUS) since each password is evaluated in a separate Factor:

• The first password is evaluated in the first factor (e.g. LDAP). If successful, then proceed to the second factor.
• The second factor (e.g. RADIUS) evaluates the second password. However, the second password has already been entered so there’s no need to ask the user for it again. To prevent a Login Schema from being shown to the user, select noschema (LSCHEMA_INT) in the Authentication Policy Label.

Several Login Schema .xml files are included with NetScaler under /nsconfig/loginschema/LoginSchema. You can easily duplicate and modify these files. You can also download login schemas from support.citrix.com.

After duplicating one of the existing .xml files, you can edit it as desired. You can change the labels. Or you can configure fields to pre-fill information from previous Factors as shown below:

The login schema can also contain a domain drop-down. See CTX201760 nFactor – Domain Drop-Down in First Factor then Different Policy Evaluations Based on Groups for a sample configuration.

Login Schema Profile

To configure a Login Schema Profile:

1. Create or Edit a Login Schema .XML file based on your nFactor design.
2. Go to Security > AAA > Login Schema.
   
3. On the right, switch to the Profiles tab and click Add.
   
4. In the Authentication Schema field, click the pencil icon.
   
5. Click the LoginSchema folder to see the files in it.
   
6. Select one of the files. You can see a preview on the right. The labels can be changed by editing the file under /nsconfig/loginschema/LoginSchema/.
   
7. On the top right, click Select.
   
8. Give the Login Schema a name.
   
9. You typically need to use the entered credentials elsewhere. For example, you might need to use the username and one of the passwords to later Single Sign-on to StoreFront. Near the bottom of the Login Schema Profile, enter unique values for the indexes. These values can be between 1 and 16.
10. You can also configure these values on your noschema profiles so that passwords received from a previous factor can be put into a different Index.
    
11. Later you reference these index values in a Traffic Policy/Profile by using the expression HTTP.REQ.USER.ATTRIBUTE(#).
    
12. Click Create.
    
13. Note: if you later edit the Login Schema .xml file, the changes might not be reflected until you edit the Login Schema Profile and select the .xml file again

Login Schema Policy

Login Schemas can be bound directly to a AAA Virtual Server. If one of the Advanced Authentication policies bound directly to the AAA Virtual Server is forms-based, then bind the Login Schema directly to the AAA Virtual Server. If you are binding the Login Schema directly to a AAA Virtual Server, then you must first create a Login Schema Policy expression that is linked to the Login Schema Profile.

Or Login Schemas can be bound to an Authentication Policy Label (described later). If you are binding a Login Schema to an Authentication Policy Label, then there’s no need to create a Login Schema policy expression.

To create and bind a Login Schema Policy:

1. On the left, go to Security > AAA > Login Schema.
2. On the right, switch to the Policies tab and click Add.
   
3. Use the Profile drop-down to select the Login Schema Profile you already created.
4. Enter a Default Syntax expression in the Rule box and click Create.
   
5. On the left, go to Security > AAA > Virtual Servers and edit an existing AAA Virtual Server.
   
6. On the right, in the Advanced Settings column, click Login Schemas.
   
7. On the left, in the Login Schemas section, click where it says No Login Schemas.
   
8. Click to select.
   
9. Select the Login Schema policy and click Select. Only Login Schema Policies appear in this list. Login Schema Profiles (without a policy) do not appear.
   
10. Click Bind.
    

Advanced Authentication Policies

Authentication policies are a combination of policy expression and policy action. If the expression is true, then evaluate the action.

The Action is always an authentication server (LDAP, RADIUS, etc.).

The policy expression can be either in classic syntax, or in the newer default syntax.

The policy type is either Basic or Advanced. Basic policies can only use classic syntax. Advanced policies only use the newer default syntax. Both types of policies use the same Actions (authentication servers).

nFactor requires Advanced Authentication Policies; Basic policies won’t work.

Create Advanced Authentication Policy

You will need Authentication Actions/Servers (e.g. LDAP, RADIUS, CERT, SAML, etc.)

When creating an Advanced Authentication Policy, there’s a plus icon that lets you create Authentication Actions/Servers.

Or you can create Authentication Actions prior to creating the Advanced Authentication Policy. The Authentication Actions are located under the Security > AAA > Policies > Basic Policies > <Action Type> node. On the right, switch to the Servers tab to create the Actions/Servers. Once the Actions are created, use the instructions below to create the Advanced Authentication Policy. There’s no need to create a Basic Authentication Policy.

To create an Advanced Authentication Policy:

1. Go to Security > AAA > Authentication > Advanced Policies > Policy.
   
2. On the right, click Add. You typically create at least one Authentication Policy for each Factor. When you create multiple Authentication Policies for one Factor, NetScaler checks each policy in priority order until one of them succeeds.
   
3. Use the Action Type drop-down to select the Action Type (e.g. LDAP). The Action Type depends on your nFactor flow design.
   
4. If you don’t currently have any Actions configured, of if you want to create a new one, click the plus icon next to the Action drop-down. The Actions/Servers are created in the normal fashion.
   
5. In the Expression box, enter an expression using the Default Syntax. ns_true won’t work because that’s Classic syntax. There’s an Expression Editor link on the right. Or hit Ctrl+Space to see your options. true is a valid Default expression. Click Create when done.
6. Create more Advanced Authentication Policies as needed for your nFactor design.
   

Bind Advanced Authentication Policy to AAA

Only the Advanced Authentication Policies for the first Factor are bound directly to the AAA Virtual Server. The Advanced Authentication Policies for the remaining Factors are bound to Authentication Policy Labels as detailed in the next section.

1. Go to Security > AAA > Virtual Servers.
2. Edit an existing AAA Virtual Server.
   
3. On the left, in the Advanced Authentication Policies section, click where it says No Authentication Policy.
   
4. Click to select.
   
5. Select the Advanced Authentication Policy and click Select.
   
6. The Select Next Factor field can optionally point to an Authentication Policy Label as detailed in the next section. The Next Factor is only evaluated if this Advanced Authentication Policy succeeds.
7. If this Advanced Authentication Policy fails, then the Goto Expression determines what happens next. If it is set to NEXT, then the next Advanced Authentication Policy bound to this Factor is evaluated. If it is set to END, of if there are no more Advanced Authentication Policies bound to this Factor, then authentication is finished and marked as failed.
8. Click Bind.
   

LDAP Group Extraction

Sometimes you only want to extract a user’s groups from Active Directory but have don’t actually want to authenticate with LDAP. These groups can then be used to select the next authentication Factor.

To configure an LDAP Action/Server for only group extraction:

1. Make sure Authentication is unchecked.
   
2. Make sure the Group Attribute and Sub Attribute Name are filled in.
   

Authentication Policy Label

When configuring the first Factor, you bind two objects to the AAA Virtual Server:

• Login schema – for forms-based authentication
• Advanced Authentication Policy

When binding the Advanced Authentication Policy to the AAA Virtual Server, there’s a field to Select Next Factor. If the Advanced Authentication Policy succeeds, then the Next Factor is evaluated.

The Next Factor is actually an Authentication Policy Label.

Authentication Policy Labels contain three objects:

• Login Schema
• Advanced Authentication Policies
• Next Factor – the next Authentication Policy Label

Here’s the flow:

1. User connects to AAA or NetScaler Gateway Virtual Server.
2. If forms-based authentication, the Login Schema bound to the AAA Virtual Server is displayed.
3. Advanced Authentication Policies bound to the AAA Virtual Server are evaluated.
   1. If the Advanced Authentication Policy is successful, go to the configured Next Factor, which is an Authentication Policy Label.
      1. If Next Factor is not configured, then authentication is complete and successful.
   2. If the Advanced Authentication Policy fails, and if Goto Expression is Next, then evaluate the next bound Advanced Authentication Policy.
   3. If none of the Advanced Authentication Policies are successful, then authentication failed.
4. If the Next Factor Authentication Policy Label has a Login Schema bound to it, display it to the user.
5. Evaluate the Advanced Authentication Policies bound to the Next Factor Authentication Policy Label.
   1. If the Advanced Authentication Policy is successful, go to the configured Next Factor, which is an Authentication Policy Label.
      1. If Next Factor is not configured, then authentication is complete and successful.
   2. If the Advanced Authentication Policy fails, and if Goto Expression is Next, then evaluate the next bound Advanced Authentication Policy.
   3. If none of the Advanced Authentication Policies are successful, then authentication failed.
6. Continue evaluating the Next Factor Authentication Policy Label until authentication succeeds or fails. You can chain together an unlimited number of Authentication Policy Labels.

If you are binding a Login Schema to an Authentication Policy Label, then you only need the Login Schema Profile. There’s no need to create a Login Schema Policy.

Not every Factor needs a Login Schema (logon page). It’s possible for a prior Factor to gather all of the credential information and simply pass it on to the next Factor. If you don’t need a Login Schema for a particular Authentication Policy Label, simply select LSCHEMA_INT, which is mapped to noschema. Or create a new Login Schema Profile based on noschema.

Create Authentication Policy Label

To create an Authentication Policy Label:

1. Authentication Policy Labels are configured at Security > AAA > Policies > Authentication > Advanced Policies > PolicyLabel.
   
2. On the right, click Add.
   
3. Give the Policy Label a name.
4. Select a Login Schema Profile. This can be one that is set to noschema if you don’t actually want to display anything to the user. Then click Continue.
   
5. In the Policy Binding section, Click to select.
   
6. Select an Advanced Authentication Policy that evaluates this Factor. Click Select.
   
7. Use the Goto Expression drop-down to select NEXT or END. If you want to bind more Advanced Authentication Policies to this Factor, then select NEXT.
   
8. In the Select Next Factor field, if you chain another Factor, Click to select and bind the next Authentication Policy Label (Next Factor).
9. Or don’t select anything, and if this Advanced Authentication Policy succeeds, then authentication is successful and complete. This ends the chaining.
   
10. Click Bind when done.
    
11. You can click Add Binding to add more Advanced Authentication Policies to this Policy Label (Factor). Or you can bind Advanced Authentication Policies to the next Policy Label (Next Factor). Click Done.
    

Bind Authentication Policy Label

Once the Policy Label (Factor) is created, you bind it to an existing Advanced Authentication Policy binding. This is how you chain Factors together.

1. Either edit an existing AAA Virtual Server that has an Advanced Authentication Policy already bound to it.
2. Or edit a different Authentication Policy Label.
   
3. On the left, in the Advanced Authentication Policies section, click the bindings.
   
4. Right-click an existing binding and click Edit Binding.
   
5. In the Select Next Factor field, Click to select.
   
6. Select the Policy Label for the Next Factor and click Select.
   
7. Click Bind.
   
8. Click Done.
   

nFactor for NetScaler Gateway

AAA Authentication Profile

Authentication Profile lets you bind a AAA Virtual Server to NetScaler Gateway. This is what enables nFactor on NetScaler Gateway.

1. Go to Security > AAA > Authentication Profile.
   
2. On the right, click Add.
   
3. Give the Authentication Profile a name.
4. In the Authentication Host field, it wants a URL to redirect users to your AAA Virtual Server. If you do this configuration from the CLI then this field is optional. But in the GUI it is required. NetScaler Gateway does not need to redirect so it doesn’t matter what you enter here.
5. In the Authentication Virtual Server field, Click to select.
   
6. Select the AAA Virtual Server that has Login Schema, Advanced Authentication Policy, and Authentication Policy Labels configured. The AAA Virtual Server does not need an IP address. Click Select.
   
7. Then click Create.
   
8. Go to NetScaler Gateway > Virtual Servers.
   
9. On the right, edit an existing Gateway Virtual Server.
   
10. In the Basic Settings section, click the pencil icon.
    
11. Click More.
    
12. Use the Authentication Profile drop-down to select the Authentication Profile you just created.
    
13. If one of your Factors is client certificates, then you’ll need to configure SSL Parameters and CA certificate as detailed in the next section.
14. When you browse to your Gateway, you’ll see the nFactor authentication screens.
    

Gateway Client Certificate Authentication

If one of your authentication Factors is certificate, then you must perform some SSL configuration on the NetScaler Gateway Virtual Server:

1. Go to Traffic Management > SSL > Certificates and install the root certificate for the issuer of the client certificates. Certificate Authority certificates do not need key files.
   
2. Go to NetScaler Gateway > Virtual Servers, and edit an existing NetScaler Gateway Virtual Server that is enabled for nFactor.
   
3. On the left, in the SSL Parameters section, click the pencil icon.
   
4. Check the box next to Client Authentication.
5. Make sure Client Certificate drop-down is set to Optional, and click OK.
   
6. On the left, in the Certificates section, click where it says No CA Certificate.
   
7. Click to select.
   
8. Select the root certificate for the issuer of the client certificates and click Select.
   
9. Click Bind.
   

nFactor Single Sign-on to StoreFront

When performing Single Sign-on to StoreFront, nFactor defaults to using the last entered password. If LDAP is not the last entered password, then you need to create a Traffic Policy/Profile to override the default nFactor behavior.

1. Go to NetScaler Gateway > Policies > Traffic.
   
2. On the right, switch to the Traffic Profiles tab.
3. Click Add.
   
4. Give the Traffic Profile a name.
5. In the Protocol section, select HTTP. Scroll down.
   
6. In the SSO Expression fields, enter an HTTP.REQ.USER.ATTRIBUTE(#) expression that matches the indexes specified in the Login Schema.
7. Click Create.
   
8. On the right, switch to the Traffic Policies tab and click Add.
   
9. Give the policy a name.
10. Select the previously created Traffic Profile.
11. Enter a classic expression (e.g. ns_true) and click Create.
    
12. Edit an existing NetScaler Gateway Virtual Server.
    
    
13. Scroll down to the Policies section and click the plus icon.
    
14. Select Traffic > Request and click Continue.
    
15. Select the previously created Traffic Policy.
    
    
16. Bind the Traffic Policy.
    

Sample Configurations

From Citrix Docs: Sample deployments using nFactor authentication:

• Getting two passwords up-front, pass-through in next factor. Read
• Group extraction followed by certificate or LDAP authentication, based on group membership. Read
• SAML followed by LDAP or certificate authentication, based on attributes extracted during SAML.Read
• SAML in first factor, followed by group extraction, and then LDAP or certificate authentication, based on groups extracted. Read
• Prefilling user name from certificate. Read
• Certificate authentication followed by group extraction for 401 enabled traffic management virtual servers. Read
• Username and 2 passwords with group extraction in third factor.Read
• Certificate fallback to LDAP in same cascade; one virtual server for both certificate and LDAP authentication. Read
• LDAP in first factor and WebAuth in second factor.Read
• Domain drop down in first factor, then different policy evaluations based on group.Read

Certificate auth: If Successful, LDAP only. If Failure, LDAP+RADIUS

This scenario is described in Citrix Blog Post Configuration Notes on nFactor

The authentication process flows like this:

1. User connects to NetScaler Gateway.
2. NetScaler Gateway asks user for certificate.
3. If user selects a certificate, NetScaler Gateway compares certificate signature to the CA certificate that is bound to the NetScaler Gateway. If it doesn’t match, then user certificate is ignored.
4. Bound to the NetScaler Gateway Virtual Server is an Authentication Profile, which links NetScaler Gateway to AAA nFactor.
5. Certificate authentication: The lowest priority number authentication policy on the AAA Virtual Server is Certificate. If there’s a valid user certificate:
   1. Extract the user’s userPrincipalName from the certificate.
   2. Next Factor = policy label that displays a logon screen (Single-factor Login Schema)
   3. The username field is pre-populated with the userPrincipalName attribute extracted from the certificate.
   4. User is prompted to enter the LDAP password only.
   5. LDAP policy/server is configured to use userPrincipalName to login to LDAP.
   6. If successful, NetScaler Gateway authentication is complete. Next step is to Single Sign-on to StoreFront.
   7. If LDAP authentication fails, then NetScaler Gateway authentication fails, and the user is prompted to try LDAP-only authentication again.
6. LDAP authentication: If certificate authentication fails, try next authentication policy bound to the AAA Virtual Server, which is a different LDAP Policy.
   1. Bound to the AAA Virtual Server is a Dual Factor Login Schema that asks for username, LDAP password, and RADIUS password.
   2. LDAP policy/server is configured to use sAMAccountName to login to LDAP. SAMAccountName means users don’t have to enter full userPrincipalName.
   3. If LDAP authentication is successful:
      2. Put username in Credential Index 1 and put password in Credential Index 2. These will later be used by a Traffic Policy to Single Sign-on to StoreFront.
      3. Proceed to next factor (Policy Label), which is RADIUS.
   4. If LDAP authentication fails, NetScaler Gateway login fails, and the user is prompted to try two-factor authentication again.
7. RADIUS authentication: the second factor Policy Label is configured with Noschema. This means no additional logon form is displayed because the RADIUS password was already collected in the previous factor.
   1. When multiple passwords are collected, they are tried in order. The first password was used by the previous factor. The second password is tried by this factor (Policy Label).
   2. RADIUS policy/profile attempts authentication.
   3. If RADIUS authentication is successful, NetScaler Gateway authentication is complete. Next step is Single Sign-on to StoreFront.
   4. If RADIUS authentication fails, NetScaler Gateway login fails, and the user is prompted to try two-factor authentication again.
8. Single Sign-on to StoreFront: NetScaler Gateway uses the last password collected by nFactor to Single Sign-on with StoreFront. If the last password is LDAP, then no additional configuration is needed. If the last password is not LDAP, then a Traffic Policy/Profile is needed.
   1. Bound to the NetScaler Gateway Virtual Server is a Traffic Policy.
   2. The Traffic Policy/Profile users Credential Index 1 for username and Credential Index 2 for Password. These are the same indexes configured in the Dual Factor Login Schema.

The order of configuration doesn’t match the authentication flow because some objects have to be created before others.

# Create Auth vServer, bind server cert, bind CA cert for client certificates
# Enable Optional client certificates
add authentication vserver nFactorAAA SSL 0.0.0.0 443 -AuthenticationDomain corp.com
bind ssl vserver nFactorAAA -certkeyName WildCorpCom
bind ssl vserver nFactorAAA -certkeyName CorpRoot -CA -ocspCheck Optional
set ssl vserver nFactorAAA -clientAuth ENABLED -clientCert Optional -ssl3 DISABLED

# Create auth policy for LDAP-UPN
add authentication ldapAction Corp-UserPrincipalName -serverIP 10.2.2.220 -serverPort 636 -ldapBase "dc=corp,dc=local" -ldapBindDn "corp\\ctxsvc" -ldapBindDnPassword "MyPassword" -ldapLoginName userPrincipalName -groupAttrName memberOf -subAttributeName CN -secType SSL -passwdChange ENABLED
add authentication Policy Corp-UserPrincipalName -rule true -action Corp-UserPrincipalName

# Create PolicyLabel LDAPPasswordOnly with Single-factor Login Schema
add authentication loginSchema SingleAuth -authenticationSchema "/nsconfig/loginschema/LoginSchema/SingleAuth-Corp.xml"
add authentication policylabel LDAPPasswordOnly -loginSchema SingleAuth
bind authentication policylabel LDAPPasswordOnly -policyName Corp-UserPrincipalName -priority 100 -gotoPriorityExpression NEXT

# Create Cert policy and bind to AAA vServer with LDAPPasswordOnly PolicyLabel as Next Factor
# Cert policy must have lower priority number than LDAP-SAM policy
add authentication certAction Cert_Auth_Profile -userNameField SubjectAltName:PrincipalName
add authentication Policy Cert_Auth_Policy -rule true -action Cert_Auth_Profile
bind authentication vserver nFactorAAA -policy Cert_Auth_Policy -priority 100 -nextFactor LDAPPasswordOnly -gotoPriorityExpression NEXT

# Create LDAP-SAM Auth Policy
add authentication ldapAction Corp-Gateway -serverIP 10.2.2.220 -serverPort 636 -ldapBase "dc=corp,dc=local" -ldapBindDn "corp\\ctxsvc" -ldapBindDnPassword "MyPassword" -ldapLoginName samaccountname -groupAttrName memberOf -subAttributeName CN -secType SSL -passwdChange ENABLED
add authentication Policy Corp-SAMAccountName -rule true -action Corp-Gateway

# Create RADIUS Auth Policy
add authentication radiusAction RADIUS-Action -serverIP 10.2.2.42 -serverPort 1812 -radKey MyKey
add authentication Policy RADIUS-Policy -rule true -action RADIUS-Action

# Create Dual-factor Login Schema and bind directly to AAA vServer
# This Login Schema is only shown if Cert auth fails
add authentication loginSchema DualAuth -authenticationSchema "/nsconfig/loginschema/LoginSchema/DualAuth.xml" -userCredentialIndex 1 -passwordCredentialIndex 2
add authentication loginSchemaPolicy DualAuth -rule true -action DualAuth
bind authentication vserver nFactorAAA -policy DualAuth -priority 100 -gotoPriorityExpression END

# Create RADIUS Policy Label with noschema and RADIUS Auth Policy
add authentication loginSchema Noschema -authenticationSchema noschema
add authentication policylabel NoSchema-RADIUS -loginSchema Noschema
bind authentication policylabel NoSchema-RADIUS -policyName RADIUS-Policy -priority 100 -gotoPriorityExpression NEXT

# Bind LDAP-SAM Auth Policy to AAA vServer with RADIUS as next factor
# LDAP-SAM Auth Policy must have higher priority number than Cert Policy
bind authentication vserver nFactorAAA -policy Corp-SAMAccountName -priority 110 -nextFactor NoSchema-RADIUS -gotoPriorityExpression NEXT

# Create Authentication Profile to link AAA with Gateway. Bind to Gateway.
add authentication authnProfile nFactor -authnVsName nFactorAAA -AuthenticationHost aaa.corp.com
add vpn vserver gateway.corp.com SSL 10.2.2.220 443 -icaOnly ON -dtls ON -Listenpolicy NONE -tcpProfileName nstcp_default_XA_XD_profile -appflowLog ENABLED -authnProfile nFactor

# Enable Optional Client certs on Gateway
set ssl vserver gateway.corp.com -clientAuth ENABLED -clientCert Optional -ssl3 DISABLED
bind ssl vserver gateway.corp.com -certkeyName CorpRoot -CA -ocspCheck Optional

# Create Traffic Policy to SSON to StoreFront. Bind to Gateway.
add vpn trafficAction nFactorSSO http -kcdAccount NONE -userExpression "http.req.user.attribute(1)" -passwdExpression "http.req.user.attribute(2)"
add vpn trafficPolicy nFactorSSO ns_true nFactorSSO
bind vpn vserver gateway.corp.com -policy nFactorSSO -priority 100

Navigation

• Overview
• Prerequisites
• Create Session Profile
• Create Session Policy
• Bind Session Policy
• NetScaler Gateway Plug-in Installation
• Authorization Policies
• Intranet Applications
• DNS Suffix
• Bookmarks
• VPN Client IP Pools (Intranet IPs)
• StoreFront in Gateway Portal
• Quarantine Group  💡

💡 = Recently Updated

Overview

NetScaler Gateway supports five different connection methods:

• ICA Proxy to XenApp/XenDesktop – client is built into Citrix Receiver
• SSL VPN – requires NetScaler Gateway plug-in
• Clientless – browser only, no VPN client, uses rewrite
• Secure Browse – from MDX-wrapped mobile applications (XenMobile), uses rewrite
• RDP Proxy – only RDP client is needed

If Endpoint Analysis is configured, then an Endpoint Analysis plug-in is downloaded to the Windows or Mac client.

Users use SSL to connect to NetScaler Gateway Virtual Servers.

• NetScaler Gateway prompts the user for authentication.
• Once the user is authenticated, NetScaler Gateway uses Session Policies to determine what happens next.

You can configure NetScaler Gateway Session Policies to only use one of the connection methods. Or NetScaler Gateway can be configured to let users choose between ICA Proxy, Clientless, and SSL VPN connection methods. Here’s a sample Client Choices screen using the X1 theme:

Enable SSL VPN in a Session Policy as detailed later. Then configure additional NetScaler Gateway objects including the following:

• DNS Servers and Suffix – enable DNS resolution across the VPN tunnel
• NetScaler Gateway Universal Licenses – all VPN users must be licensed.
• Intranet IP addresses – give IP addresses to VPN clients. If no client IP, then VPN clients use NetScaler SNIP to communicate with internal resources. Requires routing changes on internal network.
• Intranet Applications – if split tunnel is enabled, configure this object to dictate what traffic goes across the tunnel and which traffic stays local.
• Authorization Policies – if default authorization is DENY, use Authorization Policies to dictate what resources can be accessed across the NetScaler Gateway connection. These Authorization Policies apply to all NetScaler Gateway connections, not just VPN.
• Bookmarks – displayed on the built-in NetScaler Gateway portal page. Users click bookmarks to access resources across the VPN tunnel or clientless access (rewrite).
• Endpoint Analysis Scans – block endpoints that fail security requirements. Configured in Session Policies or Preauthentication Policies.
• Traffic Policies – Single Sign-on to internal web applications
• AAA Groups – bind Session Policies, Authorization Policies, Intranet Applications, Intranet IPs, Bookmarks, and Traffic Policies to one or more Active Directory groups. Allows different Active Directory groups to have different NetScaler Gateway configurations.

Prerequisites

Except for ICA Proxy, all NetScaler Gateway connection methods require a NetScaler Gateway Universal License for each concurrent session. Go to System > Licenses and make sure NetScaler Gateway User licenses are installed.

Also make sure the maximum AAA users equals the number of licenses. Go to NetScaler Gateway > Global Settings > Change authentication AAA settings.

DNS usually needs to function across the VPN tunnel. Go to Traffic Management > DNS > Name Servers to add DNS servers.

Create Session Profile

You can create multiple Session Policy/Profiles, each with different settings. Then you can bind these Session Policies to different AAA groups or different NetScaler Gateway Virtual Servers. You can also bind Endpoint Analysis expressions to a Session Policy so that the Session Policy only applies to machines that pass the Endpoint Analysis scan.

If multiple Session Policies apply to a particular connection, then the settings in the policies are merged. For conflicting settings, the Session Policy with the highest priority (lowest priority number) wins. Session Policies bound to AAA groups only override Session Policies bound to NetScaler Gateway Virtual Servers if the AAA group bind point has a lower priority number. In other words, priority numbers are evaluated globally no matter where the Session Policy is bound. You can run the command nsconmsg –d current –g pol_hits to see which Session Policies are applying to a particular connection.

Do the following to enable SSL VPN. First create the Session Profile. Then create a Session Policy.

1. On the left, expand NetScaler Gateway, expand Policies, and click Session.
   
2. On the right, switch to the Session Profiles tab and click Add.
   
3. Name the profile VPN or similar.
4. In Session Profiles, every line has an Override Global checkbox to the right of it. If you check this box next to a particular field, then the field in this session profile will override settings configured globally or in a lower priority session policy.
   
5. Switch to the Network Configuration tab and check the box next to Advanced Settings.
6. You will find a setting that lets you select a DNS Virtual Server. Or if you don’t select anything then the tunnel will use the DNS servers configured under Traffic Management > DNS > Name Servers.
7. Configure the behavior when there are more VPN clients than available IPs in the address pool. This only applies if you are configuring Intranet IPs.
8. There are also a couple timeouts lower on the page.
   
9. Switch to the Client Experience tab. This tab contains most of the NetScaler Gateway VPN settings.
   
10. Override Plug-in Type and set it to Windows/Mac OS X.
    
11. Whenever NetScaler firmware is upgraded, all users will be prompted to upgrade their VPN clients. You can use the Upgrade drop-downs to disable the automatic upgrade.
    
12. By default, if Receiver and NetScaler Gateway Plug-in are installed on the same machine, then the icons are merged. To see the NetScaler Gateway Plug-in Settings, you right-click Receiver, open Advanced Preferences and then click NetScaler Gateway Settings.
    
    
13. You can configure the Session Policy/Profile to prevent NetScaler Gateway Plug-in from merging with Receiver. On the Client Experience tab, scroll down and check the box next to Advanced Settings.
    
14. Check the box next to Show VPN Plugin-in icon with Receiver. This causes the two icons to be displayed separately thus making it easier to access the NetScaler Gateway Plug-in settings.
    
    
15. On the Client Experience tab, override Split Tunnel and make your choice. Setting it to Off will force all traffic to use the tunnel. Setting it to On will require you to create Intranet Applications so the NetScaler Gateway Plug-in will know which traffic goes through the tunnel and which traffic goes directly out the client NIC (e.g. to the Internet).
    
16. On the Client Experience tab, there are timers that can be configured. Global Settings contains default timers so you might want to override the defaults and increase the timeouts. See Configuring Time-Out Settings at Citrix Docs for details.
    1. Client Idle Time-out is a NetScaler Gateway Plug-in timer that disconnects the session if there is no user activity (mouse, keyboard) on the client machine.
    2. Session Time-out disconnects the session if there is no network activity for this duration.
       
    3. In addition to these two timers on the Client Experience tab, on the Network Configuration tab, under Advanced Settings, there’s a Forced Timeout setting.
       
17. By default, once the VPN tunnel is established, a 3-page interface appears containing bookmarks, file shares, and StoreFront. An example of the three-page interface in the X1 theme is shown below.
    
18. On the Client Experience tab, the Home Page field lets you override the 3-page interface and instead display a different webpage (e.g. Intranet or StoreFront). This homepage is displayed after the VPN tunnel is established (or immediately if connecting using Clientless Access).
    
19. On the Client Experience tab, there are more settings that control the behavior of the NetScaler Gateway plug-in. Hover your mouse over the question marks to see what they do.
    
20. Additional VPN settings can be found by clicking Advanced Settings near the bottom of the Client Experience tab.
    
21. Under Client Experience > Advanced Settings, on the General tab, there are settings to run a login script at login, enable/disable Split DNS, and enable Local LAN Access. Use the question marks to see what they do. Reliable DNS occurs when Split DNS is set to Remote.
    
22. Under Client Experience > Advanced Settings, on the General tab, is a checkbox for Client Choices. This lets the user decide if they want VPN, Clientless, or ICA Proxy (StoreFront). Without Client Choices, the VPN will launch automatically
    
23. On the main Client Experience tab, if you enabled Client Choices, you can set Clientless Access to Allow to add Clientless to the list of available connection methods.
    
24. An example of Client Choices is shown below:
    
25. The Client Experience > Advanced Settings section has additional tabs for controlling the NetScaler Gateway Plug-in. A commonly configured tab is Proxy so you can enable a proxy server for VPN users.
    
26. Back in the main Session Profile, switch to the Security tab.
27. Set the default authorization to Allow or Deny. If Deny (recommended), you will need to create authorization policies to allow traffic across the tunnel. You can later create different authorization policies for different groups of users.
    
28. On the Published Applications tab, set ICA Proxy to Off. This ensures VPN is used instead of ICA Proxy.
29. Configure the Web Interface Address to embed StoreFront into the 3-pane default portal page. Note: additional iFrame configuration is required on the StoreFront side as detailed below.
30. From Michael Krasnove: if you configured the Session Policy to direct users to StoreFront, then placing the following code in c:\inetpub\wwwroot\Citrix\StoreWeb\custom\script.js will cause StoreFront to end the VPN tunnel when the user logs off of StoreFront.

    var LOGOFF_REDIRECT_URL = 'https://YourGatewayFQDN.com/cgi/logout';
     
    // Prevent the default "logoff" screen from being displayed
    CTXS.Controllers.LogoffController.prototype._handleLogoffResult = $.noop;
     
    CTXS.Extensions.afterWebLogoffComplete = function () {
     window.location.href = LOGOFF_REDIRECT_URL;
    };

31. Click Create when you’re done creating the Session Profile.
    

Create Session Policy

1. In the right pane, switch to the Session Policies tab and click Add.
   
2. Give the policy a descriptive name.
3. Change the Action to the VPN Profile you just created.
   
4. Add a policy expression. You can enter ns_true, which applies to all connections.
   
5. Or you can add Endpoint Analysis scans. If the Endpoint Analysis scan succeeds, then the session policy is applied. If the Endpoint Analysis scan fails, then this session policy is skipped and the next one is evaluated. This is how you can allow VPN if EPA scan succeeds but all failed EPA scans will get a different session policy that only has ICA Proxy enabled.
6. To add an Endpoint Analysis scan, use one of the Editor links on the right.
   
7. Configure OPSWAT scans in the OPSWAT EPA Editor.
   
8. Configure Client Security Expressions in the Expression Editor.
   
9. You can combine multiple Endpoint Analysis scan expressions using Booleans (&&, ||, !). Click Create when done.

Bind Session Policy

Most of the NetScaler Gateway objects can be bound to NetScaler Gateway Virtual Server, AAA Group, or both. This section details Session Policies, but the other NetScaler Gateway objects (e.g. Authorization Policies) can be bound using similar instructions.

1. Bind the new session policy to a NetScaler Gateway Virtual Server or a AAA group. If you bind it only to a AAA group, then only members of that Active Directory group will evaluate the expression.
2. To bind to a NetScaler Gateway Virtual Server, edit a NetScaler Gateway Virtual Server (or create a new one), scroll down to the Policies section and click the Plus icon.
   
3. In the Choose Type page, select Session, Request and click Continue.
   
4. Select one or more session policies. This is where you specify a priority.
   
5. To bind to a AAA Group, go to NetScaler Gateway > User Administration > AAA Groups.
   
6. Add a group with the same name (case sensitive) as the Active Directory group name. This assumes your LDAP policies/server are configured for group extraction.
7. Edit the AAA Group.
   
8. On the right, in the Advanced Settings column, add the Policies section.
   
9. Click the plus icon to bind one or more Session Policies.
10. If you want these Session Policies to override the Session Policies bound to the NetScaler Gateway Virtual Server then make sure the Session Policies bound to the AAA Group have lower priority numbers.
    
    

NetScaler Gateway Plug-in Installation

Here is what the user sees when launching the VPN session for the first time.

And then the 3-pane interface is displayed.

Only administrators can install the NetScaler Gateway Plug-in. You can download the Gateway plug-in from the NetScaler at /var/netscaler/gui/vpns/scripts/vista and push it to corporate-managed machines. Or you can download VPN clients from Citrix.com. The VPN client version must match the NetScaler firmware version.

Authorization Policies

If your Session Profile has Security tab > Default Authorization set to Deny (recommended), then create Authorization Policies to allow access across the tunnel.

1. On the left, under NetScaler Gateway, expand Policies and click Authorization.
   
2. On the right, click Add.
   
3. Name the Authorization Policy.
4. Select Allow or Deny.
5. NetScaler Gateway requires you to Switch to Classic Syntax. The other syntax option is for AAA.
   
6. Enter an expression. Use the Expression Editor link to build an expression. You can specify destination IP subnets, destination port numbers, etc.
7. Click Create when done.
   
8. Authorization Policies are usually bound to AAA groups. This allows different groups to have different access across the tunnel.
9. On the right, in the Advanced Settings column, add the Authorization Policies section.
   
10. Then click where it says No Authorization Policy to bind policies.
    

Intranet Applications

If you enabled Split Tunnel, then you’ll need to create Intranet Applications to specify which traffic goes through the tunnel.

1. On the left, under NetScaler Gateway, expand Resources and click Intranet Applications.
   
2. On the right, click Add.
   
3. Enter a name for the Internal subnet.
4. Change the Interception Mode to TRANSPARENT.
5. Enter an IP subnet. Only packets destined for this network go across the tunnel.
6. Then click Create.
7. Create additional Intranet applications for each internal subnet.
   
8. Intranet Applications are usually bound to the Gateway Virtual Server but you can also bind them to AAA Groups.
9. On the right, in the Advanced Settings column, add the Intranet Applications section.
   
10. On the left, click No Intranet Application to bind Intranet Applications.
    

DNS Suffix

Specify a DNS Suffix for Split DNS to function with single label DNS names.

1. On the left, under NetScaler Gateway, expand Resources and click DNS Suffix.
   
2. On the right, click Add.
   
3. Enter the DNS Suffix and click Create. You can add multiple suffixes.
   

Bookmarks

Bookmarks are the links that are displayed in the 3-pane interface. They can point to file shares or websites.

1. Under NetScaler Gateway, expand Resources, and click Bookmarks.
   
2. On the right, click Add.
   
3. Give the bookmark a name and display text.
4. Enter a website or file share. For file shares you can use %username%.
5. The other fields are for Single Sign-on through Unified Gateway. Click Create.
   
6. Bookmarks (aka Published Applications > Url) are usually bound to AAA groups so different groups can have different bookmarks. But it’s also possible to bind Bookmarks to NetScaler Gateway Virtual Servers.
7. If NetScaler Gateway Virtual Server, add the Published Applications section to bind Bookmarks.
   
8. For AAA Group, it’s the Bookmarks section.
   
9. On the left, find the Published Applications section and click No Url to bind Bookmarks.
   

VPN Client IP Pools (Intranet IPs)

By default, NetScaler Gateway VPN clients use NetScaler SNIP as their source IP when communicating with internal resources. To support IP Phones or endpoint management, you must instead assign IP addresses to VPN clients.

Any IP pool you add to NetScaler must be reachable from the internal network. Configure a static route on the upstream router. The reply traffic should be routed through a NetScaler SNIP. Or the NetScaler can participate in OSPF.

When a client is assigned a client IP, this IP address persists across multiple sessions until the appliance reboots or until the appliance runs out of IPs in the pool.

1. Edit a NetScaler Gateway Virtual Server or a AAA group.
2. On the right, in the Advanced Settings section, click the plus icon next to Intranet IP Addresses.
   
3. On the left, click where it says No Intranet IP.
   
4. Enter a subnet and netmask. Click Bind.
   
5. To see the Client IP address, on the client side, right-click the NetScaler Gateway Plug-in and click Configure NetScaler Gateway.
   
6. Switch to the Profile tab to see the Client IP address.
   
7. To see the client IP on the NetScaler, go to NetScaler Gateway and on the right is Active user sessions.
   
8. Select one of the views and click Continue.
   
9. The right column contains the Intranet IP.
   

StoreFront in Gateway Portal

1. If you want to enable StoreFront to integrate with NetScaler Gateway’s default portal, edit the file C:\Inetpub\wwwroot\Citrix\StoreWeb\web.config.
2. On the bottom, there are three sections containing frame options. Change all three of them from deny to allow.
3. Also change frame-ancestors from none to self.
   
4. In NetScaler, go to NetScaler Gateway > Global Settings and click Configure Domains for Clientless Access.
   
5. Change the selection to Allow Domains, enter your StoreFront FQDN and click the plus icon.
6. Click OK.
   
7. In a Session Policy/Profile, on the Client Experience tab, make sure Single Sign-on to Web Applications is enabled.
   
8. On the Published Applications tab, configure the Web Interface Address to point to the StoreFront Receiver for Web page.
9. Configure the Single Sign-on domain to match what’s configured in StoreFront.
   
10. The Applications page of the 3-page portal should automatically show the StoreFront published icons.
    

Quarantine Group

NetScaler Gateway can be configured so that if Endpoint Analysis scans fail, then the user is placed into a Quarantine Group. You can bind session policies, authorization policies, etc. to this quarantine group. Policies bound to other AAA groups are ignored.

1. Go to NetScaler Gateway > User Administration > AAA Groups.
2. Add a new local group for your Quarantined Users. This group is local and does not need to exist in Active Directory.
   
3. Create a new Session Profile.
4. On the Security tab, check the box next to Advanced Settings.
   
5. Check the box to the right of Client Security Check String.
6. Use the Editor links to add an Endpoint Analysis expression.
   
7. Just below the Client Security Check String, select the previously created Quarantine Group.
8. Click Create when done.
   
9. Create a Session Policy and select the Session Profile you just created.
10. Enter ns_true as the expression. Then click Create.
    
11. Edit your Gateway Virtual Server and bind the new session policy.
    
12. Bind session policies, authorization policies, etc. to your quarantine group. These policies typically limit access to the internal network so users can remediate. Or it might simply display a webpage telling users how to become compliant.
13. To troubleshoot Quarantine policies, use the command nsconmsg –d current –g pol_hits.
    
14. Another option is to use the session policy bound to the Quarantine Group for SmartAccess configuration.
15. Gateway Insight (Insight Center 11.0 build 65 and newer) shows users that failed EPA scans and their quarantine status.
    

Related Pages

• SmartAccess / SmartControl
• Back to NetScaler 11

RDP Proxy

NetScaler 10.5.e and NetScaler 11 support RDP Proxy through NetScaler Gateway. No VPN required. There are two ways of launching RDP sessions through NetScaler Gateway RDP Proxy:

• Bookmarks on the Clientless Access portal page.
• After logging in, change the URL in the browser to /rdpproxy/MyRDPServer. MyRDPServer can be IP or DNS.

You can have one Gateway vServer that authenticates the user and a different Gateway vServer to proxy the RDP connection. The Gateways use Secure Ticket Authority (STA) for mutual authentication. See Stateless RDP Proxy at docs.citrix.com for more information.  💡

Links:

• Kenny Baldwin blog post RDP-Proxy on NetScaler!
• Citrix Blog Post RDP Gateway on a NetScaler SSLVPN Virtual Server
• Citrix CTX200853 How to Configure RDP Profile on NetScaler Gateway
• RDP Proxy section in Unified Gateway FAQ at docs.citrix.com
• Anton van Pelt NetScaler Gateway = RD Gateway  💡

Here are some requirements for RDP Proxy:

• NetScaler Enterprise Edition or Platinum Edition.
• NetScaler Gateway Universal Licenses for each user.
• TCP 443 and TCP 3389 opened to the NetScaler Gateway Virtual Server.
• TCP 3389 opened from the NetScaler SNIP to the RDP Servers.

Do the following to configure RDP Proxy:

1. Expand NetScaler Gateway, expand Policies, right-click RDP and click Enable Feature.
   
2. Click RDP on the left. On the right, switch to the Client Profiles tab and click Add.
   
3. Give the Client Profile a name and configure it as desired. Scroll down.
   
4. In the RDP Host field, enter the FQDN that resolves to the RDP Proxy listener, which is typically the same FQDN as NetScaler Gateway.
5. Near the bottom is a Pre Shared Key. Enter a password and click OK. You’ll need this later.
   
6. On the right, switch to the Server Profiles tab and click Add.
   
7. Give the Server Profile a name.
8. Enter the IP of the Gateway Virtual Server you’re going to bind this to.
9. Enter the same Pre Shared Key you configured for the RDP Client Profile. Click Create.
   
10. If you want to  put RDP bookmarks on the Clientless Access portal page, on the left, expand NetScaler Gateway, expand Resources, and click Bookmarks.
11. Alternatively, Simon Gottschlag Publish RDP Proxy Link via StoreFront shows how NetScaler Rewrite can insert an RDP Proxy link into a StoreFront web page.  💡
    
12. On the right, click Add.
    
13. Give the Bookmark a name.
14. For the URL, enter rdp://MyRDPServer using IP or DNS.
15. Check the box next to Use NetScaler Gateway As a Reverse Proxy and click Create.
16. Create more bookmarks as desired.
    
17. Create or edit a session profile/policy.
18. On the Security tab, set Default Authorization Action to ALLOW. Or you can use Authorization policies to control access.
    
19. On the Remote Desktop tab, select the RDP Client Profile you created earlier.
    
20. If you want to use Bookmarks, on the Client Experience tab, set Clientless Access to On.
    
21. On the Published Applications tab, make sure ICA Proxy is OFF.
    
22. Edit or Create your Gateway Virtual Server.
23. In the Basic Settings section, click More.
    
24. Use the RDP Server Profile drop-down to select the RDP Server Profile you created earlier.
    
25. Scroll down. Make sure ICA Only is not checked.
    
26. Bind a certificate.
27. Bind authentication policies.
28. Bind the session policy/profile that has the RDP Client Profile configured.
    
29. You can bind Bookmarks to either the NetScaler Gateway Virtual Server or to a AAA group. To bind to the NetScaler Gateway Virtual Server, on the right, in the Advanced Settings section, click Published Applications.
    
30. On the left, in the Published Applications section, click where it says No Url.
    
31. Bind your Bookmarks.
    
32. Since this NetScaler Gateway Virtual Server has ICA Only unchecked, make sure your NetScaler Gateway Universal licenses are configured correctly. On the left, expand NetScaler Gateway and click Global Settings.
    
33. On the right, click Change authentication AAA settings.
    
34. Change the Maximum Number of Users to your licensed limit.
    
35. If you want to connect to RDP servers using DNS, make sure DNS servers are configured on the appliance (Traffic Management > DNS > Name Servers).
    
36. If you want to use the short names instead of FQDNs, add a DNS Suffix (Traffic Management > DNS > DNS Suffix).
    
37. Connect to your Gateway and login.
    
38. If you configured Bookmarks, simply click the Bookmark.
    
39. Or you can change the address bar to /rdpproxy/MyRDPServer. You can enter IP address (e.g. rdpproxy/192.168.1.50) or DNS names (/rdpproxy/myserver).
    
40. Then open the downloaded .rdp file.
    
41. You can view the currently connected users by going to NetScaler Gateway > Policies > RDP and on the right is the Connections tab.