Hello,
In the BF server audit logs, we’re seeing bunch of bfadmin login failures, but it doesn’t show the source. Is there a way to find out which source system or BF component is causing these failures?
1|Tue, 13 Jul 2021 11:23:39 -0500|INFO|bfadmin|RESTAPI|AUTHZ|LOGIN|“ip of the ROOT server”|user “bfadmin”: Failed log in. (API Connection)
1|Tue, 13 Jul 2021 11:23:42 -0500|INFO|bfadmin|RESTAPI|AUTHZ|LOGIN|“ip of the ROOT server”|bfadmin: Too many log in attempts. (API Connection)
From the looks at the logs, it seems the bfadmin account is trying to do a restapi call from the BF root server and failing. We did recently rotated the password for bfadmin and now we’re trying to track down where this restapi call is configured on the BF root server and where it’s making the call to? probably to itself?
Some areas to check:
Server Automation Engine
CloudPlugins
Insights ETL
BFI ETL
WebUI settings
Also check Fixlets & Tasks, search for REST or SOAP credentials; these can configure the credentials for Server Automation or the Server Plugin Service.
I prefer for each integration to use a separate credential, precisely to identify which plugin is making these calls.
I pushed out the REST API credential for BES Server Plugin Service fixlet with the new password but that didn’t fix it. Is there a way to check if the SOAP credential is configured before trying to push that SOAP fixlet?
Yes; I forget the Registry key that it’s in, but if you read the actionscript of the Fixlet it should be pretty clear. If there is a value stored in that key then an earlier SOAP password was applied.
so I checked the registry and it’s blank for both SOAP username/password. However, I did notice when I try to login to the BF Web Report url using the master operator “bfadmin”, I’m getting an invalid username or password which is strange b/c I know i’m using the correct creds. Could that be causing the failed login for the RESTAPI? Any idea how to fix it?
Are you certain the Web Reports user is “bfadmin”? Web Reports has its own users, which are stored in the Web Reports database, especially the first user created for Web Reports on login.
The only things we have configured is the BFI and WebUI. In the BFI besides the Data Source which I have already updated, is there anywhere else I need to check? And I’m not sure where to check after logging in the WebUI.
I’m not sure, because the previous engineer who set this up is no longer works for the company.
Did you ever get this resolved? We are having the same issue. We have updated the RESTAPI and SOAP user/passwords but the login failures continue. We also created new users to test. The new and old users can both login successfully to WebReports and RESTAPI via a browser. However, the errors continue in the log. We also have a ticket open for the issue.
The log should tell you the IP address of the computer from which the connections are originating. You may have a BigFix application or a REST API script that is using an old version of the password to attempt authenticating.
‘tcpview’ from the Sysinternals utilities, or ‘netstat’ or ‘Performance Monitor’ should be able to help you determine the source. Look for processes that are opening connections to the root server, aside from besclient.exe.
The IP address is the server itself. When we stop the Server Plugin Service, the errors stop. We have updated the passwords in the registry using the proper fixlets associated with this service and even created new users.
Support has provided several steps but we have already taken them. We are waiting for more feedback.
Have you checked the “BES Server\Applications\Logs\MFS.Log” for error messages? That’s where the Server Plugin Service would log by default. I’d want to verify that it’s the Server Plugin Service itself with the bad credential, which should be reflected in that log.
There could be additional logs in the same directory (for instance, Plan Engine console messages if you are using Server Automation) that might help indicate whether it’s some plugin that the Server Plugin Service is launching separately that is not working correctly.
Yes, we have checked that log as well but this one doesn’t provide much detail. We only see a task ‘BESWoLMedic’ run by command… which is also the server itself.
[Wed, 17 Apr 2024 11:11:10 -0400] Task ‘BESWoLMedic’ run by command: “Z:\Program Files (x86)\BigFix Enterprise\BES Server\Applications\BESWoLMedic\BESWoLMedic.exe” -besserver http://beshostname:52311 -e “BigFix Server”
This log “BES Server\Applications\BESWoLMedic\BESWoLMedic.log” shows similar details to the server_audit.log.
[Wed Apr 17 11:11:15 2024] [ERROR] REST API returns error: HTTP 401: Unauthorized
[Wed Apr 17 11:11:15 2024] [ERROR] Problem accessing REST API (attempt 1 of 5)
[Wed Apr 17 11:11:21 2024] [ERROR] REST API returns error: HTTP 401: Unauthorized
[Wed Apr 17 11:11:21 2024] [ERROR] Problem accessing REST API (attempt 2 of 5)
[Wed Apr 17 11:11:27 2024] [ERROR] REST API returns error: HTTP 401: Unauthorized
[Wed Apr 17 11:11:27 2024] [ERROR] Problem accessing REST API (attempt 3 of 5)
[Wed Apr 17 11:11:36 2024] [ERROR] REST API returns error: HTTP 401: Unauthorized
[Wed Apr 17 11:11:36 2024] [ERROR] Problem accessing REST API (attempt 4 of 5)
[Wed Apr 17 11:11:42 2024] [ERROR] REST API returns error: HTTP 401: Unauthorized
[Wed Apr 17 11:11:42 2024] [ERROR] Problem accessing REST API (attempt 5 of 5)
[Wed Apr 17 11:11:44 2024] [ERROR] Could not access REST API.
[Wed Apr 17 11:11:44 2024] [ERROR] Terminating Excecution
Just reading through the actionscripts that configure REST and SOAP parameters, as well as the ones that setup the commands for BESWOLMedic, I think there’s possibly some cases where special characters might need to be escaped in certain ways. I don’t have the bandwith right now to test all the permutations, but I’d try again configuring passwords and make sure there are no singlequote, doublequote, percent, parentheses, or curlybracket characters.
In fact you might start off with as simple a password as is allowed in your deployment, and only add complexity after you verify it’s working correctly.
This requires both updating an actual service account password in the Console, and then actioning the “Configure REST API Credentials for BES Server Plugin Service” and “Configure SOAP API credentails for the BES Server Plugin Service” Tasks.
Thanks for the feedback, Jason. I will try again with a simple password as the current ones have at least 1 special character but none of the ones you mentioned. However, the original account did not have any special characters as it was only a combination of upper/lower alphanumeric.