NTLM registration page

Users of policies where NTLM is selected must undergo an additional, once only, registration task to associate their NTLM credentials with their registered cloud credentials. See NTLM transparent identification for further information. As with all notification pages, you can use the default page, customize it, or create your own.

Further information about NTLM

NTLM has evolved through numerous Windows and Windows NT versions. It provides a way for users to authenticate themselves with the company network.

NTLM identity

The NTLM identity is the domain\username with which users log on to their Windows PC; for example, MYDOMAIN\jsmith.

NTLM credentials

NTLM credentials include the NTLM identity (as defined above), the PC's identity, and a non-reversible encryption of the user's password. These are sent by the browser when a server (in this case a cloud service proxy) sends an NTLM challenge.

NTLM security implications

There are a number of security implications associated with the use of NTLM in the cloud service. These are discussed below.

The NTLM credentials are being passed across an unsecure Internet connection

NTLM is a secure protocol that does not carry the user's password, but a cryptographic hash of the password. To authenticate a user by validating a password hash, a network service must know the user's password. The cloud service is outside of the company network, and so does not know the user's network password. For this reason, the cloud service can use NTLM only to identify users, not to authenticate them. This limitation helps to preserve the security of the user's network passwords.

Transparent identification compared to basic authentication

Because NTLM does not require the user to actually authenticate with the cloud service by entering a password, one might argue that it is less secure than basic authentication. This is not the case. Most cloud service users save their usernames and passwords in their browsers and therefore, if someone wanted to surf the Internet as another user, they can do so if they can access that user's PC. This is exactly the same situation as NTLM. To protect against this, in both cases, and with any product that provides web filtering, you should consider physical security and keyboard locking when users leave their desks to keep the network secure.

Limitations

Transparent identification does not authenticate; for example, it does not do password checking. It relies on the customer site having secure NT or Active Directory domains set up, along with physical security to stop unauthorized access to the company network or the users' computers.


	Note Although NTLM Identification works with Windows workgroups, it is not a recommended solution if you are concerned about security and correctly identifying end users.

You cannot use transparent identification for remote users. Remote users must be registered and must log on using their email addresses.

Users of non-Windows systems in a transparent identification policy still have to log on manually.

Many proxies do not pass NTLM challenges, so if you have a chained proxy deployment, you should check this. Microsoft ISA/TMG Server and Blue Coat ProxySG do support NTLM pass-through.

A browser that supports NTLM but is operating in a non-Windows environment (e.g., Firefox on a Linux platform), may exhibit strange behavior and may not work with a cloud policy that is configured to use NTLM. Where possible, we attempt to identify such browsers by user agent type and send an authentication request rather than an NTLM challenge.

The existing Welcome page is not shown to users of NTLM-capable browsers in a transparent identification policy.

How NTLM works once users are fully configured

Fully configured means that users are registered with the cloud service and their NTLM identities are known. See End Users tab for details on registering users, and NTLM transparent identification for details on NTLM identity.

Users start their browsers and try to visit a website.

The cloud service checks the users' source IP address and applies the correct policy.

The cloud service finds that transparent identification is enabled in the policy and initiates the NTLM conversation, during which the browser sends the NTLM credentials with no involvement of the users. Note that it is the local policy (i.e., the one identified by IP address) that determines whether NTLM is to be used.

The cloud service finds the users' information in the policy by looking up the NTLM identity, and marks this connection as identified.

The cloud service processes the original request as normal.

This all happens transparently, behind the scenes.