Rico Posted June 2 Share 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. Quote Link to comment Share on other sites More sharing options...
Employee Sascha Warno Posted June 3 Employee Share 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 Quote Link to comment Share on other sites More sharing options...
Daniel Keer Posted June 4 Share 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 Quote vExpert ⭐⭐ | EUC Expert Blog theDXT.ca Link to comment Share on other sites More sharing options...
Rico Posted June 4 Author Share 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 Quote Link to comment Share on other sites More sharing options...
Employee Sascha Warno Posted June 4 Employee Share 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 Quote Link to comment Share on other sites More sharing options...
Rico Posted June 4 Author Share 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 Quote Link to comment Share on other sites More sharing options...
Employee Sascha Warno Posted June 4 Employee Share 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 Quote Link to comment Share on other sites More sharing options...
Rico Posted June 4 Author Share 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 Quote Link to comment Share on other sites More sharing options...
Rico Posted June 4 Author Share 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 Quote Link to comment Share on other sites More sharing options...
Rico Posted June 7 Author Share 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? Quote Link to comment Share on other sites More sharing options...
Rico Posted June 7 Author Share 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. Quote Link to comment Share on other sites More sharing options...
Employee Sascha Warno Posted June 10 Employee Share 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. Quote Link to comment Share on other sites More sharing options...
Solution Rico Posted June 16 Author Solution Share 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 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.