![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(281.6, 65%, 37%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EWC%3C/text%3E%3C/svg%3E)
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(41.6, 65%, 14%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EPK%3C/text%3E%3C/svg%3E)
Olá @Wellington Carlos Lopes Siqueira ,
O usuário recebe HTTP 403 (Forbidden) ao tentar executar operações de push/pull request no Azure DevOps, mesmo após remover/reincluir o usuário em grupos e gerar um novo PAT.
- Verifique se o 403 está relacionado ao contexto de “pipeline/identidade” (não apenas ao usuário)
- Quando o acesso a determinadas ações no Azure DevOps falha com erro 403, o problema geralmente não está no PAT em si, mas na identidade que está executando a ação (usuário, conta de serviço de build ou identidade da pipeline).
- Certifique-se de que as permissões sejam concedidas às Project/Collection Build Service Accounts e, em seguida, em Repository → Security, habilite Contribute to pull requests → Allow para a identidade que executa a pipeline.
- O exemplo mencionado envolve a API
POST /pullRequests/{id}/threads, que retorna 403 ao tentar criar “threads” de Pull Request.
Portanto, se a operação de push/pull request estiver sendo realizada por um processo de automação/pipeline (ou uma conta de build), é importante validar se essa identidade possui as permissões Git necessárias, especialmente as permissões relacionadas a Pull Requests.
- Se o 403 estiver vindo do acesso a recursos usados pela automação (por exemplo, Azure Storage)
Se a falha no push/pull request for causada por uma etapa da pipeline/Terraform que acessa o Azure Blob Storage (artefatos, backend, etc.), o erro 403 pode ocorrer devido a:
Restrições de rede/firewall do Storage:
- Listas de IPs permitidos
- Configurações de “Public network access”
- Private endpoints
Permissões RBAC insuficientes:
Funções como:
- Storage Blob Data Contributor
- Storage Blob Data Owner
- Storage Blob Data Reader (dependendo do requisito) O material fornecido explica como verificar:
Storage account → Networking → Firewall and virtual networks
Storage account → IAM → Verificar atribuições de funções
Também destaca que uma função genérica de Contributor pode não fornecer as permissões necessárias no data plane (acesso aos dados do blob).
Para confirmar a causa, é necessário identificar a origem exata do erro 403:
- Azure DevOps Git/Pull Request API
- Ou um recurso externo acessado pela pipeline, como o Azure Storage
Respostas às suas perguntas:
- Um ObjectID divergente entre Entra ID e Azure DevOps pode causar um 403?
Sim. Se o ObjectID do usuário no Entra ID não corresponder à identidade armazenada no Azure DevOps (por exemplo, após recriação do usuário ou migração de tenant), as validações de autorização do Azure DevOps podem falhar e retornar 403 Forbidden.
A geração de um novo PAT não resolve um problema de mapeamento de identidade, pois o PAT apenas autentica o usuário; ele não corrige a associação da identidade.
- Existe um procedimento para “sincronizar/corrigir o ObjectID” sem recriar a conta/licença?
Sim, na maioria dos casos o usuário não precisa ser recriado.
- A correção normalmente envolve atualizar o mapeamento de identidade:
- Remover permissões ou associações antigas do usuário no Azure DevOps.
- Remover referências de grupos/permissões desatualizadas.
- Adicionar novamente o usuário atual do Entra ID aos grupos e permissões necessários no Azure DevOps.
Se o usuário foi excluído e recriado no Entra ID, o novo ObjectID não poderá ser reutilizado. Nesse caso, as permissões devem ser atribuídas novamente à nova identidade.
- Existem logs/traces/IDs de correlação que podem ajudar na investigação?
Sim. Coletar as informações abaixo ajuda a acelerar a análise:
- Logs de auditoria do Azure DevOps
- Data e hora exata da falha em UTC
- Informações da organização/projeto/repositório
- UPN do usuário afetado
- Operação que falhou (push, pull, ação de PR, chamada de API)
Qualquer Activity ID, Correlation ID ou identificador retornado na mensagem de erro ou nos traces do cliente
Essas informações ajudam a determinar se o problema está relacionado a:
- Mapeamento de identidade entre Entra ID e Azure DevOps
- Permissões do Azure DevOps
- Identidade da pipeline/conta de serviço
- Outra camada de autorização
Espero que isso ajude!
Se a solução foi útil, por gentileza, reserve um momento para clicar em e selecionar "Sim" na pergunta "Esta resposta foi útil?". Caso tenha qualquer outra dúvida, estamos à disposição para ajudar.
