We have raised the limit to 100 recently. We are regularly reviewing the limits and will continue to look for opportunities to raise the limits even further. If you have scenarios requiring limits higher than what is supported, please add your scenario details here (if you are comfortable with that) or raise an issue with Azure support and we will get back to you.
100 is a step in the right direction, however honestly there should be no limits at all. It should be up to your customers and their workload as to how many sites should be published behind application gateway. Most websites require a total of 4 listeners. domain.com (HTTP) domain.com (HTTPS), www.domain.com (HTTP), www.domain.com (HTTPS). The HTTP listeners are just a redirect to HTTPS and they are not really used. It doesn't make sense to be limited to only publishing 25 websites if they are mostly idle and in turn you're not even coming close to maxing out the performance capabilities of the app gateway.
I agree with this. Given that most sites will require a HTTP listener to redirect to HTTPS, this limits you to only publishing 10 sites behind each application gateway. If your sites are relatively low traffic, this is a waste of resources to have many application gateways that are mostly idle. There should be no limit on this and it should be up to administrators to decide how many application gateways are needed to support the workload.
+1 for this. Many organizations are using a 3rd party virtual security appliance and all inbound traffic must go through the security appliance due to security requirements. This makes V2 of the application gateway useless. It would be beneficial to be able to use V2 so you can terminate TLS at the app gateway and still do HSTS.
I agree. Support doesn't even listen when you add a message saying that the ticket can be closed, they try to follow up anyway. It seems Microsoft likes to waste money by having their employees needlessly respond to tickets that can be closed.
44 votesunder review · AdminAzure IaaS Engineering Team (Azure IaaS Engineering Team, Microsoft, Microsoft Azure) responded
We added auto-stop in the platform and we are considering the addition of auto-start as well. Please continue to vote up this item if you would like to see auto-start included with our existing auto-stop feature.
We have started work on the Vnet integration for Linux sites. The feature is currently in preview.
I will update this status as the engineering team progresses.
I would suggest that the vNET integration needs to support inbound traffic. The current vNET integration is outbound only. A couple of reasons for this is we would like to require that developers connect to a VPN in order to connect to FTP to satisfy a MFA requirement. IP restrictions do not work as there is no way to restrict FTP access to particular IP addresses while allowing HTTP access from the internet. Additionally we'd like to inspect HTTP traffic by routing it through a network security virtual appliance. Ideally the app service should be assigned an internal IP address on your vNET so you can do both of those things as if they were running on a virtual machine within the vNET.
We recently announce the General Availability of Azure Active Directory Domain Services (Azure AD DS) authentication for Azure Files! By enabling integration with Azure AD DS, you can mount your Azure file share over SMB using Azure AD credentials from Azure AD DS domain joined Windows VMs with NTFS ACLs enforced. For more details, please refer to our blog post:http://aka.ms/azure-file-aadds-authentication-ga-blog.
A part of the GA announcement, we shared the upcoming plan to extend the authentication support to Active Directory (AD) either hosted on-premises or in cloud. If you need an Azure Files solution with AD authentication today, you can consider installing Azure File Sync (AFS) on your Windows File Servers where AD integration is fully supported.
If you are interested to hear future updates on Azure Files Active Directory Authentication, please complete this sign-up survey:https://aka.ms/AzureFilesADAuthPreviewSurvey.
Azure Files Team
Is there any rough estimate for a roadmap goal of when you'll be able to mount a drive from user endpoints running Windows and MacOS that are not Virtual Machines running in Azure? This is a requirement to seriously consider using Azure Files to replace on-premises SMB/CIFS shares.
I agree, also security logs for this should be able to sent over to Azure Log Analytics. This prevents organizations that have strict security requirements from using Azure Files. Many organizations have a security requirement to maintain access logs to all files to have an audit trail of what user accounts are accessing what data.
This is now available in Preview for Windows computers, it requires a registry edit on the client side to enable it. Still no support for controlling the OneDrive Sync client via conditoinal access for MacOS. https://docs.microsoft.com/en-us/onedrive/enable-conditional-access
859 votes177 comments · Azure Active Directory » Multi-factor Authentication · Flag idea as inappropriate… · Admin →
This feature is now on the roadmap. The MFA team is planning to adjust admin roles or create a new role that will allow delegation of MFA registration and credentials to an admin role.
It would be good for the Azure AD team to provide an official update on this. Some users are stating that "Authentication Administrator" works, others say it does not.
Thanks for the valid suggestion. Your feedback is now open for the user community to upvote which allows us to effectively prioritize your request against our existing feature list and also gives us insight into the potential impact of implementing the suggested feature
Thanks for the valid suggestion. Your feedback is now open for the user community to up-vote & comment on. This allows us to effectively prioritize your request against our existing feature backlog and also gives us insight into the potential impact of implementing the suggested feature.
263 votes43 comments · Azure Active Directory » Role-based Access Control · Flag idea as inappropriate… · Admin →
Just wanted to post another update that this is a high priority, but we do not have any details to announce yet.
/Stuart and Vince
I just wanted to provide feedback that this is very much a needed feature.
It seems like a pretty bad engineering oversight when the service was first designed.
Best practices 101 says that you should never assign permissions to individual users, you assign permissions to groups and add users to the groups.
DNSSEC remains on our long term roadmap, however it is unlikely to be available in CY 2019. If DNSSEC is a critical and immediate requirement for your business we’d suggest that you consider evaluating 3rd party DNS hosting solutions that provide this feature.
Thanks for the valid suggestion. Your feedback is now open for the user community to upvote & comment on. This allows us to effectively prioritize your request against our existing feature backlog and also gives us insight into the potential impact of implementing the suggested feature.
Thank you for the feedback. We will consider this suggestion.
744 votesunder review · AdminAzure IaaS Engineering Team (Azure IaaS Engineering Team, Microsoft, Microsoft Azure) responded
This request is still something that we still have on our backlog for a potential future update, but we are not able to provide a timeline for it at this point.
We’re working on planning this feature.
60 votes10 comments · Azure Active Directory » Multi-factor Authentication · Flag idea as inappropriate… · Admin →
There is planned work to address this scenario. We don’t feel that backup codes provide a good security option as they’re often misplaced. Also, it’s hard to have users print them out and have them when they’re needed. Instead, we are looking at a time-limited passcode that could be generated either by the user (just in time when it’s needed) or by an admin (for example a helpdesk agent). The organization admin would have control over when a user could generate these codes. The code can be used for a limited time, then it will no longer be valid.
Note – for areas with limited cellphone connectivity (or roaming charges), the code generated in the authenticator app will allow MFA login. The time-limited passcode is meant to stand in if the user temporarily forgot/lost their phone.
2 votes0 comments · Azure Active Directory » Privileged Identity Management · Flag idea as inappropriate… · Admin →