QEM Audit Failed Login

[MichaelMockus]

We have a rogue process or broken app calling the QEM endpoint and providing bad credentials. A valid AD username but invalid password. 
The request is accurately getting rejected, but this is rapidly becoming a Denial-of-Service situation, as the AD username is used by a valid request, and the unsuccessful login attempt locks the AD account.

For this reason but also we should be auditing this for security purposes. What loggers need to be turned on and to what level in QEM to get the basic information 

Login Failed

Username

Calling IP

We have tried various guesses a the QEM logger and level, but to no avail. 

This also would be basic information required for audit compliance for areas like SOX.

[MichaelMockus]

Thanks @Steve_Nguyen that actually is not what you get from a failed login. If you look at your logs you get those with successful logins, not failed.

The fact we have successful login is good but we need the failed.

[Steve_Nguyen]

QEM does not log fail, the failure is log with Windows Events / security

example i login to QEM with dduck

- System

- Provider

[ Name] Microsoft-Windows-Security-Auditing
[ Guid] {54849625-5478-4994-A5BA-3E3B0328C30D}

EventID 4625

Version 0

Level 0

Task 12544

Opcode 0

Keywords 0x8010000000000000

- TimeCreated

[ SystemTime] 2022-03-04T17:16:46.114877000Z

EventRecordID 637736

Correlation

- Execution

[ ProcessID] 512
[ ThreadID] 3316

Channel Security

Computer qemservername.supportqa.local

Security

- EventData

SubjectUserSid S-1-0-0
SubjectUserName -
SubjectDomainName -
SubjectLogonId 0x0
TargetUserSid S-1-0-0
TargetUserName dduck
TargetDomainName
Status 0xc000006d
FailureReason %%2313
SubStatus 0xc0000064
LogonType 3
LogonProcessName NtLmSsp
AuthenticationPackageName NTLM
WorkstationName USREM-WORKSTATION_NAME
TransmittedServices -
LmPackageName -
KeyLength 0
ProcessId 0x0
ProcessName -
IpAddress -
IpPort -

[MichaelMockus]

That gets us much closer, thought it does appear the way that the QEM process is interacting with the windows auth porcess, the IPAddress and IPPort are being stripped.

I see this in yours above as well as on my system.

[MichaelMockus]

This knowledge article seems to indicate it is possibly missing IP due to IIS having their log settings set to basic.

https://serverfault.com/questions/399878/security-log-in-event-viewer-does-not-store-ips

[Steve_Nguyen]

@MichaelMockus 

if you know the workstation name of the audit fail, then you can back trace:

example , ping or nslookup to get ip, 

[MichaelMockus]

I was trying to get at the IP because it is also not logging the machine name, just either "workstation" or the local server

Was hoping increasing IIS verbosity, would yield on IP.

[Steve_Nguyen]

the section : WorkstationName USREM-WORKSTATION_NAME  ,, is the workstation that is coming from.

check with your system admin or network team.

[MichaelMockus]

@Steve_Nguyen that isn't the name. the name is being stripped on the IIS service the best we can tell. 
So I think we need to expand the logging in IIS to see if we can get the IP. 

[Steve_Nguyen]

@MichaelMockus  on my QEM server , the windows event show the workstation name.

therefore, it could be your windows security or policy that is stripping the name.