FortiAuthenticator as Identity Provider (IdP) for Office365 / Azure Active Directory

[tbrewster]

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

[tbrewster · Accepted solution]

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 ***

[tbrewster · Accepted solution]

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 ***

[localhost]

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.

[tbrewster]

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...   

[localhost · Accepted solution]

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

[tbrewster]

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 ;)