https://worldofeuc.com logo
Join Slack
Powered by
Citrix FAS Issue: "The request is not supported" w...
# citrix-cloud
c
Citrix FAS Issue: "The request is not supported" when launching a session. Working on a migration from on-prem to Citrix Daas. Fas in use without issue for the on-prem environment. New environment is Citrix Daas and Azure resource location with FAS servers in Azure also. PKI Infrastructure is on-prem still. FAS servers in Az authorised to Citrix cloud and using the same CA's as on-prem. Kerberos Logging enabled on the VDA and seeing error “KDC_ERR_PADATA_TYPE_NOSUPP” mentioned here - https://www.citrix.com/blogs/2019/04/24/troubleshooting-the-federated-authentication-service/ and here but with event id 3 instead of event id 9 - https://www.ferroquesystems.com/resource/issue-citrix-fas-sso-incorrect-username-or-password-kerberos-event-id-9/. Has anybody seen similar or got any ideas? Thanks.
r
Are you using storefront or workspace?
c
workspace
r
Can the cloud connectors talk to the fas servers on port 80? Also does you gpo on the fas servers match the one on your vdas?
n
@Rob Zylowski the cloud connectors do not need to contact the FAS servers. GPO/registry settings would be the first thing to check.
j
I usually see this if the AD boxes don't have proper certs from the same CA as the FAS servers.
c
Will double check the GPO is applied to FAS servers, i know it is applied correctly to the VDA's. @Jeff Riechers yeah, this is where i think the issue might be but failing to spot anything yet.
r
But if it was working before wiht the same CAs then the DCs should have the kerberos certs
c
not sure if FAS will talk to local DCs in Az compare to on-prem FAS (working) talking to local DC's on-prem. Certs may not be matching up across both locations. CA's also on-prem only.
j
According to the notes you need the certs on all DCs
r
@Nathanael Davison Doesnt workspace need to talk to the FAS servers via WCF on 80 via the Cloud Connectors?
c
spotted this one also, checking DC's now.
@Rob Zylowski firewall rules should be in place to allow that traffic. Also would the FAS setup to Citrix cloud not fail without that?
n
FAS has a direct connection to the cloud - it doesn't go via Cloud Connectors.
r
Oh thanks I never knew that. Need to update my diagrams 🙂
Actually looking again I had it right in my diagrams just not in my head
🙌 1
I see that same error in our Netscaler documentation wiht references to this: Smart card logon is being attempted and the proper certificate cannot be located. This can happen because the wrong certification authority (CA) is being queried or the proper CA cannot be contacted. Are you seeing that err on the VDA or on the FAS server?
c
No errors on FAS server. Kerberos logging on the VDA shows event id 3 with “KDC_ERR_PADATA_TYPE_NOSUPP”. On the DC i do see an error like the one you mentioned - event id 29.
Confirmed the smart card and KDC certs are NOT present on all local DC's. However they are also not present on ALL DC's on-prem and existing env is working fine. Could be coincidence i guess and VDA's trying the same DC always...
either way i will look to get the cert replicated around the DC's
r
Well not present on all means luck of the draw. They are absolutely required. There are two possible certs though the domain controller cert and Kerberos cert and they need to on;cude smartcard auth. You would want to use the kerberos one.
c
Understood.
Got the certs distributed, de-authorized and re-authorized and now the behavior has changed. No longer getting error on VDA and DC, now seeing event id 123/124 on FAS and CA failure to issue the cert with event id 22 and "one of the CA certs is not trusted by the policy provider".
checking these new errors now.
r
h
Make sure that pkiview.msc is good and the AIA/CRL are in place and reachable, validate the entire chain to be trusted root/int/issueing in the domain, check valid Kerberos authentication templates from ADCS on all domain controllers being used, also validate the container options in pkiview that ntauth is filled with the issueing ca of the Kerberos template
c
Update: Issue was down to the fact that the cloud based DC's were running server core so the certs had been imported to the DC using a remote MMC console which meant they were missing the private key. Re-importing the certs using the local cli of the DC resolved the issue. Thanks all for the assist!
h
My advise should be that auto enrollment for the DC's should be checked, this should not be a manual task.
👍 1
31 Views
Open in Slack
PreviousNext
Powered by