Jump to content
Welcome to our new Citrix community!

ADC VPX 13 and XenApp & XenDesktop wizard


NEY

Recommended Posts

Hi,

 

I just installed an ADC VPX v ° 13 VM in DMZ.
I used the XenApp & Desktop wizard in the "Integrate with Citrix Products" panel which is very easy to use.

All the wizard's connection tests are correct (Delivery Controller connection and LDAP connection) but I cannot authenticate with an account on the home page.

 

Which log files can I consult to resolve my problem ?

 

Thanks

 

Nicolas

Link to comment
Share on other sites

Use the ADC debug daemon to see what's happening in real time.

Open up the CLI via PuTTY to the NSIP of the appliance.

Type shell to get to the shell.

Then start the daemon:

cat /tmp/aaad.debug

 

Then browse to the logon page and try to log in.

You should be able to see what's happening.

Hit CTRL-C to exit the daemon.

Link to comment
Share on other sites

Hello Carl,

 

In fact I can't connect to the SNIP address (172.20.05).

I can only log in to the Netscaler address (172.20.0.4 for me).

Can the SNIP IP address be in the same subnet as the Netscaler address ?

 

Nicolas

Capture.JPG

Link to comment
Share on other sites

Carl,

 

Indeed I ping the address SNIP well.

When I apply the instructions for your first response (SSH to NSIP) I don't see anything going through the debug Putty window during authentication.

Should the public IP address be natted on the NSIP address ?

Link to comment
Share on other sites

ERU2009 - system authentication for admins is separate from gateway authentication configuration.  

Are you troubleshooting your admin access (to the NSIP or if management access is enabled SNIP).

Or are you troubleshooting your access to the Gateway VIP?

Now the issue with the authentication problem, could be due to the policy config or how the authentication traffic leaves the ADC to get to its destination (which may involve the nsip or snip); but how you attempt the authentication against the NSIP or gateway vip affects whether you are troubleshooting gateway authentication or system authentication.

 

The aaad.debug only outputs external authentication events, not local authentication events.  If you are using ldap or radius (for example), these will generate events in aaad.debug output. If you are relying on local accounts on the adc such as nsroot, then no output will appear here...but then you are unlikely to have authentication failures.  The aaad.debug will show authentication output for either system login or gateway login attempts.

 

So if the issue is gateway authentication, start the debug output. Attempt to login to the gateway vip (https://<gateway fqdn>) and if you are doing LDAP, you should see if the authentication succeeds/fails based on the output.

 

If you are testing system/admin access then you are attempting a connection to the NSIP or the management enabled SNIP, then the aaad.debug will only show output if you are doing external authentication like ldap/radius and not doing local authentication (local accounts on the adc like nsroot or other).  

 

Gateway access is handled by authentication policy bound to the vpn vserver (the gateway) and involves aaa users / aaa groups.

Admin/management is handled by authentication policies bound to the global system object and involves system user / system groups.

 

 

 

Link to comment
Share on other sites

Hello,

 

when I installed the VPX 13, I set up a first IP address (172.20.0.4) which therefore is the NSIP address.

Then the assistant asked me for a subnet address (SNIP) so I put (172.20.0.5).

P.S The 172.20.0.0/24 range is my DMZ.

Then the Virtual Apps-desktops assistant asked me for a public ip address for the virtual server, so I provided the 217.108.x.x.

On my firewall I redirect the incoming https port on the public ip to the NSIP address.

Is that correct ?

Link to comment
Share on other sites

It's better I now have the external interface (VIP) that appears from the Internet.

But now the assistant can't retrieve stores.

However, the SNIP address is allowed to contact the Strorefront server from the DMZ.

Capture.JPG

Link to comment
Share on other sites

You can manually configure the store front stores without the "retrieve stores" working, which is why the Receiver for Web Path field is generated.

So, first: is your storefront server load balanced by this ADC or some other system and do you know the FQDN/Vip for the lb to reference? Or are you pointing to storefront directly (no load balancer involved). You will still need to know its FQDN/IP for the following steps.

 

On this version, the ability for the ADC to connect to the storefront Server is based on:

1) Do you have a DNS server configured to resolve names to ips?  You can test by connecting over ssh to adc and see if the gateway can resolve the storefront name to the storefront server (or storefront lb vip, if configured)

2) Is your storefront server or lb vserver actually on http:// or https://?

3) A SNIP is needed to reach the storefront destination.  (From cli, you can do a ping <storefront ip> -S <snip ip>  to see if the gateway can ping the storefront ip from a specific SNIP.

 

If these work, then it should be able to retrieve stores IF the storefront is on a recent version.

If not, you can still configure the store path manually by specifying /Citrix/<pathWeb> in the web path field.

If the connection doesn't work, you still might need to troubleshoot the above.

 

 

 

Link to comment
Share on other sites

Hi,

 

I feel like I'm not very far away from having a Citrix Gateway that works !

 Right after successful authentication (AD domain) I have an error message "cannot complete your request".

I do not know if this is related but in the XenApp & Desktops wizard when I click the "retrieve store" button the assistant picks up the store well but corrects the URL of the storefront by removing the domain. This message appears "The URL specified by you for StoreFront seems to have changed and hence has been auto-corrected from http://Srv-SGE-CTL-01.mydomain.fr to http://srv-sge-ctl-01 ".

Do you know where this error came from ?

 

Thanks

Nicolas

 

 

 

 

 

Link to comment
Share on other sites

2 hours ago, NEY said:

This message appears "The URL specified by you for StoreFront seems to have changed and hence has been auto-corrected from http://Srv-SGE-CTL-01.mydomain.fr to http://srv-sge-ctl-01 ".

Do you know where this error came from ?

 

So this can happen for a couple of reasons, you can still manually edit.

But its likely because your storefront sever does not have a cert bound AND the base url of your storefront says srv-sge-ctl-01 and not the fqdn.

So the wizard is "helping" by changing things to match your storefront config...but if the config isn't finished the wizard is now anti-helping.

 

1) All gateway to storefront communication should be https and not http:// for best security.  

2) Easier to set up the cert on the storefront (and any storefront load balancing) before running the gateway's storefront integration wizard or you will have to manually update or override the wizard settings anyway.

3) Be sure that the storefront base url (whether http or https) is actually configured to match the fqdn that users will use to connect. If load balancing storefront, the base url may need to be updated to match the load balanced fqdn and whether http or https is in use.  (The cert binding usually takes care of this...but there are factors).

 

4) When you then point the gateway to the storefront to find the stores using name1, it will update its name recommendation based on the storefronts configured base url.  

 

Again manually set the value you do want, or configure manually to avoid what the wizard says. Or fully prep the storefront before doing the gateway wizard.

 

 

 

 

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...