Jump to content
Welcome to our new Citrix community!

GSLB Sync - NetScaler


Philip Hall

Recommended Posts

Hi I have set up two sites in a GSLB Active-Active configuration, however I am having issues with GSLB Sync.

 

My SNIP is on a different subnet to the NSIP and I was hoping to use this IP address as the source address to connect to the remote IP Public address.  The reason I use this address is that the MEP also uses that address to connect to the remote sites Public IP address.  Also a default route has been setup to send external traffic out via that SNIP.

 

I have configured the RPC to be secure and to have the same password on all IP addresses on both sites.  I have also set up two services connected via TCP port 3008 and 22 to confirm that the route is up, which has been successfully achieved. 

 

However when I run the GSLB sync, it fails with a connection error. 

 

Would anyone know what I am doing wrong?

Link to comment
Share on other sites

Hello,

 

The following Citrix Support article has some great information regarding troubleshooting this issue:  https://support.citrix.com/article/CTX244517

 

Another document on the subject that might help as well: https://www.citrix.com/content/dam/citrix/en_us/citrix-developer/documents/Netscaler/how-to-synchronize-gslb-configuration-across-sites-on-a-netscaler-load-balancer.pdf

 

(questions 1 and 2 below are from those two URLs)

 

1. Is management access enabled on (all of) the GSLB site addresses?

2.  Are you also using Secure MEP and are all required ports configured to allow bidirectional flow between the sites?

3. If you run cat /var/log/ns.log | grep sync (or instead of sync, nsgslb should limit the results to just gslb related items in the log) does anything stand out (or could you post the output for review)?

4. Have you checked the firewall logs at both sites to ensure no required ports are being blocked?

 

Regards,

Jim G.

Link to comment
Share on other sites

You might want to run a trace to confirm, but I believe GSLB MEP originates from the NSIP and passes to the SNIP on the partner ADC site.  

To change this behavior, you have to change the source IP used by the MEP RPC node:  https://support.citrix.com/article/CTX202561.  The origin IP is usually (*) and can be changed to a specific SNIP assignment.  requires gslb to be reenabled on participating nodes.  

I would also strongly recommend backup config before attempting change, so in case you tweak wrong rpc node or need to restore communication, you can easily rollback.

Again, may need a trace to confirm behavior.

Related info:  https://docs.citrix.com/en-us/netscaler/11-1/gslb/configure-site-site-comm.html

 

Instead of using a management enabled SNIP on the public network (which brings with it the ability) to make management connections to the ADC.

You might want to consider asssigning a dedicated GSLB IP with management access enabled (which is still limited to MEP/GSLB communication and not other SNIP functions). 

In either case, consider using ACLs to restrict access to the GSLB IP or SNIP to only allow communication to/from the partner ADCs over the limited ports for GSLB Sync, to maintain security.  And whatever other required communication from allowed IPs is required.

 

Link to comment
Share on other sites

Hi Jim, and Rhonda,

 

Thank you for your response.  I was able to get this working using PBR and destination port address.  I originally had it on source port address which was the reason why it didn't work.

 

I am however getting another issue, where the traffic is using port 3010 rather than 3008.  MEP is using 3009 but GSLB sync is using 3010.  RPC is setup as secure on every connection with the same password on both sides.  I do not know why this is using 3010, any ideas?

Link to comment
Share on other sites

Hi,

 

I have also got another issue.  I am finding that when I try to log into the management GUI using an AD account that is not a member of a specific AD group that I am able to login but with no configuration.  I would prefer this was prevented and wasn't allowed to log in at all.

 

I am using LDAP with a search filter based on the members of an AD group.

Link to comment
Share on other sites

18 hours ago, Philip Hall said:

I am however getting another issue, where the traffic is using port 3010 rather than 3008.  MEP is using 3009 but GSLB sync is using 3010.  RPC is setup as secure on every connection with the same password on both sides.  I do not know why this is using 3010, any ideas?

 

Are you sure the secure flag is set on all RPC nodes and not just the NSIP nodes as the GSLB Site IPs (snip or dedicated IPS) must have secure enabled on all nodes to.  Then MEP should move from 3011 to 3009.  And GSLB sync should be just like HA sync and move from 3010 to 3008.  If all the rpcnodes on all gslb participants have secure enabled, you may have to contact support if its a known issue (supposed to do that).

 

