This message was deleted.

check again, I'm currently installing it

OK yep, a quick refresh and it's showing up now.

quite the thing again...

82.41 got RTMed today so it's probably just taking a minute to propagate through the CDN/etc

We just upgraded two HA pairs at different costumers, I didn't have any issues while my college got a console error "ssl3_get_record wrong version number" which resolved by enabling TLS 1.2

was your prior version the latest before today? or is this that HA bug that was introduced a few versions back?

Another day, another ADC vulnerability 🙄

The device with the SSL error was upgraded from NS12.1-60.19.nc, the other one was on 13. Indeed, we also added the relayStateRule.

does anyone have sample configuration available if we have set up ADC as a SAML SP and the IdP is Azure AD (with or without ADFS)?

Anyone configured the relayStateRule and got it working with the Workspace App? I'm getting the same as @Mads Petersen is reporting on twitter - "RelayState in Response does not match with rule in Action. Please contact your administrator

This is what i'm seeing in my debug with using Azure iDP. if i decode the Relaystate from a Browser it will start with: ns_policy=auth_azure_samlhttps://gw.netscaler.dk/ Now if i do it from native workspace app, it will look like: ns_policy=auth_azure_samlwv=1&&https://gw.netscaler.dk/ And even a AAA.LOGIN.RELAYSTATE.CONTAINS("https://gw.netscaler.dk") does not match the workspace

Have you started with Citrix Support yet? I will log a ticket in the morning.

I have not yet personally, doing my own troubleshooting, but i know others have done it already.

@Mads Petersen I have also tried (SP end) with no success. We have configured Azure AD as the IdP, which also "pays a visit" to ADFS for password entry. I've tried the following with no success:

set samlaction <http://saml_srv_gateway.company.com|saml_srv_gateway.company.com> -relaystateRule "AAA.LOGIN.RELAYSTATE.REGEX_MATCH(re#^https://[a-zA-Z0-9]*\.microsoftonline\.com/#)"

... and :

add patset patset_customer_azuread_adfs

bind patset patset_customer_azuread_adfs "<https://login.microsoftonline.com>"

bind patset patset_customer_azuread_adfs "<https://fs.customer.com>"

set samlaction <http://saml_srv_gateway.customer.com|saml_srv_gateway.customer.com> -relaystateRule AAA.LOGIN.RELAYSTATE.CONTAINS_ANY("patset_customer_azuread_adfs")

I've tried a lot of weird combinations of regex/pattern set. I think the issue is related to how the relay state is different based on browser/workspace app. I have an weird idea that the && which is added in the relay state for workspace app, breaks the encoding. I plan to play around with encoding, but we have Citrix PTEC the next couple of hours, so that will tonight

oh, got it working

I've got a handful of 12.0's out there, completely missed the EOL last Oct. I'm diving into change logs/notes as we speak, but any 12.0 -> 12.1 gotchas come to mind immediately?

@Jon Bucud, perhaps a separate thread on this one?

@Kari Ruissalo (WyW) does it work with native workspace app? I assume you're testing with a webbrowser, because yes if you're SAML SP, it will be the URL that the client enters, not the iDP. I've tried this regex also AAA.LOGIN.RELAYSTATE.REGEX_MATCH(re#^https://[a-zA-Z0-9]*\.customer\.com/#) and workspace app still breaks

@Mads Petersen, I'm getting this error on WSApp too, it's working in browser

Yeah, that is the issue i'm reporting. I've created a support case on the workspace app issue, so i'm working with Citrix on it now. the problem is related to how the relaystate is, there is a difference from a browser and the workspace app

thanks @Mads Petersen, please share what you'll find. I don't love this.

That issue i haven't seen, and i've added/removed the rule a lot of times today

yeah... just need to do an ADM job to clear that one out

I've already capture the traffic and i know what the difference is, the problem is that the SP FQDN is shown in both relay states, so a simple contains fqdn.tld/ "should" work. I might do a little more troubleshooting tonight, but it's been meetings back to back all day, so i'm not sure if i want to do more today. I've provided citrix with captures and information, so i might just wait to see what they get back with

oh ok, thanks for sharing

thanks for all the information, will keep an eye on this thread.

Anyone see Henry's post about 82.41 breaking XenMobile? https://twitter.com/hereshenry/status/1402593293561704448

Yes i've seen that one, but i also seen he fixed it with a traffic policy

