[JENKINS-24067] Handling partial anonymous bind failures gracefully

While talking to one of the users troubleshooting their problem, I discovered that an AD forest can be set up such that the top-level domain does allow anonymous binds, but sub-domains do not.

In such a situation, the anonymous bind will succeed, but when Jenkins tries to locate any users in it, it'll not find them, as users are all defined in sub-domains.

As a result, any attempt to ActiveDirectoryUnixAuthenticationProvider.retrieveUser(name,null) (i.e., loading user without having his password) will fail with UsernameNotFoundException and not UserMayOrMayNotExistException.

This makes Jenkins believe that it has positively determined that the user no longer exists in AD, and thus refuses to let the user login with API token, even if the API token matches up.

Jenkins' behaviour is reasonable here, as this is the only situation where Jenkins can positively determine that the user do not exist. If we treat this situation as UserMayOrMayNotExistException, there will never be UsernameNotFoundException, and we'll end up allowing users to login via API token even after he was removed from AD — a security hole.

I'm not sure how to address this, but leaving this as an open issue to see if other people are impacted by this, and see if we can come up with some compromise to avoid this kind of hard-to-diagnose problems.

---
Originally reported by kohsuke, imported from: Handling partial anonymous bind failures gracefully

• status: Open
  
• priority: Major
  
• component(s): active-directory-plugin
  
• resolution: Unresolved
  
• votes: 0
  
• watchers: 1
  
• imported: 2025-12-07
  

Raw content of original issue

While talking to one of the users troubleshooting their problem, I discovered that an AD forest can be set up such that the top-level domain does allow anonymous binds, but sub-domains do not.


In such a situation, the anonymous bind will succeed, but when Jenkins tries to locate any users in it, it'll not find them, as users are all defined in sub-domains.


As a result, any attempt to ActiveDirectoryUnixAuthenticationProvider.retrieveUser(name,null) (i.e., loading user without having his password) will fail with UsernameNotFoundException and not UserMayOrMayNotExistException.


This makes Jenkins believe that it has positively determined that the user no longer exists in AD, and thus refuses to let the user login with API token, even if the API token matches up.


Jenkins' behaviour is reasonable here, as this is the only situation where Jenkins can positively determine that the user do not exist. If we treat this situation as  UserMayOrMayNotExistException, there will never be UsernameNotFoundException, and we'll end up allowing users to login via API token even after he was removed from AD — a security hole.


I'm not sure how to address this, but leaving this as an open issue to see if other people are impacted by this, and see if we can come up with some compromise to avoid this kind of hard-to-diagnose problems.

Start at ActiveDirectoryUnixAuthenticationProvider.retrieveUser(name,null) and trace how anonymous binds across the AD forest produce UsernameNotFoundException or UserMayOrMayNotExistException. Review the API-token login path that consumes these exceptions. Done means an agreed, tested handling for partial anonymous-bind failures that avoids both false user rejection and allowing removed users through API tokens.

Written by the indexing model from the issue text.