Azure AD Application Proxy - Updatable objects

[David_Herselman]

We are experiencing problems trying to use Azure AD updatable objects to allow an Azure AD Application Proxy host to phone home.

Two issues:

• Is there a reference document somewhere that explains what the various updatable objects actually reference. Each comment is currently simply a copy & paste to the same statement 'This is a Microsoft object, blah blah https://www.microsoft.com/en-us/download/details.aspx?id=56519'
• We constantly have to supplement the updatable objects with additional IPs. I presume CheckPoint have contacts at Microsoft that they can address this with?

Two examples:

• We use 802.1X for both wireless and wired (port based) authentication where we want users to utilise Azure AD as a MFA method of registering their devices to the network. We subsequently created a rule that allows access to 'Azure Active Directory Domain Public Services' and 'Azure Active Directory Public Services' but many requests flow to destinations not covered by these.
• We drop requests to unknown or uncategorised sites and want to allow 'Azure AD Connect' and 'Azure AD Application Proxy' hosts to connect back to Microsoft. There are again never ending hosts that we have to continually manually add to allowed network group objects.

My impression is that the current implementation is really half baked and whilst it ticks some boxes isn't reliable. Herewith some of the IPs we've had to add:

Regards

David Herselman

[PhoneBoy]

All Updatable Objects are backed by a feed provided by the relevant vendor (MSFT in this case).
You use the Domains Tool to see what is covered in a given Updatable Object.
See: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

[David_Herselman]

Unfortunately doesn't help:

[Expert@fwcp1:0]# domains_tool -uo "Azure Active Directory Domain Public Services"

Domain tool looking for domains for 'Azure Active Directory Domain Public Services' and its children objects:

The updatable object Azure Active Directory Domain Public Services does not hold any domains
[Expert@fwcp1:0]# domains_tool -uo "Azure Active Directory Public Services"

Domain tool looking for domains for 'Azure Active Directory Public Services' and its children objects:

The updatable object Azure Active Directory Public Services does not hold any domains

[PhoneBoy]

Digging into this a bit more, it looks like you can find the IPs in $CPDIR/database/ONLINE_SERVICES/1.0/<version>/azure.C on the gateway.
In any case, Microsoft is ultimately responsible for updating the feed.

[David_Herselman]

Undocumented switches and incomplete address lists. Does CheckPoint not have contact at Microsoft they could address this with?

My original question also hasn't been answered so I presume the answer is 'No, CheckPoint do not provide a clue anywhere at to what subnets are chosen from Microsoft's lists to create the updatable objects'.

ie: You can try figure out yourself what someone in R&D cooked together?

My impression is that functionality of this nature is of great interest, but unusable in it's current state = half baked...

[PhoneBoy]

Like I said, Microsoft provide these lists, which are categorized.
There are, in fact, multiple lists.
For Azure US, it’s something like the following: https://www.microsoft.com/en-us/download/details.aspx?id=56519
See also: https://docs.microsoft.com/en-us/microsoft-365/enterprise/urls-and-ip-address-ranges?view=o365-world...
@Micky_Michaeli do we have a backchannel with Microsoft for matters like this?

[Micky_Michaeli]

Hi @PhoneBoy,

I had several meetings in the past with Microsoft people regarding multiple requests raised from our customers.

Unfortunately, almost all our requests were answered as "currently it's not in our roadmap".

As you wrote below, there are multiple objects for multiple services and the content can be viewed on the GW by running two commands, "dynamic_objects -uo_show" for getting the loaded IPs ranges and "domains_tool -uo <updatable objects name>" for getting the loaded domains.

Thanks.

[PhoneBoy]

FYI, I just went through a similar exercise with a customer trying to troubleshoot an issue with Azure-related services and Updatable Objects.
We were able to confirm that the ranges specified in the JSON file available from Microsoft correspond to what shows when using the relevant object in the rulebase and you execute dynamic_objects -uo_show.
The trick in our case was figuring out which Updatable Objects to include based on the services they were trying to access.
Between the JSON file and looking at $CPDIR/database/downloads/ONLINE_SERVICES/1.0/<ver>/azure.C, I could see what objects needed to be included for this specific customer.

[Jan_Kleinhans]

Hello,

we have a similar issue.

We have a rule allowing http/https to "Office 365 Worldwide Services". 

This rule also allows connection to IP 104.46.60.117 (kyocera.biz). This IP shouldn't be included in the O365 Services.

When I run a dynamic_objects -uo_show the range 379 : 104.46.24.0 104.46.127.255 is only included in the object CP_Azure_Azure. This object shouldn't be included in the object "Office 365 Worldwide Services".

Best regards,

Jan

[Micky_Michaeli]

Hi @Jan_Kleinhans,

The object "Office 365 Worldwide Services" contains IP addresses and domains as part of its content.

104.46.60.117 is not part of the IP addresses ranges of this object, this is correct, but it should be part of the domains associated to this object, that's why it's matched on it.

I tried to see the resolving responses of domains of kyocera.biz, all of them returned domains of cloudapp.net as their canonical name. 

One of the domains of "Office 365 Worldwide Services" is *.cloudapp.net, that's why it's possible to have the same IPs for domains of cloudapp.net and kyocera.biz and that's why it's matched on this object.

few examples:

nslookup rfs-us.kyocera.biz
rfs-us.kyocera.biz canonical name = kfs-us02-devicerest.cloudapp.net.
Name: kfs-us02-devicerest.cloudapp.net
Address: 23.101.190.57

nslookup rfs.kyocera.biz
rfs.kyocera.biz canonical name = kfs-as02-devicerest.cloudapp.net.
Name: kfs-as02-devicerest.cloudapp.net
Address: 104.46.227.64

nslookup fs-us.kyocera.biz
fs-us.kyocera.biz canonical name = kfs-us02-userweb.cloudapp.net.
Name: kfs-us02-userweb.cloudapp.net
Address: 23.102.187.77

Best regards,

Micky

[Jan_Kleinhans]

Hello Micky,

thanks for clarification. So the usage of "Microsoft O365 Worldwide Services" is a pain as it includes *.cloudapp.net which seems to be a bunch of websites which have nothing to do with O365.  That is MS fault and not yours as I can see.
We will open a call with MS. Maybe they can remove *.cloudapp.net from the list.
Perhaps you could split the O365 services in categories as described here:

https://docs.microsoft.com/en-us/microsoft-365/enterprise/microsoft-365-network-connectivity-princip...

Best regards,

Jan