Jump to content
Welcome to our new Citrix community!

Malformed Assertion sent to Netscaler; Please contact your administrator - SAML


Rowen Gunn

Recommended Posts

SAML Issue here! I've setup a new SAML nFactor process and I get this Malformed error after the user completes their SAML login. My identical SAML setup works for my ICA gateway but for my VPN gateway I just get the error above. Nothing seems to be different between the two SAML setups, the only difference in the VPN SAML server settings is the issuer name field which is the name of the VPN gateway. I am using SHA-256 already and the same cert works for the working SAML nFactor ICA profile.

 

I can't find any reason for getting this malformed error and so far support hasn't been able to provide assistance. Does anyone know where I can even start to find the cause? I have a SAML plugin for chrome and it shows my ADFS is sending the Netscaler the right SAML reply so I suspect the issue is Netscaler... something.

SAML-VPN-Error.jpg

SAML-VPN-Error-Malformed.jpg

SAML-VPN-Error-ADFS01.jpg

SAML-VPN-Error-ADFS02.jpg

SAML-VPN-Error-ADFS-Claims.jpg

 

Metadata sent from the Netscaler: (domain field changed for post)

<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" ID="_b380316085bbfcee6e646691333c67ac" entityID="https://ctxvpntest.DOMAIN.com">

<md:SPSSODescriptor AuthnRequestsSigned="true" WantAssertionsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">

<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://ctxvpntest.DOMAIN.com/cgi/logout"/>

<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://https://ctxvpntest.DOMAIN.com/cgi/logout"/>

<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://https://ctxvpntest.DOMAIN.com/cgi/samlauth" index="0"/>

<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://https://ctxvpntest.DOMAIN.com/cgi/samlauth" index="1"/>

</md:SPSSODescriptor>

</md:EntityDescriptor>

Link to comment
Share on other sites

Compare your Gateway SAML SP settings with the target SAML IDP settings.  If your IDP is configured for your other SAML SP settings, then it may not match your new SP settings.

Is your IDP returning traffic to the new SP ctxvpntest?

Is the Issuer identified consistently on the new SP and the new IDP.

Does the IDP have the correct cert for itself and the NEW SP cert matching the NEW SP FQDN?

 

Use a SAML Tracer extension in firefox or other browser to compare the sp to idp and idp return traffic.

The malformed assertion is usually an error of the assertion returned by the IDP to the SP with incorrect information. So your IDP may have the wrong SP acs url specified, or the wrong return FQDN, or the wrong SP cert specified? Or the SP has th wrong expected cert for the IDP.

 

 

 

Link to comment
Share on other sites

Same IDP or different IDP as your previous test? If same, is any part of the IDP still configured for the previous sp return details?  If different, double check resolutions, dates, certificates, and certificate trusts on the IDP.

Same ADC appliance and different vpn vserver so same firmware or different firmware between the previous test and this one?

Name specific certs or a wildcard cert? 

 

You really want to make sure from the IDP side that the correct FQDN resolves to the correct IP to return to the ADC, that the correct SP and IDP certs are specified for the correct names and properly trusted especially on the IDP side.  You may need to run a trace to make sure the IDP is sending correct info to the client to return to the SP side.

 

You can check aaad.debug for additional authentication events/info.

 

ADC articles on malformed assertions:

https://support.citrix.com/article/CTX237335/adc-saml-error-malformed-assertion-sent-to-netscaler-please-contact-your-administrator

The point is check the event viewer of the IDP for errors during processing as the issue may in fact be IDP side and not ADC side.

Other thread:  https://discussions.citrix.com/topic/388602-malformed-assertion-sent-to-netscaler/

And Reminder confirm the clock on the ADC and the clock on the ADFS server for drift that might be resulting in errors.

Link to comment
Share on other sites

1 hour ago, Rhonda Rowland1709152125 said:

Same IDP or different IDP as your previous test? If same, is any part of the IDP still configured for the previous sp return details?  If different, double check resolutions, dates, certificates, and certificate trusts on the IDP.

Same ADC appliance and different vpn vserver so same firmware or different firmware between the previous test and this one?

Name specific certs or a wildcard cert? 

 

You really want to make sure from the IDP side that the correct FQDN resolves to the correct IP to return to the ADC, that the correct SP and IDP certs are specified for the correct names and properly trusted especially on the IDP side.  You may need to run a trace to make sure the IDP is sending correct info to the client to return to the SP side.

 

