Secure Your Azure DevOps Organization NOW!

Securing on Organization in Azure DevOps is a pretty important thing to do.

Today I'm gonna show you exactly how you can do it using tools like security policies, multi-factor authentication, and much more.

Intro

I've decided to make this post because working with many companies and organizations I've noticed that often the security of development tools and environments is not the priority.

But the question is: how can you keep safe your production if you don't take care of all the previous stages and environments? And anyway often tools like Azure DevOps and Azure Pipelines are accessing production in some form, especially for deployment... so, better keep everything safe and secure, right?

There are many tools we can use to secure our Azure DevOps organization. I will try to cover most of them here but let me know in the comment section below if you have any other use case or scenario you would like me to cover, or if you are using a tool or technique I haven't mentioned.

Video

As usual, if you are a visual learner, or simply prefer to watch and listen instead of reading, here you have the video with the whole explanation and demo, which to be fair is much more complete than this post.

Link to the video: https://youtu.be/nrYSu_046cw

If you rather prefer reading, well... let's just continue :)

Connect to AAD

First thing you want to do in your Azure DevOps organization is connecting your Azure DevOps organization with your Azure AD tenant. This, as we will see, brings so many advantages to the table. Benefits like strong identity governance, MFA (Multi Factor Authentication), access policies, etc.

Watch the video to see how to connect AzDO to AAD

Note that you need to do that with an account that has the proper permissions in your Azure AD.

Also, if you have already other users in your Azure DevOps organization that don't belong to the Azure AD tenant you have chosen, they will temporarily loose access to the organization. You can eventually map them back to other users or invite them to your Azure AD.

Alright, now that your Azure DevOps organization is connected to Azure AD, let's see what we can do with it.

Dynamic User Access

First cool thing is the Dynamic User Access. Let's say you have some groups in Azure AD where all your developers are. You can dynamically add access for azure DevOps project using the Azure AD group rule.

Just go to Users under your organization settings, then click on Group Rules, and Add a group rule.

Search for the group you have in Azure AD, select the Access Level you want to Grant, and the projects you want to grant it to.

That's it, now every AD user in that group will be able to access the projects you've selected, with the access level you've set.

You can always add or remove projects, and the AD administrators can manage these accesses without using the Azure DevOps settings, directly from Azure AD.

There is more to say about this, we are just scratching the surface here, so let me know in the comments section below if you want to see this explored more in depth.

Conditional Access Policies

Probably the most useful thing you can do thanks to Azure Active Directory, and I promise that after this one we will move to something that doesn't require AAD, aside from a bonus one at the end, is enabling the Conditional Access Policy Validation.

You can find this setting under the "Policies" menu inside "Organization Settings".

When you enable it, you'll be able to enforce all the policies you have in AAD.

Things like allowing the connection to Azure DevOps only from specific IP Addresses, or authorized computers, and so forth.

More Policies

We've just seen the Policies page when enabling the conditional access from AAD, but there's more to it. As you can see, the available policies you can enable vary whether you have your organization connected to AAD or not, but there are some common ones.

The first one, the Alternate Credentials for authentication, shouldn't be actually there anymore. Will go away very soon, so disable it straight away and use Personal Access Tokens instead. If you want to know how to create a PAT in Azure DevOps, I have a post and a video that explains just that.

The second policy is to enable 3rd party Apps to connect to Azure DevOps using OAuth.

It's enabled by default, but you can turn it off if you don't plan to use any third-party application. I wouldn't recommend it though, because most like you will use applications that need OAuth.

Next one is similar, but it cover SSH authentication.

Again this is enabled by default, and as the name says it enables Azure DevOps to generate encryption keys for using with Linux, macOS, and Windows running Git for Windows. I would not recommend turning this off either.

Finally, here we have the Allow public projects policy.

As the name says, when enabled it give the possibility to the users to create public projects. It is disabled by default, because public projects are visible to anyone who has a link to them. Enable this only if you want to have your code publicly available.

Organization Permissions

Final topic I want to talk about today is fine tuning your Organization permissions. Azure DevOps has great and rich permission management system.

Watch the video to see this in action

Going to the "Permissions" menu in the Organization settings, you can fine tune all the permissions if they don't meet your company policies or they don't suit your needs. In here you can manage the policies for Groups and Users separately.

Working on Groups, you can set the permissions for each part of the service. For example, the Group that is supposed to work only on CI\CD won't need access to the creation of Processes for Azure Boards, so you can remove that. You can add members to a group, and change its general settings.

When working on Users, instead, you can really fine tune all their permissions. Let's say you have a user that needs to be able to perform some additional operations, either extemporary or as part of his duty. You can easily access their profile and enable them on the permissions needed. This will override the permissions the user has as part of the groups they are in.

Disable Organization Creation

Ok, almost done. But as promised, a bonus policy for you.

Working with a lot of clients, I've noticed that there is a tendency where all the company departments create new organizations in Azure DevOps, and IT department cant control the security settings and who has rights to access the source code.

Thanks to the Azure AD integration, however, we have a solution.

In the Azure Active Directory page under Organization Settings, in fact, we have this Restricting organization creation toggle.

When Enabled, creation of new Organizations for users in your AAD will be disabled. Only users in the Azure DevOps Administrator group and users you add to the "Allow list" will be able to create new orgs.

If you don't see the toggle in your settings, make sure the user you have logged in into Azure DevOps with is added to the "Azure DevOps administrators group" in your Azure AD. By default no user is.

Conclusions

Alright, that's it for today.

Let me know in the comment section below if you've found this guide useful, if you use any other technique to secure Azure DevOps, and if there is any area you would like for me to go deeper into.

You may also want to watch this video here, where I explain how to create the Personal Access Tokens.

Like, share and follow me for more content:

YouTube
Buy me a coffee
Patreon
Merch
Facebook page
GitHub
Twitter
LinkedIn
Podcast