**Update: So.. It appears it does show up but… it shows under “Show built-in Responder Policies. **
This is where you select to show built-in.They should up like normal now.
Did an upgrade of 13.0-84.11 to 13.0-87.9. Same thing occurred as in the upgrade to 13.0-85.15. The responder policies seem to vanish from the GUI. It will show the correct number of policies at the overview screen, if you look on the bound vServer, but not in the pane that shows all available policies. If you check the ns.conf, you will see the policies are there and are bound where they should be. Seems to be a bug again where it goes the way of the dodo.
You can see there are policiesYou see there are no policies showingBut you can see there are policies bound to the vServer
Ran into some fun with setting up FAS for MFA. I was testing a shorter list of ciphers on a test SSL profile on ADC on the test vServer. Come to find out, when accessing a machine that was using MFA from outside the network, I was getting an SSL error 4 on Windows machines and SSL error 47 on Stratodesk machines. I hadn’t seen that error since Receiver 4.x. It appears there are some additional ciphers needed in regards to the Citrix Workspace App. It appeared to work fine with the other cipher set using the HTML5 Workspace App. This article has the updated cipher set you need to have or it may cause you some issues (Changes To FAS Ciphers). These would be applied to your SSL profile assigned to the vServer on the ADC.
Ciphers needed in the SSL profile that are in link above
I also ran into an issue with EndGame.
When trying to connect from to VDI Windows 10 machines, you would encounter an incorrect user name or password error if EndGame was enabled, instead of it SSO logging you in.
Checking the event log on the machine, you encounter a Smart Card Logon Event 5.
There are 2 DLLs you have to add to a global exclusion, scardhook.dll and scardhook64.dll. These are located under C:\Program Files\Citrix\ICAService. Just excluding those DLLs got rid of the Event 5 Smart Card Logon error and allowed the Provider DLL to initialize.
After getting these exclusions applied, SSO works normally for accessing the VDI machines.
Simple little script that you can modify the commands you want to run against a Citrix ADC. I’ve included using the “show ha node,” “show version,” and “show ip.” You can blank the commands and leave ” to have it skip the command. I ran into an issue with trying to send the password to the ADC so I had to use GetNetworkCredential().password on the $credential variable ($credential.GetNetworkCredential().password). This allowed the password to be passed without issue.
If you run the commands to query against the secondary node in an HA pair, you will get this error and it can be ignored: plink :Warning: You are connected to a secondary node; configuration changes made in this session will not be propagated to, or saved on, other nodes.(If you want to make changes via the commands, you will need to target the primary node)
# Script to use PuTTY Plink to access Citrix ADC to run commands remotely and get output to text file. This is using PowerShell ISE 5.1 and having PuTTY / Plink in the system path to being able to access.
$credential = Get-Credential
$sessionHost = "nodeip"
$pw = $credential.GetNetworkCredential().password
$user = $credential.UserName
$date = Get-Date -Format MMddyyyy
$reportName = "netscaler.txt"
$reportLocation = "c:\scripts\logs"
$report = @()
# Commands
$cmd1 = 'show ha node'
$cmd2 = 'show version'
$cmd3 = 'show ip'
if($cmd1 -ne ''){
$log1 = Echo Y | plink -ssh -l $user -pw $pw $sessionHost $cmd1
$report += $log1
}
if($cmd2 -ne ''){
$log2 = Echo Y | plink -ssh -l $user -pw $pw $sessionHost $cmd2
$report += $log2
}
if($cmd3 -ne ''){
$log3 = Echo Y | plink -ssh -l $user -pw $pw $sessionHost $cmd3
$report += $log3
}
$report | Out-File -FilePath "$reportLocation\$date-$reportName" -noclobber
Update coming for a process to do a weekly update of the CSV files from MaxMind to use more current files than the included ones in the ADC firmware.
So you have some compliance you need to meet on your IRS1075. You might see one of those points that you have to restrict based on origin country IP. Well… That can be a little bit of fun (note below on how that can be fun). So you will need to logon to your ADC with your super secret squirrel account to change the laws of access. For this, I would recommend using the all powerful command line. There is a link to a CTX article that explains parts of this https://support.citrix.com/article/CTX130701/how-to-use-netscaler-to-block-access-to-a-website-using-a-location-database-based-on-users-country
In this example, I’m using Ubuntu on WSL for that Windows / Linux immersive experience.
Login to ADC with SSH.
This is using the inbuilt csv that is part of the firmware that is in the ADC from firmware 11.0. You can use an external file as well which is outlined in the CTX130701 article.
Enter in “add locationFile “/var/netscaler/inbuilt_db/Citrix_Netscaler_InBuilt_GeoIP_DB.csv””
Hit enter and it will report “Done.”
Enter in “add audit messageaction log_locationInformation NOTICE “\”dropped request for \” + CLIENT.IP.SRC + \” from \” + CLIENT.IP.SRC.LOCATION” -logtoNewnslog YES”
This will create the audit log that you can associate to the Responder Policy to write out to whatever syslog you are using.
Enter “add responder policy Drop_non_US_IRS1075 “CLIENT.IP.SRC.MATCHES_LOCATION(\”.US....\”).NOT && CLIENT.IP.SRC.MATCHES_LOCATION(\”.CA....\”).NOT && CLIENT.IP.SRC.IN_SUBNET(10.0.0.0/8).NOT && CLIENT.IP.SRC.IN_SUBNET(172.16.0.0/12).NOT && CLIENT.IP.SRC.IN_SUBNET(192.168.0.0/16).NOT” DROP -logAction log_locationInformation”
This will allow all USA and Canada IPs, and the private addresses for the internal users. If you leave that part off, well…. they aren’t gonna connect internally. This is assuming you want to allow all the private internal IP ranges. You can narrow that further if you wish to be more restrictive. **this is note referenced above**
Enter “set locationParameter -matchWildcardtoany YES” This is for NetScaler 11.1 build 53.11 and above. This is referenced in the CTX article.
Enter “show locationparameter” and it will show the loaded csv file and the “Match wildcard qualifier to any: YES”
You have the audit log configured and the Responder Policy configured. You will need to now bind it to your vservers to apply the policy.
Enter “bind lb vserver <vservername> -policyName Drop_non_US_IRS1075 -priority 100”
I would definitely recommend testing this on an internal testing site so as not to break your production environment. Happy restricting!
So you want to get that sweet, sweet forward proxy all up there for some kiosks? Well… Have I got a deal for you! If you happen to have the licensing (Premium license requirement), you too can be the proud owner of this actually wonderful product. I have been using this for years now and it works extremely well if you don’t have to constantly add sites to the allowed list. Now… First things first. This is for defining your OWN allow list that YOU have to maintain. Getting Gmail to work will take some effort as there are a LOT of sites you have to add for images. This is not using the URL Threat Intelligence which is a line item purchase. This was completed with the help of Kevin Lofy from Citrix. https://www.linkedin.com/in/jkevinlofy/. This also is the GUI way of configuring this. Hope that this is of help. It REALLY solved a couple issues and allowed a good bit of control with using AppLocker on the VDA hosting server that was publishing the Firefox browser that linked to the proxy address.
Logon to Citrix ADC.
You will need to select “System” > “Settings” > “Configure Basic Features.”
If “Integrated Caching” is not enabled, you will need to enable the feature. This WILL require a reboot.
You will need to set a policy to set the IP and Port defined for the proxy (typically 8080) and apply to the machine that will be using the proxy. Using AppLocker with it will make it harder to pivot out of for machine security.
I’ll gather up a blog post of AppLocker and a way to use it with SSL Forward Proxy.
Get rid of it! In the How To Create The Wow nFactor part one (https://xenapplepie.com/2022/03/13/how-to-create-the-wow-nfactor/), there is a section where you get a popup after configuring your LDAPS authentication. This outlines resolving that by logging into your handy, dandy Netscaler ADC with the power of SSH or putty. I’ll also link from that location the changes listed here to resolve that. This example will use putty as getting in the door. After that point of connection, the commands are the same from an SSH session.
Open up Putty and enter the host name / IP.
Login with your nsroot privilege.
Enter “shell” to drop to the Linux shell.
At the prompt, enter “cd /nsconfig/loginschema/LoginSchema.”
Press “Enter.”
Enter “ls” to list folder contents. You are looking for the PrefilUserFromExpr.xml file.
Enter “cp PrefilUserFromExpr.xml /nsconfig/loginschema/PrefilUserFromExpraaa.xml.” You can change the file name to whatever you wish. I just used this name for the example. This copies the xml file that is the template for the xml file you are going to modify.
Press “Enter.”
Type “cd..” to go up a folder level.
Type “ls” to list folder contents. This is to confirm the file copied correctly.
Type “vi PrefilFromUserExpraaa.xml.” This will open the file in vi editor so that you can make changes to the file.
Press “Enter.”
Use your arrow keys to navigate to the ${http.req.user.name}.
Highlight the first “h.”
Press the “Del” key to delete the text until you have just “{}.”
Press the “i” key to “Insert” and enter “AAA.USER.NAME” in the area so that it looks like ${AAA.USER.NAME}.
Press the “Esc” key and enter “:w!” This will write the file.
Press the “Esc” key and enter “:q” This will quit the vi session.
Type “exit” and press “Enter.” This exits the shell session.
Type “exit” and press “Enter.” This will exit your putty session.
Now you will need to go back to the section for the LDAP schema in your nFactor flow and edit. You will choose the LDAPS_Auth_Test Login Schema.
Click “Edit.”
Click the pencil icon.
Click on the “PrefilFromUserExpraaa.xml.”
Click “Select.” If you do not do this part, you won’t see the change reflected. You will see the ${AAA.USER.NAME} in the “User name” field.
Click “OK.”
Click “Done.”
You have completed the change to the custom XML file to move from the deprecated setting!
So ran into something fun with the 13.0-84.11 firmware for the ADC. After moving to this version, we noticed the packet engine crashed and failed over. Then it did it again a few days later. After a call with Citrix, looks like there is a known bug in there that is to be remediated in the next month with a new firmware release. The recommendation to do the fix is to run this command on each node of an HA pair: nsapimgr -ys enable_ica_edtinsight=0. There was a CTX article that was referenced (https://support.citrix.com/article/CTX341028), but I was unable to view it. There is a caveat if you happen to be using EDT that it won’t show in ADM after you make this change, so you would need to disable HDX Adaptive Transport if you want to see session information in ADM.
This is part 2 of the nFactor setup that outlines how to setup the AAA-TM server and the Authentication Profile that you need in order to implement the nFactor flow you created in part 1. Link to Part 1 below.
This section outlines setting up the AAA-TM server to replace basic authentication on Citrix Gateway. If you want to make this accessible to things other than just Citrix Gateway, you will need an IP address, a certificate, and a DNS entry to point to said IP address. If you want to ONLY use it for Citrix Gateway, there is an option under the configuration for IP Address Type to select “Non Addressable.” In this example, an IP address will be used.
Login to you Citrix ADC and navigate to Security > AAA – Application Traffic > Authentication Virtual Servers. Select “Add.”
You can do two different assignments with this setting. Under “IP Address Type,” you can select “Non Addressable” if you only wish to use for Citrix Gateway.
Enter “Name.”
Select “IP Address Type” as “IP Address.”
Enter IP address.
Click “OK.”
Click on “No Server Certificate.”
Select the certificate you wish to bind to the AAA-TM server.
Click “Select.”
Select “Bind.”
Select “Bind.”
Select “Continue.”
Click “nFactor Flow.”
Click “Add Binding.”
Select the nFactor flow you created previously and click “Select.”
Enter “true” for the “Expression.”
Click “Bind.”
In the upper-right, select “Portal Themes.”
Select “Add.”
Here you can change the look of the theme. Accepting the defaults, click “OK.”
Click “Done.”
Click “OK.”
Click “Done.”
This completes the setup of the AAA-TM vserver. The next step is to create the Authentication Profile that will be used on Citrix Gateway to utilize the AAA-TM vserver.
Recently we had upgraded firmware on a Citrix ADC from 13.0-83.27 to 13.0-85.15. This was to try and correct an issue with the HTML interface not updating the custom settings on the Login Schemas for nFactor configuration. It would create the custom XML file for use, but it wouldn’t reflect any changes to it. I checked the permissions on the XML file and they would show root had read / write. You could still copy the XML file down via tools like WinSCP, make the edit, and copy back to the ADC.
Below you can see what happened. You would navigate to AppExpert > Responder and you would see the proper number of policies showing.
After you click on the the # Responder Policies, you see below.
It shows that there are no policies there. You can click on “Statistics” and you see this below.
It appears that it reset the counters as well. You can putty into the ADC and do a “show run” and you see that they are still there.
You can see that the policies are there. They do appear to work, but they just don’t show on the HTML GUI.
So a downgrade of version will be in order to see if that resolves the issue and Citrix is still looking at the issue to find a resolution.
UPDATE: Looks like a firmware revision reversion took care of the display issue with the showing of Responder policies.
This configuration covers setting up EULA as a first factor in an nFactor flow to do one side of an MFA configuration. This will setup a group extraction that looks for an assigned Universal group that is designated to trigger directing traffic to an MFA provider. The reason for using a Universal group would be in an instance where you have a forest with multiple subdomains that have a two-way transitive trust. This allows you to manage group membership from one domain as the Universal group will be replicated to all the domain controllers. This example is to check membership of the Universal group and perform cascading LDAP for the users that are NOT members of that Universal group.
So I was trying to move to advanced authentication in a test environment. While I was doing that, I thought to myself that since my end goal with that test, would be to prep to move to MFA. That led to me thinking how I would want to implement that. Then…… I ran into a very interesting thing when you move from using basic authentication to an authentication profile with AAA-TM, that the EULA option goes bye bye. There isn’t even an option to select. So I went looking how to resolve that. One option was to follow a guide that I found to edit some xml files, but that meant that I would have to manually copy these to keep them in sync between the Citrix ADCs. I didn’t like that idea but did see the option to use EULA as a first factor in nFactor. Hmm… I was already thinking in that mode to setup nFactor since it would be needed to go down the MFA road. So that is the decision I decided to work on and get testing. I also found some interesting tidbits that I’ll point out in the configuration.
Update: Changed LDAPS policy settings to fix “Anonymous” issue.
Update: Added link to article to create custom XML file to change ${http.req.user.name} to ${AAA.USER.NAME}
So here we go!
You will need to have either Advanced or Premium license to have access to this feature. You will also need to have configured an Authentication Virtual Server which I will link soon.
In the “Authentication Schema” box, select the “Edit” pencil.
Click on the “LoginSchema.” This will bring up a list to choose from.
Scroll down and select “Eula.xml.”
Click the “Edit” button if you want to edit the EULA message.
After you change the EULA message below and click “Save,” click the “Select” button. This is VERY important or it won’t select it.
After you have configured the message, click “Save.”
Click “Create” button.
Click “OK.”
Click on “Add Policy.”
Click the “Add” button.
Name the policy and select “Action” as “NO_AUTHN.”
For the “Expression,” enter “HHTP.REQ.URL.CONTAINS(“/nf/auth/doAuthentication.do”)
Click “OK.”
Click “+” sign beside “NO_Authn_Pol” (whatever you name the Authentication Policy).
Select “Create Factor.” This factor will do the group extraction to test group access.
Name “Factor Name.” (Grp_Ext_Test in this example)
Select “Add Schema.”
Select “Only_User_Name.” This will have the user enter their user name to be evaluated.
Click “OK.”
Click “Add Policy.”
Click “Add.”
Enter “Name” for policy (test-ldap-grpexpt-pol in this example).
Select “Action Type” as “LDAP.”
For the “Expression” enter “true.”
Click “Add” on “Action.”
Select the root of the forest (domain if you only have 1 domain) for the “Server Name.” (The DC that you are trying to access will need to have the Global Catalog available for this to work correctly)
For the “Port,” choose either 3268 for unsecure LDAP or 3269 for secure LDAP (This will require that you upload the root certificate for the organization to utilize).
Make sure the UNCHECK the box for Authentication. This is just going to do a lookup if the user is part of the MFA group.
Enter your “Base DN” as where the users will be or the root of the forest / domain.
Enter “Administrator Bind DN” which is the account that will authenticate to the domain.
Enter and confirm “Administrator Password.”
Click “Test Network connectivity” to make sure that it is working correctly.
Complete “Server Logon Name Attribute” as “sAMAccountName.” The samaccountnames need to be unique in the forest or you will have issues with this global catalog lookup.
For “Group Attribute” select “memberOf.”
For “Sub Attribute Name” select “cn.”
Click the “+” sign beside “test-ldap-grpext-pol.”
Select “Create decision block” and enter “Decision block Name.” (Grp_Eval_Test in this example)
Click “Create.”
Click “Add Policy.”
Click “Add.” (NonMFA_Test in this example)
Select “Action Type” as “N0_AUTHN.”
Select “Action” as “NO_AUTHN.”
In the “Expression” enter “AAA.USER.IS_MEMBEROF(“UniversalGroup”).NOT.” (UniversalGroup is the group name of the MFA testing group)
Click on the “+” sign beside “NonMFA_Test.”
Select “Create Factor.”
Enter “Factor Name.” (LDAPS_Auth_Test in this example)
Click “Create.”
For the “Authentication Schema” click the pencil icon.
This allows you to take what was entered just after click on “Continue” for the EULA and populating that in the User Name / Password dialogue to prevent users from having to enter it twice.
Under the “Login Schema Files” select “PrefilUserFromExpr.xml. (Note that User Name contains $(http.req.user.name).
You can click the “+” sign on the bottom of the box to add additional LDAP/LDAPS policies. This is what you would normally see under the Basic Authentication on the Citrix Gateway.
