Citrix ADC, Secure LDAP

Microsoft has announced that from January 2020, only secure LDAP request are supported: https://support.microsoft.com/en-us/help/4520412/2020-ldap-channel-binding-and-ldap-signing-requirement-for-windows

From the article:

LDAP channel binding and LDAP signing provide ways to increase the security of network communications between an Active Directory Domain Services (AD DS) or an Active Directory Lightweight Directory Services (AD LDS) and its clients. There is a vulerability in the default configuration for Lightweight Directory Access Protocol (LDAP) channel binding and LDAP signing and may expose Active directory domain controllers to elevation of privilege vulnerabilities.  Microsoft Security Advisory ADV190023 address the issue by recommending the administrators enable LDAP channel binding and LDAP signing on Active Directory Domain Controllers. This hardening must be done manually until the release of the security update that will enable these settings by default. 

Microsoft intends to release a security update on Windows Update to enable LDAP channel binding and LDAP signing hardening changes and anticipate this update will be available in mid-January 2020.”

And why is this important for the Citrix ADC. Well that is because that we can use 3 mode of LDAP communications on the Citrix ADC:

  • PLAINTEXT:
  • TLS:
  • SSL:

If your configuration uses PLANTEXT, that it will stop working after mid-January, if you patch your Windows Domain Controllers, and who don’t do that.

Get out there and check your configuration and change it if you are using PLAINTEXT.

Citrix ADC, User Certificate Authentication

Once again, a was struggling to get User Certificate Authentication to work, until I suddenly remembered why:

You cannot put your Certification Authentication Virtual Server behind a Content Switching Virtual Server.

You can, but then you must enable Client Authentication on the Content Switching Virtual Server, and as this often have a lot of other web sites configured all of them will have Client Authentication enabled.

The reason for this is that when you use Content Switching Virtual Server the SSL session is established to this and the you need Client Authentication configured here.

So, if you have a special web site that you need to protect with Client Authentication you need a direct accessible Authentication Virtual Server.

Let me show the configuration I ended up with:

Create an Authentication Virtual Server:

Bind your public certificate and your root ca certificate:

For test a use a local user account, but this is normal an Active Directory account:

Then add the Certificate Authentication policy:

You will end up with 2 primary authentication policies:

Change the SSL Parameters so that Client Authentication is enabled:

Now create the Load Balancing Virtual Server and enable Authentication on this:

That is, it, and when we test, we will get this.

When testing with a user that have no certificate the site will close the connection:

And testing with a user that have a certificate the user is prompted for the certificate to use:

After selected the certificate, the user is redirected to the Authentication Virtual Server for logon:

Conclusion:

You can use User certificates when protecting web sites with authentication. Just remember that the authentication virtual server can often not be behind a content switching server as this will enable user certification on all web site configured on the content switching server.

Citrix ADC, Developer monitor

Again, by a customer I was asked to deliver a solution to there Citrix ADC. The customer has a web server farm which is controlled and maintained by their web developers. There needed their web developers to control witch servers where active in the farm and witch there where in maintains mode.

The easy way is to create a login for the web developers for the Citrix ADC, but there where other system load balanced through the Citrix ADC, and the web developers may not change the configuration for the other systems. We could have created a partition on the Citrix ADC, but I came up with a custom monitor solution. The web developers agreed to put a file on the web servers, and I created a monitor the checked for the content of that file.

GUI:

CLI:

add lb monitor lb_mon_www HTTP-ECV -send "GET https://www.domain.dk/nodestatus.txt" -recv online -LRTM DISABLED -secure YES

If the “nodstatus.txt” return online, the monitor detects the web server as “up” and the load balancing will send traffic to the web server. If anything, else than online is received the monitor will set the web server as “down” and no traffic will be sent to it.

The web developers control the content of the nodestatus.txt file, and in that way, they can control which web servers receive request and which is not, and the developers have no login/access to the Citrix ADC.

Citrix ADC 12.1 (NetScaler ADC), New licensing

Expiration:

 

With the new version 12.1 Build 48.13, Citrix added information about license expiration date. This is nice when running a Trial or Demo license:

