Allow Office 365 not getting desired results...

[LCMember172]

Hei,

We recently moved over to a full O365 solution and I am trying to customise the ruleset to Allow for O365 traffic when all other traffic is blocked.

Unfortunately I have hit a wall and cannot seem to get the application to be allowed. I am hoping one of you can point out what I have done wrong and how to correct it.

I have used Addresses (with FQDN) and Address Groups where I have defined all the sites that MS states are required. List is here: Office 365 URLs and IPs [Ideally I'd avoid using IPs as these are subject to change. 😉 ]

I then changed the top level policy to allow for the Address Group.

In testing, the client pc is able to start Office and receives the login screen but no login is able to complete. In the Monitor of PAN it details Destination as an IP and Application as "not-applicable"

I have also tried using the predefined Application setting (ms-office365), but then on the client pc it does not even resolve to the login screen, just displaying a bland "Unable to connect" pop-up.

Thanks in advance for any advice!

Details:

[pankaku]

Try one more thing.

Allow everything from that test machine and check the logs what all application are required to allow the access to office365 don't use URL filtering first. Then narrow down the security policy

Or 

Create a deny any any for that IP and check what all applicaiton are blocked and then add them to the allowed rule.

[LCMember172]

I have previously tried that and according to the Monitor, the Applications are (ms-office365-base), (web-browsing) and (ssl).

Unfortunately, these machines will be used by students in exams, so allowing for internet based traffic would be a bad idea...

[cpainchaud]

Use URL categories , not FQDN !! they are absolutly not the same thing !!!

[pankaku]

You can get two things from the logs application and IP/fdqn. Now add applicaiton and Destination address in rules in this way it will not allow access to other webistes.

[Brandon_Wertz]

That's what we did...Just dumped the URLs into a custom URL Category.

[ABAdmin]

Still not getting the desired results. 😞

I've tried the following (and a combination of the following):

1) Taken all the URLs and placed them in a new URL category in Objects. Placed this into the main Policy that allows for traffic irrespective of when we have to close access to the internet. Result = access still blocked

2) Taken all the individual IPs (599 of them) and placed them into a URL category in Objects. And updated this to the main rule. Result = no access

3) In a pique of curiosity - I created the rule to allow for all traffic to "www.*.com" and "*.com". And that didnt work either.

4) I have opened up all traffic, took a copy of the destinations that were used, created a rule for them and tried that once the blocks were in place...nope.

5) I have gone through the Application filters and updated the main policy to allow for ms-office365 and all other derivaties I could find...but that didnt work either.

So - any other tips? I am not a network specialist (clients & scripting are my main) but I cannot understand why it is not working or what is actually been blocked. Unfortunatley too much information is been hidden within the "not-application" description in the Monitor. I can see that the IPs are within the correct subnet range and ports are correct (80 and 443) for Office365 traffic. But why are the applications getting hidden by "not-applicable"?

[Brandon_Wertz]

@ABAdmin From TAC, I've been told to not use IP addresses in custom URL categories.  Only use them in address groups.

[ABAdmin]

Ok will give that a try, thanks for the tip.

[Brandon_Wertz]

Also, last night I was looking through our applications as my company use O365 too.  I'm not sure what part of the service you're using but we allow:

ms-office365-base

outlook-web-online
sharepoint-base
sharepoint-online
sharepoint-documents
office-on-demand
skydrive-base
live-mesh-base
SSL
web-browsing

[ethiSEC]

A custom URL category added to a URL filtering profile on the rule with the required office 365 app-ids may work but it may also be a bit hit and miss.

URL categories are very handy when you want to more accurately match traffic against a specific rule. The good thing about URL categories is these are used as an additional match criteria for the rule. For example if you want to all allow traffic on an office 365 with an SSL and web-browsing dependancy app-ids coming from a trusted zone going to the untrusted zone and a URL category is applied with the appropriate URL matches, all three components will need to match before the traffic will be allowed by this rule.

In my experience they have proven more reliable way of ensuring the right traffic hits the right rule.

Jason

[ABAdmin]

@Brandon_Wertz: We added those previously and nothing - traffic was still blocked for some or other reason

In the end we resolved this by adding every IPv4 address MS has listed to Addresses with an appropriate Tag.

In Address Groups we created a Dynamic Group based on the aforementioned Tag.

In Policies we allowed for the Address Group. And now our clients are able to authenticate the Office 365 license. The authentication process is ridiculousloy slow though. With all traffic enabled, license authentication takes a second or two. With the internet restricted and this rule in place...it takes 2 - 3 minutes to authenticate. Very strange this, not to sure where the optimisation must be done.

As we only need to get a license, we only added all IPs relating to Portal and ID.

(Ps: But...to cover our bases - I have also added the IPv6 to Addresses, URLs to URL Category and created an Application Group based on the needed O365 applications in the PAN-2020. Nothing wrong with a little overkill 😉

Cheers and thanks for the help

Anthony