Why am I seeing this in the log?

Hi,

First things first: These two log messages are nothing to worry about. Probably the level ‘warn’ in your first example is not appropriate and should be an ‘info’ at most.

So what does it mean: Users can have many sources in SCM-Manager, the LDAP plugin is just one example. So when a user logs in, all these sources (aka authentication realms) are queried. The first log message is just an info, that this user could not have been found in your LDAP directory.

The second message for your external (LDAP) user is just a hint, that the internal database of SCM-Manager was updated with the information found by the LDAP plugin, so that you can see this user on the Users page and assign permissions and groups.

I hope this helps, if not, just keep asking.

René

I see. Thank you for explaining. But I was seeing very poor performance of the application with 8 cpus at 100%, so I was looking at the log and it was recording these entries every minute or so. It seemed like it was not necessary.

I also looked at the configuration and realized that I have the java memory option set to 1g. So, I raised it to 4g and rebooted the server. Things are running much better now. Do you have any recommended server configurations in your docs? I am running an ubuntu linux vm.

~WRD0348.jpg

image001.png

image002.png

image009.png

image004.png

image011.png

image006.jpg

NOTE: Below settings are for RPM based flavors - tested on CentOS-8.4, RockY-Linux-8.4 and AlmaLinux-8.4

  1. System environment:
    1.1. OS: Rocky Linux release 8.4 (Green Obsidian)
    1.2. CPU: 16 CORES
    1.3. RAM: 16 GB
    1.4. HDD: SSD
    1.5. SCM-Manager version: 2.27.2
    1.6. JDK:
       Openjdk version "11.0.13" 2021-10-19 LTS
       OpenJDK Runtime Environment 18.9 (build 11.0.13+8-LTS)
       OpenJDK 64-Bit Server VM 18.9 (build 11.0.13+8-LTS, mixed mode, sharing)
  1. STOP the scm-manager service
  2. Change the file “/etc/default/scm-server
    3.1. Comment out “EXTRA_JVM_ARGUMENTS
    #EXTRA_JVM_ARGUMENTS="$EXTRA_JVM_ARGUMENTS -Djetty.host=$HOST -Djetty.port=$PORT"

  1. Change the file “/opt/scm-server/bin/scm-server
    4.1. Add or update these arguments and values carefully
# ----------------------------------------------------------------------------

#   Copyright (c) 2001-2002 The Apache Software Foundation.  All rights
#   reserved.

# scm-server host interface
HOST="0.0.0.0"

# scm-server port
PORT="8080"

# extra jvm arguments
#############################################################################
#EXTRA_JVM_ARGUMENTS="-Djava.awt.headless=true -Dlogback.configurationFile=logging.xml"
EXTRA_JVM_ARGUMENTS="-Djetty.host=${HOST} \
-Djetty.port=${PORT} \
-Xms1024m \
-Xmx8192m \
-XX:+UseG1GC \
-XX:MaxMetaspaceSize=2048m \
-XX:MaxGCPauseMillis=200 \
-XX:+ParallelRefProcEnabled \
-XX:+AlwaysPreTouch \
-XX:+UseStringDeduplication \
-XX:+DisableExplicitGC \
-XX:+ExplicitGCInvokesConcurrent \
-Djava.awt.headless=true \
-Dlogback.configurationFile=logging.xml \
-Dcom.sun.management.jmxremote \
-Dcom.sun.management.jmxremote.port=10053 \
-Dcom.sun.management.jmxremote.authenticate=false \
-Dcom.sun.management.jmxremote.ssl=false"
###############################################################################

BASEDIR="/opt/scm-server"

Note that the “com.sun.management.jmxremote” are for Zabbix JMX monitoring interface.

  1. START SCM-Manager service

  2. The load on the server can be monitored with Zabbix through the JMX interface (Java default monitoring console also can give a quick overview)

These are the enterprise scalable production JVM settings that are working for me and I am seeing a crisp experience with the SCM-Manager 2.27.2

3 Likes

today I am being asked by my IT people why scm-manager is making 300k+ of a threat of “User Login Brute Force Attempt”. Can you help me figure this out? please

Just for clarification: Does this alert come from an LDAP that SCM-Manager is connected to? If this is the case, the question is, how many users your instance has. We have a cache that should reduce the ldap connections, but might not be sufficient for your case.

To get some more insights, you could use the Support Plugin and create a trace log for some time. With this, we can see, how many requests SCM-Manager makes against the ldap.

~WRD0348.jpg

image001.png

image002.png

image003.png

image004.png

image005.png

(Attachment 6FT0ROAUr8S.zip is missing)

