Many organizations need or desire to do NTLM authentication for their users if system is not part of domain upon Kerberos failure.
NT LAN Manager (NTLM)
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).
Microsoft no longer recommends NTLM in applications:
“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.
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.
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.
NetIQ Access Manager Identity Server setup details
Download and copy the jar files, which has custom authentication class and dependent library jar files to folder to your NAM 3.2.x / 4.0 Identity Server(s) /opt/novell/nam/idp/webapps/nidp/WEB-INF/lib
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
Before hitting Apply or OK, add following properties to the class
com.novell.nidp.authentication.local.kerb.svcPrincipal – service principal as created based Kerberos authentication documentation
com.novell.nidp.authentication.local.kerb.realm – realm value
com.novell.nidp.authentication.local.kerb.jaas.conf – jaas configuration file
com.novell.nidp.authentication.local.kerb.kdc – KDC IPAddress
com.novell.nidp.authentication.local.kerb.ADUserAttr – userstore search attribute name
com.novell.nidp.authentication.local.kerb.upnSuffixes – upn suffixes, domain names
Above parameters can be referred to NAM documentation. Map above parameters with Kerberos documentation.
Following parameters used by NTLM
DOMAIN_CONTROLLER_IP – AD domain controller IPAddress
DOMAIN_CONTROLLER_FQDN – AD domain controller FQDN
SERVICE_ACCOUNT_NAME – Computer account name
SERVICE_ACCOUNT_PWD – Computer account password
DOMAIN – windows NT type domain name
Your NAM authentication class is now defined. Next, define a NAM Identity Server Method using the custom Kerberos NTLM Authenticator Class just created, click Apply.
Your NAM authentication method is now defined. Next, define a Contract, click Apply.
Apply changes on IDP and update IDP server
Testing the configuration:
Access NetIQ Identity Server page http(s)://<<idp server >>:<<port>>/nidp or protected resource
Select the newly created contract.
If client machine is connected to domain, user will be authenticated with Kerberos.
If client machine is not connected to domain, NTLM login prompt shows up. Enter user name as email@example.com and password
If user does not want to do the NTLM, user can click cancel, where fall back method will be executed.
Computer Account Information
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.
Dim strDn, objPassword, strPassword, objComputer
If WScript.arguments.count 1 Then WScript.Echo “Usage: SetComputerPass.vbs <ComputerDN>” WScript.Quit End If
strDn = WScript.arguments.item(0)
Set objPassword = CreateObject(“ScriptPW.Password”) WScript.StdOut.Write “Password:” strPassword = objPassword.GetPassword() Set objComputer = GetObject(“LDAP://” & strDn) objComputer.SetPassword strPassword
WScript.Echo WScript.Echo “Password set on ” & strDn
Note: This script should also work remotely from another workstation provided it is executed with sufficient credentials.
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
‘Set objPassword = CreateObject(“ScriptPW.Password”)
‘strPassword = objPassword.GetPassword()
strPassword = “ALongRandomPassword”
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.