- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
As Windows evolves to meet the needs of our ever-changing world, the way we protect users must also evolve to address modern security challenges. A foundational pillar of Windows security is user authentication. We are working on strengthening user authentication by expanding the reliability and flexibility of Kerberos and reducing dependencies on NT LAN Manager (NTLM).
Kerberos has been the default Windows authentication protocol since 2000, but there are still scenarios where it can’t be used and where Windows falls back to NTLM. Our team is building new features for Windows 11, Initial and Pass Through Authentication Using Kerberos (IAKerb) and a local Key Distribution Center (KDC) for Kerberos, to address these cases. We are also introducing improved NTLM auditing and management functionality to give your organization more insight into your NTLM usage and better control for removing it.
Our end goal is eliminating the need to use NTLM at all to help improve the security bar of authentication for all Windows users.
The legacy of NTLM
User authentication in Windows is used to prove to a remote system that a user is who they say they are. NTLM does this by proving knowledge of a password during a challenge and response exchange without revealing the password to anyone. The way NTLM works has benefits that have made its use popular in the past:
- NTLM doesn’t require local network connection to a Domain Controller.
- NTLM is the only protocol supported when using local accounts.
- NTLM works when you don’t know who the target server is.
These benefits have led to some applications and services hardcoding the use of NTLM instead of trying to use other, more modern authentication protocols like Kerberos. Kerberos provides better security guarantees and is more extensible than NTLM, which is why it is now a preferred default protocol in Windows.
Organizations can turn off NTLM, but it may cause issues with applications which hard-coded NTLM use. Disabling NTLM may also cause issues in scenarios that will not work with Kerberos. Kerberos must have access to a Domain Controller and requires specifying the target server. These requirements cannot always be met, which will cause authentication problems if NTLM is not available as a fallback. Evolving Windows authentication and reducing the usage of NTLM requires that we remove these limitations in Kerberos.
Kerberos, better than ever
For Windows 11, we are introducing two major features to Kerberos to expand when it can be used—addressing two of the biggest reasons why Kerberos falls back to NTLM today. The first, IAKerb, allows clients to authenticate with Kerberos in more diverse network topologies. The second, a local KDC for Kerberos, adds Kerberos support to local accounts.
IAKerb is a public extension to the industry standard Kerberos protocol that allows a client without line-of-sight to a Domain Controller to authenticate through a server that does have line-of-sight. This works through the Negotiate authentication extension and allows the Windows authentication stack to proxy Kerberos messages through the server on behalf of the client. IAKerb relies on the cryptographic security guarantees of Kerberos to protect the messages in transit through the server to prevent replay or relay attacks. This type of proxy is useful in firewall segmented environments or remote access scenarios.
The local KDC for Kerberos is built on top of the local machine’s Security Account Manager so remote authentication of local user accounts can be done using Kerberos. This leverages IAKerb to allow Windows to pass Kerberos messages between remote local machines without having to add support for other enterprise services like DNS, netlogon, or DCLocator. IAKerb also does not require us to open new ports on the remote machine to accept Kerberos messages.
Authentication through the local KDC uses AES out of the box improving the security of local authentication.
In addition to expanding Kerberos scenario coverage, we are also fixing hard-coded instances of NTLM built into existing Windows components. We are shifting these components to use the Negotiate protocol so that Kerberos can be used instead of NTLM. By moving to Negotiate, these services will be able to take advantage of IAKerb and LocalKDC for both local and domain accounts.
All these changes will be enabled by default and will not require configuration for most scenarios. NTLM will continue to be available as a fallback to maintain existing compatibility.
Improving the management of NTLM
In addition to new Kerberos features, we are extending NTLM management controls to provide administrators with greater flexibility in how they track and block NTLM usage in their environments. There are existing event viewer logs that provide information on incoming and outgoing authentication requests that use NTLM. We are adding service information to these logs to provide more clarity on exactly which applications are using NTLM. Similarly, we are extending the control for NTLM to allow specifying granular policy at the service level. With these policies you will be able to block NTLM usage for a specific service or create service exceptions to system wide NTLM blocks.
Future disablement of NTLM
Reducing the use of NTLM will ultimately culminate in it being disabled in Windows 11. We are taking a data-driven approach and monitoring reductions in NTLM usage to determine when it will be safe to disable. In the meantime, you can use the enhanced controls we are providing to get a head start. Once disabled by default, customers will also be able to use these controls to reenable NTLM for compatibility reasons.
What should you do now?
The reduction of NTLM usage has often been a priority for customers and we have some existing resources that will aid in preparing for these changes.
- Start cataloging your NTLM use. We recommend using existing policy and logging to understand where NTLM is used and what apps may block you from disabling NTLM. For more information see, NTLM Blocking and You: Application Analysis and Auditing Methodologies in Windows 7.
- For application developers, audit code for hardcoded usage of NTLM. Look for calls to the AcquireCredentialsHandle function that are passing in the hardcoded string “ntlm” and replace with “negotiate”. Also look for calls to the RpcBindingSetAuthInfo function and replace “RPC_C_AUTHN_DEFAULT” with “RPC_C_AUTHN_GSS_NEGOTIATE”.
- Register for our upcoming webinar, “The Evolution of Windows Authentication”, on October 24th, 2023, at 8:00 am Pacific Time. Join our product engineering team for live demos, Q&A, troubleshooting guidance, and a sneak peek at our long-term strategy for the ultimate disablement and removal of NTLM.
- Look out for more updates about our upcoming functionality improvements to address scenarios that Kerberos doesn’t currently support.
Continue the conversation. Find best practices. Bookmark the Windows Tech Community ,then follow us @MSWindowsITPro on X/Twitter. Looking for support? Visit Windows on Microsoft Q&A.