Technical Tip: Microsoft Azure SAML authentication error 'Sorry, but we’re having trouble signing you in. AADSTS700016: Application with identifier 'https://x.x.x.x:1003/remote/saml/metadata/' was not found in the directory...'

[pachavez]

Description	This article describes how to resolve the issue in SAML authentication when the error shows: Sorry, but we’re having trouble signing you in. AADSTS700016: Application with identifier 'https://10.230.3.239:1003/remote/saml/metadata/ ' was not found in the directory 'Default Directory'. This can happen if the application has not been installed by the administrator of the tenant or consented to by any user in the tenant. You may have sent your authentication request to the wrong tenant.
Scope	FortiGate v7.2.5 as SP, MS Azure as IdP.
Solution	In this setup, a captive portal for SAML authentication is configured for LAN users in FortiGate. When a user accesses a website, it will redirect to the Microsoft authentication page before going to the actual website: After a user signs in to the Azure authentication page, the error shows: 'Sorry, but we’re having trouble signing you in. AADSTS700016: Application with identifier 'https://10.230.3.239:1003/remote/saml/metadata/' was not found in the directory 'Default Directory'. This can happen if the application has not been installed by the administrator of the tenant or consented to by any user in the tenant. You may have sent your authentication request to the wrong tenant.' Double-check the entity-id on Azure if it matches the entity-id on the FortiGates. Azure: FortiGate: In this example, on Azure, the entity-id is set to 'HTTP' while on FortiGate, the entity-id is set to 'HTTPS'. To resolve the issue, it is possible to either change the entity-id on Azure to 'HTTPS' to match FortiGate's or change the entity-id on FortiGate to 'HTTP' to match Azure's. Once the entity-id of the Azure and FortiGate match, the SAML LAN user should now be able to authenticate successfully and be redirected to the website. Check the authenticated SAML user on FortiGate. From GUI: From CLI: FG-VM (root) # diagnose firewall auth list 10.230.3.100, pearl src_mac: 00:56:69:76:1b:01 type: fw, id: 0, duration: 45, idled: 0 expire: 300, allow-idle: 300 server: Azure-AD-SAML packets: in 1340 out 648, bytes: in 1314123 out 165072 group_id: 3 group_name: Azure-FW-Auth ----- 1 listed, 0 filtered ------ Note: A similar error appears in the case of SSL VPN if the SAML SP entity-id does not match on FortiGate and Azure. In this example, the forward slash was missing on the Azure Identifier (Entity ID), but it was set onthe  FortiGate entity-id after metadata: On FortiGate: FortiGate# show user saml config user saml     edit "Entra_ID_10443"     [...]         set entity-id 'https://X.X.X.X:10443/remote/saml/metadata/' <---- Note the last forward-slash after the word 'metadata'         [...] Azure Entra error message after attempted login (Azure set with SP entity-id of 'https://X.X.X:10443/remote/saml/metadata'): Sorry, but we’re having trouble signing you in. AADSTS700016: Application with identifier 'https://X.X.X.X:10443/remote/saml/metadata/' was not found in the directory 'Y Y'. This can happen if the application has not been installed by the administrator of the tenant or consented to by any user in the tenant. You may have sent your authentication request to the wrong tenant. After adding the '/' to the end of the Azure Identifier (SP Entity ID), the issue is resolved. Related documents: Outbound firewall authentication with Azure AD as a SAML IdP Technical Tip: Setting up a captive portal for network authentication using SAML and Azure for LAN u...