Share via

Use Authentication

  • Article

You can control access to the device and services only to authorized users by implementing authentication protocols available in Windows CE. Some are built into the feature and others require you to add features to your operating system. For example, if your want to use NTLM SSP and/or Kerberos SSP, you need to add these features to your operating system. NTLM and Kerberos are implemented through the Security Support Provider Interface (SSPI).

SSPI is available through the Secur32.dll module, which is a well-defined, commonly used, API for obtaining integrated security services for authentication, message integrity, and message privacy. It provides an abstraction layer between application-level protocols and security protocols. Because different applications require different ways of identifying or authenticating users and different ways of encrypting data as it travels across a network, SSPI provides a way to access dynamic-link libraries (DLLs) containing different authentication and cryptographic data schemes. These DLLs are called Security Support Providers (SSPs).

The following illustration shows the relationship of the SSP DLLs to the SSPI Secur32.dll, Winsock, and WinInet.

The following table shows available SSPs in Windows CE.

Security Support Provider Description
Kerberos SSP The Kerberos protocol defines how clients interact with a network authentication service. The Kerberos authentication protocol provides a mechanism for mutual authentication between entities before a more secure network connection is established.
Schannel SSP Schannel SSP contains a set of security protocols that provide identity authentication and enhanced communication security through encryption. Schannel is primarily used for Internet applications that require a more secure Hypertext Transfer Protocol (HTTP) communications.
Windows NT LAN Manager SSP (NTLM SSP) NTLM SSP is based on Microsoft Windows NT® LAN Manager challenge/response and NTLM version 2 authentication protocols used on networks running versions of Windows NT operating system or Windows CE servers.

Some schemes are more secure than others. Basic authentication is much weaker than Kerberos, therefore you should keep this in mind when determining which scheme best fits the needs of the application.

The following list summarizes the authentication best practices:

  • Use the StartUI component to password-protect a device. Without password protection, anyone can use the device and potentially gain access to resources on a network.

  • Enable device locking capabilities to require a password to access a device while it is powered on.

  • If you need to keep user credentials on the device, save user credentials in the registry. For best protection, do not store user credentials on the device. This prevents hackers from extracting the network credentials from the device if the device is stolen.

  • If you want to allow users to save authentication information on a device, use Credential Manager. However, you can increase the level of protection if you do not save user credentials on the device itself. If the application is using the Credential Manager, you can set the DisallowSavedNetworkPasswords registry value to 1. This prevents hackers from extracting the network credentials from the device in case the device is stolen.

  • Use smart cards to store user credentials. This prevents hackers from extracting the network credentials from the device in case the device is stolen.

  • Use NTLM SSP or Kerberos SSP in client-server applications. The client applications supply the user name, domain name, and password and the server and client applications exchange tokens to complete the authentication.

  • Use Kerberos to provide mutual authentication between entities. This allows the server to authenticate the client and allows the client to authenticate the server. Note that NTLM does not provide mutual authentication.

  • Use a strong authentication protocol. When using NTLM SSP, you can specify the authentication protocols for the client and the server separately. To prevent NTLM SSP from using the weaker authentication protocol, set the LmCompatibilityLevelClient registry value to 3. This specifies that the client will only use NTLM v2 for authentication; however, authentication will fail if the server is not capable of NTLM v2 protocol. You can also set the LmCompatibilityLevelServer value to 2 or 3. This specifies that the server will only use NTLM v2; authentication will fail if the client is not capable of NTLM v2 protocol.

    NTLM v2 authentication protocol is only available in Windows CE .NET 4.1 and later. Servers running Microsoft Windows 2000 and later support NTLM v2.

  • Avoid authentication protocols that use clear text passwords. When using Lightweight Directory Access Protocol (LDAP), use NTLM or Negotiate instead of Basic authentication protocol. Basic uses clear text passwords.

  • Use ldap_bind_s function to use authentication services, such as NTLM or other Security Support Providers. The ldap_simple_bind function uses a clear text password for authentication. For more information, see LDAP Security Model.

See Also

Authentication Services | LDAP Client | Smart Card | Credential Manager

Last updated on Wednesday, April 13, 2005

© 2005 Microsoft Corporation. All rights reserved.