Allow access to office 365

Create address entities for all those destinations using the FQDN setting (Fully Qualified Domain Name), then either put them all in the destination of a policy, or create a group (much neater), and use that group as the destination. This policy needs to be before the general Internet usage policy in the list. From this point on, any traffic destined to any of those servers will go through this new policy.

Hi, This is exactly what is wanted to do, but does it work with *.outlook.com for example? It will match for example phbiubl456@outlook.com with fqdn? Meanwhile I created an url exempt for these domains in the webfilter profile. I am waiting to test it Thanks.

This is exactly what is wanted to do, but does it work with *.outlook.com for example? It will match for example phbiubl456@outlook.com with fqdn?

FQDNs have to be fully resolvable host names. A FQDN for phbiubl456@outlook.com would be the " outlook.com" part. In the case of multiple IPs for same host name, the fgt is smart enough to include those too (at least in my own testing it does).

Anyone solved this? We have exactly the same problem and strange thing is, the FQDN doesn' t work. For example, we have a policy with ID 1 for HTTPS without SSL Inspection. Everything works so far, as well the Lync authentication. When we enable SSL Inspection on this policy, we can' t authenticate anymore, because of the certificate mismatch. So we created a new policy with all the FQDN address for Office365 as destination with the ID 133 and placed this policy on the TOP and without SSL Inspection of course. But you know what, all traffic is still going through the policy 1 and ignores the new policy 133. evsecure-aia.verisign.com evsecure-crl.verisign.com evsecure-ocsp.verisign.com login.microsoftonline.com lync.com microsoftonline-p.com microsoftonline-p.net microsoftonline.com microsoftonlineimages.com microsoftonlinesupport.net msecnd.net msocdn.com office.net office365.com officeapps.live.com officecdn.microsoft.com online.lync.com onmicrosoft.com outlook.com sharepoint.com our-365-online-domain.com After all the troubles I had with 5.0.4 after updating from 4.x and the bad experience I had with the Fortinet Support with my 2 last cases, where it took 2 weeks just to get any reaction from them, I almost lost my trust in Fortinet right now The support " engineer" really suggested us to reset the FG and start from scratch. He could see our FG has a strange behaviour, but he can' t reproduce it in their lab. To get this answer took 4 weeks and plenty remote-sessions. Does anyone know if we forgot any FQDN needed for Lync authentication? We checked all the Microsoft TID' s and couldn' t find any others than what we have already. But I guess it must be something like that

Looks like there some misconceptions regarding FQDN address entries in this thread. When creating an FQDN firewall address the Fortigate does a DNS lookup for that domain name and caches that IP. The FGT is not smart enough to do wildcard lookups, in fact in order to achieve this it would need to do a zone transfer which most DNS servers would reject. For illustration purposes I' ve created two FQDN addresses... microsoft.com and www.microsoft.com We can check what IPs the Fortigate has cached for those domain names using " diag firewall fqdn list" : microsoft.com: ID(67) REF(1) ADDR(65.55.58.201) ADDR(64.4.11.37) www.microsoft.com: ID(214) REF(1) ADDR(65.55.57.27) As you can see they are different. What' s more, for larger domains like microsoft and Outlook.com (and especially google.com) the time you query and dns servers you query will yield different results as these domains host their services on hundreds/thousands of servers. So it is very important that the Fortigate and client machine query the same DNS server

I see, but I guess that for we could change and reduce the cache-ttl for each address to it' s minimum. config firewall address edit BigWebsite.com set cache-ttl 600 end What' s the minimum size of the cache-ttl parameter?