Rasmus Kindberg
-
Posts
27 -
Joined
-
Last visited
-
Days Won
2
Content Type
Forums
Articles
Labs
Videos
TechZone
Citrix Community Articles
Events
Profiles
Posts posted by Rasmus Kindberg
-
-
From what I understand, Citrix changed the internal STA Monitor on Netscaler in version 13, and a consequence of this is that sometimes it takes 15-30 min for STA servers to go from DOWN to UP after upgrade. I have experienced the same as you, but after re-adding the STA servers and waiting they came up automatically after a while.
Have you run 'dig FQDN' in Netscaler cli to verify the DNS lookup?
-
You can run https://www.nirsoft.net/utils/smsniff.html (packet sniffer) on your radius server and see if there are any incoming requests to the radius server on port 1812. If you see requests from vpx node 1 (the one that doesn't work) then your firewall is allowing the traffic and then you need to check the radius logs on the radius server itself (wrong secret key or sourceIP perhaps).
-
If you have specified the Radius servers directly in your Radius Actions on Netscaler, then Netscaler will use NSIP as the sourceIP when sending Radius traffic to the servers. If you have specified the IP of a LB vServer in your Radius Action, then Netscaler will use SNIP as SourceIP.
My guess is that you're not using a LB vServer and you have only specified the NSIP of Netscaler node #1 in your internal firewall and/or in the radius configuration on your radius servers. When you failover to Netscaler node #2, a different NSIP is used.
-
Try changing the Policy Expression to 'true' (temporarily), and only configure some of the parameters of the Transform Action. On many Netscaler versions the GUI for transform actions is bugged and causes settings to not apply correctly. I would avoid using the GUI, if possible.
Example through CLI:
add transform profile URL-TPR-SHAREPOINT
add transform action URL-TPA-SHAREPOINT-01 URL-TPR-SHAREPOINT 100
set transform action URL-TPA-SHAREPOINT-01 -resUrlFrom documentsiteinternal -resUrlInto documentsiteexternal.external.domain
add transform policy URL-TPO-SHAREPOINT true URL-TPR-SHAREPOINT -
On 1/27/2020 at 10:01 AM, Jens Dellner said:
Hi Philipp,
I had a similar problem some weeks ago. I don´t know what happened but one morning the portal theme was not shown any more. I figured out, that one link from the Portal Theme to tmindex.html was missing. I fixed it this way:
1. Connect via WinSCP to all affected appliances
2. Change directory to /var/netscaler/logon/themes/<Your Portal Theme>
3. Rightclick -> New link
Link/shortcut file: tmindex.html
Point link/shortcut to: /var/netscaler/logon/LogonPoint//tmindex.html
Maybe it is not exactly your problem, but it helps you for further troubleshooting.
Best regards,
Jens
I ran into the same issue and above resolved it for me as well. Note that it should not be '//' before 'tmindex.html' but just 1 forward slash, ie /var/netscaler/logon/LogonPoint/tmindex.html. Also in my case it was 'index.html' that the link needed to point to and not 'tmindex.html' (depends on Theme type and whether it's AAA or VPN vServer, I believe).
Thanks Jens-Dellner.
-
As you mentioned, SmartAccess is one way to do it. Another way is to configure BrokerAccessPolicy through Powershell on your Citrix Delivery Controller. See https://developer-docs.citrix.com/projects/delivery-controller-sdk/en/latest/Broker/Set-BrokerAccessPolicyRule/.
Basically, whenever you create a Delivery Group there will be 2 BrokerAccessPolicy rules attached to it by default, one for internal access (directly through Storefront) and one for external access (through Netscaler). On your Delivery Group 'A' which contains Apps and Desktops that you don't want to show to external users, you can configure the external BrokerAccessPolicy tied to this DeliveryGroup with the parameter 'ExcludedUsers' and specify the 'another group' (that you refer to above) to prevent those users from seeing any Apps or Desktops from that DeliveryGroup when they logon through Netscaler.
You then create a new Delivery Group 'B' which is specifically meant to only contain those Apps and Desktops that you want your external users to see, and you can do this by specifying the 'IncludedUsers' parameter on the external BrokerAccessPolicy (for this Delivery Group) and specify the 'another group' you referred to.
Benefit of above is that all the config is done on the delivery controller, while SmartAccess is a bit messy and relies on policy names on Netscaler matching the specified name on Delivery Controller etcetera.
-
AAA/VPN vServers and NSIP/MIP and SNIP (with management option enabled) are vulnerable. If you don't use AAA/VPN vServers, then only users on internal network are a potential attack vector (but this can be handled with ACLs restricting access from only specific servers/subnets).
-
1
-
-
One way is to enable encryption on the radius traffic (NPS server setting + specify encryption in Radius Action on Netscaler), which should solve the issue for you.
The other way is to configure LDAP + Radius authentication (both) on Netscaler, where LDAP auth is performed first. This will allow password changes to be made (and this is regular LDAP, no Radius). The Radius auth is then purely for MFA authentication (and not password changes). There will be no change in behaviour for end-users (still only 1 prompt).
-
I'm not 100% sure, but: above solution in https://support.citrix.com/article/CTX208789 would work if the theme wasn't RfWebUI. With RfWebUI, the HTML content displayed on AAA page is generated dynamically upon load and not read from a .html file (like tmindex.html). What you probably need to do is instead of a Responder Policy redirecting, you create a Rewrite that changes the HTML contents of the AAA HTML code returned and then bind the rewrite policy globally with an expression HTTP.REQ.HOSTNAME.SERVER.EQ("myaaa.mydomain.com") (you can't bind Rewrite to AAA vServers directly).
Below is an example of a rewrite action that remove the 'Password 2' field that is displayed on AAA page when 2 factor auth is enabled. This particular Rewrite isn't related to above, but it should help you give an idea on how to specify the rewrite action. I think it will take some time for you to get it working, just so you know.
add rewrite action RWA-RES-REMOVE_2ND_PASSWORD_FIELD_RFWEBUI replace_all "HTTP.RES.BODY(99999)" "\"\\r\\n\"+\n\"<style type=\\\"text/css\\\">\\r\\n\"+\n\"[for=\\\"passwd1\\\"] { display: none;}\\r\\n\"+\n\"#passwd1 { display: none; }\\r\\n\"+\n\"[for=\\\"response\\\"] { display: none;}\\r\\n\"+\n\"</style>\\r\\n\"+\n\"\\r\\n\"+\n\"</body>\\r\\n\"+\n\"</html>\\r\\n\"" -search "text(\"</body>\n</html>\")"
-
You need to perform a network trace on Netscaler to get the traffic flow between Netscaler and the backend server during a POST upload, and then you will be able to see the behaviour of Netscaler.
I wrote a blog post about this a while back that might be useful: https://tech.xenit.se/netscaler-resolve-large-http-post-packets-against-aaa-protected-lb-vservers/
-
This might be related to an issue I raised with CItrix Support. It seems that using RfWebUI + iPhone + mobile app to receive the OTP code is not working correctly (it is javascript code in RfWebUI that is not compatible with recent iPhone changes from Apple). It is specifically the swap from Safari (on phone) to Authenticator app and back to Safari again that was failing for us.
Do you get the same issue if you use android? You could also test this using 2 iphones, iphone #1 is doing the Netscaler login and iphone #2 is the one with the authenticator app which receives OTP (this way, the #1 phone never has to 'leave' Safari app during logon).
The response from Citrix was that this is an Apple issue (which I strongly disagree with) and Citrix wasn't gonna pursue a solution. In our case we decided to just use X1 Theme instead of RfWebUI (since X1 theme doesn't have the same 'faulty' javascript), but this gives worse user experience due to X1 not adapting to phone screen size resolution.
-
Hi,
When creating Bookmarks on Netscaler for Unified Gateway we usually bind these Bookmarks to a AAA group (and create an AD group with identical name) to give users access to these based on group membership. However, I don't know how to handle the scenario where you have multiple VPN vServers (with Unified Gateway) and you only want bookmarks to be displayed to users on one of these VPN vServers. I could obviously bind the Bookmarks to the specific VPN vServer directly, but then we lose the group membership filtering/distinction.
I haven't encountered above with a customer yet since they have only used 1 VPN vServer with Unified Gateway, but I'm pretty sure above scenario will arise sooner or later.
Any suggestions are appreciated.
-
I don't think you can share SSO between Authentication vServers and VPN vServers (AAA to AAA and VPN to VPN however are fine). A workaround for you would be to recreate the Authentication vServer as a VPN vServer instead (I can't think of any technical drawbacks to it) and ensure the "Authentication domain" in both authnprofile's you use is the same.
You can try above by temporarily creating a new VPN vServer and see if it shares SSO with your Unified Gateway VPN vServer.
-
Wouldn't it work to use NSGW completely instead of mixing Storefront LB + ICA routing? I'm guessing you don't do this because then you lose the automatic SSO that happens when the internal user, in your scenario, browses to the Storefront LB VIP?
Perhaps you could configure a Negotiate Policy (kerberos) on your VPN vServer (or AAA vServer and have the VPN vServer point to the AAA through an authnProfile) to resolve SSO to Netscaler?
-
46 minutes ago, Simon Hearnshaw1709158117 said:
Thanks for the suggestions and links. I don't think this URL will work with my setup as whenever I try to go to those links it just redirects me straight to the logon URL for sign in and as the AAA address doesn't match the application reply address it gives me an error.
Seems from the links you gave that URL would be more if I was accessing an application via a LBVS where with my setup we are accessing a NetScaler Gateway Virtual Server.
Try /cgi/logout. The 'tmlogout' is for AAA vServers.
-
Default authentication for ActiveSync traffic is Basic auth on the backend servers, which is one of the reasons why you simply let that type of traffic through AAA. I haven't tried this, but you could probably change to WIndows Authentication on the backend for the ActiveSync virtual directory specifically and then configure a Traffic Policy + Profile on your Exchange ActiveSync LB vServer to handle 401 Windows Auth SSO. So ActiveSync devices would auth at AAA, hopefully save the AAA cookie generated and re-use this cookie for subsequent requests, and at the same time Netscaler will cache the credentials and use them to provide SSO to backend when backend requests auth. But the issue here is that the AAA cookie won't be persistent, so users will have to auth against AAA every so often.
You can run below PS command on your backend exchange to see the current configuration for activesync:
Get-ActiveSyncVirtualDirectory | fl identity, *url*, *auth*
-
Active-Sync traffic should be allowed to bypass AAA and hit backend exchange servers directly (you can achieve this with Content Switch policies to separate "/owa" traffic from "/microsoft-server-activesync" and have one LB vServer for the owa traffic and another LB vServer, without AAA protection, for the Active-Sync traffic) . If you have already done this and you have verified that CS policies are applied correctly, then I would look at the authentication configuration on your exchange servers and/or any logs there.
-
1
-
-
If you load balance Storefront through Netscaler you can through a Rewrite Policy on Netscaler ensure the cookie is always deleted, thus ensuring the choice always appearing to the user.
-
- External access to an RDS environment is less user-friendly than Citrix (less SSO, more popups)
- Smartcard authentication sucks on RDS
+ RDS is much cheaper
-
1
-
-
You want to specify 'Default group' ("FakeGroupDomainA" for example) in the LDAP server profile, and then use HTTP.REQ.USER.MEMBEROF("FakeGroupDomainA") in the session policy to apply the correct session policy depending on which sub domain the user authenticated against (so you have the LDAP policies for each sub domain, in cascading list).If your Netscaler version doesn't support Advanced Expressions in session policy then you need to create an AAA group named "FakeGroupDomainA" and bind the session policy to it.
-
Netscaler involved? Do you make use of AAA groups? If Netscaler involved, have you tried logging on with her account directly to either of the two storefronts instead? Tried adding her account manually to a specific published app?
Is her account nested in AD groups similar to other functional users, or her AD nesting unique somehow?
-
Also if you schedule for 30 min after boot, citrix is going to think there is an issue and put the desktop into maintenence mode.
This behaviour can be disabled/modified through registry keys on the DDC.
-
Dear Jay stevens
i've exactly the same problem on Application requesting database (not responding) only on windows 2008...
the same application works fine on windows 2003 (applications is also compliant with W2K8...)
have you find root cause ? or workaround ?
Thnaks a lot for your help
Do you have the XA policy Memory Optimization enabled? Try disabling that and see if that makes a difference.
-
If you are using Netscaler Gateway for login then the account could be used in the LDAP policy.
I would also check if the account is used to run any windows services on your WI or XML brokers (unlikely though)
Netscaler AAA-TM issue with POST dropping form data in the body
in Core ADC use cases
Posted
Hi,
I'm the one who wrote the blog article above. From my testing on later Netscaler versions (12.1 and 13.0) it seems Citrix added additional code to handle this scenario but the new code doesn't actually work. The workaround i describe in my blog is still required, from what I can tell.