locked
Microsoft.TriGateway causing Event 4776 every few seconds on all Domain Controllers RRS feed

  • Question

  • After the 1.9 upgrade we got an Timeline event about Brute Force attacks.

    When investigating and looking at Event Logs >Security I started to panic when noticing 4776 errors against user: "administrator" and the source workstation was always a domain controller.

    This would happen every few seconds.  Stopping the ATA gateway service on the domain controllers stopped this behaviour.

    Any ideas or recommendations?

    Thanks

    The computer attempted to validate the credentials for an account.

    Authentication Package:    MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
    Logon Account:    administrator@xxxx.xxx
    Source Workstation:    DC4
    Error Code:    0xc0000064

    Thursday, April 5, 2018 1:18 PM

All replies

  • Are all the Gateways reported OK in the console UI ?

    Thursday, April 5, 2018 10:06 PM
  • Yes they had all been reporting as working while this was happening.
    Friday, April 6, 2018 9:18 PM
  • Is the reported account in the event is the same account used for ATA directory services?

    (I hope not, as we only need a read only user, not an admin...)

    You mentioned that stopping the GW stopped the issue.

    IS starting the GW brings it back?

    Saturday, April 7, 2018 7:36 PM
  • Sorry for being slow to respond I was away Friday.  Where is the ATA directory services user configured?  i will take a look right now.

    Yes it does come back right away.  For the Gateway Service on the DCs what should the LogOn user be?  Mine is set to "This account: Local Service"

    Monday, April 9, 2018 12:16 PM
  • I am not referring to the LogOn user of the service, I am referring to the AD user we use to authenticate outside the GW machine, it is defined in the Center UI configuration as described here:

    https://docs.microsoft.com/en-us/advanced-threat-analytics/install-ata-step2#step-2-provide-a-username-and-password-to-connect-to-your-active-directory-forest

    Monday, April 9, 2018 12:20 PM
  • So I found the directory service configuration and updated it.  Now the authentication errors come in as:  ATAuser@domain.local

    Is this normal?  If not how can I correct this?

    Monday, April 9, 2018 12:49 PM
  • So  administrator@xxxx.xxx was configured there before?

    What happens if you press the "Test connection" button AFTER you save the credentials?

    Does it work or report an error?

    Any chance you have a policy that forces NTLM authentication over Kerberos? 

    Monday, April 9, 2018 12:53 PM
  • Yes administrator@xxxx.xxx was configured there before.

    Test Connection says it is successful.

    I wouldn't know where to start looking for that policy.  Can you show me where its configured and I will look?

    I don't why that would be configured, it would be something I would likely be the one to configure.

    Thanks again for all your help.

    Monday, April 9, 2018 2:55 PM
  • It's really strange.

    Usually Error Code:    0xc0000064

    means the password was incorrect, but if the test connection worked, it means the password was OK 

    (giving that you saved it before checking)

    Does it happen from all Gateways or only some?

    What was the target machine?

    Can you export the brute force SA to excel, and share it with me?

    You can email me at 

    atashare at microsoft com,

    please mention a link to this post in the email.

    Eli

    Monday, April 9, 2018 7:07 PM
  • The Brute Force event in the timeline doesn't actually reference any of these events.  It only prompted me to investigate which is where I saw these event in EVENT VIEWER > SECURITY

    The Brute Force one does keep growing though:

    Excessive number of authentication failures (4,370 within 7 days) from DC5 for 1,742 accounts

    I am not sure if these are bad RADIUS authentications? We have a large Guest Network.

    Where would I turn to get official MS support on this product?

    Tuesday, April 10, 2018 1:20 PM
  • Do you have a premier support contract in place?
    Tuesday, April 10, 2018 9:09 PM
  • BTW, while I might be able to help diagnose the reason for the 4776 events from the GW, but your first priority should be the Brute force SA, so you can explain the failed authentications and fix them.

    This will also reduce noise on the machine, then ping me again so we can focus on the events.

    Tuesday, April 10, 2018 9:12 PM
  • I believe we do have Premier.  Just finding out from supervisor how to access it.

    What is SA? Suspicious authentication?  What triggers the Brute Force how many failures?

    Thanks again


    • Edited by BMFII Wednesday, April 11, 2018 6:39 PM
    Wednesday, April 11, 2018 6:37 PM
  • SA = Suspicious Activity
    Wednesday, April 11, 2018 8:12 PM