 G'day viewers, my name is Oren Thomas. I'm a Principal Hybrid Cloud Advocate at Microsoft. In this video, you'll learn about the account log-on category of Advanced Security Auditing for Windows Server. This advice is based on the documentation published on learn.microsoft.com at the link in this video's description. This video is part of a series of videos on advanced auditing and related events that will be published in the coming weeks. Our aim is to provide you with a comprehensive understanding of advanced security auditing in Windows Server and Active Directory environments. Configuring advanced security auditing policy settings in the account log-on category can help you document attempts to authenticate account data on a domain controller or on a local security accounts manager. Unlike log-on and log-off policy settings and events, account log-on settings and events focus on the account database that is used. This category includes the following policies, audit credential validation, audit Kerberos authentication service, audit Kerberos service ticket operations, audit other account log-on events. Now, we will examine each policy, what configuring it allows you to monitor and the events it generates. Audit credential validation policy determines whether the operating system generates audit events on credentials that are submitted for a user account log-on request. These events occur on the computer that is authoritative for the credentials as follows. For domain accounts, the domain controller is authoritative. For local accounts, the local computer is authoritative. The event volume is high on domain controllers and low on member servers and workstations. Because domain accounts are used much more frequently than local accounts in enterprise environments, most of the account log-on events in a domain environment occur on the domain controllers that are authoritative for the domain accounts. However, these events can occur on any computer and they may occur in conjunction with or on separate computers from log-on and log-off events. The main reason to enable this auditing subcategory is to handle local accounts authentication attempts and for domain accounts in TLM authentication in the domain. It is especially useful for monitoring unsuccessful attempts to find brute force attacks, counter-nimeration and potential account compromise events on domain controllers. The expected volume of events is high for domain controllers because this subcategory will generate events when an authentication attempt is made using any domain account and TLM authentication. Microsoft recommends success auditing to keep track of domain account authentication events using the NTLM protocol. Just collecting success auditing events in this subcategory, the future use in case of a security incident is not very useful because events in this subcategory are not always informative. Microsoft recommends configuring failure auditing to collect information about failed authentication attempts using domain accounts and the NTLM authentication protocol. Event IDs generated in the security log when you enable this auditing category are 4774, an account was mapped for log-on. 4775, an account could not be mapped for log-on. 4776, the computer attempted to validate the credentials for an account. 4777, the domain controller failed to validate the credentials for an account. Audit Kerberos authentication service policy determines whether to generate audit events for Kerberos authentication ticket granting ticket TGT requests. If you configure this policy setting an audit event is generated after a Kerberos authentication TGT request. Success audits record successful attempts and failure audits record unsuccessful attempts. Event volume is high on Kerberos key distribution center servers and domain controllers. This subcategory contains events about issued TGTs and failed TGT requests. It also contains events about failed pre-authentications due to wrong user password or when the user's password has expired. Microsoft recommends success auditing because you will see all Kerberos authentication requests TGT requests which are a part of domain account log-ons. Also you can see the IP address from which this account requested a TGT when TGT was requested which encryption type was used and so on. Microsoft also recommends failure auditing because you will see all failed requests with wrong password, username, revoc certificate and so on. You will also be able to detect Kerberos issues or possible attack attempts. Event ideas generated in the security log when you enable this auditing category are 4768, a Kerberos authentication ticket TGT was requested 4771, Kerberos pre-authentication failed. 4772, a Kerberos authentication ticket request failed. Audit Kerberos service ticket operations policy determines whether the operating system generates security audit events for Kerberos service ticket requests. Events are generated every time Kerberos is used to authenticate a user who wants to access a protected network resource. Kerberos service ticket operation audit events can be used to track user activity. This subcategory contains events about issued Kerberos service ticket requests, TGSs and failed TGS requests. Expected volume is very high on domain controllers. Microsoft recommends success auditing because you will see all Kerberos service ticket requests which are part of service use and access requests by specific accounts. Also, you can see the IP address from which this account requested TGS. When TGS was requested, which encryption type was used and so on. Microsoft recommends failure auditing because you will see all failed requests and be able to investigate the reason for failure. You will also be able to detect Kerberos issues or possible attack attempts. Event ideas generated in the security log when you enable this auditing category are Audit 769, a Kerberos service ticket was requested. Audit 770, a Kerberos service ticket was renewed. Audit 773, a Kerberos service ticket request failed. The audit other account logon events subcategory does not generate any events. It may be used in future but was designed when auditing was done locally rather than with Azure integration. With active directory being supported but not extended it is unlikely that this subcategory will be used for anything interesting. A success audit event is triggered when a defined action such as accessing a file share is completed successfully. A failure audit event is triggered when a defined action such as a user sign in isn't completed successfully. The appearance of failure audit events in the event log doesn't necessarily mean that something is wrong with your system. For example, if you configure audit logon events, a failure event may mean that a user mistyped the password. This video provided an introduction to Windows Server advanced security auditing account logon policies. Future videos will cover policies in each advanced audit policy category and notable events that enabling the policies generate. The advice in this video is based on the documentation published on learn.microsoft.com at the link in this video's description. Increasing the security controls applied to active directory will improve your overall ADDS security posture that will not make your systems invulnerable. Security is always a matter of balancing what can be pragmatically accomplished by administrators in day-to-day operations with an assumed breach philosophy. We are interested in hearing about your experiences as an ADDS administrator. Is there any ADDS security or Windows Server related topics you'd like us to cover in a future video? If so, mention it below. I hope you found this video useful and informative. My name is Oren Thomas. You can find me at aka.ms slash oren. And if you've got any questions or feedback, drop a comment below.