Hello,
I've setup the integration between AAD and Snowflake through SCIM and am getting constance notified of synchronization errors as the list of IPs under AzureActiveDirectoryDomainServices isn't enough, there are many requests being done through other IPs that get blocked resulting in constant errors. Can you please help clarify this?
⚠Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.
For example, Azure AD tried to provision using the IP 40.76.90.35, which failed with the error below because I've only whitelisted the IPs under AzureActiveDirectoryDomainServices following this documentation.
{"statusType":"FORBIDDEN","entity":"client ip-address is blocked by network policy","entityType":"java.lang.String","metadata":{"Content-Type":[{"type":"application","subtype":"json","parameters":{},"wildcardType":false,"wildcardSubtype":false}]},"status":403}
Hi folks,
We have the same issue. I think The IP list in the JSON file which Microsoft shared on download center is not including some ranges.
@eduardohl Thanks for bringing this to our notice. We are investigating into the issue and will update you shortly.
@eduardohl Suggest you check on this documentation for the Network considerations for Azure AD Domain Services. Also, you should have the range of IP Address enabled from the list in this document.
Let us know how it goes.
We are using the JSON file which you are mentioned. But it still the same.
Just to let you know, I've tried several combinations of IPs, but right now only the entire AzureCloud range of ips work, any other combinations eventually fails.
We've had the same issue since around 29th of April and has had an almost incremental increase in errors.
Looked at the SCIM logs in Snowflake and found
{"statusType":"FORBIDDEN","entity":"client ip-address is blocked by network policy","entityType":"java.lang.String","metadata":{"Content-Type":[{"type":"application","subtype":"json","parameters":{},"wildcardType":false,"wildcardSubtype":false}]},"status":403}
These requests came from IP
137.135.128.27
Which are a part of
AzureCloud.northeurope
137.135.128.0/17
I was also under the understanding that it was IPs directly related to Domain Services that needed to be whitelisted. Is it necessary to add additional ranges and what ranges are we talking about in that case?
Hello @tcvall86, I've tried several combination and unfortunately it seems to come from pretty much ALL ranges (useast1, 2, central, europe...) meaning it's pretty much all of Azure ip range. This is a big security issue and I would ask Microsoft to treat this as a security priority.
@eduardohl Agreed, also noticed other IPs coming in now.
We have had this integration working without errors like these since 27th of February so this is definitely a new behavior with the SCIM integrations or we have just lucked out for 2 months prior to this
Hey @tcvall, I thought the same, but I always had sync errors showing up in my logs that I didn't go through investigating, I was thinking they were already happening. @neeleshray-msft and @ChiragMishra-MSFT can you please alert the technica team there's a security issue going on here? The documentation is NOT covering the range of IPs the SCIM requests are originating from, they're originating from pretty much ANY ip within Azure range.
@neeleshray-msft and @ChiragMishra-MSFT , any updates on this subject? Could you let me know if there's and ETA for resolution?
@eduardohl We are checking with the Product Team on this and would get back to you on the same.
Any update on this issue?
Hi all, we are working on two stages to address this.1) Having a dedicated tag for identity that will include all the IP ranges (targeted next month) 2) Releasing a solution that will allow you to deploy an agent on prem and avoid having to open any IP ranges (this is a longer term effort).
As a shorter term mitigation, we are working on identifying a smaller list of IP ranges next week. Will respond back with the details.
These are the IP ranges we are using currently. We're also working on a tag with a smaller set of IP ranges. 13.86.239.205;
52.188.178.195;
13.86.61.156;
40.67.254.206;
51.105.237.71;
20.44.38.166;
40.81.88.68;
52.184.94.250;
20.43.180.59;
20.193.16.105;
20.40.167.232;
13.86.3.57;
52.188.72.113;
13.88.140.233;
52.142.121.156;
51.124.0.213;
40.81.92.36;
20.44.39.175;
20.189.114.130;
20.44.193.163;
20.193.23.17;
20.40.173.237;
13.86.138.128;
52.142.29.23;
13.86.2.238;
40.127.246.167;
51.136.72.4;
20.44.39.244;
40.81.92.186;
20.189.114.131;
20.44.193.210;
20.193.2.21;
20.40.174.46;
13.86.219.18;
40.71.13.10;
20.44.16.38;
13.89.174.16;
13.69.66.182;
13.69.229.118;
104.211.147.176;
40.78.195.176;
13.67.9.240;
13.75.38.48;
13.70.73.48;
13.77.52.176;
@eduardohl @ArvindHarinder1
Apologies for the delayed response.
We have confirmation that the document has been updated with the current IPs needed.
We will be closing this thread now. Please reopen and Tag myself if you need further help.
Most helpful comment
As a shorter term mitigation, we are working on identifying a smaller list of IP ranges next week. Will respond back with the details.