Use integrated identity information to create and manage identities and control access to enterprise resources. We provide identity and access management, single sign–on (SSO), access governance, and more.

Detect and respond to all potential threats quickly and decisively. By monitoring user activities, security events, and critical systems, we provide actionable security intelligence to reduce the risk of data breach.

Get affordable, high-performance disaster recovery. We protect your workloads and help you meet or exceed RPOs and RTOs of an hour or less, with mirroring-like performance at a price point approaching tape.

Introduction

In a Windows network, NT LAN Manager (NTLM) is a suite of Microsoft security protocols that provides authentication, integrity, and confidentiality to users. NTLM is the successor to the authentication protocol in Microsoft LAN Manager (LANMAN), an older Microsoft product, and attempts to provide backwards compatibility with LANMAN. NTLM version 2 (NTLMv2), which was introduced in Windows NT 4.0 SP4 (and natively supported in Windows 2000), enhances NTLM security by hardening the protocol against many spoofing attacks, and adding the ability for a server to authenticate to the client.

NTLM is a suite of authentication and session security protocols used in various Microsoft network protocol implementations and supported by the NTLM Security Support Provider (“NTLMSSP”). Originally used for authentication and negotiation of secure DCE/RPC, NTLM is also used throughout Microsoft’s systems as an integrated single sign-on mechanism. It is probably best recognized as part of the “Integrated Windows Authentication” stack for HTTP authentication; however, it is also used in Microsoft implementations of SMTP, POP3, IMAP (all part of Exchange), CIFS/SMB, Telnet, SIP, and possibly others.

The NTLM Security Support Provider provides authentication, integrity, and confidentiality services within the Window Security Support Provider Interface (SSPI) framework. SSPI specifies a core set of security functionality that is implemented by supporting providers; the NTLMSSP is such a provider. The SSPI specifies, and the NTLMSSP implements, the following core operations:

Authentication — NTLM provides a challenge-response authentication mechanism, in which clients are able to prove their identities without sending a password to the server.

Signing — The NTLMSSP provides a means of applying a digital “signature” to a message. This ensures that the signed message has not been modified (either accidentally or intentionally) and that that signing party has knowledge of a shared secret. NTLM implements a symmetric signature scheme (Message Authentication Code, or MAC); that is, a valid signature can only be generated and verified by parties that possess the common shared key.

Sealing — The NTLMSSP implements a symmetric-key encryption mechanism, which provides message confidentiality. In the case of NTLM, sealing also implies signing (a signed message is not necessarily sealed, but all sealed messages are signed).

NTLM has been largely supplanted by Kerberos as the authentication protocol of choice for domain-based scenarios. However, Kerberos is a trusted-third-party scheme, and cannot be used in situations where no trusted third party exists; for example, member servers (servers that are not part of a domain), local accounts, and authentication to resources in an untrusted domain. In such scenarios, NTLM continues to be the primary authentication mechanism (and likely will be for a long time).

“Implementers should be aware that NTLM does not support any recent cryptographic methods, such as AES or SHA-256. It uses cyclic redundancy check (CRC) or message digest algorithms (RFC1321) for integrity, and it uses RC4 for encryption. Deriving a key from a password is as specified in RFC1320 and FIPS46-2. Therefore, applications are generally advised not to use NTLM.”

While Kerberos has replaced NTLM as the default authentication protocol in an Active Directory (AD) based single sign-on scheme, NTLM is still widely used in situations where a domain controller is not available or is unreachable. For example, NTLM would be used if a client is not Kerberos capable, the server is not joined to a domain, or the user is remotely authenticating over the web.

About New Authentication Class

New authentication class will extend existing Kerberos class. Adds NTLM support along with Kerberos and fall back mechanism. NAM will send authentication challenge for Kerberos and NTLM. Browser/user-agent will try Kerberos if it fails NTLM will be tried. If user selects not to do NTLM, then fall back method will be executed.

Setup Details

Pre-Requisite

