# NTLM

Outgoing connections authenticating to Windows and Active Directory-protected APIs with domain credentials.

[Video: New NTLM definition](https://zatosource-production.b-cdn.net/docs/gfx/security/ntlm-create.webm?v=1792089421)

Dashboard menu: Security > NTLM

## Overview {#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](https://zato.io/docs/security/kerberos/index.html), 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 {#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](https://zato.io/docs/admin/enmasse.html) under the `security` key, with `type: ntlm` - the fields are in the [enmasse reference](https://zato.io/docs/admin/enmasse-reference.html).

## Outgoing connections {#outgoing-connections}

Assign a definition to an [outgoing REST connection](https://zato.io/docs/dev/rest/outconns.html) 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)](https://zato.io/docs/security/kerberos/index.html) definition type covers the same class of Windows-protected APIs with keytab-based credentials instead of a password.

## Learn more {#learn-more}

- [Securing channels](https://zato.io/docs/admin/security/channel.html) - Which security types a channel accepts, and how to assign them
- [Securing outgoing connections](https://zato.io/docs/admin/security/outgoing.html) - Credentials Zato presents to the systems it calls
- [API keys](https://zato.io/docs/security/api-keys.html) - Per-client keys in a configurable HTTP header
- [Basic Auth](https://zato.io/docs/security/basic-auth.html) - Usernames and passwords for channels and outgoing connections
- [Bearer tokens](https://zato.io/docs/security/bearer-tokens/) - Static tokens and JWTs verified against a JWKS endpoint
- [Security groups](https://zato.io/docs/security/groups.html) - Many API client credentials on one channel or MCP gateway
- [Kerberos (SPNEGO)](https://zato.io/docs/security/kerberos/) - Negotiate authentication from a keytab, with no ticket management
- [mTLS](https://zato.io/docs/security/mtls/) - Client certificates in both directions, matched by fingerprint or DN
- [WS-Security](https://zato.io/docs/security/ws-security.html) - UsernameToken, X.509 and SAML for SOAP traffic
- [Quota tiers](https://zato.io/docs/security/quota-tiers.html) - Named rate-limit plans assigned to any number of API clients
- [TLS certificates](https://zato.io/docs/admin/security/ssl/) - Your own certificates, the self-signed ones and how to rotate them