Locating source of repeated failed login attempts

[ptong]

Hey all, I have a current issue where there are constant failed login events from a domain account originating within the Windows Server hosting my vCenter server.

This server is a small vm that is ONLY for running vCenter and its peripherals, so there aren't other systems banging away at it other than those it installed itself (running with @vsphere.local creds etc).

Event list looks like this:

• Cannot login user DOMAIN\USER@127.0.0.1: no permission
• Cannot login user DOMAIN\USER@<vcenter host ip>: no permission

These two errors always appear as pairs, occurring every 30 seconds

The particular user is someone who works on these systems with me, but hasn't been part of any setup steps where they could conceivably store permissions in a scheduled task. I do NOT want to "fix" the error by giving his account permissions, I want to figure out WHY this account is constantly trying to login.

I've run through the logs, but there really isn't much I can get from them:

2018-04-03T06:55:40.267-04:00 info vpxd[38256] [Originator@6876 sub=AuthorizeManager opID=9fb0d07b-a21c-48c1-83c0-4e1af46e008e-864336-ngc-66] [Auth]: User <DOMAIN\USER>

2018-04-03T06:55:40.268-04:00 info vpxd[38256] [Originator@6876 sub=vpxLro opID=9fb0d07b-a21c-48c1-83c0-4e1af46e008e-864336-ngc-66] [VpxLRO] -- FINISH lro-1295975

2018-04-03T06:55:40.268-04:00 info vpxd[38256] [Originator@6876 sub=Default opID=9fb0d07b-a21c-48c1-83c0-4e1af46e008e-864336-ngc-66] [VpxLRO] -- ERROR lro-1295975 -- SessionManager -- vim.SessionManager.loginByToken: vim.fault.NoPermission:

--> Result:

--> (vim.fault.NoPermission) {

-->    faultCause = (vmodl.MethodFault) null,

-->    faultMessage = <unset>,

-->    object = 'vim.Folder:5CBADB22-BEDC-43A7-BD5D-60D5E80A30D3:group-d1',

-->    privilegeId = "System.View"

-->    msg = ""

--> }

--> Args:

-->

--> Arg locale:

--> "en"

Does anyone have any thoughts about how to track down the system/application which is the source of these login attempts?

As always, thanks for the assistance!

[daphnissov]

If the events show that the origin is from 127.0.0.1, then you might have a scheduled task or service using this credential that is attempting to login to vCenter from the vCenter server VM. Normally, failed logins will show the IP source and that's how you can track it down.

[ptong]

Hey daphnissov,

I've run through all the services looking for "long on as" type entries and also scrapped the task scheduler for any non-system tasks (found 2, 1 VMware based task running different creds and an audio driver), no luck there.

I noticed that the datastore that is listed in the error is not available on the server, from the layout of the name I'm assuming it is one of the handful we deleted about a week ago. Are there any known issues with outdated datastore addresses and login auth errors?

[daphnissov]

I can't see how that would have a bearing. It sounds like an automated script or process that is hard-coded to address some of the vCenter's inventory objects directly and it's not finding them. Still sounds like a local process to me.