search

MicrosoftDocs / azure-docs

Open source documentation of Microsoft Azure
https://docs.microsoft.com/azure
Creative Commons Attribution 4.0 International
10.31k stars 21.49k forks source link

AAD sees an IPv6 address coming from an Azure VNET, *only* if the subnet has the Microsoft.AzureActiveDirectory service endpoint enabled #59437

Closed andresm53 closed 3 years ago

andresm53 commented 4 years ago

Hi, In the IPv6 section, the doc states: " In addition, if you are using Azure VNets, you will have traffic coming from an IPv6 address. If you have VNet traffic blocked by a Conditional Access policy, check your Azure AD sign-in log. Once you’ve identified the traffic, you can get the IPv6 address being used and exclude it from your policy."

But according to our tests, AAD sees an IPv6 address coming from an Azure VNET, only if the subnet has the Microsoft.AzureActiveDirectory service endpoint enabled (which is actually an endpoint used by Data Lake, according to this). If the subnet doesn't have that endpoint enabled, AAD sees the VM's public IPv4 address.

Note, in our test, the VNet / subnet / VM don't have IPv6 enabled.

Also, it would help to clarify if that IPv6 address coming from the subnet is fixed per VM, internal, and if it's safe to white-listed in a CA policy (I have a MS support ticket open, asking for this clarification).

Thanks.

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

amanmcse commented 4 years ago

@andresm53 Thank you for your feedback . We will investigate and update the thread further.

nduijvelshoff commented 4 years ago

@andresm53 after several tests it looks like it's a range per subnet, at the moment I assume that is a /120. I think my issue #59653 can be linked to this one.

aaronnavratil commented 4 years ago

Hi, we also have noticed this condition, in our case we are using a web job which accesses Azure Active Directory over a vNet service endpoint (the app service is attached to a vnet), the source address is using an IPv6 Unique Local Address (fd00::/7) however this address range is not assigned to the vnet or visible anywhere else in the Azure Portal. Several questions are brought up, What is the size of this subnet (/64 ?) is this ULA unique to this tenant/vnet/subnet? is it safe to add this to a trusted location in Conditional Access? (note this is how we are working around the issue currently, using "Named Locations - Preview"). Can you please help to address the aforementioned questions? Thanks.

MicrosoftGuyJFlo commented 3 years ago

@andresm53 if this is still an issue please let me know. It sounds like you had a support case open for this. #please-close

nduijvelshoff commented 3 years ago

@MicrosoftGuyJFlo the documentation is still not updated with the missing information. Please chase for an update internally instead of closing an unsolved issue.

knightian commented 2 years ago

I'm experiencing this also, noticed Azure AD Connect from my server is signing in with IPv6 not the VM IPv4 and so it was being blocked by Conditional access policy. I see the IPv6 is not constant so without knowing the IPv6 block how can we add to the exclusion? @MicrosoftGuyJFlo

JamesMCTB commented 2 years ago

We are also experiencing this. Any update @MicrosoftGuyJFlo ?

aaronnavratil commented 2 years ago

Hi all - I'm not sure why MS has been silent on this, but in all my cases the last 32 bits of the ipv6 is a mapping to the ipv4 address subnet/scope configured on the vnet. So in CA policy if you create a conditional access policy with the ipv6 address with the first 96 bits + the mask bits for your ipv4 network (i.e /24).

So if you had 192.0.2.0/24 for the vnet ipv4 subnet - the resulting ipv6 address space COULD BE something like fd00:0000:0000:a9b0:6d26:0100:c000:0200/120. So then in CA you'd add a named location for fd00:0000:0000:a9b0:6d26:0100:c000:0200/120.

I've observed this pattern in ALL our isolated VNET service endpoint Resource Groups.

I hope this helps some of you.

tx0-stb commented 1 year ago

Have the same issue

jbrailsford commented 1 year ago

Hi - I'm experiencing this same behaviour, @aaronnavratil - did you ever find a way to reliably determine the first 96 bits?

Given that service endpoints work across tenants I think it's critical that some of this information is exposed in the portal.

@MicrosoftGuyJFlo I don't think this should be closed personally, the documentation on service endpoint NAT, cross tenant scenarios and ability to determine the service endpoint NAT address pool are all missing.

