NTLM Audit in Active Directory: From Audit to Enforcement

Topic

The guide follows the most important Microsoft principle for this topic: observe the real NTLM usage first, fix the dependencies second, and only then apply progressive restrictions. A block performed without an audit phase is not hardening: it is a compatibility test done directly in production, which we call a "scream test" in a friendly way.

Context: NTLM is not the migration plan

In an Active Directory domain, Kerberos is the preferred authentication protocol. NTLM remains available for compatibility, but it often hides issues related to naming, SPN, delegation, legacy applications, or undocumented configuration.

The point is not only to ask "how do I block NTLM?". The operational questions are:

• which accounts, clients, servers, and applications are still using NTLM?
• which side of the connection is negotiating NTLM?
• is the fallback caused by a fixable Kerberos error?
• is the dependency truly legacy, or is it simply an IP- or alias-based access path?
• who owns the service, and what test proves the change is safe?

Microsoft documents the NTLM restriction settings in the security policy and recommends using audit to identify dependencies before blocking the protocol. 1 2 3

The correct model: four phases, not a single flag

Phase 1: baseline and audit

Collect a snapshot of the domain and define the observation window. A window that is too short can miss nightly jobs, backup processes, monthly batches, administrative access, and disaster recovery flows.

The baseline must include at least:

• Domain Controllers and OS version;
• relevant Windows clients and servers;
• trusts and domains involved;
• published applications and multi-tier services;
• service accounts and their owners;
• appliances, NAS devices, printers, and Linux domain-joined systems;
• GPOs that modify NTLM, LAN Manager, or authentication protocols;
• operational windows and systems that cannot be restarted without a change.

Phase 2: event triage

Do not treat every NTLM event as an equal cause. Each record should be enriched with at least:

• timestamp and Domain Controller that recorded the event;
• client and server involved;
• account used;
• service or protocol involved;
• application or process, when available;
• originating workstation, server, or appliance;
• frequency and time distribution;
• technical and application owners;
• proposed action and verification criterion.

An aggregate count such as "there are 10,000 events" is not enough. The useful data is a dependency map that allows us to answer a concrete question: which service will stop working if this NTLM path is blocked?

Phase 3: root-cause remediation

Before classifying a dependency as legacy, verify whether it is a fixable Kerberos fallback. Common causes include:

• access through an IP address;
• short name used instead of the name consistent with the service;
• DNS aliases or CNAMEs without matching SPNs;
• missing or duplicate SPNs;
• service running under an account different from the one that owns the SPN;
• Kerberos delegation required but not designed;
• stale keytab or Kerberos configuration on non-Windows systems;
• application that supports only NTLM;
• appliance or protocol that does not support Kerberos.

Microsoft notes that Windows clients normally do not attempt Kerberos when the destination is an IP address and may therefore fall back to other enabled protocols. The preferred fix is to use a stable DNS name consistent with the SPN; IP-based SPN support should only be considered when naming cannot be corrected. 4

For deeper diagnostics on missing or duplicate SPNs and KCD/RBCD cases, see SPN in Active Directory. To understand why the Kerberos-to-NTLM fallback is never truly "harmless" and which Event IDs make it visible, see Fallback Kerberos -> NTLM in Active Directory. For the limits and correct use cases of Protected Users as a testing tool, see Protected Users: production limitations.

Real cases observed in the field

These are concrete examples encountered during assessments and are useful for recognizing similar patterns in your environment:

• Drive mapping via GPO using an IP address: a Group Policy Preference maps a drive as \\192.168.10.7\data instead of \\fileserver.domain.local\data. The client never attempts Kerberos against that destination and falls back to NTLM every time the drive is mounted, for every domain user affected by the policy.
• Line-of-business application with a historical connection string: a legacy application points to a fixed IP because internal DNS was not reliable at the time. No one revisited the connection string after DNS stabilized.
• Backup job using the short NetBIOS name: a scheduled script connects to \\FS01\backup instead of \\fs01.domain.local\backup; it works, but it always goes through NTLM even though the file server is perfectly capable of negotiating Kerberos.
• Load balancer with a VIP not registered as an SPN: clients reach a web service through a virtual IP or a name published by the load balancer, but the SPN is registered only on the real server name behind the balancer.

