Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-55813

Improve AD/LDAP attribute analysis for locked accounts

    XMLWordPrintable

Details

    Description

      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:

      Attachments

        Issue Links

          Activity

            wfollonier Wadeck Follonier created issue -
            spinus1 Alessio Moscatello made changes -
            Field Original Value New Value
            Assignee Wadeck Follonier [ wfollonier ] Alessio Moscatello [ spinus1 ]
            wfollonier Wadeck Follonier made changes -
            Remote Link This issue links to "#89 in active-directory (Web Link)" [ 22316 ]
            wfollonier Wadeck Follonier made changes -
            Remote Link This issue links to "#34 in ldap (Web Link)" [ 22317 ]
            wfollonier Wadeck Follonier made changes -
            Remote Link This issue links to "#3866 in core (Web Link)" [ 22318 ]
            spinus1 Alessio Moscatello made changes -
            Assignee Alessio Moscatello [ spinus1 ] Wadeck Follonier [ wfollonier ]
            danielbeck Daniel Beck made changes -
            Link This issue is duplicated by SECURITY-900 [ SECURITY-900 ]
            fbelzunc Félix Belzunce Arcos made changes -
            Status Open [ 1 ] In Progress [ 3 ]
            fbelzunc Félix Belzunce Arcos made changes -
            Status In Progress [ 3 ] Open [ 1 ]
            jvz Matt Sicker made changes -
            Remote Link This issue links to "#96 in active-directory (Web Link)" [ 23013 ]
            jvz Matt Sicker made changes -
            Remote Link This issue links to "#89 in active-directory (Web Link)" [ 22316 ]
            jvz Matt Sicker made changes -
            Description In the current situation, there is no check about the accounts that are disabled, locked or expired, or having their credentials expired in active-directory.

            This ticket has the goal to improve the situation by reading as much as possible from the attributes returned by the server.
            In the current situation, there is no check about the accounts that are disabled, locked or expired, or having their credentials expired in active-directory.

            This ticket has the goal to improve the situation by reading as much as possible from the attributes returned by the server.

            Relevant docs:
             * [https://ldapwiki.com/wiki/Administratively%20Disabled]
             ** [https://ldapwiki.com/wiki/ACCOUNTDISABLE]
             * [https://ldapwiki.com/wiki/Account%20Expiration]
             ** [https://ldapwiki.com/wiki/AccountExpires]
             * [https://ldapwiki.com/wiki/Password%20Expiration]
             ** [https://ldapwiki.com/wiki/AD%20Determining%20Password%20Expiration]
             * [https://ldapwiki.com/wiki/Account%20Lockout] and [https://ldapwiki.com/wiki/Intruder%20Detection]
             ** [https://ldapwiki.com/wiki/Active%20Directory%20Account%20Lockout]
            jvz Matt Sicker made changes -
            Remote Link This issue links to "LDAP PR second attempt (Web Link)" [ 25811 ]
            jvz Matt Sicker made changes -
            Remote Link This issue links to "Core PR second attempt (Web Link)" [ 25812 ]
            oleg_nenashev Oleg Nenashev made changes -
            Labels security-hardening
            oleg_nenashev Oleg Nenashev made changes -
            Status Open [ 1 ] In Progress [ 3 ]
            oleg_nenashev Oleg Nenashev made changes -
            Status In Progress [ 3 ] In Review [ 10005 ]
            jvz Matt Sicker made changes -
            Assignee Wadeck Follonier [ wfollonier ] Matt Sicker [ jvz ]
            jvz Matt Sicker made changes -
            Description In the current situation, there is no check about the accounts that are disabled, locked or expired, or having their credentials expired in active-directory.

            This ticket has the goal to improve the situation by reading as much as possible from the attributes returned by the server.

            Relevant docs:
             * [https://ldapwiki.com/wiki/Administratively%20Disabled]
             ** [https://ldapwiki.com/wiki/ACCOUNTDISABLE]
             * [https://ldapwiki.com/wiki/Account%20Expiration]
             ** [https://ldapwiki.com/wiki/AccountExpires]
             * [https://ldapwiki.com/wiki/Password%20Expiration]
             ** [https://ldapwiki.com/wiki/AD%20Determining%20Password%20Expiration]
             * [https://ldapwiki.com/wiki/Account%20Lockout] and [https://ldapwiki.com/wiki/Intruder%20Detection]
             ** [https://ldapwiki.com/wiki/Active%20Directory%20Account%20Lockout]
            In Spring Security, a user account has four flags related to the account's validity:
             * Whether or not the account is enabled (used by admins to disable accounts rather than deleting them)
             * Whether or not the account is locked (used by intrusion detection systems typically)
             * Whether or not the account is expired (used to set a specific lifetime for an account; this can be handy for time-bound contracts and such)
             * Whether or not the account's credentials are expired (used by administrators to re-enact outdated, broken security policies from the 1990's and 2000's)

            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:
             * [https://ldapwiki.com/wiki/Administratively%20Disabled]
             ** [https://ldapwiki.com/wiki/ACCOUNTDISABLE]
             * [https://ldapwiki.com/wiki/Account%20Expiration]
             ** [https://ldapwiki.com/wiki/AccountExpires]
             * [https://ldapwiki.com/wiki/Password%20Expiration]
             ** [https://ldapwiki.com/wiki/AD%20Determining%20Password%20Expiration]
             * [https://ldapwiki.com/wiki/Account%20Lockout] and [https://ldapwiki.com/wiki/Intruder%20Detection]
             ** [https://ldapwiki.com/wiki/Active%20Directory%20Account%20Lockout]
            jvz Matt Sicker made changes -
            Component/s cli [ 15624 ]
            jvz Matt Sicker made changes -
            Status In Review [ 10005 ] In Progress [ 3 ]
            jvz Matt Sicker made changes -
            Status In Progress [ 3 ] In Review [ 10005 ]
            jvz Matt Sicker made changes -
            Description In Spring Security, a user account has four flags related to the account's validity:
             * Whether or not the account is enabled (used by admins to disable accounts rather than deleting them)
             * Whether or not the account is locked (used by intrusion detection systems typically)
             * Whether or not the account is expired (used to set a specific lifetime for an account; this can be handy for time-bound contracts and such)
             * Whether or not the account's credentials are expired (used by administrators to re-enact outdated, broken security policies from the 1990's and 2000's)

            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:
             * [https://ldapwiki.com/wiki/Administratively%20Disabled]
             ** [https://ldapwiki.com/wiki/ACCOUNTDISABLE]
             * [https://ldapwiki.com/wiki/Account%20Expiration]
             ** [https://ldapwiki.com/wiki/AccountExpires]
             * [https://ldapwiki.com/wiki/Password%20Expiration]
             ** [https://ldapwiki.com/wiki/AD%20Determining%20Password%20Expiration]
             * [https://ldapwiki.com/wiki/Account%20Lockout] and [https://ldapwiki.com/wiki/Intruder%20Detection]
             ** [https://ldapwiki.com/wiki/Active%20Directory%20Account%20Lockout]
            In Spring Security, a user account has four flags related to the account's validity:
             * Whether or not the account is enabled (used by admins to disable accounts rather than deleting them)
             * Whether or not the account is locked (used by intrusion detection systems typically)
             * Whether or not the account is 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:
             * [https://ldapwiki.com/wiki/Administratively%20Disabled]
             ** [https://ldapwiki.com/wiki/ACCOUNTDISABLE]
             * [https://ldapwiki.com/wiki/Account%20Expiration]
             ** [https://ldapwiki.com/wiki/AccountExpires]
             * [https://ldapwiki.com/wiki/Account%20Lockout] and [https://ldapwiki.com/wiki/Intruder%20Detection]
             ** [https://ldapwiki.com/wiki/Active%20Directory%20Account%20Lockout]
            jvz Matt Sicker made changes -
            Description In Spring Security, a user account has four flags related to the account's validity:
             * Whether or not the account is enabled (used by admins to disable accounts rather than deleting them)
             * Whether or not the account is locked (used by intrusion detection systems typically)
             * Whether or not the account is 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:
             * [https://ldapwiki.com/wiki/Administratively%20Disabled]
             ** [https://ldapwiki.com/wiki/ACCOUNTDISABLE]
             * [https://ldapwiki.com/wiki/Account%20Expiration]
             ** [https://ldapwiki.com/wiki/AccountExpires]
             * [https://ldapwiki.com/wiki/Account%20Lockout] and [https://ldapwiki.com/wiki/Intruder%20Detection]
             ** [https://ldapwiki.com/wiki/Active%20Directory%20Account%20Lockout]
            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:
             * [https://ldapwiki.com/wiki/Administratively%20Disabled]
             ** [https://ldapwiki.com/wiki/ACCOUNTDISABLE]
             * [https://ldapwiki.com/wiki/Account%20Expiration]
             ** [https://ldapwiki.com/wiki/AccountExpires]
             * [https://ldapwiki.com/wiki/Account%20Lockout] and [https://ldapwiki.com/wiki/Intruder%20Detection]
             ** [https://ldapwiki.com/wiki/Active%20Directory%20Account%20Lockout]
            basil Basil Crow made changes -
            Link This issue relates to JENKINS-64850 [ JENKINS-64850 ]
            basil Basil Crow made changes -
            Link This issue relates to JENKINS-64629 [ JENKINS-64629 ]
            jvz Matt Sicker made changes -
            Link This issue causes JENKINS-65806 [ JENKINS-65806 ]
            wfollonier Wadeck Follonier made changes -
            Resolution Fixed [ 1 ]
            Status In Review [ 10005 ] Resolved [ 5 ]

            People

              jvz Matt Sicker
              wfollonier Wadeck Follonier
              Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: