You can configure your environment to provide client authentication for Microsoft domains using the following protocols.
:How you join the NetCache appliance to a Microsoft domain determines the authentication methods available to you.
You can join the appliance to a domain using either of the methods described in Joining a Microsoft Windows NT domain.
In this case, the NetCache is viewed as an NT system. It can use NTLM for authentication.
You can join the appliance to a Microsoft Windows 2000 domain using either of the methods described in Joining a Microsoft Windows 2000 domain.
In this case, whether the Microsoft Windows 2000 domain is native mode or mixed mode and the method you use to join the NetCache to the domain determines how the NetCache is viewed as a system. For an explanation of the two Microsoft Windows 2000 domains, see About Windows 2000 domains.
Here is how the NetCache behaves when it joins the Windows 2000 domain in either of its two modes:
As mentioned previously, there are two kinds of Microsoft Windows 2000 domains: native mode and mixed mode. Here are their defining characteristics:
Joining the Windows NT domain as an NT system.
Joining the Windows 2000 domain as 2000 system or an NT system.
Microsoft has created provisions for Microsoft Internet Explorer users to be authenticated without requiring the user to input a user name and password every time a browser session is started.
In this documentation, this process is referred to as promptless authentication because the user is not prompted from the browser (yet again) for this information. Rather, promptless authentication depends on the tendency of Microsoft Windows to maintain a persistent password state about the current user.
Note
Microsoft Internet Explorer 6 (MSIE 6) does not support authentication of a client to a proxy server (such as the NetCache appliance) using Kerberos.
When a user signs on to an NT domain, the user name and password are kept locally for later use. When an application encounters the need to prove the identity of the user to another machine, the application might request that the user name and password be used to encrypt an arbitrary challenge string provided by the other machine. The encrypted string is then sent to the machine sending the challenge; that machine might then pass it to the Primary Domain Controller (PDC). The PDC will then encrypt the challenge with the password and compare the result with the challenge-response sent by the client.
Copyright © 1994-2002, Network Appliance, Inc. All rights
reserved.
Part No. 210-00370
File: auth11.htm
Last updated: 11/12/02 11:23:17