Intro

Enterprise-wide visibility of Azure DevOps projects has often been a requested feature for Azure DevOps. Unfortunately, Microsoft has never given us the option so far, only private and public projects. In the enterprise context, public projects make no sense in very few cases. But isn't it still possible to do inner-source in an enterprise context without enterprise visibility?

I have thought about an approach that is both secure and has some advantages.

What I'm describing here is an approach based on Access Packages and the use of AAD groups in Azure DevOps.

But what exactly are Access Packages? For the exact description I would like to refer to the documentation from Microsoft: docs.microsoft.com/en-us/azure/active-direc..

In short, Access Packages allow us to easily order roles (AAD group memberships). At the same time the whole thing is paired with an approval system, access reviews, expiration date of the membership and much more.

So what do we do exactly?

We will create an Access Package during the scope of this post, and at the same time I will also document the ordering process, etc.

Prerequisites For Using Access Package Functionality

• You need to have one of the following licenses:
  • Azure AD Premium P2
  • Enterprise Mobility + Security (EMS) E5 license
• Azure DevOps needs to be connected to Azure Active Directory

Create Azure Active Directory Group

First we create an AAD group, mine is called "azuredevops-inner-source". To do this, we first go to the Azure Portal, then go to Azure Active Directory and create the new security group. For me it looks like this:

Create Access Package + Add Created AAD Group

First we go to Azure Active Directory then to Identity Governance and there to Access packages then to New access package. The first things we need to enter is the name of the Access Package, the description and also the Catalog. The Catalog is a set of Azure Active Directory groups that can be added to the Access Package at all. In my case I use "General", because this is where all my AAD groups are located.

Now can can click next to get to the next screen (Resource roles) here you are going to add one or more groups, which the users will get if he orders the Access Package. In my case I only added the group I created before. Important: The option "Role" in the back determines whether the user will be added to the group as owner or member. What we want is member.

Then we can go to "Requests". In my case I chose "For users in your directory" and also "All users (including guests).

To get everything more secure I also added an approval (in my case "specific", not "manager"). Also I set "Enable new requests" to yes. Here corresponding screenshots:

Now I have switched directly to Lifecycle. Here, corresponding runtimes and so on can be specified for the Access Package. Also, whether there should be Access Reviews for it, which makes sense in the enterprise context in any case.

Now we can finish the creation of the Access Package by clicking on "Review + create".

Add AAD Group To Azure DevOps Project(s)

Now we can add the AAD group to the Azure DevOps project(s). For this we go to Project settings then to Permissions and select appropriate group. In my case the Contributors group. After that we go to the Member tab and add the AAD group. The AAD group can of course be added to as many projects as you like, and that's exactly how we get some enterprise visibility.

At this point, the group is still empty.

Order Access Package

To get to the portal that allows us to order an Access Package, we use the following link (caution: YOURORGA must be replaced accordingly, of course)

https://myaccess.microsoft.com/@YOURORGA.onmicrosoft.com

After login with your account, it should look something like this:

Now we can start the roll order via "Request". In the order process, a corresponding reason must be specified, optionally a validity period can also be specified.

After clicking on "Submit", the approver of the access package should also receive an email notification.

Access Package Approval

If the approver now goes to MyAccess page, he should find appropriate requests in the "Approvals" section. Reminder for MyAccess-URL:

https://myaccess.microsoft.com/@YOURORGA.onmicrosoft.com

With a click on "Details" the request can be approved :

A few seconds after the approval, the requestor should then have access to the Azure DevOps project.

Some thoughts

Of course, the whole thing can be covered in a much simpler way, such as simply adding users to a project team, because the default project team group is also a contributor.

I've talked to a few Azure DevOps administrators from different companies now, and often it's simply that the default Azure DevOps groups are not used (Contributor, Project Admin, etc.). Often custom groups are even created for the projects. I also hear more often that no one is a Project Administrator anymore either.

Especially in the enterprise environment with several hundred users, it is absolutely necessary to think about the structure of the Azure DevOps organization, and at the same time, of course, about the corresponding structure of the team projects. It is often the case that project access is simply completely restrictive, which can have various reasons.

And at least when you have thought about the Azure DevOps organization and the team projects, and you are possibly pursuing a "not quite so open" concept, the next step is to think about how the users could be authorized to access a projects.

Here I have only shown a minimal example of how Access Packages can be used, but let's see it in a broader context: Access Packages could clearly also be used to cover all existing projects in an organization, so that access can be ordered accordingly.