-
Improvement
-
Resolution: Fixed
-
Major
In Spring Security, a user account has three relevant flags related to the account's validity:
- Disabled (used by admins to disable accounts rather than deleting them)
- Locked (used by intrusion detection systems typically)
- Expired (used to set a specific lifetime for an account; this can be handy for time-bound contracts and such)
As it exists now, these attributes are not actually specified by any of Jenkins' security realms. In Spring Security, these attributes are typically only used by a JDBC-backed user database (or other first-party Spring Security user databases), but Jenkins does not expose that functionality. Spring Security's servlet filters and such all check these flags on the user details loaded for an authenticated user, and performing a normal password login will also respect flags provided the AD or LDAP server itself denies the login due to these states (which is how they normally work). These flags are not validated when authenticating with alternative methods than the user's password such as via an API token or SSH key. This may allow an account that hasn't logged in since having their validity state change may still be able to use their API token, SSH key, or any other automated actions that work on behalf of that user (e.g., authorize project running a pipeline as the user if they still have commit access).
The goal of this issue to introduce additional security hardening to attempt to detect when user accounts have gone invalid without needing to re-authenticate them (which would have necessitated storing their password long term which is a no go). When user details are loaded from an Active Directory or LDAP security realm, the user's operational attributes should be checked according to some commonly used standards such as the draft LDAP password policy and Active Directory's attributes.
Relevant docs:
- causes
-
JENKINS-65806 LDAP plugin has wrong 'administratively disabled' logic for Oracle Internet Directory (OID)
-
- Resolved
-
- relates to
-
-
- In Review
-
-
-
- Closed
-
- links to
[JENKINS-55813] Improve AD/LDAP attribute analysis for locked accounts
| Assignee | Original: Wadeck Follonier [ wfollonier ] | New: Alessio Moscatello [ spinus1 ] |
| Remote Link | New: This issue links to "#89 in active-directory (Web Link)" [ 22316 ] |
| Remote Link | New: This issue links to "#34 in ldap (Web Link)" [ 22317 ] |
| Remote Link | New: This issue links to "#3866 in core (Web Link)" [ 22318 ] |
| Assignee | Original: Alessio Moscatello [ spinus1 ] | New: Wadeck Follonier [ wfollonier ] |
| Link | New: This issue is duplicated by SECURITY-900 [ SECURITY-900 ] |
wfollonier what do you mean by cover most of the usage? The usage within Jenkins plugins that may wish to impersonate a user? Or other LDAP servers? I've been starting to investigate this and have gotten somewhat confused around the current goal.
jvz In the core, I covered only the cast of the API Token, but didn't investigate further, it was just a PoC at that time. We need to ensure that every use of the Security realm check methods are consistent, i.e. checking the attribute of the UserDetails before using them.
The PRs in ldap and active-directory uses the Microsoft's standard for the attribute names/values. I am not sure that's sufficient to cover most of the usage.