The transition away from NT LAN Manager (NTLM) authentication represents one of the most critical security initiatives in modern enterprise network administration. For nearly three decades, NTLM served as a default or fallback authentication mechanism within Windows-centric environments, despite its vulnerability to credential relay, offline dictionary attacks, and lack of mutual authentication. To resolve these vulnerabilities, Microsoft has initiated a structured phase-out of NTLM across Windows 11 and Windows Server 2025.
To eliminate NTLM without breaking authentication across segmented networks or standalone workgroup topologies, two strategic security features have been introduced: Initial and Pass-Through Authentication Using Kerberos V5 and the GSS-API (IAKerb), and the Local Key Distribution Center (Local KDC). This report provides an exhaustive technical analysis comparing IAKerb and standard Kerberos, analyzes their GSS-API Object Identifiers (OIDs), details their step-by-step protocol flows, and evaluates how Visuality Systems’ YNQ and jNQ commercial implementations facilitate compliance in non-Windows and embedded systems.
Architectural Mechanisms and Protocol Identifiers
Standard Kerberos authentication operates under a three-party security model requiring the client, the application server, and a centralized Key Distribution Center (KDC) to have direct, bi-directional network communication. In segmented enterprise architectures, remote access scenarios, or firewalled demilitarized zones (DMZs), client devices frequently lack direct network access or “line-of-sight” to a Domain Controller. Historically, this network isolation triggered an automatic fallback to NTLM.
IAKerb is a Generic Security Service Application Program Interface (GSS-API) mechanism designed to maintain Kerberos authentication in these constrained topologies. Originally designed by MIT Kerberos and defined by the Internet Engineering Task Force (IETF) draft draft-ietf-kitten-iakerb-03, IAKerb allows a client to authenticate to an application server (such as an SMB server) when the client cannot reach the KDC directly, but the server has a valid network path to the KDC. Instead of establishing direct connections on UDP/TCP port 88, the client encapsulates its Kerberos messages inside GSS-API tokens, tunneling them over the primary application session (such as TCP port 445) within the Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) security blobs used during SMB2 SESSION_SETUP.
For standalone, workgroup, or peer-to-peer deployments where no centralized Domain Controller exists, the authentication framework is supported by a Local KDC. Co-located on the SMB server itself, the Local KDC leverages the local Security Account Manager (SAM) database to authenticate local user accounts using Kerberos semantics and strong ciphers (such as AES). By combining IAKerb with a Local KDC, remote local accounts can authenticate securely without requiring enterprise dependencies like Domain Name System (DNS), Netlogon, or active Domain Controllers.
During the security negotiation phase, the client and server exchange SPNEGO security tokens to negotiate mutually supported mechanisms. This negotiation relies on specific Object Identifiers (OIDs) to declare support for direct Kerberos, legacy variants, or proxied IAKerb authentication.
Mechanism Name | Object Identifier (OID) | Protocol Context and Negotiation Behavior |
SPNEGO | 1.3.6.1.5.5.2 | The negotiation wrapper that negotiates security mechanisms between peers. |
IAKerb | 1.3.6.1.5.2.5 | The proxy mechanism used to tunnel Kerberos traffic over Port 445. |
Kerberos V5 | 1.2.840.113554.1.2.2 | The standard GSS-API Kerberos mechanism defined in RFC 1964. |
Legacy MS Kerberos | 1.2.840.48018.1.2.2 | An older Microsoft-specific Kerberos identifier used for backward compatibility. |
NTLMSSP | 1.3.6.1.4.1.311.2.2.10 | The NTLM Security Support Provider OID, omitted in NTLM-disabled setups. |
To understand why this shift is so critical for modern enterprise security, watch this brief breakdown of the key differences between legacy NTLM and modern Kerberos authentication:
The timeline for Microsoft’s NTLM deprecation roadmap highlights when these mechanisms transition from optional configurations to mandatory security controls.
Phase | Timeline | Operational Impact and Capabilities Enabled |
Phase 1 | Late 2025 / Active | Deployment of enhanced NTLM auditing tools in Windows 11 (24H2) and Windows Server 2025 to map legacy dependencies and identify NTLM-active binaries. |
Phase 2 | Second Half of 2026 | Broad release of IAKerb and Local KDC features to resolve NTLM fallback triggers, updating core Windows components to negotiate Kerberos first. |
Phase 3 | Suc. to Server 2025 (2027/2028) | Outbound and inbound network NTLM authentication disabled by default, requiring fully compliant IAKerb or Kerberos configurations. |
Technical Flow Topology Comparison
The fundamental architectural difference between standard Kerberos and IAKerb lies in the routing path of the authentication tokens. In a standard Kerberos environment, the client orchestrates the ticket exchanges by communicating directly with the KDC over Port 88. In an IAKerb environment, the client interacts solely with the SMB server over TCP Port 445; the SMB server decapsulates the IAKerb wrappers and proxies the raw Kerberos messages to the KDC.
Standard Kerberos Topology Diagram
IAKerb Topology Diagram
Detailed Step-by-Step Flow Execution
The step-by-step execution details the packet-level actions of both authentication flows, demonstrating how the IAKerb proxy mechanism replaces direct client-to-KDC transactions.
Step | Standard Kerberos Flow Execution (Direct DC Access) | IAKerb Flow Execution (Proxied via SMB Server) |
1 | Client → KDC (UDP/TCP 88): The client transmits an AS-REQ to the KDC to request a Ticket Granting Ticket (TGT), typically performed at system startup or initial login. | Client → SMB Server (TCP 445): The client initiates connection by transmitting an SMB2 NEGOTIATE request packet to the SMB server. |
2 | KDC → Client (UDP/TCP 88): The KDC processes the credentials, validates the identity, and returns an AS-REP containing the encrypted TGT. | SMB Server → Client (TCP 445): The server returns an SMB2 NEGOTIATE response, advertising the IAKerb OID (1.3.6.1.5.2.5) alongside Kerberos V5 (1.2.840.113554.1.2.2) in the SPNEGO mechTypes list. |
3 | Client → SMB Server (TCP 445): The client initiates connection with the target file share by transmitting an SMB2 NEGOTIATE request. | Client → SMB Server (TCP 445): The client generates an AS-REQ, wraps it in a GSS-API token with the IAKerb OID, and transmits it inside an SMB2 SESSION_SETUP request. |
4 | SMB Server → Client (TCP 445): The server responds with an SMB2 NEGOTIATE response, advertising Kerberos V5 (1.2.840.113554.1.2.2), Legacy MS Kerberos (1.2.840.48018.1.2.2), and NTLMSSP (1.3.6.1.4.1.311.2.2.10). | SMB Server → KDC (UDP/TCP 88 or Local IPC): The server unwraps the IAKerb container and forwards the plain, unmodified AS-REQ to its reachable KDC (a remote Domain KDC or Local KDC). |
5 | Client → KDC (UDP/TCP 88): The client presents its TGT and transmits a TGS-REQ to the KDC, requesting a service ticket for the target Service Principal Name (SPN), e.g., cifs/<server>@<REALM>. | KDC → SMB Server (UDP/TCP 88 or Local IPC): The KDC verifies the client’s request and returns a plain AS-REP to the SMB server. |
6 | KDC → Client (UDP/TCP 88): The KDC issues a TGS-REP containing the service ticket encrypted with the SMB server’s shared secret key. | SMB Server → Client (TCP 445): The server encapsulates the plain AS-REP into a GSS-API IAKerb token and returns it within an SMB2 SESSION_SETUP response. |
7 | Client → SMB Server (TCP 445): The client initiates session setup by sending an SMB2 SESSION_SETUP request containing the GSS-API encapsulated AP-REQ. | Client → SMB Server (TCP 445): The client extracts the AS-REP, generates a TGS-REQ for cifs/<server>, encapsulates it in an IAKerb token, and transmits it via SMB2 SESSION_SETUP. |
8 | SMB Server → Client (TCP 445): The server decrypts the service ticket, validates the client’s signature, and completes the authentication process by returning STATUS_SUCCESS. | SMB Server → KDC (UDP/TCP 88 or Local IPC): The server decapsulates the token and transmits the plain TGS-REQ to the KDC. |
9 | N/A (Authentication already complete) | KDC → SMB Server (UDP/TCP 88 or Local IPC): The KDC processes the TGS-REQ and responds with a plain TGS-REP containing the service ticket. |
10 | N/A (Authentication already complete) | SMB Server → Client (TCP 445): The server wraps the plain TGS-REP in an IAKerb token and returns it to the client inside an SMB2 SESSION_SETUP response. |
11 | N/A (Authentication already complete) | Client → SMB Server (TCP 445): The client extracts the service ticket, generates an AP-REQ, encapsulates it within an IAKerb-FINISHED wrapper (confirming cryptographic integrity), and sends it via SMB2 SESSION_SETUP. |
12 | N/A (Authentication already complete) | SMB Server → Client (TCP 445): The server validates the ticket and the IAKerb-FINISHED packet, establishes the security context, and responds with an SMB2 STATUS_SUCCESS. |
Modernizing Embedded and Java Infrastructures
The deprecation of NTLM creates operational challenges for non-Windows platforms, legacy devices, and Java-based application integrations. Many embedded systems and Human-Machine Interfaces (HMIs) running Real-Time Operating Systems (RTOS), such as Windows CE, VxWorks, or QNX lack native-like SMB3+ support and modern Kerberos integration.
Updating these systems through custom software rewrites is often costly and complex. To address these challenges, Visuality Systems provides commercial, fully licensed SMB client and server stacks that run natively on non-Windows platforms and include Microsoft SMB IP patent protections under a direct licensing agreement with Microsoft.
Technical Implications for Security and Performance
Replacing NTLM with Kerberos and IAKerb introduces several key improvements to enterprise network security and performance.
In traditional Kerberos deployments, client devices must communicate with both the Domain Controller and the SMB server, requiring multiple ports to be open across the network.
Standard:
SMB Client ===(UDP/TCP Port 88: Kerberos KDC)===> Domain Controller
SMB Client ===(TCP Port 445: SMB Transport)======> SMB Server
By tunneling Kerberos messages through the SMB connection itself, IAKerb allows clients to authenticate using only Port 445. This port consolidation simplifies firewall configurations, reduces the exposed attack surface of Domain Controllers, and helps administrators enforce micro-segmentation policies in zero-trust architectures.
During an IAKerb exchange, the SMB server decapsulates and proxies GSS-API tokens between the client and the KDC. However, the server does not have access to the client’s long-term credentials or the negotiated session keys. The authentication payloads remain encrypted end-to-end, protecting the exchange from tampering or eavesdropping by intermediate proxy servers.
Summary
As Microsoft progresses with its NTLM deprecation roadmap, organizations must transition their network architectures and devices to Kerberos-based authentication.
For organizations running non-Windows platforms, RTOS devices, or Java-based applications, Visuality Systems’ YNQ and jNQ libraries provide a secure transition path to compliant SMB3 configurations. By replacing legacy, vulnerable protocols with fully supported, commercially licensed SMB3 implementations, enterprises can ensure continuous interoperability while protecting their environments from modern security threats.
Ready to Secure Your Network for the Post-NTLM Era?
Don’t let NTLM deprecation interrupt connectivity for your embedded platforms or Java integrations. Transition smoothly to compliant, high-performance SMB3 authentication with Visuality Systems.
Contact us to discuss your integration requirements.
Raphael Barki, Head of Marketing, Visuality Systems