In all of these cases, the root cause is not "the service is old": it is naming that has never been aligned with the SPNs, often remaining invisible until NTLM events are observed in audit.

NTLM/NTLMv2 compatibility by system type

The table below summarizes the levels documented by Microsoft for the Network security: LAN Manager authentication level setting (LmCompatibilityLevel). It should be read as a reference for understanding which protocols a system can send or accept, not as an automatic instruction for what level to set: the choice depends on the actual clients and services present in the domain.

Registry level	Setting	Client behavior	Domain Controller behavior
0	Send LM & NTLM responses	Sends LM and NTLM, never NTLMv2 session security	Accepts LM, NTLM, and NTLMv2
1	Send LM & NTLM - use NTLMv2 session security if negotiated	Sends LM and NTLM, uses NTLMv2 session security if the server supports it	Accepts LM, NTLM, and NTLMv2
2	Send NTLM response only	Sends only NTLMv1 (with NTLMv2 session security if supported)	Accepts LM, NTLM, and NTLMv2
3	Send NTLMv2 response only	Sends only NTLMv2	Accepts LM, NTLM, and NTLMv2
4	Send NTLMv2 response only. Refuse LM	Sends only NTLMv2	Refuses LM, accepts NTLM and NTLMv2
5	Send NTLMv2 response only. Refuse LM & NTLM	Sends only NTLMv2	Refuses LM and NTLM, accepts only NTLMv2

Microsoft documents that, in terms of effective defaults, standalone servers and modern member servers are already set to "Send NTLMv2 response only" (level 3), while on clients the policy remains "Not Defined" unless explicitly configured. Always verify the actual value with Get-ItemProperty in the registry or via RSOP before raising the level, because very old systems or legacy appliances may not support NTLMv2 and will stop authenticating. 6

Phase 4: progressive enforcement

Enforcement must be applied by scope and by phase, with a pilot group, monitoring, and rollback already defined. The exact sequence depends on the operating system version and the perimeter being protected.

To decide which audited NTLM dependencies to fix first and which to handle in the pilot, use the Active Directory hardening finding prioritization framework.

A prudent model is:

1. audit without blocking;
2. remediation of evident Kerberos fallbacks;
3. testing on representative clients and accounts;
4. restriction on a pilot OU or a controlled technical perimeter;
5. verification of authentications, services, jobs, and interactive access;
6. extension to groups of systems with an identified owner;
7. explicit management of residual exceptions;
8. periodic review of exceptions and their elimination when possible.

How to perform the audit: policies, GPOs, and Event IDs to review

This section turns phases 1 and 2 into concrete configurations: which policies to enable, where they are in the GPO, and which Event IDs to correlate. It must be validated against the actual Windows Server and Windows client build in use before being applied.

The log to monitor

Most events produced by the Restrict NTLM policies do not end up in the Security log, but in a dedicated log:

Applications and Services Logs > Microsoft > Windows > NTLM > Operational

Microsoft explicitly documents that audit and block events from the Restrict NTLM policies are recorded in this operational log and not through a separate configurable security audit policy. It therefore needs to be enabled and collected separately from the Security log. 8

# Enable the NTLM operational log (disabled by default) on a test host
wevtutil set-log "Microsoft-Windows-NTLM/Operational" /enabled:true

# Export the collected events for analysis
Get-WinEvent -LogName "Microsoft-Windows-NTLM/Operational" |
    Select-Object TimeCreated, Id, Message |
    Export-Csv ntlm-operational.csv -NoTypeInformation -Encoding UTF8

Policies to enable in Phase 1 (audit, no blocking)

All of the following policies are located in the same GPO path:

Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options

Policy	Applies to	Recommended value in audit	What it produces
Network security: Restrict NTLM: Audit NTLM authentication in this domain	Domain Controller	Enable all	Log of every NTLM authentication against domain DCs
Network security: Restrict NTLM: Audit incoming NTLM traffic	Member servers	Enable auditing for all accounts	Log of NTLM requests received on that server
Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers	Clients and servers that initiate connections	Audit all	Log of remote servers to which the client sends NTLM requests
Network security: LAN Manager authentication level	All systems	Verify the effective value before changing it	Does not generate log entries by itself, but determines whether LM/NTLMv1 is still being sent or accepted

