nFactor – Certificate Fallback to LDAP in Same Cascade with One Virtual Server for Certificate and LDAP Authentication on Citrix ADC

Note: According to RFC6176 from Internet Engineering Task Force (ITEF), TLS servers must not support SSLv2. The NetScaler appliance does not support SSLv2 from release 12.1.

This article describes following scenario:

  1. 1st factor is configured for either Certificate or LDAP Authentication.

  2. If a user fails to present Certificate for Authentication, there is an option to fall down to LDAP Authentication.

  3. Only a single Authentication vserver is needed to configure both.

This section describes these steps in detail. The first section briefly introduces the entities that are encountered in this document, and in general for nFactor authentication. The next section pictographically demonstrates the flow. The following sections have example “LoginSchema” that can be used to realize the logon form, and the relevant configuration.

Entities used in nFactor

LoginSchema

Login Schema is an XML construct that is aimed at providing sufficient information to the UI tier so that it can generate user interface based on the information that is sent in this XML blob. LoginSchema is a logical representation of logon form in XML medium.

It can be added as:

add authentication loginSchema <name> -authenticationSchema <XML-Blob> -userExpression <Expression> ­-passwordExpression <Expression>

where authenticationSchema is a well-structured XML that defines the way login form is rendered. UserExpression is used to extract username from login attempt. Likewise passwordExpression is used to extract password.

Authentication Policylabel

Auth Policy label is a collection of authentication policies for a particular factor. It is recommended that these are pseudo-homogenous policies, which means, the credentials received from user apply to all the policies in the cascade. However, there are exceptions to this when a fallback option is configured or feedback mechanism is intended.

Authentication policy labels constitute secondary/user-defined factors. With nFactor, there’s no single “secondary” cascade. There could be “N” secondary factors based on configuration. There could be as many policy labels as desired and the number of factors for a given authentication is defined by the longest sequence of policylabels beginning with the vserver cascade.

When an authentication policy is bound to authentication vserver, specify nextFactor, which represents a policylabel/factor that would be taken if the policy succeeds. Likewise, when policies are bound to policylabels, nextFactor specifies the next policylabel to continue if the policy succeeds.

It can be added as:

add authentication policylabel <name> -loginSchema <loginSchemaName>

Where, loginSchemaName will be the login schema that we want to associate with this authentication factor.

We can bind authentication policies to this label:

bind authentication policylabel <name> -policy LDAP –priority 10 –nextfactor <nextFactorLabelName>

Use Case Description

  1. User accesses TM vserver and he is redirected to Authentication vserver.

  2. If User Certificate is present in the client device, he will see a prompt as below to select the certificate for authentication:

    User-added image

  3. Upon selecting the appropriate certificate, user will be authenticated and granted access to backend resource.

  4. Now in case if user Certificate is absent, then user will see a login page for LDAP authentication as below and on submitting the user credentials, he will be authenticated and granted access to backend resource.

    User-added image

Users see a login page with Username and Password field. The fields such as labels for username and password can be customized.

Here’s the example used for this specific representation of logon form:

<?xml version="1.0" encoding="UTF-8"?><AuthenticateResponse xmlns="http://citrix.com/authentication/response/1" ><Status >success </Status><Result >more-info</Result><StateContext/><AuthenticationRequirements><PostBack> /nf/auth/doAuthentication.do</PostBack ><CancelPostBack>/Citrix/Authentication/ExplicitForms/CancelAuthenticate</CancelPostBack><CancelButtonText>Cancel</CancelButtonText><Requirements><Requirement><Credential><ID>login</ID><SaveID>ExplicitForms-Username</SaveID><Type>username</Type></Credential><Label><Text>Enter Login Name:</Text><Type>plain</Type></Label><Input><AssistiveText>Please supply either username as saamaccountname</AssistiveText><Text><Secret>false</Secret><ReadOnly>false</ReadOnly><InitialValue></InitialValue><Constraint>.+</Constraint></Text></Input></Requirement><Requirement><Credential><ID>passwd</ID><SaveID>ExplicitForms-Password</SaveID><Type>password</Type></Credential><Label><Text>Password:</Text><Type>plain</Type></Label><Input><Text><Secret>true</Secret><ReadOnly>false</ReadOnly><InitialValue></InitialValue><Constraint>.+</Constraint></Text></Input></Requirement><Requirement><Credential><Type>none</Type></Credential><Label><Text> Hello , Please submit password to continue Login ...</Text><Type>confirmation</Type></Label><Input /></Requirement></Requirements></AuthenticationRequirements></AuthenticateResponse>

