Rico Posted June 2 Posted June 2 (edited) Hi, Currently I am testing with TrueSSO for VMware Horizon. Because of this, I want to enable SAML authentication on the UAG side too. In Azure/Entra ID I have created an Enterprise Application, based on the built in template of the Unified Access Gateway. In the UAG admin interface I have uploaded the SAML metadata of the relaying party / enterprise application. During this process I don’t have enabled the option called Always force SAML Auth. Because of this, I don’t expect a forceAuthn=True property in the SAML request. While testing this configuration, the Horizon Clients opens a webbrowser. Unfortunately I need to log in with my Azure AD credentials, even when the device is a corporated enrolled device which is Entra ID joined. After given my credentials, everything is working fine. Even TrueSSO works when I click on a desktop pool. But, I want a full single sign on. When inspecting the SAML request, unfortunately I see a forceAuthn=True. This should not be the case, since I have not enabled the Always force SAML auth option. When I export the UAG settings to a JSON file, I see the forceAuthn is set to FALSE of the identity provider settings. So this is weird. Anyone else seeing this behavior? How can I fix this? Some facts: * Unified Access Gateway 2306.1 2309 * VMware Horizon Connection Server 2312.1 * VMware Enrollment Server 2312.1 Thanks in advance! Edited June 4 by Rico Wrote the wrong UAG version.
Employee Sascha Warno Posted June 3 Employee Posted June 3 Besides the forceAuthN, you say the device is Entra ID joined. Is the PRT for SSO on the device? What does dsregcmd /status show for SSO State? And what browser does it open? If the PRT is present it should bypass the credentials. 1
Daniel Keer Posted June 4 Posted June 4 On 6/2/2024 at 1:07 AM, Rico said: While testing this configuration, the Horizon Clients opens a webbrowser. Unfortunately I need to log in with my Azure AD credentials, even when the device is a corporated enrolled device which is Entra ID joined. I was playing with this but haven't done the TrueSSO part yet and everything seems to SSO all the way to the horizon app launcher screen. I'm on 2303. What happens if you launch the Enterprise app from the myapps.microsoft.com screen to make it launch the Horizon client? Could an Entra ID Conditional Access policy be messing with it? I have mine configured to force MFA after 1 hour. 1 vExpert ⭐⭐ | Omnissa Tech Insider Blog theDXT.ca
Rico Posted June 4 Author Posted June 4 (edited) 3 hours ago, Daniel Keer said: I was playing with this but haven't done the TrueSSO part yet and everything seems to SSO all the way to the horizon app launcher screen. I'm on 2303. What happens if you launch the Enterprise app from the myapps.microsoft.com screen to make it launch the Horizon client? Could an Entra ID Conditional Access policy be messing with it? I have mine configured to force MFA after 1 hour. @Daniel Keer maybe something has been changed since version 2309.1 (I did wrote the wrong version, excuse me). When launching the app from the My Apps page, SSO works fine. The app launcher screen is loaded directly without asking for credentials by Azure. The problem in my case is that the UAG sends the SAML request to the iDP with the property forceAuthn=TRUE inside it. <saml2p:AuthnRequest xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" AssertionConsumerServiceURL="https://<URL_UAG/HORIZON>/portal/samlsso" Destination="https://login.microsoftonline.com/<app_id>/saml2" ForceAuthn="true" ID="_c3ac0a6d67d9d9792f183842fd576f4c" IssueInstant="2024-06-03T18:29:55.258Z" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" ProviderName="portal" Version="2.0"> <saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">https://<URL_UAG/HORIZON>/portal </saml2:Issuer> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/> <ds:Reference URI=“..”> <ds:Transforms> <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/> <ds:DigestValue>...=</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue>... </ds:Signature> <saml2p:NameIDPolicy AllowCreate="true" Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"/> </saml2p:AuthnRequest> Edited June 4 by Rico
Employee Sascha Warno Posted June 4 Employee Posted June 4 I can see an issue with SAML auth for admins enforcing ForceAuthn even if disabled in GUI. Fix for that seems to coming in UAG 24.06. Let me inquire if that affects other use cases of SAML as well. Do you have a ticket open for the issue? 1
Rico Posted June 4 Author Posted June 4 39 minutes ago, Sascha Warno said: I can see an issue with SAML auth for admins enforcing ForceAuthn even if disabled in GUI. Fix for that seems to coming in UAG 24.06. Let me inquire if that affects other use cases of SAML as well. Do you have a ticket open for the issue? @Sascha Warno sounds good. If you want to check this internally, I will really appreciate it. I have an open ticket: 00628886
Employee Sascha Warno Posted June 4 Employee Posted June 4 Just a heads up on the admin interface behavior, that is actually expected and enforced by us. The update will just address the tool tip to let people know that SAML authentication for the admin portal will ignore the setting and always set ForceAuthN=true. It seems you see the same behavior but other workloads should actually honor the ForceAuthN setting. Do you use SAML for the admin portal as well? 1
Rico Posted June 4 Author Posted June 4 (edited) 33 minutes ago, Sascha Warno said: Just a heads up on the admin interface behavior, that is actually expected and enforced by us. The update will just address the tool tip to let people know that SAML authentication for the admin portal will ignore the setting and always set ForceAuthN=true. It seems you see the same behavior but other workloads should actually honor the ForceAuthN setting. Do you use SAML for the admin portal as well? @Sascha Warno, thanks for the usefull update! I don't use SAML for the admin portal at this moment. Only for the Horizon Edge Service. Edited June 4 by Rico
Rico Posted June 4 Author Posted June 4 (edited) @Sascha Warno I did some tests with the 2306.1 version right now, this version of the UAG does not have this behaviour. See SAML requests which includes the ForceAuthn property with a value of FALSE. <saml2p:AuthnRequest xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" AssertionConsumerServiceURL="https://<portal_url>/portal/samlsso" Destination="https://login.microsoftonline.com/3fb8cd55-4363-44aa-9f95-789cd45be175/saml2" ForceAuthn="false" ID="_09f4f0ae05bbeb174632a373e1e1db02" IssueInstant="2024-06-04T17:32:28.668Z" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" ProviderName="portal" Version="2.0"> <saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">https://<portal_url>/portal </saml2:Issuer> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/> <ds:Reference URI=“#…”> <ds:Transforms> <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/> <ds:DigestValue>…</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue> … </ds:SignatureValue> </ds:Signature> <saml2p:NameIDPolicy AllowCreate="true" Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"/> </saml2p:AuthnRequest> Can you test this internally with both the 2306.1 and 2309 version and share your results? Edited June 4 by Rico
Rico Posted June 7 Author Posted June 7 On 6/4/2024 at 7:37 PM, Rico said: @Sascha Warno I did some tests with the 2306.1 version right now, this version of the UAG does not have this behaviour. See SAML requests which includes the ForceAuthn property with a value of FALSE. <saml2p:AuthnRequest xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" AssertionConsumerServiceURL="https://<portal_url>/portal/samlsso" Destination="https://login.microsoftonline.com/3fb8cd55-4363-44aa-9f95-789cd45be175/saml2" ForceAuthn="false" ID="_09f4f0ae05bbeb174632a373e1e1db02" IssueInstant="2024-06-04T17:32:28.668Z" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" ProviderName="portal" Version="2.0"> <saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">https://<portal_url>/portal </saml2:Issuer> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/> <ds:Reference URI=“#…”> <ds:Transforms> <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/> <ds:DigestValue>…</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue> … </ds:SignatureValue> </ds:Signature> <saml2p:NameIDPolicy AllowCreate="true" Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"/> </saml2p:AuthnRequest> Can you test this internally with both the 2306.1 and 2309 version and share your results? @Sascha Warno what do you think?
Rico Posted June 7 Author Posted June 7 I think I have found the root cause. We have multiple Unified Access Gateway deployment. On one of them I have accidentally enable the option Force SAML Authentication. Export of the INI files on both UAGS: UAG 1 [IDPExternalMetadata3] allowUnencrypted=false entityID=Azure AD forceAuthN=true metadataXmlFile= UAG 2 [IDPExternalMetadata3] allowUnencrypted=false entityID=Azure AD forceAuthN=false metadataXmlFile= I am so sorry! Will check how to fix this, since we can't do it by the GUI.
Employee Sascha Warno Posted June 10 Employee Posted June 10 Good to know, got around testing today and couldn't replicate and just wanted to ask how you import the settings or if you create new.
Solution Rico Posted June 16 Author Solution Posted June 16 On 6/10/2024 at 12:29 PM, Sascha Warno said: Good to know, got around testing today and couldn't replicate and just wanted to ask how you import the settings or if you create new. @Sascha Warno excuse me, was a little bit busy and sick last week. After reimporting the same federation metadata XML file, I didn’t changed the force setting now. This is working as expected. Conclusion: problem was created and (luckly) fixed by myself. May I thank you for all your help and thoughts!? 1
Alex Li Posted November 8 Posted November 8 @Rico The signature algorithm in the SAML request I saw was rsa-sha256, but my saml reqeust is rsa-sha1. Could you tell me where it was configured? I use keycloak as my idp. me: <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"></ds:SignatureMethod> your: <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/
Rico Posted November 11 Author Posted November 11 On 11/8/2024 at 9:40 AM, Alex Li said: @Rico The signature algorithm in the SAML request I saw was rsa-sha256, but my saml reqeust is rsa-sha1. Could you tell me where it was configured? I use keycloak as my idp. me: <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"></ds:SignatureMethod> your: <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/ Hi, I don't know where to configure in KeyCloak. I am using Entra ID, where the default is SHA256 for signing algorithm.
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now