# Azure DevOps service hooks unauthorized after upgrade

**URL:** <https://community.jenkins.io/t/azure-devops-service-hooks-unauthorized-after-upgrade/13206>\
**Category:** Using Jenkins\
**Created:** [March 11, 2024, 9:10am UTC](https://community.jenkins.io/t/azure-devops-service-hooks-unauthorized-after-upgrade/13206 "2024-03-11T09:10:22Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![aysebusk](https://avatars.discourse-cdn.com/v4/letter/a/b4bc9f/32.png) [@aysebusk](https://community.jenkins.io/u/aysebusk)\
**Post date:** [March 11, 2024, 9:10am UTC](https://community.jenkins.io/t/azure-devops-service-hooks-unauthorized-after-upgrade/13206/1 "2024-03-11T09:10:22Z")

</div>

After upgrading Jenkins from version 2.332.4 to 2.426.3 Azure Devops service hooks on code push event become unauthorized. It use Built-in Jenkins API. Git plugin version 5.2.1  
On Azure Devops username and password appear to be valid.  
But when I test it from Azure devops it says in:  
Status Code: 401  
Reason Phrase: Unauthorized  
HTTP Version: 1.1  
Headers:  
{  
X-Content-Type-Options: nosniff  
Cache-Control: no-store, must-revalidate, no-cache  
Date: Mon, 11 Mar 2024 08:01:42 GMT  
Server: Jetty(10.0.18)  
Content-Length: 925  
Content-Type: text/html; charset=iso-8859-1  
}

Environment:  
Jenkins 2.426.3, Git plugin version 5.2.1  
openjdk version “11.0.22” 2024-01-16  
OpenJDK Runtime Environment (build 11.0.22+7-post-Ubuntu-0ubuntu220.04.1)  
OpenJDK 64-Bit Server VM (build 11.0.22+7-post-Ubuntu-0ubuntu220.04.1, mixed mode, sharing)  
Ubuntu 20.04.4 LTS  
Can you help us with this issue?

---

<div class="post-metadata">

**Author:** ![MarkEWaite](https://dub1.discourse-cdn.com/flex013/user_avatar/community.jenkins.io/markewaite/32/20_2.png) [@MarkEWaite](https://community.jenkins.io/u/MarkEWaite)\
**Post date:** [March 11, 2024, 7:36pm UTC](https://community.jenkins.io/t/azure-devops-service-hooks-unauthorized-after-upgrade/13206/2 "2024-03-11T19:36:58Z")

</div>

If the Azure DevOps service hook on code push is calling the `/notifyCommit` URL of the Jenkins controller with arguments, then you need to follow the instructions in the [git plugin documentation](https://plugins.jenkins.io/git/#plugin-content-push-notification-from-repository). That includes:

- Generate a Git plugin notifyCommit access token from the “Configure Global Security” page
- Update the caller to include that token as an additional argument

You can read more about it [SECURITY-284](https://www.jenkins.io/security/advisory/2022-07-27/#SECURITY-284). The improvement was introduced in git plugin 4.11.4.

---

<div class="post-metadata">

**Author:** ![joshea](https://avatars.discourse-cdn.com/v4/letter/j/3e96dc/32.png) [@joshea](https://community.jenkins.io/u/joshea)\
**Post date:** [October 10, 2024, 10:23pm UTC](https://community.jenkins.io/t/azure-devops-service-hooks-unauthorized-after-upgrade/13206/3 "2024-10-10T22:23:26Z")

</div>

Is this fixed by making configuration changes in the DevOps server’s service hooks or is there a config change required on the DevOps server itself. This is unclear. Thanks

---

<div class="post-metadata">

**Author:** ![MarkEWaite](https://dub1.discourse-cdn.com/flex013/user_avatar/community.jenkins.io/markewaite/32/20_2.png) [@MarkEWaite](https://community.jenkins.io/u/MarkEWaite)\
**Post date:** [October 10, 2024, 11:19pm UTC](https://community.jenkins.io/t/azure-devops-service-hooks-unauthorized-after-upgrade/13206/4 "2024-10-10T23:19:22Z")

</div>

The [git plugin documentation](https://plugins.jenkins.io/git/#plugin-content-push-notification-from-repository) offers choices of where you make the change.

1. The most secure method is to change the webhook definition on the caller (Azure DevOps) to include the value of the authentication token that you’ve generated.
2. A less secure method is to disable the authentication in the Jenkins git plugin notifyCommit so long as the request to notifyCommit is a request for polling. That is done by setting the Java property `hudson.plugins.git.GitStatus.NOTIFY_COMMIT_ACCESS_CONTROL=disabled-for-polling` or by setting that value from a [groovy hook script](https://www.jenkins.io/doc/book/managing/groovy-hook-scripts/)  
`hudson.plugins.git.GitStatus.NOTIFY_COMMIT_ACCESS_CONTROL='disabled-for-polling'`
3. The least secure method is to disable all authentication in the Jenkins git plugin notifyCommit by setting the Java property `hudson.plugins.git.GitStatus.NOTIFY_COMMIT_ACCESS_CONTROL=disabled` or by setting that value from a [groovy hook script](https://www.jenkins.io/doc/book/managing/groovy-hook-scripts/)  
`hudson.plugins.git.GitStatus.NOTIFY_COMMIT_ACCESS_CONTROL='disabled'`

Option 1 requires a change to your Azure DevOps webhook definition after you’ve generated the notifyCommit authentication token in Jenkins. Option 2 assumes that your Azure DevOps webhook definition is not passing the `sha1` argument. Option 3 assumes that you will use some other technique to safeguard the notifyCommit on your Jenkins controller

---

<div class="post-metadata">

**Author:** ![joshea](https://avatars.discourse-cdn.com/v4/letter/j/3e96dc/32.png) [@joshea](https://community.jenkins.io/u/joshea)\
**Post date:** [October 14, 2024, 10:03pm UTC](https://community.jenkins.io/t/azure-devops-service-hooks-unauthorized-after-upgrade/13206/5 "2024-10-14T22:03:08Z")

</div>

Thanks Mark! Option #1 is preferred but I need help making the updated request via DevOps Service Hooks. I’m working directly with Microsoft to see if I can get specific guidance on this. The “Jenkins” Service Hooks in DevOps Server I have been using that broke after upgrading from 4.11.3 don’t seem to provide a way to modify the request, but there is a more generic “Web Hooks” option that might work, but I need help figuring out what’s missing. I note that while we have been providing an Admin username and API Token, the newer Git plugin adds the ability to generate the token in Gobal Security. However, it’s unclear how the wrap all that into a proper request using the options within DevOps Server. I’ve shared this chat with the support folks but haven’t yet gotten this resolved. That said, we’ll stick with option 1 though we have been able to upgrade around the git plugin and its dependencies for now. Hoping for an answer this week. Will keep updates here as well. Any additional help is also appreciated.