All the customizable portions of the logon form are highlighted here. Administrators can modify these values to suit their needs.

nFactor Flow Presentation


Policies for this use-case

add lb vserver lb_ssl SSL 10.217.28.166 443 -persistenceType NONE -cltTimeout 180 -AuthenticationHost auth.aaatm.com -Authentication ON -authnVsName avnadd authentication vserver avn SSL 10.217.28.167 443 -AuthenticationDomain aaatm.combind authentication vserver avn -policy <Certificate Auth Policy> -priority 1 -gotoPriorityExpression NEXTbind authentication vserver avn -policy <LDAP Auth Policy> -priority 2 -gotoPriorityExpression NEXT

The preceding configuration describes adding a TM vserver for resource access, adding Authentication vserver for securing TM vserver, and relevant policies for this use-case. Portions highlighted in “yellow” are to replaced with appropriate authentication policies by the administrators.

The GOTO Priority expression by default is NEXT, so that we fall down to the next policy if it fails.

Certificate and LDAP Policy Configuration

The following is an examples of certificate and LDAP policy configuration:

add authentication certAction ca -userNameField SubjectAltName:PrincipalName

add authenticationpolicy cert -rule true -action ca

add authentication ldapAction ldap-new -serverIP 10.217.28.180 -ldapBase “cn=users,dc=aaatm,dc=com” -ldapBindDn administrator@aaatm.com -ldapBindDnPassword 1.linux -ldapLoginName sAMAccountName -groupattrName memberof -subAttributeName CN

add authenticationpolicy ldap-new -rule true -action ldap-new

Configuration Through Visualizer

1. Go To Security > AAA-Application Traffic > nFactor Visualizer > nFactor Flow and click on Add

2. Click on the + sign to add the nFactor Flow


3. Add Factor, this will be the name of the nFactor Flow


4. No schema needs to be selected for this configuration as the Cert Authentication doesn’t require a login schema and if the Authentication falls back to LDAP, the default login page is used.


5. Click on Add Policy and then Add after Choosing the Cert Authentication Policy


For more information on Client Cert Authentication see, CTX205823

6. Click on the blue plus sign below the Cert_Policy just selected to add LDAP Authentication Policy


7. Select the LDAP_Policy and then Add


For more information on creating LDAP Authentication see,Configuring LDAP Authentication

8. Click on Done this will automatically save the configuration.

9. Select the nFactor Flow just created and bind it to a AAA Virtual Server by clicking on Bind to Authentication Server and then Create

NOTE:Bind and Unbind the nFatctor Flow through he option given in nFactor Flow under Show Bindings only.

To unbind the nFactor Flow:

1. Select the nFactor Flow and Click on Show Bindings

2. Select the Authentication VServer and Click Unbind

Important ns.log Messages

  1. For the case when Certificate is absent:

ClientVersion TLSv1.2 - CipherSuite "AES-256-CBC-SHA SSLv2 Non-Export 256-bit" - Session New -NO_CLIENT_CERT-Jul 30 21:08:50 <local0.debug> 127.0.0.2 07/30/2015:21:08:50 GMT 0-PPE-2 : default AAA Message 437 0 : "NFactor: Cert Auth: certificate is absent, falling back nFactor login"Jul 30 21:08:50 <local0.debug> 127.0.0.2 07/30/2015:21:08:50 GMT 0-PPE-2 : default AAATM Message 438 0 : "LoginSchema policyeval did not return an active policy"Jul 30 21:08:50 <local0.debug> 127.0.0.2 07/30/2015:21:08:50 GMT 0-PPE-0 : default SSLLOG SSL_HANDSHAKE_SUCCESS 524 0 : SPCBId 568 - ClientIP 10.252.112.163 - ClientPort 54500 - VserverServiceIP 10.217.28.167 - VserverServicePort 443 - ClientVersion TLSv1.2 - CipherSuite "AES-256-CBC-SHA SSLv2 Non-Export 256-bit" - Session NewJul 30 21:09:11 <local0.debug> 127.0.0.2 07/30/2015:21:09:11 GMT 0-PPE-2 : default SSLVPN Message 439 0 : "core 2: ns_get_username_password: loginschema gleaned is default "Jul 30 21:09:11 <local0.debug> 127.0.0.2 07/30/2015:21:09:11 GMT 0-PPE-2 : default SSLVPN Message 440 0 : "aaad_authenticate_req: copying policylabel name avn to aaa info, type 33 for auth "Jul 30 21:09:11 <local0.debug> 127.0.0.2 07/30/2015:21:09:11 GMT 0-PPE-2 : default SSLVPN Message 441 0 : "sslvpn_extract_attributes_from_resp: attributes copied so far are user11.citrix "Jul 30 21:09:11 <local0.debug> 127.0.0.2 07/30/2015:21:09:11 GMT 0-PPE-2 : default SSLVPN Message 442 0 : "sslvpn_extract_attributes_from_resp: total len copied 23, mask 0x5 "Jul 30 21:09:11 <local0.debug> 127.0.0.2 07/30/2015:21:09:11 GMT 0-PPE-2 : default AAATM Message 443 0 : "SAMLIDP: Checking whether current flow is SAML IdP flow, input aHR0cDovL25zc3AuYWFhdG0uY29tL3Rlc3RtZS5odG1s"Jul 30 21:09:11 <local0.debug> 127.0.0.2 07/30/2015:21:09:11 GMT 0-PPE-2 : default AAATM Message 444 0 : "Invaid tass cookie while checking whether current authentication is due to idp functionality: aHR0cDovL25zc3AuYWFhdG0uY29tL3Rlc3RtZS5odG1s "Jul 30 21:09:11 <local0.info> 127.0.0.2 07/30/2015:21:09:11 GMT 0-PPE-2 : default AAA EXTRACTED_GROUPS 445 0 : Extracted_groups "grp1,grp2,grp3,Group2,group1"
  1. For the case when Certificate is present:

Jul 30 21:10:36 <local0.debug> 127.0.0.2 07/30/2015:21:10:36 GMT 0-PPE-2 : default SSLLOG SSL_HANDSHAKE_SUCCESS 452 0 : SPCBId 596 - ClientIP 10.217.28.185 - ClientPort 57227 - VserverServiceIP 10.217.28.167 - VserverServicePort 443 - ClientVersion TLSv1.2 - CipherSuite "AES-256-CBC-SHA SSLv2 Non-Export 256-bit" - Session ReuseJul 30 21:11:02 <local0.debug> 127.0.0.2 07/30/2015:21:11:02 GMT 0-PPE-0 : default SSLLOG SSL_HANDSHAKE_SUCCESS 539 0 : SPCBId 578 - ClientIP 10.217.28.185 - ClientPort 57226 - VserverServiceIP 10.217.28.167 - VserverServicePort 443 - ClientVersion TLSv1.2 - CipherSuite "AES-256-CBC-SHA SSLv2 Non-Export 256-bit" - Session New- CLIENT_AUTHENTICATED -SerialNumber "140000000FAED08CAE9B092FEF00000000000F" - SignatureAlgorithm "sha1WithRSAEncryption" - ValidFrom "Mar 13 21:05:01 2015 GMT" - ValidTo "Mar 12 21:05:01 2016 GMT"Jul 30 21:11:02 <local0.debug> 127.0.0.2 07/30/2015:21:11:02 GMT 0-PPE-0 : default SSLLOG SSL_HANDSHAKE_ISSUERNAME 540 0 : SPCBId 578 - IssuerName " DC=com,DC=aaatm,CN=aaatm-DC-CA-1"Jul 30 21:11:02 <local0.debug> 127.0.0.2 07/30/2015:21:11:02 GMT 0-PPE-0 : default SSLLOG SSL_HANDSHAKE_SUBJECTNAME 541 0 : SPCBId 578 - SubjectName " DC=com,DC=aaatm,CN=Users,CN=user2"Jul 30 21:11:02 <local0.debug> 127.0.0.2 07/30/2015:21:11:02 GMT 0-PPE-0 : default AAA Message 542 0 : "NFactor: Successfully completed cert auth, nextfactor is "Jul 30 21:11:02 <local0.info> 127.0.0.2 07/30/2015:21:11:02 GMT 0-PPE-0 : default AAATM LOGIN 543 0 : Context users@10.217.28.185 - SessionId: 37- User users - Client_ip 10.217.28.185 - Nat_ip "Mapped Ip" - Vserver 10.217.28.167:443 - Browser_type "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:39.0) Gecko/20100101 Firefox/39.0" - Group(s) "N/A"Jul 30 21:11:02 <local0.debug> 127.0.0.2 07/30/2015:21:11:02 GMT 0-PPE-0 : default SSLVPN Message 544 0 : "core 0: initClientForReuse: making aaa_service_fqdn_len 0 "