One more thing of the CVEs; are these raised in well known forums like nist.gov, or similar (at least the Finnish security officials haven't raised this as an issue yet)? I'm also concerned of how high the severity on these is?

The DoS is rated as medium, it will requre you have layer 2 access, and some more stuff i can't say here because of NDA - i wouldn't schedule an emergancy upgrade because of this one The SAML is rated a high, but it does require a phishing attack to happen beforehand, so the user would need to click on a link or something, to visit an endpoint at the attacker beforehand, so it's not an easy exploit. So even with a way to steal a valid user session, it does require other bad stuff to happen beforehand

Reply for follow 😅

thank you @Mads Petersen!

We had also several deployements for our cuustomers were we updated and applied the change. In some situation some could logon and some could not. We currently made a copy of the action (as we could not change the existing one)

Just had customer who got the following message after updating HA cluster (Version 12.1) "Unable to establish connection with the secondary. Command propagation failed". Then I remembered that he automatically turned on Secure HA (TCP 3008). After I checked on the internal service that the certificate is bound correctly, I activated TLS 1.2. Voila and the sync runs again.

We did some test with saml tracer in Firefox (fyi published apps were started via a different portalsite, Workspace365) , (the relay state is encoded in base64) and found out that in our case it contained the following info

"ns_policy=your_saml_action_name<nul>/Citrix/StoreWeb/Workspace365AppLauncher.html?appname=AppName"

so this did not contain the hostname but something different. so we need to expand our expression probably with something like

|| AAA.LOGIN.RELAYSTATE.CONTAINS("/Citrix/StoreWeb/Workspace365AppLauncher.html")

We have to schedule maintenance with the customer to test this. When I know more I will post it here.

We're eagerly waiting for a solution for the Workspace App side. I'm also a bit afraid that if we get the Windows WSApp working, we'll face issue with OS X, Android, iOS WSApps... no news on the support case yet @Mads Petersen?

All i can share is expect good news soon

We patched one production environment (12.1-60.19 -> 12.1-62.23) on Wednesday. Yesterday everything worked just fine, but today we started getting an error on Workspace App (see screen capture). We haven't implemented a relaystaterule for this environment due to WSApp -problems. As a precaution I always update just one node and wait for a couple of days before upgrading the other node, so I just HA failovered to the node that wasn't yet patched and everything started working again. The error message is in German and we're located in Finland. I have no idea why the error message is in German, but Google translate results in "demand can not be completed". So my guess is, that this originates from StoreFront and is "Request cannot be completed"

Yes smells like StoreFront. What is in the Event Log on your StoreFront Server ?

I'm logging in just now to see

Have also converted several customers with SAML. Without Rule of course. They are all still running, without any probs

are you running FAS?

Is your FAS server certificate still valid, could be a coincidence? Also check your FAS eventlogs (Application)

I did check the logs, but there was nothing

Also we removed the relaystate expression for some of our customers. And they are functioning without issues. Waiting on more info currently

@John Billekens, did you find a way to remove the relaystaterule expression without recreating the saml actions?

no, temp create a new action (click the excisting one and select add, it will use the same settings) just change the name and remove the expression. Click add. Then in policy change to the new action

that's what I did too... not optimal...

Via the vendor of Workspace365 portal we got the following expression and this seems to work in our case.

AAA.LOGIN.RELAYSTATE.EQ("<https://portal.domain.com/>") || (AAA.LOGIN.RELAYSTATE.LENGTH.EQ(0) && HTTP.REQ.HOSTNAME.EQ("<http://portal.domain.com|portal.domain.com>"))

not sure yet if it works in all cases, but it was an improvement.

can't try this today anymore with WSApp, but looking forward to see how it works, thank you!

Np, as said earlier, I have not yet had time to test it thoroughly but wanted to share it.

I bet someone will test this in the US timezone today and report back 🙂

Confirmed by Citrix engineers that this adjustment is secure against the CVE-2020-8300

Firmware out that fixed the CWA bug. • The authentication from Citrix Workspace app fails when Citrix ADC is configured with SAML authentication and relayStateRule. The browser based login is not impacted. • [ NSAUTH-10517 ] Was not expecting it today, but tomorrow 🙂

But I still enough. The latest 12.1 version also fixes the error. 😂😇

what kind of expression did you end up using?

The new version solves the issue with CWA, but it's still recommended by Citrix support to use this expression (n our case):

AAA.LOGIN.RELAYSTATE.EQ("<https://portal.domain.com/>") || (AAA.LOGIN.RELAYSTATE.LENGTH.EQ(0) && HTTP.REQ.HOSTNAME.EQ("<http://portal.domain.com|portal.domain.com>"))

I'm using a regex match rule

AAA.LOGIN.RELAYSTATE.REGEX_MATCH(re#^https://[a-zA-Z0-9]*\.domain\.tld/#)

thx guys, I'll check with support myself too. Just for laughs if we get a third one 😄

Fyi if you are using a aaa auth vserver for access to cs/lb vserver. Add all fqdn's to your expression for each site, add |`|| AAA.LOGIN.RELAYSTATE.EQ("https://authsite.domain.com/")`

I have a client where multiple users have bookmarked the ADC page after they've logged in, ie the URL is https://gateway.domain.com/citrix/storeweb and if they use this bookmarked URL we are seeing the "RelayState in Response does not match" error. Debug shows the relaystate as "ns_policy=samlaction/citrix/storeweb/", I've tried multiple versions of the Relay State Rule with regex as per Citrix doco, minimal versions eg AAA.LOGIN.RELAYSTATE.CONTAINS("storeweb") and more but unable to come up with something that works. Anyone else seen this and can help me out?

We're seeing the same exact issue with web browsers as @Daniel Marsh and the only way around the issue seems to be to either use incognito browser mode or empty the browser cache

I've been given another expression to try by a Citrix engineer - have not tested yet, I'll be doing this tonight:

AAA.LOGIN.RELAYSTATE.EQ("<https://example.com/>") || (AAA.LOGIN.RELAYSTATE.LENGTH.EQ(0) && HTTP.REQ.HOSTNAME.EQ("<http://example.com|example.com>"))