I have asked where they are getting the report, and will let you know. I ran the support logs and have tried to email them but the zip file generated by your product was rejected by your system. how can I upload it here?

here is the report that my IT dept is seeing.
Top attacker sources
Panorama : Wednesday, March 16, 2022
Source Address Source Host Name Source EDL Source User Source Dynamic Address Group Count
xxx.xx.xxx.xx(IP) Hostname domain\username 276.01 k
etc…

Hi Marlene,

you could try to split your zip file. This is an available option in your zip programm (like 7zip and many more) before you are creating a zip file.

At first you would have to unzip the log trace and then zip it in several files. Afterwards you should be able to upload them.

I believe we figured it out. the user was using a svn notifier that was hitting the repos every minute.

1 Like

Great you found it, good work :+1:
Thanks for the update!

well unfortunately, not so fast. I am still seeing hundreds of entries for a local user who is trying to access svn repos. This is probably fisheye/crucible updating the index, but why would it keep trying ldap once it knows this is an internal user? this must be made smarter! my ldap server is getting hammered!
2022-04-01 07:21:39.099 [qtp1793329556-22135507] [ ] WARN sonia.scm.auth.ldap.UserSearcher - no user with username jenkins found
no user with username jenkins found
2022-04-01 10:41:09.153 [qtp1793329556-22863096] [ ] WARN sonia.scm.auth.ldap.UserSearcher - no user with username jenkins found
2022-04-01 10:41:09.165 [qtp1793329556-22795497] [ ] WARN sonia.scm.auth.ldap.UserSearcher - no user with username jenkins found
2022-04-01 10:41:09.176 [qtp1793329556-22863096] [ ] WARN sonia.scm.auth.ldap.UserSearcher - no user with username jenkins found
2022-04-01 10:41:09.188 [qtp1793329556-22795497] [ ] WARN sonia.scm.auth.ldap.UserSearcher - no user with username jenkins found
2022-04-01 10:41:09.200 [qtp1793329556-22863096] [ ] WARN sonia.scm.auth.ldap.UserSearcher - no user with username jenkins found
2022-04-01 10:41:09.211 [qtp1793329556-22795497] [ ] WARN sonia.scm.auth.ldap.UserSearcher - no user with username jenkins found
2022-04-01 10:41:09.223 [qtp1793329556-22863096] [ ] WARN sonia.scm.auth.ldap.UserSearcher - no user with username jenkins found
2022-04-01 10:41:09.235 [qtp1793329556-22795497] [ ] WARN sonia.scm.auth.ldap.UserSearcher - no user with username jenkins found
2022-04-01 10:41:09.246 [qtp1793329556-22863096] [ ] WARN sonia.scm.auth.ldap.UserSearcher - no user with username jenkins found
2022-04-01 10:41:09.257 [qtp1793329556-22795497] [ ] WARN sonia.scm.auth.ldap.UserSearcher - no user with username jenkins found
2022-04-01 10:41:09.277 [qtp1793329556-22863096] [ ] WARN sonia.scm.auth.ldap.UserSearcher - no user with username jenkins found
2022-04-01 10:41:09.288 [qtp1793329556-22795497] [ ] WARN sonia.scm.auth.ldap.UserSearcher - no user with username jenkins found
2022-04-01 10:41:09.300 [qtp1793329556-22863096] [ ] WARN sonia.scm.auth.ldap.UserSearcher - no user with username jenkins found
2022-04-01 10:41:09.312 [qtp1793329556-22795497] [ ] WARN sonia.scm.auth.ldap.UserSearcher - no user with username jenkins found
2022-04-01 10:41:09.323 [qtp1793329556-22863096] [ ] WARN sonia.scm.auth.ldap.UserSearcher - no user with username jenkins found
2022-04-01 10:41:09.334 [qtp1793329556-22795497] [ ] WARN sonia.scm.auth.ldap.UserSearcher - no user with username jenkins found
2022-04-01 10:41:09.346 [qtp1793329556-22863096] [ ] WARN sonia.scm.auth.ldap.UserSearcher - no user with username jenkins found
2022-04-01 10:41:09.357 [qtp1793329556-22795497] [ ] WARN sonia.scm.auth.ldap.UserSearcher - no user with username jenkins found
2022-04-01 10:41:09.368 [qtp1793329556-22863096] [ ] WARN sonia.scm.auth.ldap.UserSearcher - no user with username jenkins found
2022-04-01 10:41:09.380 [qtp1793329556-22795497] [ ] WARN sonia.scm.auth.ldap.UserSearcher - no user with username jenkins found
2022-04-01 10:41:09.390 [qtp1793329556-22863096] [ ] WARN sonia.scm.auth.ldap.UserSearcher - no user with username jenkins found
2022-04-01 10:41:09.409 [qtp1793329556-22795497] [ ] WARN sonia.scm.auth.ldap.UserSearcher - no user with username jenkins found
2022-04-01 10:41:09.421 [qtp1793329556-22863096] [ ] WARN sonia.scm.auth.ldap.UserSearcher - no user with username jenkins found
2022-04-01 10:41:09.432 [qtp1793329556-22795497] [ ] WARN sonia.scm.auth.ldap.UserSearcher - no user with username jenkins found
2022-04-01 10:41:09.444 [qtp1793329556-22863096] [ ] WARN sonia.scm.auth.ldap.UserSearcher - no user with username jenkins found
2022-04-01 10:41:09.455 [qtp1793329556-22795497] [ ] WARN sonia.scm.auth.ldap.UserSearcher - no user with username jenkins found
2022-04-01 10:41:09.466 [qtp1793329556-22863096] [ ] WARN sonia.scm.auth.ldap.UserSearcher - no user with username jenkins found
2022-04-01 10:41:09.478 [qtp1793329556-22795497] [ ] WARN sonia.scm.auth.ldap.UserSearcher - no user with username jenkins found

