We are constantly working to improve our experience end-to-end, including how our products are purchased. In response to feedback from our customers, we are pleased to announce some changes that will simplify how some Azure DevOps services are purchased.
Today we are excited to announce that Azure DevOps is now available over Azure ExpressRoute. Customers who typically operate in the government and financial services sectors have requested this support because they want private connections that don’t go over the public Internet for security reasons. ExpressRoute also typically offers them more reliability, faster speeds, and lower latencies than typical Internet connections.
Azure DevOps now supports AzureAD (AAD) users accessing organizations that are backed by Microsoft accounts (MSA). For administrators, this means that if your organization uses MSAs for corporate users, new employees can use their AAD credentials for access instead of creating a new MSA identity.
On the 24th of July 2018, we notified some customers via e-mail and on this blog about a planned action that we would start taking in relation to the malicious ESLint NPM package incident. This action is now underway.
As promised in the Protecting our users from the ESLint NPM package breach blog post last week, we have deployed new REST APIs to allow administrators of Visual Studio Team Services (VSTS) accounts to centrally revoke Personal Access Tokens (PAT) and JSON Web Tokens (JWT) created by users in their accounts.
Today, we’re excited to announce that users with the Stakeholder access level can now be administrators in Visual Studio Team Services (VSTS). With these upcoming changes, Stakeholders can administer access levels, permissions, and settings – if they have been granted permissions to do so.
Visual Studio Team Services (VSTS) offers a suite of DevOps capabilities to developers including Source control, Agile planning, Build, Release, Test and more. But until now all these features require the user to first login using a Microsoft Account before they can be used.
On January 5, 2018, I announced that Visual Studio Team Services will no longer allow creation of new MSA users with custom domain names backed by AzureAD. While most customers agree with the direction of this change, I got clear feedback that they could not connect their VSTS to AzureAD by the March 31 deadline.
In February 2017, VSTS announced support for Azure Active Directory Conditional Access Policy (CAP). One caveat that was called out in that announcement was that alternate authentication mechanisms, such as personal access tokens, would not enforce CAP.
As I discussed previously,
A few weeks ago, I posted about a change coming to organizations managing their identities with Microsoft Accounts (MSAs); as of March 30th, you will no longer able to create new MSAs with a custom domain name that is linked to an Azure Active Directory tenant.