Hi, Is there any way to track failed Kerberos authentication attempts? I am looking for situations in which NTLM is used once Kerberos failes. ideally, I like to get a list of failed Kerberos authentications on AD machine as well as the machine that hosts the service Thank you,

Hi, Microsoft Windows 2000, Windows Server 2003, and Windows Server 2008 offer the capability of tracing detailed Kerberos events through the event log mechanism. For more information, please refer to: How to enable Kerberos event logging http://support.microsoft.com/kb/262177/en-us Kerberos Authentication Tools and Settings http://technet.microsoft.com/en-us/library/cc738673(v=ws.10).aspx Hope this helps. Regards, Bruce

Hi, Microsoft Windows 2000, Windows Server 2003, and Windows Server 2008 offer the capability of tracing detailed Kerberos events through the event log mechanism. For more information, please refer to: How to enable Kerberos event logging http://support.microsoft.com/kb/262177/en-us Kerberos Authentication Tools and Settings http://technet.microsoft.com/en-us/library/cc738673(v=ws.10).aspx Hope this helps. Regards, Bruce

first, make things more defined. Generally, NTLM is used in several cases: - either when a client tries to access a server and specifies its IP adress instead of a name. Such as \\ip.ip.ip.ip instead of \\computer.domain.local. This is a built-in behavior starting with Windows Vista/2008 and means that Kerberos is not tried at all. The machine detects the attempt references the IP address instead of a name and goes directly for NTLM. The only exception to this behavior is DCOM (such as WMI) which can determine the remote computer's name after establishing the communication (anonymous or NTLM) and can then restart the authentication using Kerberos. - the other case is when a client asks for a Kerberos TGS ticket and specifies a name (preciselly to say SPN) that cannot be found in the Active Directory. In this case, the KDC (Kerberos DC) returns PRINCIPAL_UNKNOWN error and the client may proceed with NTLM authentication. Duplici SPNs are another example when the client may proceed with NTLM after not-receiving Kerberos ticket. - some services (such as IIS) can limit the authentication methods explicitly to NTLM. They can disable Kerberos and require NTLM only. Such an example is default SharePoint web application configuration. The server simply does not offer Kerberos as an available authentication method so the clients go for NTLM directly without ever trying Kerberos at all. - Kerberos requires DNS to work correctly. The clients query DNS for _kerberos SRV records and without these, the Kerberos client does not ask for ticket at all and proceeds with NTLM automatically. This means that clients located on public networks, behind firewalls or with incorrect DNS configuration do not use Kerberos without trying. - in other situations, Kerberos errors just prevent further processing. These are such examples as time skew or incorrect SPN binding to alien accounts or excesive numbers of groups/sids. Under these conditions, the clients receive Kerberos tickets with invalid parameters and try to use them against the remote service to authenticate themselves. But the remote service may reject such a ticket. If the ticket is present, but rejected, clients usually do not proceed with NTLM further. Taking these facts into account, I would not pursue your original aproach with monitoring failed Kerberos attempts. Sometimes, there may be NTLM due to an incorrect Kerberos configuration while there may be no Kerberos error at all. If you want to see all NTLM authentication, regardless of why it has been used, audit successful Account Logon events on all DCs and extract events ID 4776 (on 2008+) or in case of Windows 2003, Logon Event 528 which mentions MICROSOFT_AUTHENTICATION_PACKAGE_V1_0.

first, make things more defined. Generally, NTLM is used in several cases: - either when a client tries to access a server and specifies its IP adress instead of a name. Such as \\ip.ip.ip.ip instead of \\computer.domain.local. This is a built-in behavior starting with Windows Vista/2008 and means that Kerberos is not tried at all. The machine detects the attempt references the IP address instead of a name and goes directly for NTLM. The only exception to this behavior is DCOM (such as WMI) which can determine the remote computer's name after establishing the communication (anonymous or NTLM) and can then restart the authentication using Kerberos. - the other case is when a client asks for a Kerberos TGS ticket and specifies a name (preciselly to say SPN) that cannot be found in the Active Directory. In this case, the KDC (Kerberos DC) returns PRINCIPAL_UNKNOWN error and the client may proceed with NTLM authentication. Duplici SPNs are another example when the client may proceed with NTLM after not-receiving Kerberos ticket. - some services (such as IIS) can limit the authentication methods explicitly to NTLM. They can disable Kerberos and require NTLM only. Such an example is default SharePoint web application configuration. The server simply does not offer Kerberos as an available authentication method so the clients go for NTLM directly without ever trying Kerberos at all. - Kerberos requires DNS to work correctly. The clients query DNS for _kerberos SRV records and without these, the Kerberos client does not ask for ticket at all and proceeds with NTLM automatically. This means that clients located on public networks, behind firewalls or with incorrect DNS configuration do not use Kerberos without trying. - in other situations, Kerberos errors just prevent further processing. These are such examples as time skew or incorrect SPN binding to alien accounts or excesive numbers of groups/sids. Under these conditions, the clients receive Kerberos tickets with invalid parameters and try to use them against the remote service to authenticate themselves. But the remote service may reject such a ticket. If the ticket is present, but rejected, clients usually do not proceed with NTLM further. Taking these facts into account, I would not pursue your original aproach with monitoring failed Kerberos attempts. Sometimes, there may be NTLM due to an incorrect Kerberos configuration while there may be no Kerberos error at all. If you want to see all NTLM authentication, regardless of why it has been used, audit successful Account Logon events on all DCs and extract events ID 4776 (on 2008+) or in case of Windows 2003, Logon Event 528 which mentions MICROSOFT_AUTHENTICATION_PACKAGE_V1_0.