US 7,958,347 B1Grant
Methods and apparatus for implementing authentication
Issue Date:2011-06-07
•28 Claims
•10 Drawing Sheets
Abstract
A proxy (e.g., a switch) resides in a respective network environment between one or more clients and multiple servers. One purpose of the proxy is to provide the clients a unified view of a distributed file system having respective data stored amongst multiple remote and disparate storage locations over a network. Another purpose of the proxy is to enable the clients retrieve data stored at the multiple servers. To establish a first connection between the proxy and a respective client, the proxy communicates with an authentication agent (residing at a location other than at the client) to verify a challenge response received from the client. When establishing a set of second connections with the multiple servers, the proxy communicates with the authentication agent to generate challenge responses on behalf of the client. The proxy facilitates a flow of data on the first connection and the set of second connections.
Metadata
Assignee
- F5 Networks, Inc.
Inventor
- J C Ferguson
Application Information
Application Number:US 11/346,415
Filing Date:2006-02-02
Priority Date:2005-02-04
Art Unit:2439
Classifications
IPC:
H04L29/06H04L9/32G06F7/04G06F17/30G06F15/16
Patent Drawings (10 sheets)
Description
Related Applications
[0001] This application is related to and claims the benefit of earlier filed U.S. Provisional Patent Application Ser. No. 60/650,201 entitled “Methods and Apparatus Providing Secure Agent,”, filed on Feb. 4, 2005, the entire teachings of which is incorporated herein by this reference.
Background
[0002] In general, authentication is a process of determining whether someone is who they claim to be. In the computer industry, authentication is commonly performed via use of logon passwords. Knowledge of the password is assumed to guarantee a user is authentic. In many applications, each user initially registers (or is registered by someone else) using an assigned or self-declared password. On each subsequent use of a computer, the user must know and use the previously declared password in order to log onto a computer and use a respective network. For security reasons, passwords are generally not transmitted over a network in raw form. Instead, hashing functions are applied to passwords (provided by the user) prior to transmission over a respective network.
[0003] One type of authentication protocol is known as NTLM (e.g., Windows™ NT LAN Manager). In general, the NTLM authentication protocol involves a series of communications with a user attempting to use a respective network.
[0004] According to the NTLM authentication protocol, a client initially sends a respective server a Negotiate CIFS protocol request message. In the header of this CIFS message is a bit-mask indicating the client's capabilities, such as authentication methods supported by the client.
[0005] In response to receiving the CIFS NegProt_Request message, the server chooses a CIFS dialect for future communications based on the list presented in the NegProt_Request message. If the negotiated authentication scheme is NTLM, the server receiving the NegProt_Request message includes an 8-byte “challenge” in the NegProt_Response message.
[0006] Upon receipt of the challenge message from the server, the client encrypts the 8-byte challenge value using a derivation of a user provided password (e.g., an encryption key that is an MD4 hash of the password that is turned into a DES key). The result is a 24-byte challenge “response.” The challenge response is encoded into the SessionSetup CIFS message sent to the server.
[0007] Upon receipt of the challenge response from the client, the server performs the same computation (e.g., encryption of the 8-byte challenge) the client performed using a password hash function associated with the client. The password hash function used by the server is stored in a so-called Windows SAM database. If the result generated by the server matches encrypted value received from the client, the server returns an authentication-success message to the client allowing a respective connection. The server communicates with a domain controller of the respective network using the NetLogon Microsoft RPC protocol for purposes of authenticating a respective client. If authentication is successful in this last step, the client is cleared to send file operations to the server.
[0008] In addition to conventional NTLM techniques as discussed above, a so-called Kerberos V5 authentication model discloses a way for a client to delegate the authority for an intermediary system (e.g., another computer) to perform authentication on behalf of the client. This makes it possible to allow one's identity to flow through a multi-tier system where decisions about authority can be made in the originating identity at each tier. For example, if a user “JC” connects to machine “A,” through delegation, machine “A” can be granted the authority to authenticate a session to an application on machine “B” as user “JC.” Thus, on machine “B,” access control is applied in the context of user “JC” rather than the context of machine “A.”
Summary
[0009] Conventional mechanisms such as those explained above suffer from a variety of shortcomings. According to the Kerberos authentication model as discussed above, a proxy is delegated the authority to establish a downstream connection to a target device using the information (e.g., username) associated with the client delegating the authority to the proxy. Accordingly, the proxy is able to establish a connection with a target server based on use of information from the client. After performing an authentication according to the Kerberos model between the client and proxy and between the proxy and the target server, the client computer is able to communicate with the target device thru the proxy computer.
[0010] The conventional NTLM (Windows NT LAN Management) protocol lends itself to applications in which the client authenticates a direct communication link between the client and a target device. However, there is no provision in the conventional NTLM protocol to authenticate tandem communication links (e.g., successive CIFS connections) in a local area network environment connecting a client to a respective target device.
[0011] In contradistinction to the techniques discussed above as well as additional techniques known in the prior art, embodiments discussed herein include novel techniques associated with implementing authentication in a respective network environment. For example, embodiments herein are directed to a proxy device (e.g., a switch) residing in a respective network environment between one or more clients and multiple servers (e.g., a distributed storage system). One purpose of the proxy device is to provide one or more respective clients a unified view of a distributed file system having respective resources spread amongst multiple storage locations in a network. Accordingly, clients can connect to the proxy and view data information available from the multiple servers such as backend filers, files systems, etc.
[0012] In one embodiment, the proxy device manages the distributed data and enables the clients to access information from the multiple servers through the proxy device. That is, a client directly communicates with the proxy device via a first authenticated communication link; the proxy device also accesses data stored in the distributed file system (e.g., backend filers, storage systems, etc.) on behalf of the client via a corresponding set of authenticated links between the proxy device and the multiple servers.
[0013] More specifically, according to one embodiment herein, the proxy device enables the clients to establish connections with the proxy. However, the proxy terminates a respective client's CIFS TCP connection and negotiates a new CIFS dialect/session to each of multiple remote target locations (e.g., backend filers, servers, etc.) on behalf of the respective client. As discussed above, the connections between the proxy and multiple servers enables the proxy to access corresponding stored data in the multiple servers on behalf of the clients. Unfortunately, the proxy device needs access to the clients' password information so the proxy device is able to establish the connection between the client and the proxy device as well as establish similar types of connections between the proxy device and each of multiple servers.
[0014] For example, according to an embodiment herein, when the proxy attempts to establish a connection between the client and the proxy, the proxy must be able to verify the client is authentic. That is, the proxy must be able to verify that a client provides appropriate password information for a given username in order to establish respective connections or communication links (on behalf of the client) with the multiple servers.
[0015] One way of authenticating the client without sending password information over a respective network is to generate a “challenge” to the client. In this case, however, the proxy initiates forwarding the challenge to the client. The challenge includes a numerical value (e.g., an 8 byte value generated by a random number generator) sent to the client. In response to the challenge, the client sends a first encrypted value (e.g., a 24 byte value) of the 8-byte value back to the proxy. For example, in one embodiment, the client generates the 24-byte challenge response by applying a password hash key (e.g., a 3DES key generated by applying an MD4 algorithm to a plain text password provided by a user) to the numerical value in the challenge. To verify authorization of the client, the proxy forwards i) the numerical value associated with the challenge, ii) the client's username, and iii) the encrypted value (e.g., the 24-byte challenge response) received from the client in response to the challenge to a source (e.g., a an authentication agent) that resides in the respective network at a location other than at the client. In one embodiment, the source is an authentication agent residing at a domain controller associated with a respective network. The domain controller stores username and corresponding password information associated with the respective network environment.
[0016] Upon receiving the i) the numerical value associated with the challenge, ii) the client's username, and iii) the encrypted value (e.g., the 24-byte challenge response) from the proxy, the authentication agent retrieves a password hash key associated with the client, applies the password hash key to the numerical value (received from the proxy) to produce a second encrypted value, and determines whether the 24-byte challenge response (e.g., the first encrypted value) provided by the client matches the second encrypted value generated by the authentication agent. If so, the authentication agent determines that the client is authentic. Based on the comparison, the authentication agent notifies the proxy whether the client (e.g., the user) has been authenticated and whether the proxy can allow the connection (e.g., communication link) between the proxy and the client.
[0017] As mentioned, the authentication agent performing the “compare” function can be a secured agent. For example, in such an embodiment, the proxy communicates with the authentication agent over a respective network via a secured link.
[0018] The authentication agent can maintain password hash key information associated with users of a respective network based on communications with the domain controller. For example, in one embodiment, the authentication agent periodically (or occasionally) receives a memory dump from the domain controller including usernames and corresponding password hash keys. Thus, for purposes of verifying authentication of the client, the secured agent can retrieve respective password hash key associated with the client (e.g., a user attempting to access stored data) and initiate the steps as discussed above to verify the challenge response provided to the proxy by the client.
[0019] According to further embodiments herein, in addition to or in lieu of the verification process discussed above, the secured agent is also able to act on behalf of the respective client and establish individual sessions between the proxy and each of multiple servers and/or backend storage systems. For example, to establish a connection (a.k.a., a session) with a given one of the multiple servers, the proxy generates and forwards a message (e.g., an NTLM negotiate protocol request) to the server for purposes of requesting a connection on behalf of the client. The server replies to the proxy with an authentication challenge including a random 8-byte numerical value generated by the server. The proxy responds to the challenge without communicating again with the client.
[0020] For example, according to one embodiment, the proxy communicates the 8-byte challenge received from the server to the authentication agent. The authentication agent obtains (from its own local memory or storage) the respective password hash key associated with the username for which the connection is being established and applies the password hash key to the 8-byte numerical value received from the server to produce an encrypted value. The authentication agent forwards the encrypted value to the proxy. The proxy, in turn, forwards the encrypted value to the server in response to the challenge. The server, in turn, communicates with the domain controller to verify that the proxy, acting on behalf of the client, is able establish the connection with the server. In other words, the server forwards the encrypted value to the domain controller. The domain controller then verifies whether the encrypted value forwarded by the server matches the encrypted value that the proxy should have generated in response to the challenge. If there is an appropriate match, the proxy is authenticated and the server is allowed to notify (e.g., via an NTLM session setup response) the proxy that the session or connection can be established. Note that according to one embodiment, the proxy can setup multiple sessions over a single so-called TCP connection.
[0021] The proxy can repeat the above procedure for each link to the multiple servers (e.g., backend filers) in order to establish and authenticate connections (i.e., sessions) with each of the multiple servers. Accordingly, a client connects to the proxy via a first connection and the proxy connects to the multiple servers via a set of multiple second connections.
[0022] Embodiments described herein are useful in the context of proxy authentication. For example, a proxy switch according to embodiments herein needs to proxy a user's identity (e.g., a username) to potentially more than one backend filer. Since the proxy switch herein terminates a client's CIFS session, there is a need to create a new TCP connection and negotiate a new CIFS dialect/session to each backend filer on behalf of the client. In certain embodiments, the proxy switch herein establishes two sessions to a backend filer such as one from the NSM (data plane) to the backend filer and one from the ASM (control plane) to the backend filer, and so on. For each backend filer connection, a NegProt_Request and NegProt_Response exchange takes place. That is, the proxy switch herein attempts to establish a respective connection between the proxy and a first backend filer as well as between the proxy and a second backend filer. During each negotiate protocol request, a respective backend filer sends a different challenge value to the proxy switch. To respond to each challenge, the proxy switch needs the password hash key associated with a respective user for which the connection is being established for authentication purposes. This information is available from a domain controller that stores username and corresponding password hash key information.
[0023] One solution for supporting proxy authentication is to create a static database in the proxy switch to store user names and passwords in lieu of using a remote authentication agent as discussed above. In such a case, the proxy switch could use the information to appropriately respond to the backend filers generating the unique challenge values. Such a static database could be configured on the proxy switch using a respective CLI (Command Line Interface). An administrator would manually enter usernames and passwords.
[0024] However, this solution may not scale for larger customers who manage many user accounts. For example, assume that a large customer had to manage 35,000 accounts in their Windows Domain. Using the above-mentioned statically configured NTLM authentication database, the large customer would have to painstakingly enter every user (e.g., 35K users in this example) in their domain into an NTLM authentication database via the CLI. The database would have to be manually updated each time a user updated his/her password. The earlier discussed embodiments of using a remote authentication agent solve this scalability problem because username and password information is automatically and periodically dumped for storage at a respective authentication agent that handles verify and compare operations on behalf of the proxy for authentication purposes. Thus, earlier embodiments eliminate the need for manual updating of information. Also, the authentication agent as discussed above can be located at any location in a respective network even at the proxy switch, although a usual place for the authentication agent is at the domain controller.
[0025] Note that techniques herein are well suited for use in applications in which a proxy initiates authentication of a respective client and establishment of connections for communicating messages. However, it should be noted that configurations herein are not limited to use in such applications and thus configurations herein and deviations thereof are well suited for other applications as well.
[0026] In addition to the techniques discussed above, example embodiments herein also include one or more computerized devices configured to support proxy authentication and related services. According to such embodiments, the computerized device includes a memory system, a processor (e.g., a processing device), and an interconnect. The interconnect supports communications among the processor and the memory system. The memory system is encoded with an application that, when executed on the processor, produces a process to support proxy authentication technology and related services as discussed herein.
[0027] Yet other embodiments of the present application disclosed herein include software programs to perform the method embodiment and operations summarized above and disclosed in detail below under the heading Detailed Description. More particularly, a computer program product (e.g., a computer-readable medium) including computer program logic encoded thereon may be executed on a computerized device to support proxy authentication and related techniques as further explained herein. The computer program logic, when executed on at least one processor with a computing system, causes the processor to perform the operations (e.g., the methods) indicated herein as embodiments of the present application. Such arrangements of the present application are typically provided as software, code and/or other data structures arranged or encoded on a computer readable medium such as an optical medium (e.g., CD-ROM), floppy or hard disk or other a medium such as firmware or microcode in one or more ROM or RAM or PROM chips or as an Application Specific Integrated Circuit (ASIC) or as downloadable software images in one or more modules, shared libraries, etc. The software or firmware or other such configurations can be installed onto a computerized device to cause one or more processors in the computerized device to perform the techniques explained herein.
[0028] One particular embodiment of the present application is directed to a computer program product that includes a computer readable medium having instructions stored thereon to support proxy authentication and related services. The instructions, when carried out by a processor of a respective first router (e.g., a computer device), cause the processor to perform the steps of: i) engaging in a first set of communications to establish a first communication link with a client; ii) engaging in a second set of communications to obtain and/or utilize security information associated with the client from a resource other than the client for purposes of establishing a set of second communication links with multiple servers on behalf of the client; and iii) facilitating a flow of traffic between the first communication link and the set of second communication links to enable the client to access information from the multiple servers. Other embodiments of the present application include software programs to perform any of the method embodiment steps and operations summarized above and disclosed in detail below.
[0029] It is to be understood that the embodiments of the invention can be embodied strictly as a software program, as software and hardware, or as hardware and/or circuitry alone, such as within a data communications device. The features of the invention, as explained herein, may be employed in data communications devices and/or software systems for such devices such as those manufactured by Acopia Networks, Inc. of Lowell, Mass.
Brief Description of the Drawings
[0030] The foregoing and other objects, features and advantages of the invention are apparent from the following description of particular embodiments of the invention, as illustrated in the accompanying drawings in which like reference characters refer to the same parts throughout the different views. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the invention.
[0031] FIG. 1 is a diagram of a respective network environment supporting proxy authentication according to an embodiment herein.
[0032] FIG. 2 is a diagram illustrating downloading of information from a domain controller to an authentication agent according to an embodiment herein.
[0033] FIG. 3 is a block diagram of a respective network environment including multiple proxies according to an embodiment herein.
[0034] FIG. 4 is a block diagram of an example environment on which to execute a proxy and/or an authentication agent according to embodiments herein.
[0035] FIG. 5 is a flowchart illustrating a general technique for supporting proxy authentication according to an embodiment herein.
[0036] FIGS. 6 and 7 combine to form a flowchart illustrating more specific techniques for supporting proxy authentication according to an embodiment herein.
[0037] FIG. 8 is a flowchart illustrating a technique of verifying a challenge response from a client via use of a remote authentication agent according to an embodiment herein.
[0038] FIG. 9 is a flowchart illustrating a technique of generating a challenge response at a respective remote authentication agent on behalf of a client according to an embodiment herein.
Detailed Description
[0039] According to embodiments herein, at least one proxy (e.g., a switch) resides in a respective network environment between one or more clients and multiple servers. One purpose of the proxy (or multiple proxies as the case may be) is to provide the clients a unified view of a distributed file system having respective data stored amongst multiple remote and disparate storage locations over a network. The proxy can manage the distributed file system. Another purpose of the proxy is to enable the clients to retrieve data stored at the multiple servers. As discussed above, according to conventional methods, a client communicates directly with a server that authenticates the client for purposes of enabling the client to access data in the server. Adding the proxy according to embodiments herein requires providing a different authentication procedure to authenticate clients. However, use of the proxy eliminates a need for the client to directly communicate and establish links with multiple servers because the proxy handles such communication on behalf of the client.
[0040] To establish a (first) connection between the proxy and a respective client, the proxy communicates with an authentication agent (residing at a location other than at the client such as in a network domain controller) to verify a challenge response received from the client. Further downstream, when establishing a set of (second) connections between the proxy and the multiple servers, the proxy communicates with the authentication agent to generate challenge responses on behalf of the client. After authenticating and establishing the first connection and set of second connections, the proxy facilitates a flow of data on the first connection and the set of second connections to enable an authenticated client to access information from the multiple servers.
[0041] FIG. 1 is a diagram of a network environment 100 (e.g., a communication system such as a local or wide area network, intranet, internet, etc.) in which computer system 120 includes proxy 140 supporting authentication according to an embodiment herein. Note that computer system 120 can be any type of data communication device that supports communication of data in a network between entities such as clients 110 and storage systems 180.
[0042] As shown, network environment 100 includes client 110-1, client 110-2, . . . , client 110-N (collectively, clients 110), computer system 120, computer system 121, storage system 180-1, storage system 180-2, . . . , storage system 180-J (collectively, storage systems 180), authentication agent 150, and domain controller 160. Computer system 120 executes proxy 140. Computer system 121 executes authentication agent 150 and domain controller 160.
[0043] Connection 115-1 connects clients 110 to proxy 140. Connection 115-2 connects client 110-2 to proxy 140. Connection 115-N connects client 110-N to proxy 140. Connection 117-1 connects proxy 140 to storage systems 180. Connection 117-2 connects proxy 140 to storage system 180-2. Connection 117-J connects proxy 140 to storage system 180-J. Based on such connectivity, client 110-1 can communicate through proxy 140 for purposes of viewing data stored at storage system 180-1 and 180-2. Thus, embodiments herein support point-to-multipoint as well as any other kind of connectivity between one or more clients 110 and one or more servers (e.g., storage system 180).
[0044] Note that the configuration of network environment 100 shown in FIG. 1 is merely an example for purposes of illustrating techniques according to embodiments herein. For example, network environment 100 can include many more different combinations of proxies, connections, clients, storage systems, etc. than the example embodiment shown in FIG. 1 . Authentication agent 150 can operate on domain controller 160. Also, in alternative embodiments, note that authentication agent 150 and domain controller 160 need not operate on the same computer system 121. For example, authentication agent 150 can alternatively reside in other locations such as on computer system 120 alone with proxy 140, servers associated with storage system 180, etc. Thus, according to one embodiment herein, techniques herein include some sort of method to obtain usernames and password hashes from a particular domain controller (and corresponding SAM database) to an agent instance on a non-domain controller computer.
[0045] As mentioned above, embodiments herein are directed to a proxy 140 (e.g., a switch, network manager, etc.) residing in a respective network environment 100 between one or more clients 110 and multiple servers associated with storage systems 180 (e.g., a distributed storage system). As discussed above, one purpose of the proxy 140 is to provide one or more respective clients 110 a unified view of a distributed file system having respective resources (e.g., data, files, etc.) spread amongst disparately located storage systems 180 in network environment 100. In other words, proxy can manage a hierarchical tree of data stored in storage systems 180 and present the hierarchical tree to a client for choosing which data to retrieve from the storage systems 180. Accordingly, each client 110 can connect to the proxy 140 and view data information available from the multiple servers such as backend filers, files systems, etc. Note that the storage systems 180 can enforce access control lists indicating which clients are able to retrieve and view corresponding stored data.
[0046] In one embodiment, the proxy 140 manages the distributed data associated with network environment 100 and enables the clients 110 to access information in storage system 180. As mentioned, each of the storage systems 180 can include a corresponding one or more servers that facilitate access to data stored in storage system 180. That is, a respective client in network environment 100 directly communicates with the proxy 140 via a first authenticated communication connection 115 (a.k.a., a communication link for purposes of this disclosure). The proxy 140 connects to the storage systems 180 via additional authenticated connections 117 (a.k.a., communication links for purposes of this disclosure) on behalf of the client and/or clients to access corresponding data stored in the distributed file system (e.g., backend filers, storage systems, etc.).
[0047] More specifically, the proxy 140 enables the clients 110 to establish connections 115 with the proxy 140. However, according to embodiments herein, the proxy 140 terminates a respective client's connection 115 (e.g., a CIFS TCP connection) and negotiates one or more new connections 117 (e.g., CIFS dialect/session) to each of multiple remote target locations (e.g., storage system 180) on behalf of the respective client. As discussed above, the connections 117 between the proxy 140 and multiple storage systems 180 (e.g., servers) enable the proxy 140 to access corresponding stored data in the multiple storage system 180 on behalf of the clients 110.
[0048] In one embodiment, each of the connections 115 and connections 117 are authenticated and utilized on a per user basis. In other words, according to one embodiment, each of connections 115 and connections 117 is dedicated for use by a particular authenticated client. Consequently, at any given time, proxy 140 can establish many different connections 117 (e.g., one per each respective user) from computer system 120 to a respective server so that multiple clients can send file operations to the same server or storage system 180.
[0049] According to a conventional technique as mentioned above, the clients 110 can establish a connection directly with the storage system 180 without use of proxy 140 via use of the conventional NTLM protocol. Unfortunately, the conventional NTLM protocol does not lend itself for use in a proxy mode in which the proxy 140 has access to information in the domain controller 160. According to embodiments herein, the proxy 140 needs access to the clients' password information so that the proxy 140 is able to establish a connection 115-1 between the client 110-1 and the proxy 140 as well as establish similar types of connections 117 between the proxy 140 and each of multiple storage system 180. Based on techniques herein, proxy 140 is transparent to the user because the client uses the same protocol to connect with the proxy 140 as the client would otherwise use to connect directly with a respective server or storage system 180.
[0050] When the proxy 140 attempts to establish a connection 115-1 between the client 110-1 and the proxy 140, the proxy 140 must be able to verify that the client 110-1 is authentic. This could appropriately be named a “verification” procedure. In this procedure, the proxy 140 must be able to verify that, during a connection negotiation process utilizing an NTLM-like protocol, the client 110-1 provides the appropriate password information for a given username in order to establish a connection 115. The proxy 140 also must be able to act on behalf of the client to establish connections 117 with corresponding storage systems 180.
[0051] In the context of the present example, one way of authenticating the client 110-1 without sending password information over a respective network is to generate a challenge from the proxy 140 to the client 110-1. The challenge includes a numerical value (e.g., an 8-byte value generated by a random number generator) sent to the client 110-1. The random numerical value can be generated by a source such as the proxy 140 or authentication agent 150.
[0052] In response to the challenge, the client 110-1 sends a first encrypted value (e.g., a 24 byte value) of the 8-byte value back to the proxy 140. For example, in one embodiment, the client 110-1 generates a 24-byte challenge response by applying a password hash key (e.g., a 3DES key generated by applying an MD4 algorithm to a plain text password provided by the client 110-1) to the numerical value in the challenge value received from the proxy 140.
[0053] To verify the authentication of the client 110-1 (e.g., a user attempting to mount a file system stored in storage systems 180), the proxy 140 forwards i) the numerical value associated with the challenge, ii) the client's username, and iii) the encrypted value (e.g., the 24-byte challenge response received from the client 110-1 in response to the challenge) to authentication agent 150 over connection 131 (e.g., a secured communication link in which communications are encrypted for security reasons) to the authentication agent 150.
[0054] Authentication agent 150 (e.g., a processing function) resides in the respective network environment 100 at a location other than at client 110-1. For example, according to one embodiment, the authentication agent 150 is an independently operating secured agent residing and/or being executed by the domain controller 160. Among other things, the domain controller 160 manages password information and corresponding usernames associated with persons authorized to use network environment 100. The domain controller 160 oversees which clients 110 in network environment 100 are allowed to establish communication sessions (e.g., connections) and retrieve information from storage systems 180.
[0055] Upon receiving i) the numerical value associated with the challenge, ii) the client's username, and iii) the encrypted value (e.g., the 24-byte challenge response from the client 110-1) from the proxy 140, the authentication agent 150 retrieves a password hash key associated with the client 110-1 based on a previous dumping of password and username information from the domain controller 160 to the authentication agent 150.
[0056] The authentication agent 150 applies the appropriate password hash key to the numerical value (received from the proxy 140) to produce a second encrypted value. The authentication agent 150 performs a compare function to determine whether the 24-byte challenge response (e.g., the first encrypted value) provided by the client 110-1 matches the second encrypted value generated by the authentication agent 150. If there is a match, the authentication agent 150 determines that the client is authentic. Effectively, the authentication agent 150 identifies whether a user (e.g., client 110-1) provides the appropriate password information for establishing connections 115 and 117. After applying the compare function, the authentication agent 150 notifies the proxy 140 whether the client (e.g., the user) has been authenticated (e.g., provides the appropriate response to the challenge) and whether the proxy 140 can allow the connection 115-1 between the proxy 140 and the client 110-1.
[0057] As mentioned, the authentication agent 150 performing the “compare” function can be a secured agent. For example, in such an embodiment, the proxy 140 utilizes encryption techniques to communicate with the authentication agent 150 over connection 131. In a reverse direction, the authentication agent 150 encrypts corresponding messages sent over connection 131 to proxy 140.
[0058] As discussed briefly above, the authentication agent 150 can maintain password information (i.e., password hash key information) associated with users authorized to use network environment 100. FIG. 2 is a diagram more specifically illustrating how domain controller 160 forwards such information to authentication agent 150 according to an embodiment herein. For example, using a tool such as pwdump.exe, authentication agent 150 periodically or occasionally (e.g., every few minutes or so) receives a memory dump 225 from the domain controller 160. The memory dump 225 can include a text string of usernames and corresponding password hash key information (e.g., MD4 password hash key information). The authentication agent 150 parses the text string and stores the username and password information in storage 230 (e.g., memory, disk, etc.). Thus, for purposes of verifying authentication of a user such as client 110-1, the authentication agent 150 can retrieve a respective password hash key from memory 230 associated with the client 110-1 and initiate the steps (e.g., generation of an encrypted value and comparison) as discussed above to verify the challenge response provided to the proxy 140 by the client 110-1.
[0059] Note that authentication agent 150 herein is not limited to communicating with only a single proxy. For example, as shown, the authentication agent 150 can execute a separate processing thread for each of multiple proxies 140 operating in network environment 100. In the context of such an example, authentication agent 150 executes a first thread to manage communications over connection 130-A to proxy 140-A; authentication agent 150 executes a second thread to manage communications over connection 130-B to proxy 140-B, and so on. Thus, authentication agent 150 initiates execution of individual processing threads for each proxy 140. Accordingly, authentication agent 150 can more quickly authenticate connections on behalf of one or more respective proxies 140. As discussed above, messages sent over the connections 130 (e.g., connection 130-A, connection 130-B, etc.) can be encrypted for security reasons.
[0060] Referring again to FIG. 1 , in addition to or in lieu of the verification process discussed above for authenticating connections 115 between clients 110 and the proxy 140, the authentication agent 150 can act on behalf of the respective clients 110 and establish individual connection sessions between the proxy 140 and each of multiple servers or storage systems 180. This can appropriately be called a “create challenge response” procedure. According to this embodiment and procedure, to establish a connection 117 with a given one of the multiple servers or storage systems 180, the proxy 140 generates and forwards a message (e.g., an NTLM negotiate protocol request) to a server or storage system 180 for purposes of requesting and establishing a connection 117 on behalf of a client. In response to receiving an NTLM negotiate protocol request (or NTLM-like negotiate protocol request) from the proxy 140, the server or storage system 180 replies to the proxy 140 with an authentication challenge (e.g., a negotiate protocol response) including a random 8-byte numerical value generated by the server or storage system 180.
[0061] The proxy 140 can respond to the challenge from the server or storage system 180 without having to communicate again with the client 110. For example, according to one embodiment, the proxy communicates the 8-byte challenge received from the server or storage system 180 as well as a username associated with the client 110-1 to the authentication agent 150. As discussed above, the authentication agent 150 stores username and corresponding password information. In this example, the proxy 140 need only provide the authentication agent 150 the username of the client 110-1 to obtain password information.
[0062] Based on stored information, the authentication agent 150 obtains the respective password hash key associated with the client 110-1 (e.g., username) for which the connection is being established and applies the password hash key to the 8-byte numerical value received from the proxy 140 to produce an encrypted value. In a particular embodiment, the encrypted value is 24 bytes in length if the authentication agent 150 was able to successfully generate a challenge response and 4 bytes in length indicating a respective error code if the authentication agent 150 is unable to generate a proper challenge response.
[0063] The authentication agent 150 forwards the encrypted value (e.g., challenge response) to the proxy 140. The proxy 140, in turn, replies to the challenge received from the server or storage system 180 by forwarding the encrypted challenge response value (as generated by the authentication agent 150) to the server or storage system 180. The server or storage system 180, in turn, communicates with the domain controller 160 (similar to the conventional case as if the client 110-1 sent the server the negotiate protocol request and the server uses the net logon RPC protocol to communication with the domain controller) to verify that the proxy 140, acting on behalf of the client 110-1, is able establish the connection 117-1 with the backend server or, storage system 180-1. In other words, a server or storage system 180 receiving the challenge response from the proxy 140 verifies the received challenge response by forwarding the encrypted value to the domain controller 160. The domain controller 160 verifies whether the encrypted value forwarded by the server or storage system 180-1 matches the encrypted value that the proxy 140 generated in response to the challenge. If there is a match (e.g., success), the proxy 140 and corresponding client 110-1 is authenticated and the server or storage system 180-1 is allowed to notify (e.g., via an NTLM session setup response) proxy 140 that the connection 117-1 can be established. If there is not a match (e.g., a failure), the server or storage system 180 notifies the proxy 140 that the corresponding client 110-1 has not been authenticated for purposes of establishing connection 117.
[0064] The proxy 140 can repeat this above procedure for different challenges on each link to the multiple servers or storage systems 180 in order to establish and authenticate connections 117 with each of the multiple servers or storage system 180. Accordingly, a client 110 can connect to the proxy 140 via a respective first connection 115 and, on behalf of the client 110, the proxy 140 connects to the multiple servers or storage system 180 via a set of multiple second connections 117.
[0065] Upon successfully establishing a point-to-multipoint communication topology including connection 115-1, connection 117-1, and connection 117-2, the client 110-1 is cleared to send messages to through proxy 140 to target destinations such as storage system 180-1 and storage system 180-2.
[0066] FIG. 3 is a block diagram of a network environment 300 including multiple proxies 140 (e.g., proxy 140-A, proxy 140-B, . . . ) according to an embodiment herein. As shown, client 110-1 can communicate through one or more paths including multiple proxies 140 to backend servers or storage systems 180. For example, proxy 140-A authenticates client 110-1 as discussed above in order to establish connection 315-1. Proxy 140-B authenticates client 110-1 as discussed above in order to establish connection 317-1, connection 317-2, connection 317-M, and 317-Z. For authenticating and establishing connection 316-1, proxy 140-B initiates the “create challenge response” procedure discussed above while proxy 140-B initiates the “verification” procedure as discussed above. Note that different switches (e.g., proxies 140 running on the same or different computer platform) may establish a respective communication session with the same agent server. In addition, a single proxy 140 can reference (e.g., establish a connection to) multiple different agent instances present in network environment 100. Typically, in a multi-domain windows environment, there is at least one agent instance per domain. This allows authentication to support multi-domain type environments.
[0067] FIG. 4 is a block diagram illustrating an example architecture of computer system 120 or, more specifically, a data communication device for implementing authentication procedures according to embodiments herein. The authentication agent 150 can operate on a similar type of platform (e.g., computer system 120) executing agent applications, domain controller applications, etc.
[0068] Computer system 120 is a computerized device such as a personal computer, workstation, portable computing device, console, network terminal, processing device, router, server, etc. As shown, computer system 120 of the present example includes an interconnect 111 that couples a memory system 112, a processor 113, I/O interface 114, and a communications interface 415. I/O interface 114 potentially provides connectivity to optional peripheral devices such as a keyboard, mouse, display screens, etc. Communications interface 115 enables computer system 120 to establish respective connections 131 to authentication agent 150 for purposes of authenticating connections 115 between clients 110 and computer system 120 as well as connections 117 between computer system 120 and servers 180.
[0069] As shown, memory system 112 is encoded with proxy application 140-1 supporting authentication procedures as discussed above and as further discussed below. Proxy application 140-1 may be embodied as software code such as data and/or logic instructions (e.g., code stored in the memory or on another computer readable medium such as a disk) that supports processing functionality according to different embodiments described herein.
[0070] During operation, processor 113 accesses memory system 112 via the interconnect 111 in order to launch, run, execute, interpret or otherwise perform the logic instructions of the proxy application 140-1. Execution of the proxy application 140-1 produces processing functionality in proxy process 140-2. In other words, the proxy process 140-2 represents one or more portions of the proxy application 140-1 (or the entire application) performing within or upon the processor 113 in computer system 120. It should be noted that, in addition to proxy process 140-2, embodiments herein include the proxy application 140-1 itself (i.e., the un-executed or non-performing logic instructions and/or data). The proxy application 140-1 may be stored on a computer readable medium such as a floppy disk, hard disk or in an optical medium. The proxy application 140-1 may also be stored in a memory type system such as in firmware, read only memory (ROM), or, as in this example, as executable code within the memory system 112 (e.g., within Random Access Memory or RAM). In addition to these embodiments, it should also be noted that other embodiments herein include the execution of proxy application 140-1 in processor 113 as proxy process 140-2. Thus, those skilled in the art will understand that the computer system 120 (e.g., a data communication device or computer system) can include other processes and/or software and hardware components, such as an operating system that controls allocation and use of hardware resources.
[0071] Functionality supported by computer system 120 and, more particularly, proxy 140 will now be discussed via the flowcharts shown in FIG. 5-9 . For purposes of this discussion, computer system 120, proxy 140, and/or authentication agent 150 generally carry out steps in the flowcharts. However, note that this functionality can be extended to operate on other entities in network environment 100.
[0072] Note that the following discussion of flowcharts and corresponding steps may overlap with respect to concepts and techniques discussed above for FIGS. 1 through 4 . Also, note that the steps in the below flowcharts need not always be executed in the order shown.
[0073] FIG. 5 is a flowchart 500 illustrating a technique of authenticating communication links (e.g., connections 115 and 117) via a proxy 140 and corresponding authentication agent 150 according to embodiments herein. As discussed, one purpose of utilizing proxy 140 is to manage distributed data at a central location and facilitate a corresponding flow of data traffic through computer system 120 in lieu of requiring that each respective client manage data flows with the backend servers. Authentication agent 150 enables the proxy 140 to authenticate clients and ensure that connections are properly established on behalf of the clients 110 for purposes of accessing backend servers through the proxy 140.
[0074] In step 510, proxy 140 engages in a first set of communications to establish a first type (e.g., a client-proxy type connection) of communication link (i.e., connection 115) with a respective client 110-1. The first type of communication link connects the client 110-1 to the proxy 140.
[0075] In step 520, proxy 140 engages in a second set of communications to: i) obtain security information (e.g., password hash key information) associated with the client 110-1 from a resource (e.g., authentication agent 150) other than the client 110-1, and ii) utilize the security information on behalf of the client 110-1 to establish a set of second type (e.g., a proxy-server type of connection) of communication links with the multiple servers (e.g., storage systems 180). In other words, the proxy 140 engages the authentication agent 150 to obtain and utilize a password hash key associated with the client 110-1 for purposes of establishing the connection 117-1 between the proxy 140 and a respective server. As discussed above, one use of the password hash key is to generate a challenge response for the proxy 140. Although embodiments can vary, according to a particular embodiment herein, the authentication agent 150 does not send the password hash over connection 131 between the authentication agent 150 and the proxy 140 for security purposes. If the password hash were passed over connection 131, the security model according to embodiments herein, may become questionable. However, note that in certain applications, sending the password hash value between the authentication agent and the proxy 140 may be acceptable.
[0076] In step 530, proxy 140 facilitates a flow of data traffic between the first communication link (e.g., connection 115-1) and the set of second communication links (e.g., connection 117-1 and connection 117-2) to enable the client 110-1 to access information from multiple servers.
[0077] FIGS. 6 and 7 combine to form a flowchart 600 (e.g., flowchart 600-1 and flow chart 600-2) illustrating more specific techniques for carrying out authentication techniques according to embodiments herein.
[0078] In step 610 of flowchart 600-1 of FIG. 6 , proxy 140 engages in a first set of communications to establish a first communication link (e.g., connection 115-1) with client 110-1.
[0079] In sub-step 615 of step 610, the proxy 140 forwards a challenge to the client 110-1 for purposes of authenticating that the client is authorized to establish the first communication link (e.g., connection 115-1). As discussed above, the challenge is a request generated by a proxy 140 for the client 110-1 to produce an encrypted value (e.g., challenge response) based on a proper password associated with the client. In one embodiment, the challenge includes an 8-byte value generated by the authentication agent 150 or proxy 140.
[0080] In sub-step 615 of step 610, the proxy 140 receives a challenge response from the client 110-1 and forwards the challenge response to an authentication agent 150 that stores security information (e.g., username and password information) retrieved form a domain controller 160 in order to verify that a respective message received from the client 110-1 includes an encrypted value generated by the client 110-1 indicating that the client 110-1 is authentic. In other words, the authentication agent checks whether a user at client 110-1 provides the appropriate response for a respective username.
[0081] In step 625, proxy 140 engages in a second set of communications to utilize security information (e.g., password hash key information) associated with the client 110-1 from a resource (e.g., authentication agent 150) other than the client 110-1 for purposes of establishing a set of second communication links (e.g., connections 117) with multiple servers or storage systems 180 on behalf of the client 110-1.
[0082] In sub-step 630 of step 625, for each server (or storage system 180) of the multiple servers (of storage systems 180), the proxy 140 communicates with the authentication agent 150 to: i) generate a message and corresponding encrypted value (e.g., a challenge response) based on use of the security information and a respective data value (e.g., 8-byte challenge value) received from a respective server. The proxy 140 receives and forwards the corresponding encrypted value (e.g., challenge response) received from the authentication agent 150 to the respective server for purposes of establishing and authenticating a respective second communication link (e.g., connection 117) with the respective server or storage system 180 on behalf of the client 110-1.
[0083] In sub-step 635 of step 625, the authentication agent 150 generates different encrypted values (e.g., challenge responses) depending on challenge values received from different servers. The proxy 140 forwards the different challenge responses generated by the authentication agent 150 to the respective servers or storage systems 180.
[0084] In step 710 of flowchart 600-2 of FIG. 7 , proxy 140 facilitates a flow of data traffic amongst the first communication link (e.g., connection 115-1) and the set of second communication links (e.g., connections 117-1 and 117-2) to enable the client 110-1 to access information from the multiple servers or storage systems 180.
[0085] In sub-step 715 of step 710, the proxy 140 receives an access request from the client 110-1 over the first communication link (e.g., connection 115-1).
[0086] In sub-step 720 of step 710, in response to receiving the access request, the proxy 140 communicates with the multiple servers or storage systems 180 over one or more of the second communication links (e.g., connections 117-1 and 117-2) to retrieve requested information associated with the access request.
[0087] In sub-step 725 of step 710, the proxy 140 forwards the requested information retrieved from the multiple servers or storage system 180 to the client 110-1 over the first communication link (e.g., connection 115-1).
[0088] In sub-step 730 of step 710, the servers or storage systems 180 utilize one or more respective access controls list to enable the client (or clients) to retrieve information stored in the multiple servers or storage systems 180. The access control lists can be used to prevent other clients from accessing at least some of the information stored in the multiple servers or storage systems 180.
[0089] FIG. 8 is a flowchart 800 illustrating more specific techniques for verifying authentication of a client at proxy 140 according to an embodiment herein.
[0090] In step 810, the proxy 140 receives a request to communicate from the client 110-1.
[0091] In step 815, the proxy 140 generates a numerical value (e.g., an 8-byte challenge value). Note also that authentication agent 150 can alternatively generate an 8-byte challenge value to the proxy 140 that in turn forwards the challenge value to the client 110-1.
[0092] In step 820, the proxy 140 forwards the numerical value (e.g., challenge value) to the client 110-1.
[0093] In step 825, the proxy 140 receives a username and a first encrypted value (e.g., a challenge response from the client 110-1) which is generated based on the client 110-1 applying a password hash function or key to the numerical challenge value.
[0094] In step 830, the proxy 140 forwards the username associated with the client 110-1, the numerical value (e.g., challenge value), and the first encrypted value (e.g., the challenge response received from the client 110-1) over a network connection 131 to an authentication agent 150 that: i) generates a second encrypted value (e.g., an expected challenge response) based on the numerical value and security information such as a respective password hash function associated with the username of the client 110-1, and ii) compares the first encrypted value (e.g., actual challenge response received from the client 110-1) and the second encrypted value (e.g., an expected challenge response that should have been received from the client 110-1) to authenticate the client 110-1 and corresponding communications with the client 110-1 over the first communication link (e.g., connection 115-1).
[0095] FIG. 9 is a flowchart 900 illustrating more specific techniques for creating challenge responses on behalf of a client according to an embodiment herein. As discussed above, the following routine can be performed for each of multiple servers or storage systems 180.
[0096] In step 910, the proxy 140 originates a request to a respective server or storage system 180 for establishing a respective second type of communication link such as a connection 117.
[0097] In step 915, the proxy 140 receives a numerical value associated with a challenge from the respective server or storage system 180. The challenge from the server or storage system 180 is received in response to the proxy 140 sending a request session message to the respective server of storage system 180.
[0098] In step 920, the proxy 140 forwards the numerical value (e.g., randomly generated 8-byte unique value) associated with the challenge as well as username information associated with the client over connection 131 of network environment 100 to authentication agent 150 that: i) obtains a password hash function associated with the username, and ii) applies the password hash function to the numerical value to generate an encrypted value (e.g., challenge response).
[0099] In step 925, the proxy 140 receives the encrypted value (e.g., challenge response) from the authentication agent 150 over connection 131. Accordingly, authentication agent 150 generates the response on behalf of the client.
[0100] In step 935, the proxy 140 forwards the encrypted value (e.g., challenge response) to the respective server or storage system 180 as a response to the challenge from the respective server or storage system 180.
[0101] In step 935, the proxy 140 receives confirmation from the respective server or storage system 180 indicating whether the respective second communication link (e.g., connection 117) and/or corresponding client has been authenticated for conveying futures communications on behalf of the client.
[0102] Note again that techniques herein are well suited for use in applications in which a proxy and authentication agent 150 handle authentication on behalf of a client to support point-to-multipoint type of communications in a respective network environment. For example, in the context of HTTP web services, an authenticated client can communicate with multiple servers (e.g., storage systems) through the proxy. Although the embodiments herein, at times, indicate a specific use and configuration, it should again be noted that configurations herein are not limited to use in such applications and thus configurations herein and deviations thereof are well suited for other applications as well. Thus, while this invention has been particularly shown and described with references to preferred embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the invention as defined by the appended claims. For example, the above techniques are not limited to 2-tiers. It is possible, for example, to deploy several tiers of proxies to produce a client-proxy1-proxy2-server connection. Also, note that each tier can include several proxy devices.
Claims
What is claimed is:
1. A method for authenticating communications in a respective network environment, the method comprising:
engaging in a first set of communications to establish a first communication link with a client;
engaging in a second set of communications by utilizing security information associated with the client obtained from a resource independent from the client for purposes of establishing a set of second communication links with multiple servers on behalf of the client; and
facilitating a flow of traffic between the first communication link and the set of second communication links to enable the client to access information from the multiple servers;
wherein utilizing security information associated with the client from the resource other than the client includes on behalf of the client, communicating with an agent over a secure network connection to obtain the security information managed by a domain controller associated with the respective network environment and wherein the resource further communicates with the domain controller to obtain password based information for the client authorized to communicate with the multiple servers, wherein the password based information is used by one or more of the multiple servers to authorize the client.
2. A method as in claim 1, wherein engaging in the first set of communications and the second set of communications includes propagating an identity of the client to the multiple servers via an authentication process used to establish the second set of communication links with the multiple servers on behalf of the client.
3. A method as in claim 1, wherein engaging in the first set of communications and the second set of communications occurs in response to the client attempting to mount a respective file system supported by the multiple servers.
4. A method as in claim 1, wherein engaging in the first set of communications includes verifying that a respective message received from the client includes an encrypted value generated by the client indicating that the client is authentic and is able to establish a connection with the multiple servers.
5. A method as in claim 4, wherein engaging in the second set of communications includes:
for each server of the multiple servers: i) generating a message and corresponding encrypted value on behalf of the client based on use of the security information and a respective data value received from a respective server, and ii) forwarding the corresponding encrypted value to the respective server for purposes of establishing and authenticating a respective second communication link with the respective server on behalf of the client.
6. A method as in claim 5 further comprising:
generating different encrypted values for each of the multiple servers based on different respective data values received from the multiple servers.
7. A method as in claim 1, wherein engaging in the second set of communications includes:
for each respective server of the multiple servers: i) generating a message and corresponding encrypted value on behalf of the client based on use of the security information and a corresponding data value received from a respective server, and ii) forwarding the corresponding encrypted value to the respective server for purposes of authenticating a respective second communication link with the respective server on behalf of the client.
8. A method as in claim 1, wherein engaging in the first set of communications includes:
receiving a username associated with the client;
generating a numerical value;
forwarding the numerical value to the client;
receiving a first encrypted value in response to the client applying a password hash function to the numerical value;
on behalf of the client, forwarding the username associated with the client, the numerical value, and the first encrypted value over a network to an authentication agent that: i) generates a second encrypted value based on the numerical value and the security information, the security information being a respective password hash function associated with the username of the client, and ii) compares the first encrypted value and the second encrypted value to authenticate the client.
9. A method as in claim 1, wherein engaging in a second set of communications includes:
for each respective server of the multiple servers:
originating a request to a respective server of the multiple servers for establishing a respective second communication link;
receiving a numerical value associated with a challenge from the respective server;
forwarding the numerical value associated with the challenge as well as username information associated with the client over a network to an authentication agent that: i) obtains a password hash function associated with the username, ii) applies the password hash function to the numerical value to generate an encrypted value;
receiving the encrypted value from the authentication agent over the network;
forwarding the encrypted value to the respective server in response to the challenge from the respective server; and
receiving confirmation from the respective server indicating whether the respective second communication link has been authenticated for conveying communications on behalf of the client.
10. A method as in claim 1, wherein engaging in the first set of communications includes initiating and forwarding a challenge to the client for purposes of authenticating that the client is authorized to establish the first communication link, the challenge being a request generated by a proxy on behalf of the multiple servers for the client to produce an encrypted value based on a proper password associated with the client.
11. A method as in claim 1, wherein engaging in the second set of communications includes receiving a unique challenge value from each of the multiple servers and replying to multiple unique challenge values from the multiple servers with different respective responses on behalf of the client for purposes of authenticating that a respective proxy acting on behalf of the client is authorized to establish the second communication links with the multiple servers.
12. A method as in claim 1 further comprising:
enabling the agent to obtain a memory dump from the domain controller associated with the respective network environment, the memory dump including username information and corresponding password encryption key information for each of multiple clients authorized to communicate with the multiple servers.
13. A method as in claim 12 further comprising:
initiating the agent to authenticate the client based on respective username information associated with the client retrieved from the memory dump and applying a respective password encryption key associated with the respective username information to a numerical value, the numerical value also provided to the client as part of an authentication challenge.
14. A method as in claim 1 further comprising:
after establishing the first communication link and the multiple second communication links, utilizing at least one access control list associated with the multiple servers to i) enable the client to retrieve at least some of the information stored in the multiple servers and ii) prevent other clients from accessing at least some of the information stored in the multiple servers.
15. A method as in claim 1, wherein facilitating the flow of traffic includes:
managing how information is stored in the multiple servers; and
after establishing the first communication link and the set of second communication links, providing the client a unified view of accessible information stored in the multiple servers.
16. A method as in claim 1, wherein facilitating the flow of traffic between the first communication link and the set of second communication links includes:
receiving an access request from the client over the first communication link;
in response to receiving the access request, communicating with the multiple servers over the second communication links to retrieve requested information associated with the access request; and
forwarding the requested information retrieved from the multiple servers to the client over the first communication link.
17. A computer system that performs authentication procedures on behalf of a client for purposes of accessing multiple servers, the computer system comprising:
a processor;
a memory unit that stores instructions associated with an application executed by the processor; and
an interconnect coupling the processor and the memory unit, enabling the processor to execute the application and perform operations comprising:
engaging in a first set of communications to establish a first communication link with the client;
engaging in a second set of communications by utilizing security information associated with the client obtained from a resource independent from the client for purposes of establishing a set of second communication links with the multiple servers on behalf of the client; and
facilitating a flow of traffic between the first communication link and the set of second communication links to enable the client to access information from the multiple servers;
wherein utilizing security information associated with the client from the resource other than the client includes on behalf of the client, communicating with an agent over a secure network connection to obtain the security information managed by a domain controller associated with the respective network environment and wherein the resource further communicates with the domain controller to obtain password based information for the client authorized to communicate with the multiple servers, wherein the password based information is used by one or more of the multiple servers to authorize the client.
18. A computer system as in claim 17, wherein engaging in the first set of communications includes verifying that a respective message received from the client includes an encrypted value generated by the client indicating that the client is authentic and is able to establish a connection with the multiple servers.
19. A computer system as in claim 18, wherein engaging in the second set of communications includes:
for each server of the multiple servers: i) generating a message and corresponding encrypted value on behalf of the client based on use of the security information and a respective data value received from a respective server, and ii) forwarding the corresponding encrypted value to the respective server for purposes of establishing and authenticating a respective second communication link with the respective server on behalf of the client.
20. A computer system as in claim 19 that supports further operations of:
generating different encrypted values for each of the multiple servers based on different respective data values received from the multiple servers.
21. A computer system as in claim 17, wherein engaging in the second set of communications includes:
for each respective server of the multiple servers: i) generating a message and corresponding encrypted value on behalf of the client based on use of the security information and a corresponding data value received from a respective server, and ii) forwarding the corresponding encrypted value to the respective server for purposes of authenticating a respective second communication link with the respective server on behalf of the client.
22. A computer system as in claim 17, wherein engaging in the first set of communications includes initiating and forwarding a challenge to the client for purposes of authenticating that the client is authorized to establish the first communication link, the challenge being a request generated by a proxy on behalf of the multiple servers for the client to produce an encrypted value based on a proper password associated with the client.
23. A computer system as in claim 17, wherein engaging in the second set of communications includes receiving a unique challenge value from each of the multiple servers and replying to multiple unique challenge values from the multiple servers with different respective responses on behalf of the client for purposes of authenticating that a respective proxy acting on behalf of the client is authorized to establish the second communication links with the multiple servers.
24. A computer system as in claim 17, wherein facilitating the flow of traffic includes: i) managing how information is stored in the multiple servers, and ii) after establishing the first communication link and the set of second communication links, providing the client a unified view of accessible information stored in the multiple servers, the method further comprising:
enabling the agent to obtain a memory dump from the domain controller associated with the respective network environment, the memory dump including username information and corresponding password encryption key information for each of multiple clients authorized to communicate with the multiple servers; and
initiating the agent to authenticate the client based on respective username information associated with the client retrieved from the memory dump and applying a respective password encryption key associated with the respective username information to a numerical value, the numerical value also provided to the client as part of an authentication challenge.
25. A network system comprising:
a client;
a first set of multiple servers;
a first proxy device disposed in a respective network environment between the client and the first set of multiple servers, the first proxy device supporting operations of:
engaging in a first set of communications to establish a first communication link with a client;
engaging in a second set of communications by utilizing security information associated with the client obtained from a resource independent from the client for purposes of establishing a set of second communication links with multiple servers on behalf of the client; and
facilitating a flow of traffic between the first communication link and the set of second communication links to enable the client to access information from the multiple servers;
wherein utilizing security information associated with the client from the resource other than the client includes on behalf of the client, communicating with an agent over a secure network connection to obtain the security information managed by a domain controller associated with the respective network environment and wherein the resource further communicates with a domain controller to obtain password based information for the client authorized to communicate with the multiple servers, wherein the password based information is used by one or more of the multiple servers to authorize the client.
26. A network system as in claim 25, wherein the client, the multiple servers, and the first proxy device rely on at least partial use of the NTLM (Windows NT LAN Manager) protocol to authenticate the first communication link and the set of second communication links.
27. A network system as in claim 25 further comprising:
a second proxy device;
wherein the first proxy establishes at least one communication link with the second proxy device, the second proxy device supporting operations of:
engaging in a third set of communications to: i) obtain security information associated with the client from the resource independent from the client, and ii) utilize the security information on behalf of the client to authenticate a set of third communication links between the second proxy device and a second set of multiple servers such that the client is able to access data from the second set of multiple servers via a path including the first communication link, the at least one communication link, and the set of third communication links from the second proxy device to the second set of multiple servers.
28. A non-transitory computer program product including a computer-readable medium having instructions stored thereon for processing data information, such that the instructions, when carried out by a processing device, enable the processing device to perform the steps comprising:
engaging in a first set of communications to authenticate and establish a first communication link associated with a client;
engaging in a second set of communications by obtaining and utilizing security information on behalf of the client obtained from a resource independent from the client to authenticate and establish a set of second communication links with multiple servers; and
facilitating a flow of traffic between the first communication link and the set of second communication links to enable the client to access information from the multiple servers;
wherein utilizing security information associated with the client from the resource other than the client includes on behalf of the client, communicating with an agent over a secure network connection to obtain the security information managed by a domain controller associated with the respective network environment and the resource further communicates with a domain controller to obtain password based information for the client authorized to communicate with the multiple servers, wherein the password based information is used by one or more of the multiple servers to authorize the client.
Patent Citations (158)
| Patent | Date | Inventor | Cited By |
|---|---|---|---|
| US4993030(A) | 1991-02-01 | Krakauer et al. | Applicant |
| US5218695(A) | 1993-06-01 | Noveck et al. | Applicant |
| US5473362(A) | 1995-12-01 | Fitzgerald et al. | Applicant |
| US5537585(A) | 1996-07-01 | Blickenstaff et al. | Applicant |
| US5548724(A) | 1996-08-01 | Akizawa et al. | Applicant |
| US5550965(A) | 1996-08-01 | Gabbe et al. | Applicant |
| US5583995(A) | 1996-12-01 | Gardner et al. | Applicant |
| US5586260(A) | 1996-12-01 | Hu | Examiner |
| US5590320(A) | 1996-12-01 | Maxey | Applicant |
| US5649194(A) | 1997-07-01 | Miller et al. | Applicant |
| US5649200(A) | 1997-07-01 | Leblang et al. | Applicant |
| US5692180(A) | 1997-11-01 | Lee | Applicant |
| US5721779(A) | 1998-02-01 | Funk | Examiner |
| US5724512(A) | 1998-03-01 | Winterbottom | Applicant |
| US5806061(A) | 1998-09-01 | Chaudhuri et al. | Applicant |
| US5832496(A) | 1998-11-01 | Anand et al. | Applicant |
| US5832522(A) | 1998-11-01 | Blickenstaff et al. | Applicant |
| US5838970(A) | 1998-11-01 | Thomas | Applicant |
| US5862325(A) | 1999-01-01 | Reed et al. | Applicant |
| US5893086(A) | 1999-04-01 | Schmuck et al. | Applicant |
| US5897638(A) | 1999-04-01 | Lasser et al. | Applicant |
| US5905990(A) | 1999-05-01 | Inglett | Applicant |
| US5917998(A) | 1999-06-01 | Cabrera et al. | Applicant |
| US5920873(A) | 1999-07-01 | Van Huben et al. | Applicant |
| US5999664(A) | 1999-12-01 | Mahoney et al. | Applicant |
| US6012083(A) | 2000-01-01 | Savitsky et al. | Applicant |
| US6029168(A) | 2000-02-01 | Frey | Applicant |
| US6044367(A) | 2000-03-01 | Wolff | Applicant |
| US6047129(A) | 2000-04-01 | Frye | Applicant |
| US6078929(A) | 2000-06-01 | Rao | Applicant |
| US6085234(A) | 2000-07-01 | Pitts et al. | Applicant |
| US6128627(A) | 2000-10-01 | Mattis et al. | Applicant |
| US6128717(A) | 2000-10-01 | Harrison et al. | Applicant |
| US6161145(A) | 2000-12-01 | Bainbridge et al. | Applicant |
| US6161185(A) | 2000-12-01 | Guthrie et al. | Examiner |
| US6181336(B1) | 2001-01-01 | Chiu et al. | Applicant |
| US6223206(B1) | 2001-04-01 | Dan et al. | Applicant |
| US6233648(B1) | 2001-05-01 | Tomita | Applicant |
| US6256031(B1) | 2001-07-01 | Meijer et al. | Applicant |
| US6289345(B1) | 2001-09-01 | Yasue | Applicant |
| US6308162(B1) | 2001-10-01 | Ouimet et al. | Applicant |
| US6324581(B1) | 2001-11-01 | Xu et al. | Applicant |
| US6339785(B1) | 2002-01-01 | Feigenbaum | Applicant |
| US6349343(B1) | 2002-02-01 | Foody et al. | Applicant |
| US6389433(B1) | 2002-05-01 | Bolosky et al. | Applicant |
| US6393581(B1) | 2002-05-01 | Friedman et al. | Applicant |
| US6397246(B1) | 2002-05-01 | Wolfe | Applicant |
| US6438595(B1) | 2002-08-01 | Blumenau et al. | Applicant |
| US6477544(B1) | 2002-11-01 | Bolosky et al. | Applicant |
| US6493804(B1) | 2002-12-01 | Soltis et al. | Applicant |
| US6516350(B1) | 2003-02-01 | Lumelsky et al. | Applicant |
| US6516351(B2) | 2003-02-01 | Borr | Applicant |
| US6553352(B2) | 2003-04-01 | Delurgio et al. | Applicant |
| US6556997(B1) | 2003-04-01 | Levy | Applicant |
| US6556998(B1) | 2003-04-01 | Mukherjee et al. | Applicant |
| US6601101(B1) | 2003-07-01 | Lee et al. | Applicant |
| US6612490(B1) | 2003-09-01 | Herrendoerfer et al. | Applicant |
| US6721794(B2) | 2004-04-01 | Taylor et al. | Applicant |
| US6742035(B1) | 2004-05-01 | Zayas et al. | Applicant |
| US6757706(B1) | 2004-06-01 | Dong et al. | Applicant |
| US6775679(B2) | 2004-08-01 | Gupta | Applicant |
| US6782450(B2) | 2004-08-01 | Arnott et al. | Applicant |
| US6801960(B1) | 2004-10-01 | Ericson et al. | Applicant |
| US6826613(B1) | 2004-11-01 | Wang et al. | Applicant |
| US6839761(B2) | 2005-01-01 | Kadyk et al. | Examiner |
| US6847959(B1) | 2005-01-01 | Arrouye et al. | Applicant |
| US6847970(B2) | 2005-01-01 | Keller et al. | Applicant |
| US6889249(B2) | 2005-05-01 | Miloushev et al. | Applicant |
| US6922688(B1) | 2005-07-01 | Frey, Jr. | Applicant |
| US6934706(B1) | 2005-08-01 | Mancuso et al. | Examiner |
| US6938059(B2) | 2005-08-01 | Tamer et al. | Applicant |
| US6959373(B2) | 2005-10-01 | Testardi | Applicant |
| US6973549(B1) | 2005-12-01 | Testardi | Applicant |
| US6985936(B2) | 2006-01-01 | Agarwalla et al. | Applicant |
| US6985956(B2) | 2006-01-01 | Luke et al. | Applicant |
| US6986015(B2) | 2006-01-01 | Testardi | Applicant |
| US6990547(B2) | 2006-01-01 | Ulrich et al. | Applicant |
| US6990667(B2) | 2006-01-01 | Ulrich et al. | Applicant |
| US6996841(B2) | 2006-02-01 | Kadyk et al. | Examiner |
| US7013379(B1) | 2006-03-01 | Testardi | Applicant |
| US7051112(B2) | 2006-05-01 | Dawson | Applicant |
| US7072917(B2) | 2006-07-01 | Wong et al. | Applicant |
| US7113962(B1) | 2006-09-01 | Kee et al. | Applicant |
| US7127556(B2) | 2006-10-01 | Blumenau et al. | Applicant |
| US7146524(B2) | 2006-12-01 | Patel et al. | Applicant |
| US7155466(B2) | 2006-12-01 | Rodriguez et al. | Applicant |
| US7173929(B1) | 2007-02-01 | Testardi | Applicant |
| US7194579(B2) | 2007-03-01 | Robinson et al. | Applicant |
| US7280536(B2) | 2007-10-01 | Testardi | Applicant |
| US7284150(B2) | 2007-10-01 | Ma et al. | Applicant |
| US7293099(B1) | 2007-11-01 | Kalajan | Examiner |
| US7293133(B1) | 2007-11-01 | Colgrove et al. | Applicant |
| US7383288(B2) | 2008-06-01 | Miloushev et al. | Applicant |
| US7406484(B1) | 2008-07-01 | Srinivasan et al. | Applicant |
| US7475241(B2) | 2009-01-01 | Patel et al. | Examiner |
| US7509322(B2) | 2009-03-01 | Miloushev et al. | Applicant |
| US7512673(B2) | 2009-03-01 | Miloushev et al. | Applicant |
| US7519813(B1) | 2009-04-01 | Cox et al. | Examiner |
| US7562110(B2) | 2009-07-01 | Miloushev et al. | Applicant |
| US7624109(B2) | 2009-11-01 | Testardi | Applicant |
| US2001/0047293(A1) | 2001-11-01 | Waller et al. | Applicant |
| US2001/0051955(A1) | 2001-12-01 | Wong | Applicant |
| US2002/0035537(A1) | 2002-03-01 | Waller et al. | Applicant |
| US2002/0120763(A1) | 2002-08-01 | Miloushev et al. | Applicant |
| US2002/0133330(A1) | 2002-09-01 | Loisey et al. | Examiner |
| US2002/0133491(A1) | 2002-09-01 | Sim et al. | Applicant |
| US2002/0138502(A1) | 2002-09-01 | Gupta | Applicant |
| US2002/0147630(A1) | 2002-10-01 | Rose et al. | Applicant |
| US2002/0150253(A1) | 2002-10-01 | Brezak et al. | Examiner |
| US2002/0161911(A1) | 2002-10-01 | Pinckney, III et al. | Applicant |
| US2003/0009429(A1) | 2003-01-01 | Jameson | Applicant |
| US2003/0028514(A1) | 2003-02-01 | Lord et al. | Applicant |
| US2003/0033308(A1) | 2003-02-01 | Patel et al. | Applicant |
| US2003/0033535(A1) | 2003-02-01 | Fisher et al. | Examiner |
| US2003/0115218(A1) | 2003-06-01 | Bobbitt et al. | Applicant |
| US2003/0135514(A1) | 2003-07-01 | Patel et al. | Applicant |
| US2003/0149781(A1) | 2003-08-01 | Yared et al. | Examiner |
| US2003/0159072(A1) | 2003-08-01 | Bellinger et al. | Examiner |
| US2003/0171978(A1) | 2003-09-01 | Jenkins et al. | Applicant |
| US2003/0177388(A1) | 2003-09-01 | Botz et al. | Examiner |
| US2004/0006575(A1) | 2004-01-01 | Visharam et al. | Applicant |
| US2004/0025013(A1) | 2004-02-01 | Parker et al. | Applicant |
| US2004/0028043(A1) | 2004-02-01 | Maveli et al. | Applicant |
| US2004/0028063(A1) | 2004-02-01 | Roy et al. | Applicant |
| US2004/0030857(A1) | 2004-02-01 | Krakirian et al. | Applicant |
| US2004/0054777(A1) | 2004-03-01 | Ackaouy et al. | Examiner |
| US2004/0098383(A1) | 2004-05-01 | Tabellion et al. | Applicant |
| US2004/0133573(A1) | 2004-07-01 | Miloushev et al. | Applicant |
| US2004/0133577(A1) | 2004-07-01 | Miloushev et al. | Applicant |
| US2004/0133606(A1) | 2004-07-01 | Miloushev et al. | Applicant |
| US2004/0133607(A1) | 2004-07-01 | Miloushev et al. | Applicant |
| US2004/0133652(A1) | 2004-07-01 | Miloushev et al. | Applicant |
| US2004/0139355(A1) | 2004-07-01 | Axel et al. | Examiner |
| US2004/0236798(A1) | 2004-11-01 | Srinivasan et al. | Applicant |
| US2005/0021615(A1) | 2005-01-01 | Arnott et al. | Applicant |
| US2005/0050107(A1) | 2005-03-01 | Mane et al. | Applicant |
| US2005/0108575(A1) | 2005-05-01 | Yung | Examiner |
| US2005/0289109(A1) | 2005-12-01 | Arrouye et al. | Applicant |
| US2006/0075475(A1) | 2006-04-01 | Boulos et al. | Examiner |
| US2006/0080353(A1) | 2006-04-01 | Miloushev et al. | Applicant |
| US2006/0161518(A1) | 2006-07-01 | Lacapra | Applicant |
| US2006/0167838(A1) | 2006-07-01 | Lacapra | Applicant |
| US2006/0200470(A1) | 2006-09-01 | Lacapra et al. | Applicant |
| US2006/0230265(A1) | 2006-10-01 | Krishna | Examiner |
| US2007/0024919(A1) | 2007-02-01 | Wong et al. | Applicant |
| AU2003300350(A1) | 2004-07-01 | Applicant | |
| CA2512312(A1) | 2004-07-01 | Applicant | |
| EP738970(A) | 1996-10-01 | Applicant | |
| JP63010250(A) | 1988-01-01 | Applicant | |
| JP6-332782(A) | 1994-12-01 | Applicant | |
| JP8-328760(A) | 1996-12-01 | Applicant | |
| JP8-339355 | 1996-12-01 | Applicant | |
| JP9016510(A) | 1997-01-01 | Applicant | |
| JP11282741(A1) | 1999-10-01 | Applicant | |
| WO2/056181(A3) | 2002-07-01 | Applicant | |
| WO2004/061605(A2) | 2004-07-01 | Applicant | |
| WO2008/130983(A1) | 2008-10-01 | Applicant | |
| WO2008/147973(A2) | 2008-12-01 | Applicant |
Non-Patent Literature (59)
- Basney, Jim et al. “Credential Wallets: A Classification of Credential Repositories Highlighting MyProxy,” TPRC 2003, Sep. 19-21, 2003.Examiner
- Botzum, Keys. “Single Sign On—A Contrarian View”, Aug. 2001.Examiner
- Novotny, Jason et al. “An Online Credential Repository for the Grid: MyProxy”, 2001 IEEE.Examiner
- Pashalidis, Andreas et al. “A Taxonomy of Single Sign-On Systems”, 2003.Examiner
- Pashalidis, Andreas et al. “Impostor: a single sign-on system for use from untrusted devices”, 2004.Examiner
- Tulloch, Mitch. Microsoft Encyclopedia of Security, 2003, pp. 218, 300-301.Examiner
- “Auspex Storage Architecture Guide,” Second Edition, 2001, Auspex Systems, Inc., www.ausoex.com, last accessed on Dec. 30, 2002.Applicant
- “CSA Persistent File System Technology, Colorado Software” Architecture, Inc. White Paper, Jan. 1999, p. 1-3.Applicant
- “Distributed File System: A Logical View of Physical Storage : White Paper,” 1999, Microsoft Corp., www.microsoft.com, last accessed on Dec. 20, 2002.Applicant
- “How DFS Works: Remote File Systems,” Distributed File System (DFS) Technical Reference, retrieved from the Internet on Feb. 13, 2009: URL:http://technetmicrosoft.com/en-us/library/cc782417.aspx>(2003).Applicant
- “NERSC Tutorials: I/O on the Cray T3E,” chapter 8, “Disk Striping,” National Energy Research Scientific Computing Center (NERSC), http://hpcf.nersc.gov, last accessed on Dec. 27, 2002.Applicant
- “Scaling Next Generation Web Infrastructure with Content-Intelligent Switching : White Paper,” Apr. 2000, Alteon WebSystems, Inc., (now Nortel Networks).Applicant
- “The AFS File System in Distributed Computing Environment,” May 1996, Transarc Corp., www.transarc.ibm.com, last accessed on Dec. 20, 2002.Applicant
- “VERITAS SANPoint Foundation Suite(tm) and SANPoint Foundation(trn) Suite HA: New VERITAS Volume Management and File System Technology for Cluster Environments,” Sep. 2001, VERITAS Software Corp.Applicant
- “Windows Clustering Technologies—An Overview,” Nov. 2000, Microsoft Corp., www.microsoft.com, last accessed on Dec. 30, 2002.Applicant
- Aguilera et al., “Improving recoverability in multi-tier storage systems,” International Conference on Dependable Systems and Networks (DSN-2007), Edinburgh, Scotland, Jun. 2007, 10 pages.Applicant
- Anderson et al., “Serverless Network File System,” in the 15th Symposium on Operating Systems Principles, Dec. 1995, Association for Computing Machinery, Inc.Applicant
- Anderson, Darrell C. et al., “Interposed Request Routing for Scalable Network Storage,” ACM Transactions on Computer Systems 20(1):1-24 (Feb. 2002).Applicant
- Apple, Inc. “Mac OS X Tiger Keynote Intro. Part 2” Jun. 2004, www.youtube.com <http://www.youtube.com/watch?v=zSBJwEm.RJbY>.Applicant
- Apple, Inc. “Tiger Developer Overview Series: Working with Spotlight” Nov. 23, 2004, www.apple.com using www.archive.org <http://web.archive.org/web/20041123005335/developer.apple.com/macosx/tiger/spotlight.html>, pp. 1-6.Applicant
- Cabrera et al., “Swift: A Storage Architecture for Large Objects,” Proceedings of the Eleventh IEEE Symposium on Mass Storage Systems, pp. 123-428, Oct. 1991.Applicant
- Cabrera et al., “Swift: Using Distributed Disk Striping to Provide High I/O Data Rates,” Computing Systems 4, 4 (Fall 1991), pp. 405-436.Applicant
- Cabrera et al, “Using Data Striping in a Local Area Network,” 1992, technical report No. UCSC-CRL-92-09 of the Computer & Information Sciences Department of University of California at Santa Cruz.Applicant
- Callaghan et al., “NFS Version 3 Protocol Spcification,” (RFC 1813), 1995, The Internet Engineering Task Force (IETF), www.ietf.org, last accessed on Dec. 30, 2002.Applicant
- Carns et al., “PVFS: A Parallel File System for Linux Clusters,” Proceedings of the 4th Annual Linux Showcase and Conference, pp. 317-327, Atlanta, Georgia, Oct. 2000, USENIX Association.Applicant
- Cavale, M. R., “Introducing Microsoft Cluster Service (MSCS) in the Windows Server 2003,” Microsoft Corporation, Nov. 2002.Applicant
- English Translation of Notification of Reason(s) for Refusal for JP 2002-556371 (Dispatch Date: Jan. 22, 2007).Applicant
- Fan, et al., “Summary Cache: A Scalable Wide—Area Web Cache Sharing Protocol,” Computer Communications Review, Association for Computing Machinery, New York, USA 28(4):254-265 (1998).Applicant
- Book Review by Farley, “Building Storage Networks,” Jan. 2000, McGraw-Hill, ISBN 0072120509.Applicant
- Gibson et al., “File Server Scaling with Network-Attached Secure Disks,” in Proceedings of the ACM International Conference on Measurement and Modeling of Computer Systems (Sigmetrics '97), 1997, Association for Computing Machinery, Inc.Applicant
- Gibson et al., “NASD Scalable Storage Systems,” Jun. 1999, USENIX99, Extreme Linux Workshop, Monterey, California.Applicant
- Hartman, “The Zebra Striped Network File System,” 1994, Ph.D. dissertation submitted in the Graduate Division of the University of California at Berkeley.Applicant
- Haskin et al., “The Tiger Shark File System,” 1995, in proceedings of IEEE, Spring COMPCON, Santa Clara, CA, www.research.ibm.com, last accessed on Dec. 30, 2002.Applicant
- Hwang et al., Designing SSI Clusters with Hierarchical Checkpointing and Single I/O Space, IEEE Concurrency, pp. 60-69, Jan.-Mar. 1999.Applicant
- International Search Report for International Patent Application No. PCT/US03/41202 (Sep. 15, 2005).Applicant
- International Search Report for International Patent Application No. PCT/US02/00720 (Jul. 8, 2004).Applicant
- International Search Report for International Patent Application No. PCT/US2008/064677 (Sep. 6, 2009).Applicant
- International Search Report for International Patent Application No. PCT/US2008/060449 (Apr. 9, 2008).Applicant
- International Search Report for International Patent Application No. PCT/US2008/083117 (Jun. 23, 2009).Applicant
- Karamanolis et al., “An Architecture for Scalable and Manageable File Services,” HPL-2001-173 p. 1-14 (Jul. 26, 2001).Applicant
- Katsurashima et al., “NAS Switch: A Novel CIFS Server Virtualization,” Proceedings. 20th IEEE/11th NASA Goddard Conference on Mass Storage Systems and Technologies, 2003 (MSST 2003), Apr. 2003.Applicant
- Kimball, C.E. et al., Automated Client-Side Integration of Distributed Application Servers, 13th LISA Conf., 1999. (no month, day).Applicant
- Kohl et al., “The Kerberos Network Authentication Service (V5),” RFC 1510, Sep. 1993. (http://www.ietf.org/rfc/rfc1510.txt?number=1510.Applicant
- Long et al., “Swift/RAID: A distributed RAID system,” Computing Systems, vol. 7, pp. 333-359, Summer 1994.Applicant
- Noghani et al.,“A Novel Approach to reduce Latency on the Internet: ‘Component-Based Download’,” Proceedings of the Int'l Conf. on Internet Computing, Las Vegas, NV pp. 1-6 (2000).Applicant
- Norton et al., “CIFS Protocol Version CIFS-Spec 0.9,” 2001, Storage Networking Industry Association (SNIA), www.snia.org, last accessed on Mar. 26, 2001.Applicant
- Patterson et al., “A case for redundant arrays of inexpensive disks (RAID),” Chicago, Illinois, Jun. 1-3, 1998, in Proceedings of ACM SIGMOD conference on the Management of Data, pp. 109-116, Association for Computing Machinery, Inc., www.acm.org, last accessed on Dec. 20, 2002.Applicant
- Pearson, P.K., “Fast Hashing of Variable-Length Text Strings,” Comm. of the ACM, vol. 33, No. 6, Jun. 1990.Applicant
- Peterson, “Introducing Storage Area Networks,” Feb. 1998, InfoStor, www.infostor.com, last accessed on Dec. 20, 2002.Applicant
- Preslan et al., “Scalability and Failure Recovery in a Linux Cluster File System,” in Proceedings of the 4th Annual Linux Showcase & Conference, Atlanta, Georgia, Oct. 10-14, 2000, www.usenix.org, last accessed on Dec. 20, 2002.Applicant
- Rodriguez et al., “Parallel-access for Mirror Sites in the Internet,” InfoCom 2000. Nineteenth Annual Joint Conference of the IEEE Computer and Communications Societies. Proceedings. IEEE Tel Aviv, Israel Mar. 26-30, 2000, Piscataway, NJ, USA, IEEE, US, Mar. 26, 2000, pp. 864-873, XP010376176 ISBN: 0-7803-5880-5 p. 867, col. 2, last paragraph -p. 868, col. 1, paragraph 1.Applicant
- Savage, et al., “AFRAID- A Frequently Redundant Array of Inexpensive Disks,” 1996 USENIX Technical Conf., San Diego, California, Jan. 22-26, 1996.Applicant
- Soltis et al., The Design and Performance of Shared Disk File System for IRIX, 6th NASA Goddard Space Flight Center Conf. on Mass Storage & Technologies, IEEE Symposium on Mass Storage Systems, p. 1-17 (Mar. 1998).Applicant
- Sorenson, K.M., “Installation and Administration: Kimberlite Cluster Version 1.1.0, Rev. D.” Mission Critical Linux, (no year, month, day) http://oss.missioncriticallinux.com/kimberlite/kimberlite.pdf.Applicant
- Stakutis, “Benefits of SAN-based file system sharing,” Jul. 2000, InfoStor, www.infostor.com, last accessed on Dec. 30, 2002.Applicant
- Thekkath et al., “Frangipani: A Scalable Distributed File System,” in Proceedings of the 16th ACM Symposium on Operating Systems Principles, Oct. 1997, Association for Computing Machinery, Inc.Applicant
- Wilkes, J., et al., “The HP AutoRAID Hierarchical Storage System,” ACM Transactions on Computer Systems, vol. 14, No. 1, Feb. 1996.Applicant
- Zayas, “AFS-3 Programmer's Reference: Architectural Overview,” Transarc Corp., version 1.0 of Sep. 2, 1991, doc. No. FS-00-D160.Applicant
- “Welcome to the RSYNC Web Pages,” Retrieved from the Internet URL: http://samba.anu.edu.au/rsync/ (Retrieved on Dec. 18, 2009).Applicant