I've deployed a new AADDS in Azure. and ever since Im getting a warning on this domain service that it requires:
"Required network security group update
We have detected that your Network Security Group for Azure AD Domain Services does not include the Service Tag ‘AzureActiveDirectoryDomainServices’. We are in the process of making service-side changes which will result in a service disruption for you unless this Service Tag is present. To avoid this service disruption, the Service Tag needs to be added by January 18th, 2021. To make this change, follow the steps in this document: Network security groups and required ports. If you do not make the change, we will make the change for you starting January 22nd, 2021 so that your service will not be impacted.
More about service tags."
Now.. I have already added the required port the way they have explained in their article, but im still getting this warning everytime I check the "view health" in my AADDS.
Can anyone suggest a way forward to resolve this issue?
They said that they would automatically resolve the issue for me on the 22nd but nothing has happened
You may double-check if you have these NSG rules in the NSG associated with the virtual network subnet that your managed domain is deployed into.
Furthermore, you can verify if your configuration or function is working well excluding it's just a warning. Also, verify if there is any Azure policy in your subscription trigger that warning.
So the solution was,
I had deployed the domain in a Resource Group called AADDSRG and the domain controller had its own NSG.
The server was in a separate Resource group and had its own NSG but it is part of the same V-Net as AADDS.
I had a chance to Microsoft representatives and they got me to add the Port to the second NSG.
I still do not understand why I had to do that, since they should only have access to the domain controller, and not the server that is connected to it.
But regardless, this fixed the issue.
Hope this information helps someone in future.
Related
I'm trying to get the company to use Azure Firewall as we start to move production workloads to Azure, however the network team have stated there are limitations when using Azure firewall. For example they have saod the Firewall reboots or drops all connections when you update a rule on it?
Is this true? Would anyone know of any limitations of using Azure Firewall. The network team prefer to use Checkpoint firewalls in Azure which are fine, but I would rather use Azure firewall, if its not going to fall down eveytime we do an update to teh rules.
That just doesn't sound like its right, as Azure Firewall is prouction ready resource.
• Please find the link below for detailed known documented limitations of Azure Firewall: -
https://learn.microsoft.com/en-us/azure/firewall/overview#known-issues
It clearly states all the issues regarding configuration of rules, NAT of UDR and other features of Azure that are used in integration with it. There, it clearly states that for configuration updates regarding the Azure Firewall, it takes three (3) to five (5) minutes on average to take effect independently, i.e., if multiple configuration updates are done to the Azure Firewall, each configuration update takes separate time to take effect and reciprocate it in its functioning. Thus, please check this, and as for updating of rules is concerned, I don’t think the existing rules defined on Azure Firewall are dysfunctional or the Azure Firewall as an appliance goes down for few periods of time when the rules are getting updated.
Azure Front Door does not allow frontend endpoint deletion if the endpoint's domain still points to the Front Door using a CNAME record. The same holds even when there is just the verification domain (afdverify).
409 Conflict
Cannot delete frontend endpoint "www.example.com" because it is still directly or indirectly (using "afdverify" prefix) CNAMEd to front door "example.azurefd.net". Please remove the DNS CNAME records and try again.
While I hate that there is no way to delete such a frontend, there is a way to deal with that even if the DNS zone cannot be changed by the Front Door owner -- just don't assign the frontend endpoint to any routing rule and don't mind it; it consumes just a bit of developer's attention, which makes it somewhat bearable.
The problem comes with the fact that such a frontend prevents even the deletion of the whole Front Door, which in turn prevents deletion of the whole resource group.
Why is that a problem? Consider that a single subscription is shared by the whole dev team and someone creates a Front Door instance for experiments, uses his own domain and later leaves the team. Now the resource consumes money as there has to be at least one routing rule for the default frontend endpoint and routing rules are paid per time unit, and there is no obvious way to get rid of it.
Is there a way to delete such a Front Door instance besides contacting Microsoft support or asking the owner of the domain to pretty please delete the records pointing to the Front Door?
On 5th April 2021 I received email from Microsoft that a following change was introduced in Azure:
On 9 April 2021, we're updating Azure Front Door and Content Delivery Network to help prevent dangling DNS entries and the security risks they create. At that time, we'll start requiring the removal of canonical name (CNAME) records for Azure Front Door and Content Delivery Network resource endpoints from DNS before the resources can be deleted.
To delete Azure Front Door or Content Delivery Network resources, you must first remove the resource endpoint CNAME records from DNS starting on 9 April 2021.
If you have questions, get answers from community experts in Microsoft Q&A. If you have a support plan and you need technical help, please create a support request.
If you do not own that domain at all the best you can do is to contact Microsoft through Support Plan or your CSP provider and ask for deletion or removal of the domain from your front door instance.
We had the same issue. While checking the Microsoft documentation we found that Microsoft has introduced this breaking change (Terraform provider for ARM issue #11231).
But it seems like the CNAME check can be disabled for a subscription via Azure CLI az feature:
az feature register --namespace Microsoft.Network --name BypassCnameCheckForCustomDomainDeletion
First, run the above command and then go to the Front Door resource and try deleting it.
If you need to enable the CNAME check again:
az feature unregister --namespace Microsoft.Network --name BypassCnameCheckForCustomDomainDeletion
If you need to check the status of the feature:
az feature list -o table --query "[?contains(name, 'Microsoft.Network/BypassCnameCheckForCustomDomainDeletion')].{Name:name,State:properties.state}"
I had same issue, but it was fixed. like this
recreate dns zone, add CNAME record for it. Like in your case
afdverify.example.com CNAME , then go frontdoor resource, delete it.
I think so it will helps to you
In my current situation, we have several Azure Function apps that talk to an Azure SQL database (using Entity Framework, should it matter), using functions that trigger on an Azure ServiceBus trigger.
In the last weeks we have been improving security by using a VNET and subnets to only allow access to the Azure Database server by only the Function apps that need to use it. However, I have run into a strange issue. It seems that now the database server is set to disallow traffic apart from the defined subnets in which my fuction apps run, the function apps start giving intermittent SQLExceptions when connecting to the database with the message that some specific IP is not allowed by the database Firewall rules. The weird thing is that this error is not consistent. I would expect either for the function app to be declined at the firewall for it's IP, or be allowed all the time, but not randomly as is currently the case.
Question
Is there something that I am missing with my setup? Or, how do I force my function apps in subnets to use their internal IP that is allowed by the database server firewall rules, and not some other outbound IP address that is not in the database firewall rules?
Alternatively: What can possibly explain that access to the database sometimes succeed (indicating a proper internal IP used by the funcation app), and sometimes fail on the firewall (with an unknown IP address), seemingly at random.
Hopefully somebody can help!
Detailed Description of situation
The Function App has a function that is triggered by a Service Bus trigger. The Function App is running with a P1v2 Premium service plan with Vnet integration on.
The app is running inside a Subnet in our environment with a defined IP adress range with a /26 subnet mask. If I check the environment variables of the funciton app in Kudu I can see the PRIVATE_IP_ADDRESS setting is in the subnet range. The database firewall is set up to disallow all traffic, apart from the subnet of my function app as follows:
Triggering the function app which will write some stuff into the database works sometimes (Indicating that the access to the database is working at least when the IP address of the function is the correct one) however, there are also a lot of SQLExceptions with the following error:
Cannot open server 'database-server-name' requested by the login. Client with IP address 'XXX.XXX.XXX.XXX' is not allowed to access the server. To enable access, use the Windows Azure Management Portal or run sp_set_firewall_rule on the master database to create a firewall rule for this IP address or address range. It may take up to five minutes for this change to take effect.
The IP address mentioned in the error is NOT the internal IP defined on the Vnet or subnet IP range. It is also not even one of the IP's that show up in the Possible Outbound Ip addresses of the function app,
These happen more or less randomly. Sometimes they don't appear for x triggers, sometimes it fails for hundres of calls in a row.
Enabling the Datbaase server setting "Allow Azure services and resources to access this database server" stops the error from occuring, but of course that is counter to configuring the firewall to allow certain subnets
What I have tried
Setting the configuration settings WEBSITE_VNET_ROUTE_ALL and WEBSITE_DNS_SERVER on the function app to force traffic to use the VNET route as metioned here: Unable to connect Azure Function with Azure SQL using private endpoint
Adding Storage as service endpoint to the subnet as mentioned here: Unable to connect to Azure Function App after integrating into VNET
Restarting and stopping/starting the Function app
Changing the Function app Scaling to force a change in outbound IP addresses as mentioned here: https://learn.microsoft.com/en-us/azure/azure-functions/ip-addresses#outbound-ip-address-changes
Your Azure Function will only use a private outbound IP address picked from your VNet when you have VNet integration enabled. The VNet integration option is only available in the Function Premium Plan.
Additionally, the environment variables WEBSITE_VNET_ROUTE_ALL and WEBSITE_DNS_SERVER you already mentioned should be set as well as mentioned here (assuming your SQL server is in the same VNet).
Of course a new day and fresh perspective brings the probable answer.
While I havent changed anything about the setup I mentioned in my question, I was reading this post again: https://learn.microsoft.com/en-us/azure/azure-functions/ip-addresses#outbound-ip-address-changes
It mentioned switching the service plan temporary force an IP change. I initially misinterpreted this as switching between the DEV and premium plans, which cannot happen because the DEV plans don't support VNET integration. So I switched plans between the P1v2 and P1v3 plans. This however did not work.
What was meant here was to switch beween S1 and P1v2 plans. The Standard plans are hidden behind this link:
It also shows this small message net to the Apply button.
After switching between the S1 and P1v2 plans for a moment and resubmitting deadlettered servicebus messages to the function app, everything started working again.
I assume the IP switch was necessary, but switching between P-plans is not what triggers it. It has to be between standard and premium.
I'm running an azure function which gets data from an API and stores it in a blob. Everything worked fine and stopped working out of nowhere. We then got in contact with our provider and they told us they made some changes in their API. After we made the necessary changes in our code,started getting an IP denied error from their part. I then searched and found the possible outbound IP addresses for the Azure Function. They whitelisted the whole list and still
They aren't getting any requests from those IP's,
We are not able to access that data for the same reason our IP is denied.
We've been running the code in a local machine and it works completely fine, but this is just a temporary fix and we want to keep everything in the cloud.
I've been stuck with this for about 3 weeks. I've looked into different solutions and I found about Azure Logic Apps and Azure Service Fabric.
Is there something missing in my Azure Function that isn't allowing me to make requests to the API? Am I using the wrong outbound IP? Also, if I use any of the other two services, will I encounter with the same problem? I did some research on them and I think they both also use multiple outbound IP addresses, so I'm worried I'll get the same problem.
Using NAT gateway you can specify a static IP address for outbound traffic, your function app need to be attached on a subnet which is not available for consumption plan.
Here is where you should be getting the Azure IP address ranges from. Azure Functions originate from the App Service Plan ranges. Note that this is updated weekly, things change, but not too often. Your provider will need to open all the relevant ranges and keep up to date with any changes. If your solution is not mission critical with a high SLA, then having your service provider open the relevant ranges and deal with failures, updating the ranges on an ad-hoc basis should be fine.
Secondly, if you have a good relationship with the provider, ask them to check the firewall, they will be able to give you an indication of the IP's getting blocked by checking the firewall logs. This will help you find the right range.
The only guaranteed way to solve this in a mission critical solution is to run your Azure Functions from an dedicated app service plan with a dedicated IP address. This is an expensive option but will be the most robust.
Additional helpful information here on how App Services works with IPs can be found here.
everyone.
I recently bought a domain on azure and I can't bind it to an app service (web app).
When I try to bind a domain it says "App Service Domain is in a broken state. Please navigate to the App Service Domain resource and delegate to Azure DNS before adding hostname."
When navigating to the domain at https://resources.azure.com, it looks my dnsZoneId is assigned to another resource group and I don't know how to change it.
I tried to delete the DNS zone and recreate it but I can't bind the dns back from https://dcc.secureserver.net
Can Anyone help me please?
Thanks in advance
Newest
About how to change your dnsZoneId to another resource group, you can read this post. I think it useful to you.
PRIVIOUS
Under normal circumstances, this problem does not occur, because when you successfully purchase a domain in azure, all information and services of the domain name are hosted on azure.
There is a similar case here, you can refer to it. May be helpful to you.
If there is a problem, I guess the reason is:
Some of your misoperations may cause the domain name service or settings to be configured incorrectly, making it unusable. (This probability is relatively low)
It may be the domain management service of azure, there may be a problem in your region. It may take a while to try again, or transfer the domain name to godaddy for management. (The reason for this is because I have encountered it in godaddy before, but it was solved after migrating the domain name to Tecent in China)
If the above operations have been tried and cannot be solved, please raise a ticket in the portal for help.