Create computer account and note down username and password. To create computer account follow the section Computer Account Information below. Other option is download jespa package http://www.ioplex.com/downloads.php and extract copy SetupWizard.vbs Readme.txt and license to domain controller and execute the SetupWizard.vbs and note down username password.

As you would add any new authentication scheme to NAM, use the NAM Admin Console to define a new authentication Class, Method, and Contract on your Identity Server / Cluster. First define the Kerberos-NTLM Authenticator Class under the “Local” tab select Classes and click New to add your Google Authenticator Class.

Specify the logical name for your class eg. Kerb-Ntlm below and from the drop-down list select the “java class” parameter as Other and enter the “java class path” as com.netiq.custom.auth.KerbNtlmClass

If you don’t have Computer Account please follow following steps to create a computer account in AD.

Step 1: Create the Service Account for NETLOGON Communication

To use the NTLM security provider as an authentication service you will need to create a service account in Active Directory with a specific password.

To create the service account, the Active Directory Users and Computers (ADUC) utility may be used. The NETLOGON service requires that this account be a Computer account (a User account will not work). We recommend that you use the same value for both the “Computer name” (cn) and “pre-Windows 2000 name” (sAMAccountName) and use only letters, digits and possibly underscores (do not use spaces). This name will be part of the service.acctname property described in the NtlmSecurityProvider Properties section.

Also determine and note the service account “distinguished name” (DN) for setting the password in the next step. The DN can usually be derived from the account name and domain. For example if the service account name CIGNEXCMS1 is in the Active Directory domain cignex.com, the DN might be: CN=CIGNEXCMS1,CN=Computers,DC=CCA,DC=cignex,DC=com. If you are still not sure about what the DN is, the ADSI Edit MMC Snap-In will show you directory entries by DN.

Step 2: Set the Service Account Password

The service account password must be supplied to authentication class

Currently we are unaware of a standard MS utility that can be used to set passwords on Computer accounts. Therefore, the following VBScript is used to set the password on a Computer account.

Copy Paste following VB Script code in file called SetComputerPass.vbs , you can find this script as an attachment to this Wiki.

Note: This script should also work remotely from another workstation provided it is executed with sufficient credentials.

Execute script on the Domain Controller for example “AD01.cca.cignex.com”

The following command-line dialog using the above SetComputerPass.vbs illustrates how to set the password for the service account

CN=CIGNEXCMS1,CN=Computers,DC=CCA,DC=cignex,DC=com
C:\>cscript SetComputerPass.vbs CN=CIGNEXCMS1,CN=Computers,DC=CCA,DC=cignex,DC=com Password: Note: You have to login as an Administrator to run the above command. DO NOT use same password as Computer Account Name and it should match AD Password Policy

Use a long and random password and make a note of it. And later it will be configured in portal-ext.properties

In this case, open SetComputerPass.vbs with notepad and just temporarily hard-code the password by commenting out the three lines that collect the password (a ‘ is a comment in VBScript) and set it manually like following and try to run the command again

Note: Unlike User accounts, Computer account passwords do not expire. Domain security policy is frequently used to instruct Windows installations to periodically reset their own passwords however in practice these accounts are not denied access if they do not (such as because they were turned off for several months).

Configuration for authentication class for NTLMv2

Add UPN suffix for NTLMv2 to succeed. This is necessary since NTLM returns/authenticates based on the samAccountName, and does not return the email address of the user, so LDAP lookup can only be via AD username, not email address. If UPN suffix is added, userPrincipalName can be found by building username into email format.

Disclaimer: As with everything else at NetIQ Cool Solutions, this content is definitely not supported by NetIQ, so Customer Support will not be able to help you if it has any adverse effect on your environment. It just worked for at least one person, and perhaps it will be useful for you too. Be sure to test in a non-production environment.

One Comment

This is another feature that has a lot of promise to our organization, but we could never contemplating using it while it is only released via Cool Solutions. What, if any, are your intentions to include this as a shipping feature of NAM itself that is fully supported?