These three audit policies do not block anything: they are only used to build the dependency map described in Phase 1 and Phase 2. They must always be enabled before the corresponding block policies. Do not confuse audit with block: an audit policy produces evidence only, while a restriction policy changes the authentication behavior and may cause application errors.

Enforcement policies (Phase 4, only after the pilot)

Blocking policy	Corresponding audit policy to use first	Values
Network security: Restrict NTLM: NTLM authentication in this domain	Restrict NTLM: Audit NTLM authentication in this domain	Deny for domain accounts to domain servers / Deny for domain accounts / Deny for domain servers / Deny all
Network security: Restrict NTLM: Incoming NTLM traffic	Restrict NTLM: Audit incoming NTLM traffic	Deny all domain accounts / Deny all accounts
Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers	same policy, Audit all in the previous phase	Deny all

Before shifting to Deny, use the dedicated exception lists for systems that remain legitimately dependent on NTLM during the transition:

• Network security: Restrict NTLM: Add server exceptions in this domain (for domain-side blocking);
• Network security: Restrict NTLM: Add remote server exceptions for NTLM authentication (for client-side outgoing blocking).

Warning: as with RC4, order matters. Do not enable the block policies before collecting at least 2-4 weeks of audit data and fixing the resolvable causes seen in Phase 3.

Event IDs to correlate

Event ID	Log	What it indicates
4624 with Authentication Package = NTLM	Security, on the target server	Successful logon that used NTLM instead of Kerberos; the Package Name (NTLM only) field distinguishes NTLMv1/NTLMv2/LM
4776	Security, on the Domain Controller (or the authoritative system for the account)	NTLM credential validation; useful for seeing the account, Source Workstation, and error code
Restrict NTLM family events (audit and block)	Applications and Services Logs > Microsoft > Windows > NTLM > Operational	Detailed view of each NTLM request audited or blocked by the Restrict NTLM policies

# Quick correlation: Event 4624 with NTLM as the authentication package, last 30 days
$startDate = (Get-Date).AddDays(-30)

Get-WinEvent -FilterHashtable @{
    LogName   = "Security"
    Id        = 4624
    StartTime = $startDate
} -ErrorAction SilentlyContinue |
Where-Object { $_.Properties[8].Value -eq "NTLM" } |
Select-Object TimeCreated,
    @{ N="Account";       E={ $_.Properties[5].Value } },
    @{ N="LogonType";     E={ $_.Properties[8].Value } },
    @{ N="AuthPackage";   E={ $_.Properties[9].Value } },
    @{ N="SourceHost";    E={ $_.Properties[11].Value } } |
Export-Csv ntlm-logons-4624.csv -NoTypeInformation -Encoding UTF8

# Event 4776 on Domain Controllers to review NTLM credential validation
$dcs = (Get-ADDomainController -Filter *).Name
foreach ($dc in $dcs) {
    Get-WinEvent -ComputerName $dc -FilterHashtable @{
        LogName   = "Security"
        Id        = 4776
        StartTime = $startDate
    } -ErrorAction SilentlyContinue |
    Select-Object TimeCreated,
        @{ N="Account";           E={ $_.Properties[1].Value } },
        @{ N="SourceWorkstation"; E={ $_.Properties[2].Value } },
        @{ N="ErrorCode";         E={ $_.Properties[3].Value } },
        @{ N="DC";                E={ $dc } }
} | Sort-Object TimeCreated -Descending | Export-Csv ntlm-4776.csv -NoTypeInformation -Encoding UTF8

The property indexes (Properties[n]) vary by OS version and localization: they must always be validated with Get-WinEvent ... | Select-Object -First 1 -ExpandProperty Properties on a real event before using them in a large-scale collection script.

How to read an event without jumping to conclusions

For every event, build a triage record:

Field	Operational question
Client	Which machine initiated the request?
Target	Which server or service received the request?
Account	Is it a user, a service account, or a computer account?
Protocol	Did the event identify NTLMv1, NTLMv2, or a broader category?
Application	Which process or service originated the connection?
Naming	Was the target reached by IP, alias, short name, or FQDN?
Frequency	Is it a continuous flow, a scheduled job, or an isolated event?
Owner	Who can change the service or application?
Plan	What is the fix, the test, and the rollback?

