Identifying the client that locks the user:

We would like to start with finding the log entries which might explain the behavior mentioned above. To do that, we recommend looking for the below entries in the logs:

artifactory-request.log:
2022-06-29T09:50:57.358Z|5b060543c6e05c2a|69.174.144.105|non_authenticated_user|HEAD|/api/docker/local-docker/v2/docker-image-name/manifests/81|401|-1|0|1|containerd/v1.4.12-k3s1

You may find the corresponding request in other logs using the same Trace ID ‘5b060543c6e05c2a’:

artifactory-access.log:
2022-06-29T09:50:57.358Z [5b060543c6e05c2a] [DENIED LOGIN] for client : NA / 69.174.144.109.

Based on your log analysis, you may have already identified the IP address and the user-agent that probably is using out-dated credentials and is contributing towards the Temporary Login Suspension of the associated user. In case you are still not sure that the 401 errors you see are actually associated to the user that is getting suspended, we can enable enhanced debug logging to reveal more information.

To enable the enhanced logging, add the below XML snippet to the logback.xml file:

<appender name="SecurityUserLock" class="ch.qos.logback.core.rolling.RollingFileAppender">
        <File>${log.dir}/artifactory-SecurityUserLock.log</File>
        <rollingPolicy class="org.jfrog.common.logging.logback.rolling.FixedWindowWithDateRollingPolicy">
            <FileNamePattern>${log.dir.archived}/artifactory-SecurityUserLock.%i.log.gz</FileNamePattern>
        </rollingPolicy>
        <triggeringPolicy class="org.jfrog.common.logging.logback.triggering.SizeAndIntervalTriggeringPolicy">
            <MaxFileSize>25MB</MaxFileSize>
        </triggeringPolicy>
        <encoder class="ch.qos.logback.core.encoder.LayoutWrappingEncoder">
            <layout class="org.jfrog.common.logging.logback.layout.BackTracePatternLayout">
                <pattern>%date{yyyy-MM-dd'T'HH:mm:ss.SSS, UTC}Z [jfrt ] [%-5p] [%-16X{uber-trace-id}] [%-30.30(%c{3}:%L)] [%-20.20thread] - %m%n</pattern>
            </layout>
        </encoder>
</appender>
<logger name="org.artifactory.storage.db.security.service.UserLockInMemoryServiceImpl" additivity="false">
  <level value="debug"/>
  <appender-ref ref="SecurityUserLock"/>
</logger>
<logger name="org.artifactory.security.SecurityServiceImpl" additivity="false">
  <level value="debug"/>
  <appender-ref ref="SecurityUserLock"/>
</logger>

*Enhancing the logs as suggested above may have performance implications, should be applied for a limited amount of time. In addition, the enhanced logs may reveal sensitive information, and should be handled with care.

You can now look for the below entries in the newly created artifactory-SecurityUserLock.log, an example would be:

2022-07-01T17:14:59.755Z [jfrt ] [DEBUG] [c4b041cc8b12f162] [o.a.s.SecurityServiceImpl:1450] [tp-nio-8081-exec-369] - Checking if user is not locked

2022-07-01T17:14:59.756Z [jfrt ] [DEBUG] [c4b041cc8b12f162] [o.a.s.SecurityServiceImpl:1497] [tp-nio-8081-exec-369] - Ensuring that user should not be blocked

2022-07-01T17:14:59.756Z [jfrt ] [DEBUG] [c4b041cc8b12f162] [serLockInMemoryServiceImpl:133] [tp-nio-8081-exec-369] - Delayed user: username 'ci-automation' login by 1000 milliseconds due to 2 incorrect login attempts

2022-07-01T17:14:59.756Z [jfrt ] [DEBUG] [c4b041cc8b12f162] [o.a.s.SecurityServiceImpl:1509] [tp-nio-8081-exec-369] - User ci-automation is blocked due to incorrect login attempts till 1656695700646