12 hours ago, Philip Hall said:

I have also got another issue.  I am finding that when I try to log into the management GUI using an AD account that is not a member of a specific AD group that I am able to login but with no configuration.  I would prefer this was prevented and wasn't allowed to log in at all.

 

I am using LDAP with a search filter based on the members of an AD group.

 

For the GUI behavior, note the following access is a two stage process:  1) authentication is confirmed first and then 2) authorization is validated. So the default behavior, if someone authenticates, but has no rights. You will connect to GUI or CLI, but you are less than read-only, not authorization is allowed, so no data populates.  So it is secure.

 

To change the behavior, you have to change your scope of authentication so your users fall into "authenticated" users and those who "fail authentication".

 

For system access, this is done by either changing the base dn of the authentication policy such as by going from any account in the domain, to a specific OU.

The second way, is to leave the the authentication policy base dn as domain wide, but use the "Search" field to restrict accounts meeting certain LDAP criteria.

There's a third method with if you want to get into nested group extraction with filters...but let's just use the first two.

 

Ex 1:  Let's say for example domain:  company.com,

The normal Base DN is:  dc=company,dc=com

If all of your allowed admin accounts were in specific OU (both usernames and groups), then the base dn could be changed to the following for an OU like this; adjust for actual OU or Groups ldap distinguished name as structure will cause this to vary.:

OU=ADCAdmins,DC=company,DC=com

 

Ex 2:  Otherwise, you can keep the Base DN domain wide:  dc=company,dc=com

But adjust the "allowed" accounts via the Search filter of the LDAP policy.  (Note: some ldap examples in the tool tip for this field in the gui)

Ex 2a:  Limit to members of OU (same result as the other example)

OU=<distinguished name of OU>

OU=OU=ADCAdmins,DC=company,DC=com

 

Ex 2b:  Use an LDAP Search string to find members of a specific Group (ADCAdmins)

memberOf=<ldap distguished name for Group/CN>

memberOf=CN=ADCADmins,OU=ADCAdmins,DC=company,DC=com

 

Ex 2c:  Use an LDAP Search string to find accounts with custom parameter

nsadminallowed=true

Compound syntax is possible, example in tool tip along with note on double quotes requirements (but that might be cli); if you have syntax issues try looking at 3rd article below.

 

Article:

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

https://support.citrix.com/article/CTX201948 (this one for nested group extraction with filters)

https://support.citrix.com/article/CTX208237 - note on syntax issues regarding parentheses and quotes (if done via GUI the extra parantheses wrapping clause is not needed; if done from CLI it depends; same probably regarding quotes).

 

This might require using a separate authentication policy for system admins than use use for your usual gateway/ldap authentication.

Link to comment
Share on other sites

  • 3 weeks later...

Hi Rhonda,

 

Thank you for getting back to me.  Unfortunately I was on leave the last couple of weeks so not been able to look into this further.

 

I have noticed that when I look at the logs /tmp/aaad.debug that my account is authorizing with the Remote Users (NetScaler Gateway) LDAP policy but not getting any information from the VPX bar the blank configuration.

 

I do not understand why it is using this LDAP policy as that is only used for access the remote gateway.  The User Administration only has the second policy in use that allows members of the VPXAdmins group access as a superuser.

 

Just to explain further:

 

LDAP policies

 - Remote Users (Used to allow access to the Gateway) (So if not a member will not be allowed access to the citrix login via remote access.  Blocked at the Citrix logon screen)

 - VPX Admins (Used to allow access to the VPX Console for administration purposes) (Setup using a group under User Administration and applied the SuperUser access)

 

Results from the log

 

Thu Jul 30 11:08:01 2020

 /home/build/rs_130_52_11_RTM/usr.src/netscaler/aaad/ldap_common.c[1396]: ns_lda                                                                                                                          p_search 1-0: Searching for <<(& (sAMAccountName={Username}) (MemberOf={Remote Access LDAP Policy search base}))>> from base <<dc=companyname,dc=local>>

 

So what I am seeing is the following:

 

1.  If a member of Remote Users AD group you can log into VPX Console but do not see any information

2.  If a member of VPX Admins AD Group you can log into VPX Console and see the information

3.  If in neither group you fail to log in and get the typical error.

 

I have tried to remove Remote Users AD group from global binding but when I do this users in this group are unable to log into Citrix Gateway,  Any ideas?

Link to comment
Share on other sites

As this part of your issue has nothing to do with GSLB, you might want to add the necessary info to a new thread so others can see it (if you want additional help from others sooner).

 

I think we need to look at your config holistically to define the problem.

 

System/Admin access is governed by the same authentication policies that you use with gateway (usually, depending on classic vs advanced) engine. The difference is in the bind point.

Authentication policies on the system global bind point affect authentication requirements for management IPs and are controlled by your system user/system groups (system groups for group extraction).  

 

Gateway access is governed by the authentication policies applied to either vpn global or vpn vserver bind points and involve management of the aaa users / aaa groups.

 

Usually can use the same policies in both places, but if you need to change authorization/authentication requirements such as only certain groups on system but other groups on gateway, then having a separate set of authentication policies can help.

 

So your first issue was changing from authentication/not authorized to not authenticated.  Which i went over several methods for, but we might just need more information to narrow it down.

The new issue you are bringing up is properly separating gateway access from system access, which means you might be looking at the wrong entities while trying to manage issue 1.

 

5 hours ago, Philip Hall said:

I do not understand why it is using this LDAP policy as that is only used for access the remote gateway.  The User Administration only has the second policy in use that allows members of the VPXAdmins group access as a superuser.

Based on this statement quoted, I think you are mis-understanding something. Superuser is a command policy which is an authorization policy. This doeesn't tell you what authentication policy is in use on the global system object.  If an LDAP call is being invoked during access a management IP, then you have an authentication policy bound to the system global object. (or I've misunderstood your issue.)  See if any of the above info helps.

 

 

To Troubleshoot/Continue:

So, first we have to figure out what your authentication dependencies are for your system access and separately your gateway access.

Then go back and redefine which one are we trying to fix (system, gateway, or both).

Then we can figure out how to address the problem.

 

For system access/admin stuff:
show ns runningconfig | grep "system global" -i

# should show you all authentication (and other stuff) bound to system global for admin rights.

show system user

show system group

# should let you see what your system groups for group extraction are dependent on

# If you know, your authentication policy name, you can also do this to see where all it is in use; same from group names:

show ns runningconfig | grep <policy name> -i

 

NOTE: removing a group from the system group list does not deny authentication. 

If your scope of authentication policy is any account in domain. Then any account in the domain with valid credentials will successfully login.  Then the authorization decision is made; if the user account doesn't match a group in the system group list, it will inherit a default authorization DENY. Which means they login, but have not rights to execute any command so they are less than read-only.

 

To make these out of scope admins no long allowed to login, you have to change the way we define the authentication policy in use on the "system global" bind point. If this is not a change you want to affect gateway users too, then a separate policy for system access should be used.

 

For gateway stuff, you can review this:

#these command will pull back everything at these levels, which may be way more than just authentication. But you can narrow output to the authentication stuff if needed

show ns runningconfig | grep "vpn global" -i

show ns runningconfg | grep "vpn vserver" -i

show ns runningconfig | grep "aaa group" -i

show ns runningconfig | grep "aaa user" -i

 

OR just do a 

show vpn vserver <vpn vserver name>

to see the policies bound to it.

 

Link to comment
Share on other sites

Hi Rhonda,

 

It was my mistake, I accidentally applied the Remote Users to the System Global binding.  Which caused the issue.  Once I removed this everything worked as it should have.  My error and very basic one at that.

 

As for GSLB Sync.

 

I have checked the logs in the /var/netscaler/gslb folder on both primary VPX's and there is no errors on any concern as to why GSLB sync is using the insecure port.

 

I have checked RPC on both Sites and all IP Addresses are marked as secure with the same password.  

 

Its very odd that the MEP sync is using secure port 3009 whereas the GSLB sync is using the insecure port 3010 over the same SNIP connection.  I would attach the print out from the TCP/IP Connections, however they include IP addresses that I do not wish to make public.

 

Would you be ok if I can private IM you?

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...