Has anyone successfully setup and used the FortiAuthenticator as the IdP for Azure AD?
We're following the Microsoft guidelines here https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-fed-saml-idp and having issues with the final steps.
The user login page is redirected to the FortiAuthenticator, successfully authenticated and then passed back to Microsoft where we are getting "Message: AADSTS50107: Requested federation realm object 'http://{Our-FA-URL}/saml-idp/{Our-IDP-Prefix}/metadata/' does not exist.
The FA logs show;
SAML request from SP 'Office365_GCC' failed: SAML assertion request validation error: Issuer 'urn:federation:microsoftonline.us' does not match SP config
Solved! Go to Solution.
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
For any others that run into these issues; after getting all the steps in https://docs.microsoft.com/en-us/azure/active-directory/develop/single-sign-on-saml-protocol completed and working the final missing piece for us was the
"NameID" had to be set to the "ImmutableID" (i.e. the Remote LDAP Server / user objectGUID).
Both Microsoft’s and Fortinet's documentation is a bit shaky....
Hopefully better PowerShell EXAMPLE
$dom = "EXAMPLE.com" $BrandName = "FortiAuthenticator.EXAMPLE.com SAML 2.0 IDP" $LogOnUrl = "https://FortiAuthenticator.EXAMPLE.com/saml-idp/-RANDOM-/login/" $LogOffUrl = "https://FortiAuthenticator.EXAMPLE.com/saml-idp/-RANDOM-/logout/" $MyURI = "https://FortiAuthenticator.EXAMPLE.com/saml-idp/-RANDOM-/metadata/" $MyMetadataExchangeUri = "https://FortiAuthenticator.EXAMPLE.com/saml-idp/-RANDOM-/metadata/" $MySigningCert = "***CERT***" $Protocol = "SAMLP" Set-MsolDomainAuthentication -DomainName $dom -FederationBrandName $BrandName -Authentication Federated -PassiveLogOnUri $LogOnUrl -ActiveLogOnUri $LogOnUrl -SigningCertificate $MySigningCert -IssuerUri $MyURI -LogOffUri $LogOffUrl -MetadataExchangeUri $MyMetadataExchangeUri -PreferredAuthenticationProtocol $Protocol
*** Fixed $MyURI parameter above per localhost's comments ***
I found the issue. It was a configuration issue on the Azure side.
And now the error message actually makes perfect sense
The MyURI Parameter in your example is wrong.
In case of the FortiAuthenticator it's has the same value as the MetadataExchange URI.
$dom = "EXAMPLE.com"
$BrandName = "FortiAuthenticator.EXAMPLE.com SAML 2.0 IDP"
$LogOnUrl = "https://FortiAuthenticator.EXAMPLE.com/saml-idp/-RANDOM-/login/"
$LogOffUrl = "https://FortiAuthenticator.EXAMPLE.com/saml-idp/-RANDOM-/logout/"
$MyMetadataExchangeUri = "http://FortiAuthenticator.EXAMPLE.com/saml-idp/-RANDOM-/metadata/"
$MyURI = "http://FortiAuthenticator.EXAMPLE.com/saml-idp/-RANDOM-/metadata/"
$MySigningCert = "***CERT***"
$Protocol = "SAMLP"
Set-MsolDomainAuthentication -DomainName $dom -FederationBrandName $BrandName -Authentication Federated -PassiveLogOnUri $LogOnUrl -ActiveLogOnUri $LogOnUrl -SigningCertificate $MySigningCert -IssuerUri $MyURI -LogOffUri $LogOffUrl -MetadataExchangeUri $MyMetadataExchangeUri -PreferredAuthenticationProtocol $Protocol
For any others that run into these issues; after getting all the steps in https://docs.microsoft.com/en-us/azure/active-directory/develop/single-sign-on-saml-protocol completed and working the final missing piece for us was the
"NameID" had to be set to the "ImmutableID" (i.e. the Remote LDAP Server / user objectGUID).
Both Microsoft’s and Fortinet's documentation is a bit shaky....
Hopefully better PowerShell EXAMPLE
$dom = "EXAMPLE.com" $BrandName = "FortiAuthenticator.EXAMPLE.com SAML 2.0 IDP" $LogOnUrl = "https://FortiAuthenticator.EXAMPLE.com/saml-idp/-RANDOM-/login/" $LogOffUrl = "https://FortiAuthenticator.EXAMPLE.com/saml-idp/-RANDOM-/logout/" $MyURI = "https://FortiAuthenticator.EXAMPLE.com/saml-idp/-RANDOM-/metadata/" $MyMetadataExchangeUri = "https://FortiAuthenticator.EXAMPLE.com/saml-idp/-RANDOM-/metadata/" $MySigningCert = "***CERT***" $Protocol = "SAMLP" Set-MsolDomainAuthentication -DomainName $dom -FederationBrandName $BrandName -Authentication Federated -PassiveLogOnUri $LogOnUrl -ActiveLogOnUri $LogOnUrl -SigningCertificate $MySigningCert -IssuerUri $MyURI -LogOffUri $LogOffUrl -MetadataExchangeUri $MyMetadataExchangeUri -PreferredAuthenticationProtocol $Protocol
*** Fixed $MyURI parameter above per localhost's comments ***
Thanks for sharing this information. I keep running into the same error message.
I'm also using the ObjectGUID as the immutableID. The SAML Response looks valid to me - but it's still not accepted by Azure.
Would you mind sharing your FortiAuthenticator configuration as well? Were you able to see some debugging messages in Azure? Really hard to troubleshoot this without any detailed debugging message on the Azure side.
Screenshot of my broken config attached.
We also have this ImmutableID SAML Attribute added, not 100% certain it is required.
SAML Attribute User Attribute
IDPEmail Email
ImmutableID Remote LDAP objectGUID
Open up a support ticket with Microsoft and/or Fortinet as needed. It takes a while, but they are quite helpful.
The debugging options under "Debugging Options" on that screen can be helpful
* Do not return to service provider automatically after successful authentication, wait for user input. * Disable this service provider Also the debug options under [link]https://fortiauthenticator-URL/debug/gui[/link] are useful...
I found the issue. It was a configuration issue on the Azure side.
And now the error message actually makes perfect sense
The MyURI Parameter in your example is wrong.
In case of the FortiAuthenticator it's has the same value as the MetadataExchange URI.
$dom = "EXAMPLE.com"
$BrandName = "FortiAuthenticator.EXAMPLE.com SAML 2.0 IDP"
$LogOnUrl = "https://FortiAuthenticator.EXAMPLE.com/saml-idp/-RANDOM-/login/"
$LogOffUrl = "https://FortiAuthenticator.EXAMPLE.com/saml-idp/-RANDOM-/logout/"
$MyMetadataExchangeUri = "http://FortiAuthenticator.EXAMPLE.com/saml-idp/-RANDOM-/metadata/"
$MyURI = "http://FortiAuthenticator.EXAMPLE.com/saml-idp/-RANDOM-/metadata/"
$MySigningCert = "***CERT***"
$Protocol = "SAMLP"
Set-MsolDomainAuthentication -DomainName $dom -FederationBrandName $BrandName -Authentication Federated -PassiveLogOnUri $LogOnUrl -ActiveLogOnUri $LogOnUrl -SigningCertificate $MySigningCert -IssuerUri $MyURI -LogOffUri $LogOffUrl -MetadataExchangeUri $MyMetadataExchangeUri -PreferredAuthenticationProtocol $Protocol
Yes, we found that out as well with Microsoft support last week. I didn't go back and update the parameter definitions. Glad you now have it documented out there now!
Other useful tidbits that we found out:
When changing some of these parameters we had to "Set domain to managed to clear all federation setup" Set-MsolDomainAuthentication -DomainName EXAMPLE.com -Authentication Managed
Also you can't have more than one Federated domain name without some additional setup (support multiple domains). We were getting cryptic errors when migrating our production domain but leaving the 'test' Federated domain in place. We fixed that by setting the test domain back to managed and left it that way.
When the need arises, we'll have to back an figure out the syntax for supporting multiple domains. MS support also informed us we may have to set all the domains back to managed prior to attempting to support multiple domains on the tenant. "Future problem" for future self ;)
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1536 | |
1029 | |
749 | |
443 | |
210 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.