Release v0.4.0

[msw1nkels]

Summary

Feature release adding repository initialization support, enhanced user entitlement data, and improved check/approval resource management.

What's Changed

• feat(Get-AdoUserEntitlement): Add dateCreated property to output
• feat: Add ResourceId parameter to all Check and Approval cmdlets
• feat: Add New-AdoPushInitialCommit cmdlet for creating initial commits in Azure DevOps repositories
• chore: Using namespace System.Collections.Generic declaration at the module root

Breaking Changes

• None

---

This discussion was created from the release v0.4.0.

[msw1nkels]

Hi @Antiohne,

Just released a new version with your PR #120.
Please let me know if everything is working as expected.

[Antiohne]

I tested my report and it now contains the date of each user when they were added to the organization.

[msw1nkels]

Adding the date each user joined the organization sounds really useful for auditing and lifecycle management.

I’m also curious what insights you’ve included in your report, and what specific use cases you’re targeting. If you’re open to sharing the report, or even a sample output, I’d love to take a look. It would be great to compare approaches!

This might even turn out to be complementary. I’m currently focusing on the deployment side of things, and I’m sharing my end‑to‑end governance use cases here:
👉 https://github.com/msc365/az-devops-governance

Reporting like yours could be a strong addition on top of that, especially for detecting configuration drift.

[Antiohne]

The report I am developing will be used to support audits relating to the following Software Development Life Cycle (SDLC) requirement:

Unused permissions for system development (privileged access) must be audited and removed on a half-yearly basis.

and similar requirements such as:

i. Access to source code is limited to the minimal amount of staff needed to develop code for the ICT Asset.
ii. Access to source code has to be revoked ultimately on the last working day for developers leaving the organization or moving to another function or team.

A few months ago, I became responsible for an existing Azure DevOps environment. As is common in older setups, access rights are assigned directly to user accounts, Azure DevOps groups, and Entra ID groups. My first goal is to clean up the current environment and move all access management to Entra ID groups so permissions can be centrally maintained.

To support this cleanup, I created a PowerShell script that uses direct REST API calls to Azure DevOps. The script gathers all users in the organization, their date of addition, last login (to identify unused accounts and potential license waste), assigned licenses, and project-level permissions (including access levels). Using this dataset, I generate an Excel report (via the ImportExcel module), which I use to create change requests for placing users into the appropriate Entra ID groups.

I am currently refactoring this report to make use of this module, improving maintainability and readability of the code. After migrating, I will use the report to inform managers of the current access assignments within their teams and help validate that permissions are appropriate and up to date. One remaining challenge is the variety of configuration changes developers make across pipelines, repositories, and other areas where access can be modified.

Additionally, to report on access at the user level, I must map Entra ID group memberships to Azure DevOps permissions. At the moment, I handle this through the Az.Accounts and Az.Resources modules instead of Microsoft Graph, as I currently do not have the required permissions to use Graph for this purpose.

[msw1nkels]

Thanks for sharing this! It’s a really cool real‑life use case, and the level of depth you’re putting into the access cleanup and reporting is super valuable.

By the way, are you aware of the Azure DevOps security PowerShell script samples Microsoft provides?
👉 https://learn.microsoft.com/en-us/azure/devops/organizations/security/security-scripts

They cover a lot of patterns around permissions, groups, and auditing. Might give you some extra ideas or shortcuts for your report.