jenkinsci / jenkinsci/active-directory-plugin
[JENKINS-45176] Allow user lookup by userPrincipalName (instead of sAMAccountName)
- Dominant language
- Java
- Stars
- 53
- Forks
- 115
- PR merge metrics
- No merged PRs in 30d
Description
Suggested feature (which would be very helpful to us): Allow a configuration option, e.g. a 'User-identifying attribute' dropdown with values 'sAMAccountName' (default) and 'userPrincipalName', and use that attribute when looking up users in ActiveDirectoryAuthenticationProvider.getDnOfUserOrGroup() (and perhaps elsewhere).
Background.
We have a Subversion where the each 'commit author' field is an UPN (e.g., pietje.puk@keteldorp.nl) from Active Directory. Commits from this Subversion are picked up by our Jenkins, which then sends an email to that commit author if a build fails.
Jenkins assumes that that author name (pietje.puk@keteldorp.nl) is a Jenkins user name, and requests the 'authentication realm' for that user's email address.
We are using the Active Directory plugin/realm (2.4 currently), and therefore that request ends up in ActiveDirectoryAuthenticationProvider.java line 273, where the plugin assumes that the Jenkins user name is a sAMAccountName (e.g., ppuk).
Since in our case it isn't, the email address is never found, and Jenkins reports
Not sending mail to unregistered user pietje.puk@keteldorp.nl
(We currently work around this by specifying
```
java ... -Dhudson.tasks.MailSender.SEND_TO_UNKNOWN_USERS=true -Dhudson.tasks.MailSender.SEND_TO_USERS_WITHOUT_READ=true ... -jar ...
```
and that works but the resulting warnings
Warning: pietje.puk@keteldorp.nl is not a recognized user, but sending mail anyway
are ugly. Another workaround would be to switch to the LDAP plugin, but that requires way too much configuration for my taste, and I'm struggling to get that right.)
---
Originally reported by
marnix_klooster, imported from: Allow user lookup by userPrincipalName (instead of sAMAccountName)
fbelzunc
Raw content of original issue
Suggested feature (which would be very helpful to us): Allow a configuration option, e.g. a 'User-identifying attribute' dropdown with values 'sAMAccountName' (default) and 'userPrincipalName', and use that attribute when looking up users in ActiveDirectoryAuthenticationProvider.getDnOfUserOrGroup() (and perhaps elsewhere).
Background.
We have a Subversion where the each 'commit author' field is an UPN (e.g., pietje.puk@keteldorp.nl) from Active Directory. Commits from this Subversion are picked up by our Jenkins, which then sends an email to that commit author if a build fails.
Jenkins assumes that that author name (pietje.puk@keteldorp.nl) is a Jenkins user name, and requests the 'authentication realm' for that user's email address.
We are using the Active Directory plugin/realm (2.4 currently), and therefore that request ends up in ActiveDirectoryAuthenticationProvider.java line 273, where the plugin assumes that the Jenkins user name is a sAMAccountName (e.g., ppuk).
Since in our case it isn't, the email address is never found, and Jenkins reports
Not sending mail to unregistered user pietje.puk@keteldorp.nl
(We currently work around this by specifying
java ... -Dhudson.tasks.MailSender.SEND_TO_UNKNOWN_USERS=true -Dhudson.tasks.MailSender.SEND_TO_USERS_WITHOUT_READ=true ... -jar ...and that works but the resulting warnings
Warning: pietje.puk@keteldorp.nl is not a recognized user, but sending mail anyway
are ugly. Another workaround would be to switch to the LDAP plugin, but that requires way too much configuration for my taste, and I'm struggling to get that right.)
Contributor guide
Research direction
Start with ActiveDirectoryAuthenticationProvider.java, especially getDnOfUserOrGroup(), where the issue identifies the current sAMAccountName lookup. Trace the related user lookup paths and configuration handling before deciding where the user-identifying attribute belongs. Done means users identified by userPrincipalName can be resolved while sAMAccountName remains the default.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- authentication
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100