Insider Reducing NTLM Dependency: IAKerb and LocalKDC in Windows Insider Preview

Today, Windows expands where Kerberos works—reducing the need for NT LAN Manager (NTLM) fallback with IAKerb and LocalKDC, coming to client and server public preview later this month for Windows Insiders in the Canary Channel. These capabilities extend Kerberos authentication to scenarios that previously required NTLM, helping organizations reduce their dependency on legacy protocols. For developers, this means more authentication flows can rely on modern, Kerberos-based identity (even in environments that previously required legacy protocols), reducing the need for application workarounds and helping ensure consistent behavior across managed and unmanaged environments.

With this release:​

• IAKerb will be enabled by default
• LocalKDC will be disabled by default
• Both features will be configurable through registry keys

Note: For this public preview, configuration is exposed through registry settings so you can evaluate these capabilities in Insider environments. Management surfaces, such as Group Policies and MDM-based management, will be introduced as these capabilities mature.

Why this matters​

For many organizations, moving away from NTLM is a security priority. But in practice, NTLM often remains in use because there are still real-world scenarios where traditional Kerberos cannot be used directly, such as:

• Devices that do not have direct line-of-sight to a domain controller
• Authentication flows involving local accounts
• Standalone or workgroup environments
• Network topologies where Kerberos reachability is limited

IAKerb and LocalKDC address many of these gaps (though not all) by extending Kerberos support, reducing reliance on NTLM fallback across customer environments.

What is IAKerb?​

IAKerb (Initial and Pass-Through Authentication using Kerberos) enables Kerberos to work when the initiating device (Kerberos client) does not have direct connectivity to a domain controller. In a traditional Kerberos flow, the client must communicate directly with a domain controller to obtain the tickets needed for authentication. In some environments, that path is not available even though the client can still reach the target service. In those cases, IAKerb enables the target service to act as a proxy for the Kerberos exchange, allowing authentication to stay on a Kerberos-based path rather than falling back to NTLM.

This makes IAKerb especially useful in environments with:

• Network segmentation
• Restricted domain controller visibility
• Remote or cloud-connected access patterns
• Architectures where clients can reach services but not DCs directly

What is LocalKDC?​

LocalKDC is a local Key Distribution Center implementation in Windows that enables Kerberos-based authentication for local account scenarios. Historically, local account authentication across machines has often depended on NTLM. LocalKDC helps close that gap by allowing Windows to use Kerberos semantics for local identity scenarios that would otherwise require legacy authentication. This is especially relevant for scenarios such as:

• Workgroup environments
• Standalone devices
• Local account access to remote resources
• Peer-to-peer or small-scale environments without domain infrastructure
• Administrative or file access scenarios where local identities are used

How these features fit together​

IAKerb and LocalKDC address different but complementary gaps in Windows authentication, reducing reliance on NTLM across both enterprise and local identity scenarios.

• IAKerb is meant for enterprise and corporate environments, where domain credentials are used but Kerberos authentication cannot always complete because the client lacks direct line of sight to a domain controller. By allowing authentication to remain on a Kerberos-based path in these situations, IAKerb helps reduce NTLM usage for high-value corporate credentials . This is important because reducing the use of NTLM for enterprise credentials helps strengthen defenses against credential theft and relay-based attack paths, including forms of lateral movement that have historically relied on NTLM fallback.
• LocalKDC addresses a different class of scenarios: local and non-domain identities, including workgroup, standalone, and local account access patterns. In these cases, LocalKDC helps bring Kerberos-based protections to scenarios that traditionally depended on NTLM for local credentials.

Together, these capabilities extend Kerberos in two directions: domain-based enterprise credentials, and local and consumer-style account scenarios, further reducing the exposure to credential theft and relay-based attacks. This matters because, as part of a broader shift toward modern and enforced authentication, simply disabling older protocols is not enough. Organizations also need secure, reliable authentication that works consistently, without falling back to legacy protocols. These features help deliver that by providing modern, compatible alternatives that reflect how customers operate today.

Registry Configuration:​

For this public preview, IAKerb and LocalKDC can be configured using registry settings under:


The supported values for this preview are:

• DisableIAKerb
• DisableLocalKDC

Set the value to:

• 0 to enable the feature
• 1 to disable the feature

Note: If a registry value is not present, Windows uses the default behavior for that release. In this preview, the defaults are:

• IAKerb: enabled by default (0)
• LocalKDC: disabled by default (1)

This gives you flexibility to evaluate the features in Insider environments while controlling rollout and validation according to your needs.

What you can do now​

With this public preview, customers participating in the Canary Channel can test these capabilities in preview environments and validate the scenarios where NTLM is still commonly used. These features are designed to address important NTLM fallback scenarios but will not eliminate every remaining NTLM dependency in Windows environments; some scenarios may still require NTLM based on application behavior, infrastructure assumptions, or legacy dependencies. Our goal with this preview is to close some of the key gaps by extending Kerberos to more scenarios, while continuing broader work to reduce NTLM dependency across the platform over time. Once available, you can use this preview to help:

• Identify scenarios already covered by IAKerb or LocalKDC
• Validate those scenarios in controlled environments, and use the documented configuration options to control enablement during testing
• Understand where NTLM dependencies still remain using our enhanced NTLM Auditing
• Check for dependencies such as name resolution, SPN configuration, or legacy assumptions
• Prepare for future improvements that will address additional cases

We also recommend evaluating the following areas:

• Access to SMB shares
• Remote administration scenarios
• Environments with limited or no direct Domain Controller (DC) connectivity
• Workgroup or standalone device authentication
• Local account access patterns
• Scenarios being prepared for NTLM reduction or eventual NTLM blocking

This preview is an opportunity to validate application compatibility, infrastructure dependencies, and operational readiness before broader rollout decisions are made. Learn more about upcoming work in this space here: Advancing Windows security: Disabling NTLM by default - Windows IT Pro Blog.

Troubleshooting and Feedback​

As you evaluate IAKerb and LocalKDC in preview environments, you may encounter scenarios where authentication behaves differently than expected. Windows provides built-in logging to help you understand what is happening and identify potential issues. These logs help you:

• Verify whether Kerberos authentication is being used
• Identify cases where IAKerb or LocalKDC is involved
• Detect failures or fallback conditions

You can also leverage NTLM operational logs to:

• Identify when NTLM is still being used
• Understand why fallback to NTLM is occurring
• Prioritize scenarios for further investigation

Reviewing these logs together can help you determine whether authentication is staying on a Kerberos path (via IAKerb or LocalKDC) or falling back to NTLM and why.

When to expect fallback behavior​

Because this is a preview release, some scenarios may still fall back to NTLM due to:

• Application-specific dependencies
• Environmental configuration (e.g., name resolution or SPN issues)
• Interactions between domain accounts and local accounts on the same machine

IAKerb and LocalKDC are designed to address a subset of common NTLM fallback scenarios, and continued improvements are planned to expand coverage over time.

Share feedback and scenarios​

If you encounter a scenario that does not behave as expected, or if you have a unique authentication flow you would like us to evaluate, we encourage you to contact us at [email protected].

Please include details such as:

• The scenario you are testing
• Expected vs. actual behavior
• Relevant event log entries (if available)

Your feedback is critical to helping us improve coverage and ensure these capabilities work reliably across real-world environments.

Securing today. Preparing for what’s next.​

Security in Windows is built into the platform—continuously maintained and designed to evolve as threats change.