You can check aaad.debug for additional authentication events/info.

 

ADC articles on malformed assertions:

https://support.citrix.com/article/CTX237335/adc-saml-error-malformed-assertion-sent-to-netscaler-please-contact-your-administrator

The point is check the event viewer of the IDP for errors during processing as the issue may in fact be IDP side and not ADC side.

Other thread:  https://discussions.citrix.com/topic/388602-malformed-assertion-sent-to-netscaler/

And Reminder confirm the clock on the ADC and the clock on the ADFS server for drift that might be resulting in errors.

 

So I have 2 SAML profiles on my ADC, 1 for nFactor ICA/StoreFront which works perfectly and 1 for VPN which has this error. The only difference between the two is the Issuer field which I've put the VPN gateway in. On the ADFS side the setup is also exactly the same between the two Relying parties except the return, so the ICA Relying party has my ICA gateway in it and the VPN Relying party has my VPN gateway in it (screenshots above.) Effectively I just cloned the working SAML ICA nFactor setup and just changed the name for the VPN gateway.

 

I'm showing no errors in the ADFS server logs, so I think the IDP SAML server is sending over the right data to the Netscaler.  Certs are name specific and the ADFS/SAML cert for the working ICA setup is the same cert tagged on the VPN SAML setup. Clocks appear to be correct, if they were not I would expect my ICA SAML setup would be failing and it's not.

 

Do you need to do anything different for SAML when using it for a VPN gateway and not an ICA gateway? This works in Azure, I was able to build an Azure SAML provider and get this working but I'd like to get our on-prem SAML working if possible.

Link to comment
Share on other sites

2 hours ago, Rowen Gunn said:

he only difference between the two is the Issuer field which I've put the VPN gateway in.

The SAML SP policy should have a matching cert used by the IDP.  So your icapolicy would have the ica IDP cert info AND your vpn policy should have the new IDP cert info (gateway is looking for idp cert 1 and your assertions are signed by idp cert 2, then you will have the assertion problem.)

So, its not just the Issuer field that has to be unique.

Also the new SP policy should have its own cert for its own requests (unless you have a wildcard cert on the ADC).

 

How do you distinguish the IDP for the ica flow different from the IDP for the vpn flow?

 

If both IDPs are on the same ADFS server, then I think your vpn SP is actually asking your IDP #1 to respond and so the info doesn't match what the SP is expecting.

Meaning, is your vpn SAML SP policy pointing to the correct instance of the ADFS IDP that is expecting the request from vpntest? 

And is the cert you've bound in the vpn SAML SP policy the actual cert the ADFS IDP is using to sign your assertions for the vpn test and not the previous ica test?

>> So did you update the IDP cert binding on the gateway to match the cert the ADFS IDP is actually using.

 

2 hours ago, Rowen Gunn said:

Do you need to do anything different for SAML when using it for a VPN gateway and not an ICA gateway? This works in Azure, I was able to build an Azure SAML provider and get this working but I'd like to get our on-prem SAML working if possible.

 

This shouldn't be "different" matter unless we're not addressing content switching + gateway OR you have something wrong on the Authentication vserver integration (if in use).

 

 

 

 

Link to comment
Share on other sites

Ok I guess I explained this weird...

 

My ADC has now 2 separate SAML servers, policies, etc. 1 is a working ICA SAML setup and 1 is a not working VPN SAML setup. There's no difference between the two SAML setups except the Issuer field. On the ADFS side they are setup the exact same except the Referral is changed to be the name of the gateway sending the SAML request (aka the ICA or VPN gateway) and the login URLs also point to their respective gateways.

 

Attached is the two setups side by side, the working and not working. You can see they are literally the same, minus the Issuer. 

 

 

SAML-VPN-BothConfigs.jpg

Link to comment
Share on other sites

I believe I've fixed this issue, unlike the ICA SAML setup the VPN/CVPN SAML setup requires the Signing certificate added. While for the ICA SAML I could leave that blank on both ADC and ADFS side for the VPN SAML setup I had to put the VPN's certificate in the signing certificate name field and in the ADFS relying party for the VPN login. Once I did that authentication worked as expected and I was able to SAML in.

  • Like 1
Link to comment
Share on other sites

  • 5 weeks later...

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