none
Kerberos authentication logging

    Question

  • Hello,

    I am an analyst with a university, and am relatively new to the field, so I apologize in advance for any incompetency.

    When I started this job a few months ago, the school had just put in a SEIM, with little knowledge on the software. This led to a lot of inaccuracies in event logging and its AI engine. One alarm set of alarms, Internal Brute Force Auth/Failed Brute Force Auth/Internal Distributed Auth, fires almost daily, usually multiple times a day. These fire when the SEIM detects more then 10 authentication failures from a user account within 15 minutes followed by a successful authentication (with the exception of the Failed Brute Force Auth). 

    I've determined that this can sometimes be the result of a  user changing their password, and a service on their machine not being able to authenticate correctly with a server (this can usually be determined by the reason code provided by kerberos). However, more often then not, they'll fire when a user simply types in a bad username once. For instance, recently an admin tried to log into a local admin account on a machine, and made the first time he attempted to log in. He only made this mistake once, however there were a total of 19 logs within 2 minutes, all authentication failures from that admin account against one of our domain controllers. 

    This didn't lead to his account being locked, and its not necessarily having any big impact on our operations, but I'd like to be able to mitigate the amount of alarms we receive on a daily basis. My question is what could be causing so many logs to be generated from only one misentry? Does the computer itself make more then one request when trying to receive the TGT from kerberos, leading to multiple logs? 

    Thank you in advance, please let me know if you need any clarification.

    Wednesday, January 4, 2017 4:22 PM

Answers

  • Hi,
    Generally speaking of the Kerberos authentication: The client authenticates itself to the Authentication Server (AS) which forwards the username to a key distribution center (KDC). The KDC issues a ticket-granting ticket (TGT), which is time stamped, encrypts it using the user's password and returns the encrypted result to the user's workstation. This is done infrequently, typically at user logon; the TGT expires at some point, though may be transparently renewed by the user's session manager while they are logged in. When the client needs to communicate with another node ("principal" in Kerberos parlance) the client sends the TGT to the ticket-granting service (TGS), which usually shares the same host as the KDC. After verifying the TGT is valid and the user is permitted to access the requested service, the TGS issues a ticket and session keys, which are returned to the client. The client then sends the ticket to the service server (SS) along with its service request. Please see details from:
    https://technet.microsoft.com/en-sg/library/cc780469(v=ws.10).aspx
    The TGT generation process may fail because of a range of reasons, some of which might be legitimate, some of them may result as a wrong configuration of some service, or they can also sometimes indicate an intrusion attempt. Sometimes they may appear even without any wrong consequences, such as when an application attempts first with some unsupported parameters and if that fails (producing this event by the way), it tries something more compatible - such cases might include scenarios with Kerberos delegation or AES cryptography which is only supported since 2008 DCs and sometimes also requires rather complex conditions or configurations as well.
    In your scenario, please check if you are able to find the events in the event viewer on the originating DC computer or just in the SIEM tool. And you could have a try adjusting SIEM to see if it could help to reduce the logs.
    Best regards,
    Wendy

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    • Proposed as answer by Todd Heron Thursday, January 5, 2017 12:34 PM
    • Marked as answer by RedGaijin Thursday, January 5, 2017 4:32 PM
    Thursday, January 5, 2017 6:55 AM
    Moderator

All replies

  • Hi,
    Generally speaking of the Kerberos authentication: The client authenticates itself to the Authentication Server (AS) which forwards the username to a key distribution center (KDC). The KDC issues a ticket-granting ticket (TGT), which is time stamped, encrypts it using the user's password and returns the encrypted result to the user's workstation. This is done infrequently, typically at user logon; the TGT expires at some point, though may be transparently renewed by the user's session manager while they are logged in. When the client needs to communicate with another node ("principal" in Kerberos parlance) the client sends the TGT to the ticket-granting service (TGS), which usually shares the same host as the KDC. After verifying the TGT is valid and the user is permitted to access the requested service, the TGS issues a ticket and session keys, which are returned to the client. The client then sends the ticket to the service server (SS) along with its service request. Please see details from:
    https://technet.microsoft.com/en-sg/library/cc780469(v=ws.10).aspx
    The TGT generation process may fail because of a range of reasons, some of which might be legitimate, some of them may result as a wrong configuration of some service, or they can also sometimes indicate an intrusion attempt. Sometimes they may appear even without any wrong consequences, such as when an application attempts first with some unsupported parameters and if that fails (producing this event by the way), it tries something more compatible - such cases might include scenarios with Kerberos delegation or AES cryptography which is only supported since 2008 DCs and sometimes also requires rather complex conditions or configurations as well.
    In your scenario, please check if you are able to find the events in the event viewer on the originating DC computer or just in the SIEM tool. And you could have a try adjusting SIEM to see if it could help to reduce the logs.
    Best regards,
    Wendy

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    • Proposed as answer by Todd Heron Thursday, January 5, 2017 12:34 PM
    • Marked as answer by RedGaijin Thursday, January 5, 2017 4:32 PM
    Thursday, January 5, 2017 6:55 AM
    Moderator
  • Thank you for the answer Wendy, this seems to address my issue, and I'll let you know if I have any additional questions.
    • Edited by RedGaijin Thursday, January 5, 2017 4:33 PM
    Thursday, January 5, 2017 4:33 PM
  • Hi,
    Ok, if you have any questions, please feel free to post in TechNet forum.
    Best regards,
    Wendy

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Friday, January 6, 2017 3:23 AM
    Moderator