saml Azure AD - ssl-vpn - forticlient time out

[IvK]

Hello,

I have configured our Fortigate to authenticate our ssl-vpn users with Azure AD. I've configured the enterprise app within Azure AD and configured the SAML user within the Fortigate.

I have no issues when I login the web-mode.

However when I try to connect with the Forticlient I receive a blank sceen after passing the authentication. After a while I receive the following error "Login page did not respond within time limit." The second time i press SAML Authentication the forticlient connects within seconds.

I reckon one of the URL's might be different for tunnel-mode / web-mode. Did anyone manage to find a solution for this issue?

[IvK]

Hi,

change the radius time out: https://kb.fortinet.com/kb/documentLink.do?externalID=FD48279

I wouldn't put to much effort in adfs configuration. Or do you have an completly on-prem environment?

I see a lot of organizations struggling with adfs in combination with azure ad. If possible try to get rid of the adfs servers. Atleast that is the advice Microsoft is giving

[lawrence110]

Thanks for the information. 

I also want to simply use Azure AD but ADFS with on-premise AD is forced by company regulation. I need to make ADFS working with FortiClient. 

I checked more detail of FortiClient log and found the error is

__samld_sp_login_resp [914]: Invalid assertion

I checked the content of SAML xml and don't know what error is. 

<Assertion xmlns="urn:oasis:names:tc:SAML:2.0:assertion" ID="_8faeb136-9501-4759-95e2-40b55faa629a" IssueInstant="2021-10-05T01:15:00.256Z" Version="2.0"><Issuer> 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/2000/09/xmldsig#rsa-sha1"/><ds:Reference URI="#_8faeb136-9501-4759-95e2-40b55faa629a"><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/2000/09/xmldsig#sha1"/><ds:DigestValue>1NabFEF7RWRhF8p5omnDVyfXJg4=</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue>uz0KRWwr23D3SikurnzGHojM/pBL9064OI9RWY+ENKklr2s68AdSKOxtRO2WV9UgJ5jJaVWrZBEzf43Fe6N7vQc9FTu9jsUk21Oj5dF69iQ7zrlKysHUU6nLXwzLjp3+TDNIUUknkIRrGrZIU9UkiM71Em2GCISCZzTUOYRTe5ObGNsTuHxrA2jfg52Ui1QPCbkowq+g4az6PRiGSGkw9GTEysvFhcdmf6PVzQ1LZeDV1muCdZ8N5hhUBj+A+l/8Bx1RvXdMkBT5d+2CRX8Z2zH5s3Jf9Ts2H1hyF+u6gT3JJELPCQbpV6PQ5l2ouM2rliOiyElyfqeBxNpkrS6Xgg==</ds:SignatureValue><KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><ds:X509Certificate>MIIC3k3*kk3nz9c3llkas73kKOA*3k8SK8fZOT6tvDANBgkqhkiG9w0BAQsFADAqMSgwJgYDVQQDEx9BREZTIFNpZ25pbmcgLSBtZmEuZ28tdHJ1c3QuY29tMB4XDTIxMDgxNjE2MDUwNVoXDTIyMDgxNjE2MDUwNVowKjEoMCYGA1UEAxMfQURGUyBTaWduaW5nIC0gbWZhLmdvLXRydXN0LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAN+SYAxb0da2O33YFByhEZ+LsqFEL7t/YhC+taSwWEpiKVWSa7aVUKXdRwxWNjLuJwL4moASaR/tknyByJnxDGn8YJhrSRHGls/7SDWmUsnQt6rlpI6oIWrCkijHtWxJ2+q5qPFBIl+etkmDU6q0pd715fZ/yhK4vzlvaHeF2pIhrsZmBkPIB8xodsPshrpbV0VXnkqiRt8Ny8lSTXjSI1kegcontosooyo1uzzFCqlsxd3aU7zkmD4Hztg1tv3KR8Y6dFlgggsMj1bQlLz6KzRwqaAYE2ZHG7tFtrmjKNLzCVx+Q1GssOjb9QhrZ3mDHOFVzy2MJaqTn/Z0f/XZsFw1hj8CAwEAATANBgkqhkiG9w0BAQsFAAOCAQEADnrMCS5taj8IJfkvF3gzwdYZtfudd3EAv8MESo6pGPa/sRcn548l4WfsSh4P20bEOW6S1lO5gHfb4SXGjs5wYqRF9a/blfBc8fCVgOePNJefvJRGDpm/Eq6ezr0Jevozs+C2pLiObGxRYVx1oEfr1uEFLuO941Kf1f6KD1/eQnlANtTyQRamp7PvmvJPD47/29gUFk3*kk3nz9c3llkas73kKOA*3k8SK8jFMRyoqhuYZuqxrmmCYG6pCLmebQOCPedPmaFV1CR2QzKD3STTMk3*kk3nz9c3llkas73kKOA*3k8SK8K4h39UJShKsZcamlnL7QZornEDyZrj2h1exQ==</ds:X509Certificate></ds:X509Data></KeyInfo></ds:Signature><Subject><NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">contoso/user.name</NameID><SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"><SubjectConfirmationData InResponseTo="_C1A6A8F6DF62C06D9A79BA0354272FE1" NotOnOrAfter="2021-10-05T01:20:00.256Z" Recipient="https://vpn.contoso.com:10443/remote/saml/login&#10;"/></SubjectConfirmation></Subject><Conditions NotBefore="2021-10-05T01:15:00.256Z" NotOnOrAfter="2021-10-05T02:15:00.256Z"><AudienceRestriction><Audience> AuthnInstant="2021-10-05T01:12:13.351Z" SessionIndex="_8faeb136-9501-4759-95e2-40b55faa629a"><AuthnContext><AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</AuthnContextClassRef></AuthnContext></AuthnStatement></Assertion>

[IvK]

I think assume the company regulation dictates a form of safe authentication with SSO capabilities.

Maybe in the time it was written ADFS was the best option. But time changes so if you can indicate that you can full fill the same functional requirements with less overhead/maintenance/sopf/cost by using Azure AD the regulation can be changed.

Allthough it may seem a technical a problem it's more an IT strategy choise.

I don't have the time to look into the error right now. Although it might work I think Fortinet will advice you to use a FortiAuthenticator with EMS.

[lawrence110]

Hi AvK,

   Thanks for your comments. You're right. The company's regulation will be the bottleneck for long-term maintenance of ADFS. Move to Azure AD is our plan, but it takes time. I still need to make current ADFS working with FortiGate VPN. I've also contact FortiGate technical support to help. Hope it can solve my problem.