Related:

Citrix Hypervisor unable to sync to NTP/Chrony server

Make sure that your host is having similar/correct DNS servers throughout the pool

1 Add all xenserver Public NTP servers to the host . Refer below link for the same.

https://support.citrix.com/article/CTX121278

Note: Make sure that you have identical and equal number of NTP source servers on all xenserver host in pool

2. It will automatically restart the ntpd/chronyd service but sometimes that does not sync the time to NTP and we have to manually restart the ntpd/chronyd service using below command.

# service ntpd restart

Run below command to restart chronyd service

# systemctl restart chronyd.service

If even after manually restarting the service it does not work then follow below steps

3. Stop ntpd service using below command

# Service ntpd stop

Run below command for chronyd service

# Systemctl stop chronyd.service

4. Manually sync xenserver from hwclock to desired ntp servers using below command

# ntpdate 0.xenserver.pool.ntp.org

Use below command for Citrix Hypervisor 8.1 and 8.2

# chronyd -q 'server 0.xenserver.pool.ntp.org iburst'

5. Started ntpd service

service ntpd start

It will Sync the host to NTP servers now.

Use below command to start chronyd service

systemctl start chronyd

Related:

How to Configure NetScaler MAS Simplified Audit Log Management

To configure NetScaler MAS simplified audit log management:

1. Navigate to System > Auditing > Syslog Messages.

User-added image

2. Under Syslog Messages you will see audit logs messages. You can choose to filter them based on Module, Event Type, or Severity.

User-added image

Additionally, you can click within the syslog message to gather information on what kind of module, event type any particular message was.

3. Module is selected and the module (GUI) gets highlighted:

User-added image

User-added image

5. You can use that to learn what modules, or events type, or severity you want to filter with and select them from the Filter By menu on the right hand side of the screen.

User-added image

4. Event Type gets selected (CMD_EXECUTED).

Related:

How to Test LDAP Authentication Settings on NetScaler Gateway Running 11.1 Version

From 11.1 builds there is a new feature to Test the connection between Netscaler and backend LDAP server.

In LDAP server profile we have below button now “Test Connection” which generates the traffic from Netscaler to backend LDAP server and gives the information as shown below about the connection:

To navigate to LDAP Server Profile: NetScaler > Security > AAA – Application Traffic> Policies > Authentication > Basic Policies > LDAP > Servers

User-added image

This is helpful to confirm if there is any issue in connectivity between NetScaler and LDAP server configured.

Related:

“Target Device boot fails with error PXE-E55 : ProxyDHCP service did not reply to request on port 4011″

The Option 60 is configured with the string “PXEClient”. This is telling the DHCP Clients that the target of Option 66 is a PXE Client and not a PXE Server.

To resolve this issue, edit Option 60 and clear the field and restart the DHCP Server.

Related:

AAA GROUP expressions in Gateway Vserver (CVPN, Full VPN and ICA Proxy) usecase

For using AAA Groups in policy expressions, it is mandatory to have the groups added in ADC. This is applicable for all expressions evaluated after the authentication flow is completed.

Example 1:

For example, if a user is part of a LDAP Group “Finance” and you want to have a policy expression like so (e.g. rewrite / responder or any other policy)

AAA.USER.IS_MEMBER_OF(“Finance”)

OR

AAA.USER.GROUPS.CONTAINS(“Finance”)

Related:

VDA Registration: Multiple Forests with 2 way or 1 way trusts (external trusts or forest trusts)

The following diagram illustrates XenDesktop deployment in a Multi-Forest Deployment. This is where the DDC is in a different Active Directory forest and the end users and desktops can be either in the same forest or in a separate Active Directory forest.

