Secur32.dll mainly contains the Secure Service Provider Interface, SSPI. SSPI allows developers to use different providers of secure socket-like services. In SSPI, a Secure Service Provider (SSP) is loaded by the system and queried for the capabilities it supports. You (the client developer) can choose which provider you want by name. Normal SSPs (I don't know a better name for them) are loaded by secur32.dll in the context of the calling process.

The are also authentication SSPs, which are capable of authenticating users. They're loaded (in Windows) in the context of the LSA. Since Wine doesn't have an LSA and doesn't authenticate users, I'm only talking about normal SSPs here.

SSPI is a plugin interface: SSPs are implemented in external DLLs, and secur32.dll loads them. Wine's secur32.dll is already able to load native SSP DLLs.

Wine's Secur32.dll also provides a couple of built-in SSPs, the NTLM provider and the Schannel provider.



The NTLM provider is capable of authenticating against a Windows server, and encrypting/decrypting packets to and from that server. Wine's NTLM provider is being worked on by KaiBlin, and detailed in NtlmSigningAndSealing.

Native probably keeps NTLM in MSV1_0.DLL, which is an authentication SSP. There is no incentive for wine to put NTLM in a dll external to secur32.


Schannel is Microsoft's implementation of SSL/TLS. SSL, the secure sockets layer, was designed to be a drop-in replacement for sockets: it performs authentication, and after authentication developers can write to and read from a "secure" socket as close to transparently as possible.

SSL was developed by Netscape. At some point they submitted it as an RFC to the IETF, and the IETF fixed some design flaws in it and renamed it Transport Layer Security, or TLS. The current version of the protocol is TLS 1.2. All versions of TLS are very similar to each other and to SSL 3, and products that support any of these protocols generally interoperate with each other. SSL 2 has serious flaws and should not be used.

Microsoft's SChannel also supports PCT, which is a deprecated protocol by Microsoft that was replaced by SSL/TLS.

SChannel is also an authentication SSP, for the purpose of authenticating users using a client certificate (e.g., by a web server).


Starting at Windows 2000, kerberos 5 got integrated as kerberos.dll, which is yet another SSP/AP (Security Support Provider/Authentication Package). Kerberos is a robust IETF-approved authentication protocol, and Microsoft reused it as one of the underlying protocols for Active Directory.

Wine's secur32 does not support kerberos. However, it should not be a significant problem, as there are a few good free implementations of kerberos. The SingleSignOn page should capture this information better.


Negotiate is the Microsoft name for SPNEGO, which is a protocol for negotiating other security protocols, such as ntlm and kerberos. It is mostly known when authenticating to NTLM-requiring HTTP servers or proxies. RFC 4178 and RFC 4559 are a good start.

Related DLLs

Workers: HenriVerbeet, JuanLang, KaiBlin

CategoryDLLs CategorySecurity

Secur32 (last edited 2013-07-22 02:54:39 by KyleAuble)