Add IPv6 addresses/ranges in named locations
we set up Named Locations in Azure ID to "avoid" risky Azure AD logins.
I added all our IPv4 public IPs/ranges but could not enter the IPv6 IPs/ranges. I got in touch with the Azure support and they said it is not possible yet.
As we also use IPv6 surf IPs, could you enable the feature to add IPv6 IPs/ranges as well?
This work is started.
Still nothing? This is crazy, half our countries ISPs use IPV6 now which is stopping access for people doing work!
Michael Bateman commented
Not supporting IPV6 makes CA to require modern authentication almost useless for us. We are trying to require this for some groups and when applied to outside US only I managed to kick off SEVERAL phones running IPV6. If it would at least support country of origin it would help. For a "modern" security feature it's hard to believe this was overlooked.
Mike Burgher commented
Azure AD Team, is there an ETA for when this feature will be added?
Nicholas A. Hay commented
Any updates on this such as a estimated launch quarter?
Jim Hill commented
So today we had an issue with a user on Ios 13.1.2 that we had not seen before. We are using a conditional access policy which blocks logins from outside of the USA and Bahamas (some ATT MIFI users have a Bahamas address, go figure). The named range for these countries I configured did not have the checkbox enabled for "include unknown areas." This user could not send or receive email and got a message from Exchange telling him. I saw in the logs that this CA policy blocked him, his address was an IP6. I adjusted the named region to include unknown areas and the issue went away. So IP6 addresses are not mapped to a region. The docs don't really say that. The doc states, with typing errors included, "IPv6 rangess cannot currently be included in a named location. This measn IPv6 ranges cannot be excluded from a Conditional Access policy." Refer to https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/location-condition
So, how this played out today was that the Ios user could not get email until I adjusted the named location to include unknown areas, because his device was only reporting an IP6 address. This must be addressed.
Mark McC commented
I agree that there seems to be a lack of joined up thinking here. If it is using IPv6 addresses to access a login (as it clearly is) then it is barmy that CA blocks them.
We found we were having a lot of hacking attempts from particular countries so in an attempt to improve security set up CA last week to block attempts from such countries.
So now logins to Exchange via IPv6 are being blocked even though the IP6 addresses are clearly coming from a country that should not be blocked.
It's pretty easy to build CA policies to grant with MFA at all locations, even unknown. Where this issue hurts is with countries for which we simply wish to completely block all sign-in capabilities. We can't effectively do that until this is fixed. Not that there aren't ways to beat that, too, but it's at least moderately effective. Admin, do you have an ETA on this?
The idea that this had to be voted on is ridiculous. This is a huge gap in security and shouldn't require a 2 year voting campaign to get it looked at. Shame on Microsoft for ignoring security this long
I actually though that this is already implemented, because even the idea of opposite is unfathomable to me. How can you create the "secure" public image when literally every hacker which happened to use ipv6 can easily try to login using someone's credentials?
Michael Burgher commented
It should be simple enough for Microsoft to provide location information for IPv6 addresses. Online geolocation\IP lookup databases like whatismyipaddress.com support the feature.
Is there an estimated date for adding this functionality? I have several projects dependent on this working properly.
Vincent Schneider commented
I would also like to add that the location based services are blank for IPv6 Addresses in the Azure AD sign-in logs.
The IPv4 addresses are less accurate than 3rd party lookup like ipinfo.io for instance where an IPv4 Location coming from one city is inaccurate in Azure AD logs but is accurate when i look it up on ipinfo.io.
This is not helpful especially when blocking countries like China and Russia where we in particular receive a lot of attacks from.
We either have to loosen up our policies creating security risks or make things difficult for our users where they can't access on their cellular network which uses IPv6 often blocking active sync for example.
Microsoft Please listen to your clients :) we're rooting for you!
It is simply unacceptable that Microsoft does not support IPv6 location data. We are halfway through 2019 and a good portion of the WORLD is already using IPv6.
Microsoft needs to escalate this up and get a solution in place ASAP. This was said to be "High" on your list in November, but you haven't provided ANY updates for 8 Months!!!
Hi!, The logins does not work when users connected using IPv6 if you add a conditional rules banning any overseas countries.
other problem with ipv6 if i setup a rule for conditional access blocking access from russia (ie)
if the ip used by the attacker is ipv6 the system doesn't match russia but the field location is blank so conditional accees doesn't works
Hi Microsoft team - Would really appreciate if you can add this feature in Azure.
WE have experience brute force attacks to one of our customer tenant from IPv6 address and we dont have an option to block it at all
This should be a major priority!!! Why is there no update? This limitation negates the the basis of using conditional access to secure azure & 365 resources. We literally had level II support tell us to disable 365 MFA to use conditional access - how is that a viable solution with this feature missing???
Brian ANderson commented
Any update on this?
And Microsoft continues to push "security" and conditional access - WHY IS CONDITIONAL ACCESS CONSIDERED TO REDUCE SECURITY RISKS? IT ONLY WORKS WITH IPv4, leaving more than 1/4 connections to 365 / AZURE resources insecure! Why?