An isolated event does not by itself prove a critical dependency. Conversely, a rare flow tied to backups, payroll, production, or disaster recovery may be more important than thousands of ordinary accesses.

Triage of the causes: the first question is: would Kerberos have been possible?

IP access

When possible, replace the IP reference with a stable DNS name. Then verify that the name used by the client matches the service and the expected SPN registration.

Do not register IP-based SPNs as an automatic reflex. Microsoft documents this possibility but also highlights the conflict risks and the fact that IPs can change. It should be a motivated technical exception, not the standard naming path.

Quick checks to run from the client generating the connection, before and after reproducing the access:

rem resolve the host name associated with the IP (reverse DNS)
ping -a 192.168.10.7

rem show whether a Kerberos ticket already exists for the target service
klist

# verify reverse and forward DNS resolution to compare names
Resolve-DnsName -Name 192.168.10.7
Resolve-DnsName -Name fileserver.domain.local

# list the SPNs registered on the target service account
setspn -L fileserver

How to read the result: if ping -a or Resolve-DnsName do not return a name consistent with the SPN, or if after reproducing the access klist does not show a service ticket (krbtgt aside) for the destination, the connection is almost certainly negotiating NTLM instead of Kerberos. Repeat klist before and after the test to isolate the ticket generated by the specific connection.

Missing or duplicate SPN

Initial checks to run in a test environment or during an approved maintenance window:

setspn -Q HTTP/app01.contoso.com
setspn -X

The fix must be made on the correct service and the correct owning account. Do not add SPNs "until it works": a duplicate SPN can move the problem instead of solving it.

SQL Server

For SQL Server, verify the name used by the connection, the service account, and the SPNs. A useful application-level check is to inspect the authentication schema of the session:

SELECT auth_scheme
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;

The result must be interpreted in the context of the tested connection. A single Kerberos session does not prove that all clients and aliases are correct.

For this type of diagnosis, Microsoft provides a free dedicated tool: Kerberos Configuration Manager for SQL Server (Microsoft download 39046). The tool connects to a SQL Server instance (engine, SSRS, or SSAS) and automatically analyzes:

• which SPNs are registered and on which account;
• whether duplicate or missing SPNs exist for the queried service;
• whether the account running the service has the necessary permissions to register or update SPNs;
• a guided remediation proposal, with the ability to generate the correct setspn commands instead of writing them by hand.

It is especially useful because it reduces human error in the most delicate phase (understanding which account truly owns the SPN) and provides an understandable report even to those who do not manage SQL Server daily. It remains necessary to validate the result with a real connection test (auth_scheme) after remediation, because the tool reports the SPN state but does not guarantee that every client connects using the correct name.

IIS and multi-tier applications

This section requires some context for people who do not work with IIS every day (Internet Information Services, Windows Server’s web server).

When a browser or client accesses a site hosted on IIS, the site is bound to an application pool, i.e., the Windows process that actually executes the application code. That process runs under an identity (a domain account, a virtual account, or a system account): it is that identity, not the user browsing the site, that must own the correct SPN if Kerberos is to be used.

A second key concept is the host header: the same IIS server can respond to multiple different names (for example intranet.contoso.com and intranet as a short name). If the user types a name for which no HTTP/<name> SPN is registered on the application pool account, Windows cannot build a Kerberos ticket for that specific name and the browser falls back to NTLM, even if the same site works perfectly in Kerberos under another name.

Practical points to verify, in order:

• what name users actually use to reach the site (FQDN, short name, alias, IP): often it is not the name the team that created the site expected;
• which account runs the application pool in IIS Manager (Application Pools -> Advanced Settings -> Identity);
• which HTTP SPNs exist for that account, for example with setspn -L <account>;
• if an SPN like HTTP/<name-used-by-users> is missing, that is almost always the reason for the NTLM fallback for that specific alias;
• if the application is multi-tier (for example, an IIS site that must authenticate to a downstream database or service using the original user identity): in this case, it is not enough that the first hop (browser -> IIS) works with Kerberos. The Kerberos delegation (constrained or resource-based) configured on the application pool account is also required; otherwise the second hop (IIS -> database) cannot carry the user identity and typically falls back to a fixed service account or fails.

In summary: an IIS site can appear "fine" under one name and still fall back to NTLM under another name for the same site, and it can be correct on the first hop but broken on the second if delegation is missing. Every published name and every hop must be verified separately.

