NTLM
Outgoing connections authenticating to Windows and Active Directory-protected APIs with domain credentials.
Overview
An NTLM security definition describes a Windows domain account that Zato uses to authenticate to NTLM-protected APIs - the challenge-response authentication that IIS-hosted services, Exchange and other Windows and Active Directory systems expose in front of their endpoints.
The definition is used with outgoing REST connections - Zato is the client that authenticates to a remote, NTLM-protected API. Like Kerberos, it is how Zato authenticates itself to a remote system, so channels do not accept it - a caller cannot present NTLM credentials to a channel.
Definitions are managed in the dashboard under Security > NTLM. Changes take effect immediately, without server restarts.
Definition fields
| Field | Notes |
|---|---|
| Name | A unique name for the definition |
| Username | The Windows account to log in as, in the DOMAIN\username format |
| Password | The account's password |
The definition is exported and imported with enmasse under the security key, with type: ntlm - the fields are in the enmasse reference.
Outgoing connections
Assign a definition to an outgoing REST connection by selecting NTLM/<name> in the connection's security dropdown. From then on, every call through that connection performs the NTLM handshake - the remote server replies with 401 and WWW-Authenticate: NTLM, Zato negotiates the challenge-response exchange with the domain credentials and the request is retried with the token attached, all without anything to add in service code.
For environments that already moved from NTLM to Kerberos, the Kerberos (SPNEGO) definition type covers the same class of Windows-protected APIs with keytab-based credentials instead of a password.