Note: For Forest trusts, both Forests must be in Win2003 Forest Functional Level.

User-added image

The preceding illustration shows two separate Active Directory forest with a two-way forest trust. DDC and Users are in the same forest (parent.local) but the VDAs are located in different forest (parent2.local).

For successful VDA registration with the DDC, the following must be configured correctly:

DNS, for name and reverse lookups. Depending on the approach taken, the use of DNS Forwarders and Conditional Forwarders, Forward /Reverse lookup zones and Stub zones are all acceptable for name lookup/resolution. As an example, in the preceding illustration, on the DNS server for Parent.local, a Secondary Forward Lookup Zone and a Reverse Lookup zone for Parent2.local has been added and similarly the opposite has been done on the Parent2.local. This means that the DDC should now be able to resolve the VDA by name and IP and the VDA resolves the DDC by name and IP address.

SeeManaging a Forward Lookup Zonefor information on managing Lookup Zones.

On theDesktop Delivery Controller, enable the following registry value on the DDC. This enables support for VDAs, which are located in separate forests:HKEY_LOCAL_MACHINESoftwareCitrixDesktopServerSupportMultipleForest (REG_DWORD)

User-added image

To enable VDAs located in separate forests; this value must be present and set to 1.

After changing the SupportMultipleForest value, you must restart the Citrix Broker Service for the changes to have an effect.

On theVirtual Desktop Agent, enable the following registry value on the VDA to enable support for DDCs located in a separate forest.

  • For a 32-bit VDA: HKEY_LOCAL_MACHINESoftwareCitrixVirtualDesktopAgentSupportMultipleForest (REG_DWORD)

  • For a 64-bit VDA: HKEY_LOCAL_MACHINESoftwareWow6432NodeCitrixVirtualDesktopAgentSupportMultipleForest (REG_DWORD)

To enable support for DDCs located in a separate forest; this value must be present and set to 1.

Note: The next step is only required if External Trusts are only being used.

  1. If the Active Directory FQDN does not match the DNS FQDN or if the domain where the DDC resides has a different NetBIOS name to that of the Active Directory FQDN, you must add the following registry key on the Virtual Desktop Agent machine.
    • For a 32-bit VDA: HKEY_LOCAL_MACHINESoftwareCitrixVirtualDesktopAgentListOfSIDs
    • For a 64-bit VDA: HKEY_LOCAL_MACHINESoftwareWow6432NodeCitrixVirtualDesktopAgentListOfSIDs
    • User-added image

The ListOfSIDs registry key contains the DOMAIN SID of the DDC. By using this key, DNS lookups are using the true DNS name of the DDC.

To obtain the correct domain SID of the DDC, the domain SID can be found in the results of the PowerShell cmdlet Get-BrokerController from an elevated PowerShell prompt on the delivery controller.

Note: You must restart the Citrix Desktop Service for the changes to have an effect.

Related:

Cisco Identity Services Engine Denial of Service Vulnerability

A vulnerability in the syslog processing engine of Cisco Identity Services Engine (ISE) could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition on an affected device.

The vulnerability is due to a race condition that may occur when syslog messages are processed. An attacker could exploit this vulnerability by sending a high rate of syslog messages to an affected device. A successful exploit could allow the attacker to cause the Application Server process to crash, resulting in a DoS condition.

Cisco has released software updates that address this vulnerability. There are no workarounds that address this vulnerability.

This advisory is available at the following link:
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-ise-dos-qNzq39K7

Security Impact Rating: Medium

CVE: CVE-2020-3353

Related:

Cisco Prime Network Registrar DHCP Denial of Service Vulnerability

A vulnerability in the DHCP server of Cisco Prime Network Registrar could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition on an affected device.

The vulnerability is due to insufficient input validation of incoming DHCP traffic. An attacker could exploit this vulnerability by sending a crafted DHCP request to an affected device. A successful exploit could allow the attacker to cause a restart of the DHCP server process, causing a DoS condition.

Cisco has released software updates that address this vulnerability. There are workarounds that address this vulnerability.

This advisory is available at the following link:
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-cpnr-dhcp-dos-BkEZfhLP

Security Impact Rating: High

CVE: CVE-2020-3272

Related:

  • No Related Posts