Netlogon Secure Channel and Schannel

Overview

The term “secure channel” in Windows documentation refers to different mechanisms depending on the context. In particular, the Active Directory Netlogon secure channel and the Secure Channel Security Support Provider (Schannel SSP), which implements TLS, have similar names but different purposes, credentials, and protocols.

Term	Main purpose	Peers	Main trust material
Netlogon secure channel	Verify trust between a domain member and a domain, or between domains, and protect Netlogon RPC	Domain member and Domain Controller (DC), or DCs in a trust relationship	Session key derived from a computer account password or trust password
Secure Channel / Schannel SSP	TLS / DTLS handshake and record protection	TLS client and TLS server	X.509 certificate and keys established through TLS key exchange
SSPI security context	Authentication and message-protection state established by an SSP	Application client and server peers	Depends on the selected SSP
TLS channel in CredSSP	Encrypted channel carrying credential delegation	CredSSP client and target server	TLS server certificate and TLS session key

A Windows domain error saying that the “Secure Channel is broken” usually refers to Netlogon, while a “Schannel event” or TLS handshake error refers to the Schannel SSP.

Netlogon Secure Channel

A domain-joined computer has a computer account in Active Directory (AD) and a corresponding machine account password. The local computer and AD both hold the relevant secret, and the Netlogon Remote Protocol (MS-NRPC) establishes and maintains a secure channel with a DC using that shared information.

According to Microsoft’s MS-NRPC specification, the client and DC mutually validate Netlogon credentials and confirm that they share the same password information before deriving a session key. That session key is used to sign and encrypt subsequent RPC communication.

sequenceDiagram
    participant M as Domain member / Netlogon
    participant D as Domain Controller / Netlogon

    Note over M,D: AD and local LSA hold matching machine secrets
    M->>D: Connect to Netlogon RPC after DC Locator
    M->>D: Challenge / Netlogon credential
    D->>M: Server credential / capability negotiation
    Note over M,D: Mutual verification and session key derivation
    M->>D: Signed / sealed Netlogon RPC
    D-->>M: Protected response

What it is used for

The Netlogon secure channel primarily serves these purposes:

Verify machine trust between a domain member and a DC.
Securely carry validation information for NTLM network logons received by a member server to the account authority / DC.
Provide a secure channel between DCs involved in a domain trust.
Protect Netlogon operations that maintain computer account passwords or trust passwords.
Provide integrity, sequence detection, and required confidentiality for Netlogon RPC messages.

It is not a “VPN that encrypts all traffic from a domain member to the DC.” Nor does every user Kerberos AS-REQ / TGS-REQ travel inside the Netlogon secure channel. A Kerberos client uses the Kerberos protocol with the KDC, while the Netlogon service also has other roles, such as DC Locator.

Types of secure channel

MS-NRPC defines several NETLOGON_SECURE_CHANNEL_TYPE values.

Type	Meaning
`WorkstationSecureChannel`	Channel from a domain member to a DC.
`TrustedDnsDomainSecureChannel` / `TrustedDomainSecureChannel`	Channel between DCs connected by a domain trust.
`ServerSecureChannel`	Type defined for the channel from a Backup Domain Controller (BDC) to a Primary Domain Controller (PDC).
`CdcServerSecureChannel`	Channel from a Read-Only Domain Controller (RODC) to a writable DC.

When a workstation or member server has a “trust relationship” problem in practice, investigate WorkstationSecureChannel and whether the computer account secrets match.

When a secure channel breaks

Microsoft’s troubleshooting documentation groups common causes of a broken secure channel into two categories:

Network or port reachability problems between the local computer and DC.
A mismatch between the locally stored machine password and the computer account password in AD.

Typical symptoms include domain logon failures, The trust relationship between this workstation and the primary domain failed, no logon servers available, and Netlogon event IDs 5719, 5722, and 5723. However, even the same error can have different causes, including DNS, DC Locator, firewalls, replication, snapshot rollback, or duplicate computer objects.

Initial checks