File servers, NAS devices, and appliances

Map shares, scripts, jobs, and devices that use \\IP\share or non-standard names. For appliances, explicitly document whether Kerberos is supported by the firmware and by the protocol in use.

Root-child domains and trusts: what changes

An NTLM audit or enforcement designed for a single domain can behave very differently if the environment has a multi-domain structure or external trust relationships. This must always be checked before extending a restriction beyond the perimeter of a single domain.

Root-child domains and other trusts within the same forest

Trusts within a forest (parent-child, tree-root, shortcut) are transitive and, according to Microsoft, are already protected adequately by default: they do not require additional configuration to mitigate known threats. 7

From a practical point of view, this means that a client in the child domain can normally obtain a Kerberos ticket for a resource in the root domain (or another domain in the same forest) through the automatic referrals between Key Distribution Centers. If NTLM still appears in this path, the cause is usually the same as before: naming not consistent with the SPN, access via IP, or a service that has never negotiated Kerberos regardless of the domain it is in.

External and forest trusts (interforest)

The situation changes with trusts between different forests (forest trusts) or external trusts to domains outside the same forest. Here two security controls documented by Microsoft come into play and must always be mapped before intervening on NTLM:

• SID filtering (quarantine): applied by default on external trusts created with modern Windows Server versions; it filters SIDs that do not belong to the trusted domain to prevent privilege escalation via SID history. It must be managed carefully: disabling it reduces forest security. 7
• Selective authentication: if enabled on an external or forest trust, a user from the trusted domain must have the explicit Allowed to Authenticate permission on the resource computer object, otherwise authentication fails regardless of the protocol. Microsoft also notes that when authentication occurs with NTLM instead of Kerberos, this permission must be granted on the computer account even if the service runs under a domain account. 7

The most important operational point for an NTLM project is this: Kerberos authentication across a forest trust requires the resource SPN to be resolved through the global catalog and a referral to the correct domain in the other forest. If this resolution fails (SPN not published, name suffix not registered in the trust, client unable to follow the referral), the client may fall back to NTLM for that specific connection even though Kerberos works locally without issue.

The following diagram summarizes the two possible paths and where to intervene when problems occur:

flowchart TD

C([Client in the trusted domain<br/>requests a resource in the trusting domain/forest]) --> R{Resource SPN<br/>resolvable via<br/>Global Catalog + referral?}

R -- Yes --> K[Kerberos path]
K --> K1{Selective authentication<br/>enabled on the trust?}
K1 -- No --> K2[Ticket issued<br/>Kerberos authentication succeeds]
K1 -- Yes --> K3{User/group has the<br/>Allowed to Authenticate<br/>permission on the computer object?}
K3 -- Yes --> K2
K3 -- No --> K4[Authentication denied<br/>not an NTLM/Kerberos problem]

R -- No --> N[Fallback to NTLM<br/>for this connection]
N --> N1{Selective authentication<br/>enabled on the trust?}
N1 -- Yes --> N2[Allowed to Authenticate is still required<br/>on the computer account]
N1 -- No --> N3[NTLM negotiated if the trust<br/>and target domain allow it]
N --> N4{SID filtering / quarantine<br/>on the external trust}
N4 --> N5[External SIDs from the trusted domain<br/>are filtered]

style K2 fill:#1f8a4c,color:#fff
style K4 fill:#b3261e,color:#fff
style N4 fill:#b58900,color:#fff

How to read the diagram: the left branch (Kerberos) is the desired path and the one to target with naming and SPN remediation; the right branch (NTLM) is the one to monitor in audit and correct when the cause is fixable. Selective authentication and SID filtering are not protocol problems: they are additional controls that can block access even when Kerberos or NTLM would have worked, and they must be diagnosed separately.

Why this matters for audit and enforcement

Before extending an NTLM restriction policy beyond a single domain, always verify:

• which trusts exist (parent-child, tree-root, shortcut, forest, external, realm) and their direction (one-way or two-way) and transitivity;
• whether an external trust connects a domain or forest that does not fully support Kerberos (for example, legacy domains or non-Windows realms with limited configuration): in that case NTLM may be the only available protocol for users coming from that trust, and blocking it will break all authentication coming from there;
• where selective authentication is enabled, because it introduces an additional point of failure independent of NTLM/Kerberos that can be mistaken for a protocol issue;
• whether the NTLM events captured in audit come from a child domain, the root domain, or an external trust: the remediation and enforcement risks are very different in the three cases.

