NTLMSSP Authentication from User Logged into Kerberos Realm

Resolving The Problem

Connections to NetServer from Windows users logged into an Active Directory Kerberos Realm might still attempt to authenticate with NTLMSSP encrypted password authentication.

IBM i Support is aware of two IBM i side configuration factors that might influence Windows to send up a user and password instead of a Kerberos ticket when the Windows user is logged into a Kerberos Realm.

1. The IBM i NAS CIFS principles required for the UNC name in the CIFS request are not configured.

Use the keytab list command in Qshell (STRQSH) to verify the correct CIFS principles are configured. If they are not correct, use the NAS wizard to configure the principles and update the KDC with the resulting .bat file.

2. NetServer authentication method properties set to not allow Network Authentication (Kerberos).

This can be set using the System i Navigator panel for NetServer properties, using the 5250 Emulation screen CL command menu for NetServer (GO NETS), or by the presence of a hidden share named QZLSPASSKRB$.

If the correct principles are configured and NetServer properties allow Kerberos, there is a KDC or Windows network configuration issue. The IBM Rochester Support Center knows of the following Windows requirements for kerberizing Windows Users so Windows SMB client will send a Kerberos ticket rather than NTLMSSP when connecting to NetServer. Note the order is important:

1. PC must join active directory realm.
2. The user signing onto the PC must be in Active Directory.
3. User must be enrolled in EIM.
4. CIFS SPN (service principle name) must be in the AD.

The principle must be added on the iSeries using NAS or keytab and addprinc commands. On the active directory side, they need to use ktpass to tie the SPN to the AD account, and EIM must be configured for that account first.

Any further assistance with configuring the Windows network will need to come from Microsoft.

Note: NTLMSSP is an authentication method that is an enhanced version of NTLMv1 or NTLMv2 and can actually wrapper those protocols. In the Negotiate, it allows the client and server to agree on the authentication to be used. In a network trace NTLMSSP session, setup requests appear in the data streams as a blob. This is similar to a kerberos ticket; however, not SPNEGO (Simple and Protected GSSAPI Negotiation Mechanism). NTLMSSP is a two-step process.  The first reply will return STATUS_MORE_PROCESSING_REQUIRED (x'C0000016') and the encryption key.  The client then sends the NTLMSSP_AUTH request. If NetServer responds with UNKNOWN STATUS CODE (x'00050001'), this is a generic 'access denied' error typically indicating the user ID or password is incorrect. 

For more information on NTLMSSP, refer to Microsoft's documentation entitled NT LAN Manager (NTLM) Authentication Protocol Specification.