Hi Marlene,

thank you for your feedback. We will have a look at this in parallel to your reported issue about Atlassian Crucible. We will get back to you soon.

I am also facing this issue in my production environment. I have switched over to API-KEY based access to avoid getting my service account locked out.

This indicates that the expected isolation between the LDAP provider and the internal accounts is not happening. This is a serious security flaw and expensive on the server performance. Logs are getting filled up reaching the 10MB within the 2-5minutes.

Can we have this prioritized for the upcoming fixes?

I am still having this issue too. My security team is constantly telling me that this appears to be a hacking attempt. My service account is being recorded as accessing domain records hundreds of times a day.

Unfortunately this is haunting my server performance resulting in the chain of actions like, delay in check-out, malfarmed xml, repeated 500 failures, etc. The server is busy attempting LDAP, comparing the HASH, generating the logs extra over heads on the performance.

We need to get some workaround for now before we think of a permanent solution. I am in a dilemma now.

Thank you for bringing this issue to our attention. We are working on a solution and will come back to you soon.

1 Like

The latest LDAP plugin 2.5 has slowed it down.
I see the logs are coming back after a while.

2022-06-13 22:29:33.159 [qtp1642534850-93] [          ] DEBUG sonia.scm.security.DAORealmHelper - try to authenticate svcbuildm
2022-06-13 22:29:33.159 [qtp1642534850-93] [          ] DEBUG org.apache.shiro.realm.AuthenticatingRealm - Looked up AuthenticationInfo [svcbuildm,User{name=svcbuildm, displayName=SVC Build Manager, mail=svcbuildm@swinfra.net, password=(is set), type=xml, active=true, external=false, creationDate=1637610741705, lastModified=null, properties={}},["repository:read,pull,push,readStatistics,createPullRequest,readPullRequest,commentPullRequest,mergePullRequest,readCIStatus:*"],svcbuildm] from doGetAuthenticationInfo
2022-06-13 22:29:33.159 [qtp1642534850-93] [          ] DEBUG org.apache.shiro.realm.AuthenticatingRealm - AuthenticationInfo caching is disabled for info [svcbuildm,User{name=svcbuildm, displayName=SVC Build Manager, mail=svcbuildm@swinfra.net, password=(is set), type=xml, active=true, external=false, creationDate=1637610741705, lastModified=null, properties={}},["repository:read,pull,push,readStatistics,createPullRequest,readPullRequest,commentPullRequest,mergePullRequest,readCIStatus:*"],svcbuildm].  Submitted token: [org.apache.shiro.authc.UsernamePasswordToken - svcbuildm, rememberMe=false].
2022-06-13 22:29:33.159 [qtp1642534850-93] [          ] DEBUG org.apache.shiro.realm.AuthenticatingRealm - Looked up AuthenticationInfo [null] from doGetAuthenticationInfo
2022-06-13 22:29:33.159 [qtp1642534850-93] [          ] DEBUG org.apache.shiro.realm.AuthenticatingRealm - No AuthenticationInfo found for submitted AuthenticationToken [org.apache.shiro.authc.UsernamePasswordToken - svcbuildm, rememberMe=false].  Returning null.

I am closing this thread because we will keep track here: API KEY Based access slow down the SCM-Manager - #3 by pfeuffer