Do not treat the environment as a single domain if it is not: a correct enforcement plan must have an explicit scope per domain and, separately, an explicit scope for every external trust.

What not to use as a shortcut

Protected Users is not a substitute for audit

Protected Users imposes strong restrictions on member accounts, including the inability to use NTLM and the need to support the required Kerberos requirements. It is a useful tool for targeted testing and for compatible accounts, but adding accounts without a dependency map can cause immediate disruption.

For the complete details on how the group works, which restrictions it imposes, and in which cases it should be avoided, see Protected Users: production limitations.

Do not disable NTLM in the domain to "see what breaks"

Global blocking without an audit phase can break interactive authentication, services, scripts, backups, share access, legacy applications, and cross-domain flows. The pressure to eliminate NTLM does not replace the change plan.

Do not create permanent exceptions without an owner

An exception must include at least: system, account, target, reason, accepted risk, owner, expiry date, compensating control, and removal plan. An allow-list without an expiry date becomes a new invisible baseline.

Recommended change plan

Before the change

• export the GPOs and document the link order;
• save the current NTLM policy configuration;
• define the pilot perimeter;
• inform the owners of critical services;
• verify the logs on Domain Controllers and targets;
• prepare functional tests for authentication, share access, applications, and jobs;
• define rollback and stop criteria.

During the change

• apply the policy only to the approved perimeter;
• force policy refresh according to the internal procedure;
• monitor authentication errors and application unavailability;
• do not add exceptions without recording them;
• capture the exact change time to correlate events.

After the change

• repeat functional tests;
• compare events with the pre-change baseline;
• verify systems that did not produce traffic during the window;
• review backups, monitoring, batch jobs, and administrative access;
• record the results for each owner;
• plan the removal of exceptions.

Rollback criteria

Rollback should not be "restore the GPO" and done. Define observable thresholds first, for example:

• failure of a critical service without an approved workaround;
• loss of administrative access to a group of systems;
• backup or replication failures;
• failed authentications beyond the agreed threshold;
• impact on a regulated workflow or a Tier 0 system.

The rollback must restore the previous configuration, keep auditing active, and generate a new plan for the dependency that caused the block. Going back without classifying the cause simply postpones the problem.

Review checklist

• A sufficient audit window has been defined?
• Domain Controllers, servers, clients, and non-Windows systems have been included?
• Every relevant event has a client, a target, and an owner?
• It has been verified whether the fallback depends on IP, alias, or SPN?
• Multi-tier applications have been tested across all hops?
• Dependencies for backup, monitoring, and disaster recovery are included?
• The pilot truly represents the most important flows?
• Microsoft policies have been checked against the version in use?
• Exceptions have an expiry date, owner, and compensating control?
• A tested rollback exists with stop criteria?
• The post-change phase included functional tests and event analysis?

Conclusion

Reducing NTLM does not mean flipping a switch from Enabled to Disabled. It means making visible the dependencies the domain has tolerated for years, correcting those with a fixable technical cause, and governing the few remaining exceptions.

The most defendable path is the measurable one: audit, classification, remediation, pilot, enforcement, verification, and review. The final configuration must be the result of evidence gathered from the real services, not a policy copied from another domain.

Microsoft sources to verify before publication

1. Restrict NTLM: Audit NTLM authentication in this domain
2. Restrict NTLM: Audit Incoming NTLM Traffic
3. Restrict NTLM: Outgoing NTLM traffic to remote servers
4. Configuring Kerberos for IP Address
5. Protected Users security group
6. Network security: LAN Manager authentication level
7. Security Considerations for Trusts: Domain and Forest Trusts
8. Restrict NTLM: NTLM authentication in this domain
9. Restrict NTLM: Incoming NTLM traffic
10. Restrict NTLM: Add server exceptions in this domain
11. Restrict NTLM: Add remote server exceptions for NTLM authentication
12. Event 4624(S): An account was successfully logged on
13. Event 4776(S, F): The computer attempted to validate the credentials for an account