# Check the trust relationship between the member computer and domain
Test-ComputerSecureChannel -Verbose

# Check the Netlogon secure channel status
nltest /sc_query:corp.example.com

# Check DC Locator and the selected destination
nltest /dsgetdc:corp.example.com

Test-ComputerSecureChannel is for domain member computers. Microsoft notes that it can return a false-positive error on a DC and recommends netdom.exe or nltest.exe for DC checks and resets.

nltest /sc_query reports the status of the last secure channel used. In contrast, nltest /sc_verify:<DomainName> can delete and rebuild the existing channel if verification fails, so it is not a purely read-only command. Use it under change control.

Identify the cause before repairing

On a member computer, Test-ComputerSecureChannel -Repair or Reset-ComputerMachinePassword can be used, and nltest may be appropriate depending on the situation. However, repair changes the local and AD trust state. Starting with a domain rejoin or password reset without checking the following may lose the root cause or investigation evidence:

Whether DNS and DC Locator return the correct DC.
Whether required ports are reachable, including Kerberos, LDAP, SMB, the RPC endpoint mapper, and dynamic RPC.
Whether local and DC clocks are within the allowed range.
Whether AD replication is healthy and the target DC has the latest computer account password.
Whether a VM snapshot restore, computer clone, or recreation under the same name caused the password mismatch.
Whether the target is a member computer or DC, and whether the chosen Microsoft procedure fits that role.

Schannel SSP and TLS

The Secure Channel (Schannel) SSP is Windows’ TLS / DTLS implementation. It provides server authentication with a server certificate, optional client certificate authentication, TLS key exchange, and record encryption / integrity. Applications can also use Schannel through the SSPI API. When a server requires a client certificate, the application or server also has responsibilities for certificate validation and account mapping.

Application
  -> SSPI: Select the Schannel package
  -> InitializeSecurityContext / AcceptSecurityContext
  -> Exchange TLS handshake tokens over the transport
  -> Certificate validation and key establishment
  -> Protect TLS records with EncryptMessage / DecryptMessage, etc.

Schannel is a different package from the Negotiate SSP, which chooses Kerberos or NTLM. They can nevertheless be layered within the same application stack.

HTTPS + Integrated Windows Authentication

TCP
└─ TLS / Schannel                 # Server certificate and transport protection
   └─ HTTP
      └─ Negotiate / SPNEGO       # Selects Kerberos or NTLM
         └─ Application identity

CredSSP also establishes a TLS channel first, then performs SPNEGO authentication and credential delegation inside it. Accordingly, “TLS server authentication,” “Windows user authentication,” and “credential delegation” must be assessed separately.

Security considerations

Do not treat a Netlogon secure channel problem as a simple user password error. Check machine trust, the network, DC Locator, and replication.
Protect a domain member’s machine account credentials as credentials of a security principal.
Do not weaken Netlogon RPC security enforcement; keep clients and DCs at supported patch levels.
For Schannel, manage supported TLS versions and cipher suites, certificate chains, name validation, and revocation policy.
Even with HTTPS, the underlying HTTP Negotiate authentication may still choose NTLM. Observe both TLS and the authentication mechanism.
Judge whether a channel is encrypted separately from whether credentials should be delegated to the peer.

Official Microsoft documentation

MS-NRPC: Netlogon Common Authentication Details: Mutual credential verification and session key for the secure channel.
MS-NRPC: Applicability Statement: Netlogon secure channel, RPC protection, and NTLM validation transport.
MS-NRPC: NETLOGON_SECURE_CHANNEL_TYPE: Channel types for domain members, trusts, RODCs, and others.
Secure channel problems detected: Network failures, machine password mismatches, related events, and repair considerations.
Test-ComputerSecureChannel: Channel testing and repair for member computers and limitations on DCs.
Nltest: Differences among /sc_query, /sc_verify, and /sc_reset.
Security Support Provider Interface Architecture: SSP architecture including Schannel, Negotiate, and CredSSP.
Performing Authentication Using Schannel: TLS server certificates and optional client authentication.