aaronnavratil commented 1 year ago

Hi @jbrailsford - since the address space seems to be ipv6 Unique Local Addresses (ULA), then the first 48 bits are randomly generated (by design). So the only reliable way I've seen is to have the CA policy block the login, then grab the 96 bits from the log entry in Sign-in Logs. To this day I have no idea why the issue was closed, or why no guidance is given in documentation as to how to classify Conditional Access to secure our workloads. To me it seems that security is an after thought to some product group's todo list. Hope that helps.

jbrailsford commented 1 year ago

Thanks @aaronnavratil - we're trying to get some traction on this through support channels too. Some testing this afternoon has brought to light that it seems like at least the first 64 bits are statically allocated to the virtual network resource. The prefix survives having service endpoints removed & re-enabled. Any over variable (for example, changing the subscription, resource group, location, virtual network) yields a different prefix.

Working backwards and considering one of the use cases for service endpoints within Azure, e.g., for allowing named subnets (by resource ID) to access storage accounts using network ACL's, it seems to be that within Azure there's a mechanism to translate the IPv6 address back to the originating resource (subnet).

All of that leads me to the viewpoint that given a VNET resource ID and a subnet it should be entirely possible - at the very least for Azure support engineers - to determine what that IPv6 address will be.

shammyowens commented 1 year ago

I had the same issue today. Logged a support call and got the following information back.

This is due to service endpoints being enabled on the VM vnet. These service endpoints allows the VMs to connect directly to various microsoft services including Azure AD for authentication.

Vnet service endpoints uses IPv6 encapsulation and NAT (along with some other under-the-hood principles not relevant here) to provide direct connectivity and Vnet metadata to various first-party services across Microsoft's backbone. This enables customers to allow traffic only from their virtual network to their storage account, for example. It builds a VM's source IP address via several factors that get computed to a IPv6 ULA IP (which is like an RFC1918 IPv4 IP) which is unique to a single Vnet and not internet-routable. The IPv6 ULA subnet prefix will not change for the lifetime of the Virtual Network, so long as the Service Endpoints remains enabled on the Vnet.

To stop this from happening you can delete the service endpoints from the vnet for Azure AD.

joteromontes commented 7 months ago

I think there is one concept error here, one service endpoint is created for specific purposes, as per documentation: https://learn.microsoft.com/en-us/azure/virtual-network/virtual-network-service-endpoints-overview

Azure Active Directory has no service endpoints, maybe this is why this has remained silent for so long:

Generally available

Azure Storage (Microsoft.Storage): Generally available in all Azure regions. Azure Storage cross-region service endpoints (Microsoft.Storage.Global): Generally available in all Azure regions. Azure SQL Database (Microsoft.Sql): Generally available in all Azure regions. Azure Synapse Analytics (Microsoft.Sql): Generally available in all Azure regions for dedicated SQL pools (formerly SQL DW). Azure Database for PostgreSQL server (Microsoft.Sql): Generally available in Azure regions where database service is available. Azure Database for MySQL server (Microsoft.Sql): Generally available in Azure regions where database service is available. Azure Database for MariaDB (Microsoft.Sql): Generally available in Azure regions where database service is available. Azure Cosmos DB (Microsoft.AzureCosmosDB): Generally available in all Azure regions. Azure Key Vault (Microsoft.KeyVault): Generally available in all Azure regions. Azure Service Bus (Microsoft.ServiceBus): Generally available in all Azure regions. Azure Event Hubs (Microsoft.EventHub): Generally available in all Azure regions. Azure Data Lake Store Gen 1 (Microsoft.AzureActiveDirectory): Generally available in all Azure regions where ADLS Gen1 is available. Azure App Service (Microsoft.Web): Generally available in all Azure regions where App service is available. Azure Cognitive Services (Microsoft.CognitiveServices): Generally available in all Azure regions where Azure AI services are available.

moonqiuyue commented 6 months ago

According to the public documentation https://learn.microsoft.com/en-us/azure/virtual-network/virtual-network-service-endpoints-overview#limitations "he Microsoft.AzureActiveDirectory tag listed under services supporting service endpoints is used only for supporting service endpoints to ADLS Gen 1. Microsoft Entra ID doesn't support service endpoints natively. "

So the error is expected if you are not using ADLS Gen1