With that they added another change, if care reading their documentation:

From https://docs.citrix.com/en-us/netscaler/12-1/licensing/netscaler-licensing-overview.html:

“Upon license expiration, the Citrix ADC appliance automatically restarts to revoke the license. If Citrix ADC appliance uses Citrix service provider (CSP) licenses, the appliance does not restart automatically to revoke the license. However, if the user restarts the appliance, it restarts as unlicensed.”

And trust me it will restart the NetScaler. As a consultant I offend use Trial versions for PoC. There where no problems in running beyond the expiration date if you did not restart the NetScaler. This is over now.

 

Express vs. Freemium:

 

Some time a go the Express version was replaced with the Freemium license. The Express license need to be updated every year because of the 1-year expiration. The Freemium have no expiration date, but it has not the Access Gateway feature.

This is a problem as the Express version was for very small customers with a replace for their old Citrix Secure Gateway (Yes, I am that old and have done a lot of installations of the Citrix Secure Gateway). So, what to customers running the Express version then do?

If we look at https://support.citrix.com/article/CTX121291 we find the answer:

Just update the NetScaler, and you will end up with an Express version with no expiration:

This must be done before the expiration of the old Express license, because if you restart the NetScaler with an expired license all features are disabled.

 

Conclusion:

 

Changes are made, so read the documentation. Get out there and upgrade the Express installations to version 12.1.

 

NetScaler, you are in control

As a consultant I often debug on NetScaler related issues. When I do this debugging I use different methods like nstcpdump, nstrace.

Nstcpdump I normally use just to clarify where we are sending data and if we are getting any response – this can tell if there are routing or Firewall issues.

SNIP = 10.11.12.152, Web Server = 192.168.1.152 port 8443

 

Routing problem, only sending data no answers:

Firewall Block, only sending data no answers:

And when it works we see monitoring data every 5 sec. (default):

As you see we can not tell from the nstcpdump if it is a routing problem or a Firewall block. We can only see that we are sending monitor data but never get any answer back.

 

The above is just for quick debugging on network related issues. When we want to do some deeper debugging nstrace is the tool to use.

As I do this it is important to inform the customer that we can see everything, and I mean EVERYTHING. I think this is important because we can see data that was not intended for us to see.

Let me show you.

I just do a simple nstrace with this command:

start nstrace -size 0

and stop it again with this command:

stop nstrace

The trace file will be in the /var/nstrace catalog on the NetScaler. Opening the trace that I just made looks like this (filtered with “frame contains “nsroot””:

As the trace show I just did a logon to my NetScaler while the trace was running, and I can se what username and password was provided. No surprise, I use the default nsroot, nsroot for my test NetScaler which is not in production.

But what if a user at the same time did a logon to the VIP = 10.11.12.156 for the Web Server 192.168.1.152?

Yes, I can see that too:

But what if we are using SSL connections? Well that is not a problem as we can get the NetScaler to decrypt the trace by doing this command (Not on SSL_BRIGDE sessions):

start nstrace -size 0 -mode SSLPLAIN

With that the login for an SSL session will be in clear text within the trace. I have not made screenshots of that as It will look just like the above screenshots.

 

But what do we then do to keep our back safe. Well we can do some filters on the traces, so we only see the traffic we are interested in.

Here are some examples.

To see traffic to and from a specified host:

start nstrace -size 0 -filter CONNECTION.DSTIP.EQ(192.168.1.152).OR(CONNECTION.SRCIP.EQ(192.168.1.152))

To see traffic for a specified port:

start nstrace -size 0 -filter CONNECTION.PORT.EQ(514)

By using filters on that nstrace command we only get the traffic we need for debugging on a specified system.

And again, remember to get permission to do the trace and tell the customer that when we do this we can see all traffic to and from a system.

 

Conclusion:

Well, this is only best practice for us NetScaler consultanst. We need to inform the owner of the system that when we do debugging on their system, we can get data that was not intended for us to see. Always keep a good and open dialog with the system owners so that we don’t get into trouble.

Page 1 of 3

Powered by WordPress & Theme by Anders Norén