AZURE_DEVOPS_ORG (new) and the three Entra secrets MSFT_TENANT_ID, MSFT_CLIENT_ID and MSFT_CLIENT_SECRET_VALUE, which are shared with the Azure and Microsoft 365 integrations. One more secret, AZURE_DEVOPS_PAT, is optional (see Step 4).
This integration shares the Entra app registration with Azure and Microsoft 365. If either is already connected, the threeMSFT_*secrets are already saved and you only addAZURE_DEVOPS_ORG. Rotating the app’s client secret affects all three integrations. Azure DevOps is a separate product from Azure, so it has its own page and its own tables (azdo_*).
Scope of this integration today. ConfigView collects who can do what in Azure DevOps and where pipelines can reach: users, their access level and last use, organization and project administrators, groups, projects (including public ones), repositories and whether their default branch has a review policy, service connections and the cloud they deploy to, agent pools and self-hosted agents, pipelines, variable groups, secure files, installed extensions, personal access tokens and the audit log. ConfigView only reads. It never reads source code, work items, build logs, secret values, service connection credentials or token values, and it never creates, changes or deletes anything.
What you need
- An Azure DevOps organization that is connected to your Microsoft Entra tenant (Organization settings → Microsoft Entra). Service principals can only be added to organizations backed by Entra.
- The Entra app registration from the Azure or Microsoft 365 setup, or a new one: see Azure setup, Part 1 for creating it. You do not add any Entra “API permissions” for Azure DevOps. Azure DevOps does not use them; access is granted inside Azure DevOps (Step 3).
- Permission to add users to the Azure DevOps organization (a Project Collection Administrator, or a project administrator if your invitation policy allows it)
Step 1: Open the Azure DevOps page in ConfigView
Open ConfigView in a second browser tab and leave it open:https://{companyname}.configview.com/admin/integrations/azure-devops
Step 2: Enter your organization and the Entra app
- In ConfigView, enter your organization name in
AZURE_DEVOPS_ORG. It is the part afterdev.azure.com/in your address, for examplecontosoforhttps://dev.azure.com/contoso(pasting the full address also works) - If Azure or Microsoft 365 is already connected,
MSFT_TENANT_ID,MSFT_CLIENT_IDandMSFT_CLIENT_SECRET_VALUEare already filled in. Otherwise create the app registration as described in the Azure setup and paste the Directory (tenant) ID, Application (client) ID and the client secret Value (not the Secret ID) - The token ConfigView requests is for the Azure DevOps resource (
499b84ac-1321-427f-aa17-267ca6975798/.default). It is fixed, so there is nothing to enter for it
Step 3: Add the app to Azure DevOps
A valid Entra token is not enough on its own: Azure DevOps must know the app. An app that was never added gets a “Sign-in required” answer (HTTP 203), and ConfigView’s check tells you so.- In the Entra admin center open Enterprise applications, find your app, and copy its Object ID. Use this one, not the object ID shown under App registrations
- In Azure DevOps open Organization settings → Users → Add users
- Enter the app’s name (the Enterprise application name). Choose access level Basic (Stakeholder has no access to Azure Repos, so repositories and branch policies would be empty). Leave “Send email invites” off: applications do not receive invitations
- Click Add. Application identities can’t sign in to the web portal or create tokens, and each one uses a paid Basic license in this organization
Permissions to grant (least privilege first)
Azure DevOps decides what the app may read from its groups and per-resource roles, not from its access level alone. Grant what you want ConfigView to cover. Every area ConfigView can’t read is skipped, not failed.
If you are comfortable with it, adding the app to Project Collection Administrators covers everything at once. ConfigView still only reads, but an app in that group could do far more if its client secret leaked, so prefer the narrower grants above where you can, give the client secret a short expiry, and consider Entra Conditional Access for workload identities on the app.
Step 4: Optional personal access token for token reporting
Azure DevOps lists other people’s personal access tokens only to an organization administrator through the Token Admin API. If you gave the app Project Collection Administrators in Step 3 you can skip this step. If you did not, and you want the Personal Access Tokens table:- A Project Collection Administrator opens User settings → Personal access tokens → New Token
- Name it
ConfigView, pick the shortest expiry you are comfortable renewing, choose Custom defined scopes and tick only Token Administration → Read - Copy the token and paste it into
AZURE_DEVOPS_PATin ConfigView
AZURE_DEVOPS_PAT empty if you don’t need it.
Step 5: Connect and verify
- Back on
https://{companyname}.configview.com/admin/integrations/azure-devops, confirm the credentials show as saved - Click Connect. ConfigView creates its tables and schedules every collector at your default run time. Stop any you don’t want under Collectors:
- Click Verify now. The health check reads the secrets, gets a token, reads your projects, and tries one record from each of the other areas.
- Entra token fails. The tenant ID, client ID or secret is wrong, the secret expired, or the app isn’t in that tenant.
- Organization (projects) fails with HTTP 203 or 401. The app was not added to the organization, was added with the wrong object (use the Enterprise application’s name), the organization isn’t connected to the same Entra tenant, or
AZURE_DEVOPS_ORGis not the organization name. - An area shows as skipped. Azure DevOps refused the app for that area. The message says which permission is missing (Step 3). If you don’t want that area there is nothing to fix.
- Audit log skipped. Auditing needs an organization connected to Entra and the View audit log permission.
Data Tables
Once the scripts run, these tables are created in your database. Each table has arun_at column and a raw_json column, which holds the record as Azure DevOps returned it, minus anything listed under What isn’t collected. Each table keeps only the newest run, except azdo_audit_events, which is a ledger that keeps adding new events.
Things worth knowing
Access is decided inside Azure DevOps. Unlike Azure or Microsoft 365 there is nothing to consent to in Entra. If an area comes back empty, the app is missing a group membership or a Reader role in Azure DevOps, not an API permission. Application identities use a license. The app you add counts as a Basic user in the organization (billed per organization). Removing the app from Entra does not remove it from Azure DevOps: remove stale application identities from Organization settings → Users too. ConfigView lists them inazdo_users with subject_kind = servicePrincipal.
Public projects are the biggest exposure. Anyone on the internet can read a public project without signing in. ConfigView flags every one.
Service connections are what pipelines deploy with. A connection that holds a stored secret, is shared across many projects, or is scoped to a whole management group lets any pipeline in those projects act in your cloud. ConfigView records the connection type, authentication scheme and the Azure subscription or host it reaches, never its credentials. Connections using workload identity federation hold no secret.
Personal access tokens need an administrator identity. The Token Admin API lists one user’s tokens per call, so the collector makes a request per user and reads names, scopes and dates only. Full-access tokens and tokens valid for over a year are flagged.
The audit log needs auditing. It is available to organizations connected to Microsoft Entra ID, keeps about 90 days, and the first ConfigView run reads the last 30 days (new runs resume from the newest event). Reading the audit log itself is aggregated by Azure DevOps and skipped.
Admin group members are direct members. If an Entra group is a member of Project Collection Administrators it is listed as one row; look inside that group in Entra for the people.
What can’t be listed. Azure DevOps has no API that lists every OAuth app authorized by users, so ConfigView doesn’t collect that. Review it under Organization settings → Microsoft Entra / Authorizations and Entra’s enterprise applications.
Rate limit. Azure DevOps meters each identity in throughput units (200 per sliding five minutes) and slows or rejects requests above that, telling the caller how long to wait. All ConfigView collectors share one service principal, so each paces itself at 30 requests a minute and waits as long as Azure DevOps asks. Project fan-out (repositories, policies, service connections, pipelines, variable groups) and the per-user token lookups are the slowest on organizations with many projects or users.
What isn’t collected
- Service connection credentials (client secrets, passwords, tokens, keys) and any authorization parameter other than the tenant ID, application ID, authentication type and scope
- Variable values (names and whether each is marked secret only) and secure file contents
- Personal access token values
- Source code, commits, pull request contents, work items, wikis, test results and build logs
- Billing and invoice details