METHOD FOR ACCESSING A DOMAIN
BACKGROUND
This invention relates generally to computer network, and more particularly to techniques for accessing resources in a domain by a user at a client computer, which has not joined the domain, that is, which is outside the domain.
It is understood that the administrator of a network can define a domain. The network can use any type of network operating systems including Windows NT, and the domain can have a plurality of network resources including applications, printers and the like. These network resources of the domain are administered as a unit with common rules and procedures, share a common directory database, and are normally managed by a domain server or a domain controller. Authorized users of the domain need to log into the domain to gain access to the shared resources within such a domain. For example, a n a uthorized u ser h aving a n a ccount i n t he d omain c an r etrieve shared documents in the domain, print documents to a shared printer within the domain, and so on.
To access the shared resources in the domain, normally the user needs, for example, a computer to enter the user's personal credentials contained in the user's account and send to the domain controller for authentication. Presently, the domain server requires the computer to join the domain before the user can access the shared resources through such a computer. In other words, the computer itself needs to be registered in a database of the domain controller by, for example, having identification information such as Domain Name System (DNS) or IP address of the computer stored in the database. This requirement may substantially restrict the mobility of the user in that it may not be easy for the user to find such a registered computer joined into the
domain, especially when the user travels to a different site and such a computer is not available.
Therefore, there is a need for a system and a method that allow a user of a computer outside a domain, to access shared resources inside the domain.
SUMMARY
According to an aspect of the present invention, a process for accessing resources in a domain by a client computer outside the domain is provided. The domain is managed by a domain server, and devices outside the domain are not directly accessible to the domain. An access server inside the domain is provided, and a connection between the client computer and the access server is firstly established. Then a request to access the domain is sent from the client computer to the access server, where the request specifies personal credentials of a user. Subsequently, the access server seeks authentication of the personal credentials from the domain server. Upon authentication from the domain server, the access server accesses the domain on behalf of the user.
According to another aspect of the invention, a system that allows a user to use a client computer outside a domain to remotely access resources in the domain is provided. The domain is not accessible by devices outside the domain. The system includes a domain server inside the domain for managing the domain and an access server inside the domain for communicating with the client computer. The access server has means for seeking authentication of the user from the domain server by using personal credentials of the user provided by the client computer and means for accessing the domain on behalf of the user upon authentication of the personal credentials by the domain server.
Other aspects and advantages of the invention will become apparent from the following detailed description, which illustrates by way of example the principles of the invention, when taken in conjunction with the accompanying drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
Figure 1 is a diagram illustrating a system according to an exemplary embodiment of the present invention, which allows a user to access a domain by using a client computer that is outside the domain; and
Figure 2 is a flow chart illustrating a process of accessing resources in the domain that can be implemented in the system of Figure 1.
DETAILED DESCRIPTION OF THE INVENTION
Figure 1 illustrates a computer system according to an exemplary embodiment of the present invention. The system has a client computer 101 , which has not joined a domain 100, that is, which is outside the domain 100. The client computer 101 is connected to the domain through a network 103, for example, the internet. A typical client computer 101 is a personal computer or workstation running the Microsoft Windows NT operation system or a personal digital assistant (PDA) running the Pocket PC operating system; a typical domain 100 is a collection of network devices 102, 104, 106, 108, 110 within a network (not shown) also running the Microsoft Windows NT operating system and is defined by the administrator of the network to share a common directory database (not shown) stored in a domain server or domain controller 104. The domain server 104 is also one of the network devices within the domain 100 and manages such a domain 100.
The administrator of the network may authorize certain users to access and use at least some of the shared resources within the domain. For example,
an authorized user at a computer (not shown), which has joined or is inside the domain can retrieve files stored in a file server 106, print documents to a shared printer 108 managed by a printer server (not shown), and so on, provided that this user is authorized for these resources. Before the authorized user can access these resources, authentication of the user from the domain server 104 is required. Each authorized user generally needs to have at least one particular username and corresponding password. These personal credentials of the authorized users are stored in a database (not shown) in the domain server 104 for the purpose of authentication. Furthermore, the administrator may define which shared resources in the domain 100 can be accessed for each individual authorized user. Information about each authorized user's authorizations can also be stored in a database in a server, which manages the respective shared resources, for example, the file server or the printer server.
Furthermore, the domain 100 is managed in a way such that the shared resources within the domain are not accessible by devices, which are outside the domain, that is, which have not joined the domain. For a device to join the domain, its identification information, for example, Domain Name System (DNS) or IP address of the device, needs to be registered and stored in the common directory database managed by the domain server 104. In this way, the domain 100 restricts a user at devices outside the domain from accessing the domain, no matter whether the user is an authorized one or not.
The domain 100 further includes an access server 102 for connection with the client computer 101. As part of the domain 100, the access server 102 has already joined the domain 100. On the other hand, the client computer, connected to the domain through the internet 103, is outside the domain 100 and has not joined such a domain 100. It is through the access server 102 that an authorized user of the domain at the client computer 101 is capable of accessing the shared resources within the domain 100. This process will be further discussed with reference to Figure 2.
As shown in Figure 2, in an initial step 201 , a user at the client computer 101 sends a request for accessing the shared resources inside the domain to the access server 102 via the connection established between the client computer and the domain over the internet 103. In particular, this request informs the access server 102 of the user's personal credentials, such as the username and password. Such a request to the access server can be invoked through any inter-process communication technologies. For example, if Common Object Model (COM) technology, which is available from Microsoft Company, is used, the request can be sent by using a COM method such as Logon.
Upon receiving the request, in step 203, the access server 102 seeks authentication of such a user from the domain server 104. In particular, the access server 102 uses the Windows Application Programming Interface (API) LogonUser to forward the user's credentials, such as username and password, to the domain server 104, which subsequently searches its database for verification.
If the user's username is not found in the database or if the password specified in the request from the client computer 101 does not match the record in the database, the domain server 104 denies such a user's request for access to the shared resources inside the domain 100 and sends a response to the client computer 101 through the access server 102, informing the user that the user is not an authorized user of the domain 100. The responding action is also performed through the Logon COM method.
If the user's personal credentials match the record in the database, that is, the user is an authorized user of the domain 100, the domain server 104 informs the access server 102 of the result of the authentication, and the access server 102 further informs the client computer accordingly.
Furthermore, upon authentication of the user, the access server 102 creates and temporarily stores an access token (not shown) in a memory unit (not shown) in it. The access token is created through the Windows API LogonUser to represent a session of the authenticated user. Such an access token is usually operating system (OS) specific and is only accessible through a special handle for security reasons. The handle is used to reference or access the access token indirectly.
Subsequently, in step 205, the user at the client computer 101 sends another request to the access server 102, informing the access server of the action to be taken with respect to the shared resources within the domain 100. Such a request can also be sent by using the COM method.
Take for example the case when the user wants to retrieve a shared document stored in the file serve 106. Accordingly, the user at the client computer uses the GetFile COM method to specify the destination or path of the document to be accessed in the request.
In step 207, upon receiving the request, the access server executes the COM method GetFile to retrieve the destination of the desired document. In particular, the access server impersonates the identity of the user by using ImpersonateLoggedOnUser Windows API and the handle to the access token. O nee the i mpersonation i s s uccessful, t he a ccess s erver d uplicates from the file server a copy of the desired document on behalf of the user by using the Windows API CopyFile.
Furthermore, when the access server duplicates a copy of the desired document from the file s erver, t he o perating system (not shown) of the file server uses its network management function such as Lan Manager, which is available from Microsoft Company, to automatically check if the user has the authorizations to access the document. The authorizations of the user for accessing shared documents can be pre-stored in certain form of database
such as Windows NT File System (NTFS) in the file server. If the user has the necessary authorization, access to the desired document by the access server on behalf of the user is then granted, and duplication of the document from the file server to the access server is continued. Otherwise, the duplication will be stopped, and the access server informs the user accordingly. Once the duplication is completed, the access server in turn passes the duplication of the document to the client computer through the established connection therebetween.
Another example of accessing the shared resources within the domain is also provided. In this case, the user intends to print a document from the client computer to the shared printer within the domain. Accordingly, upon authentication of the user in step 205, the client computer invokes the PrintFile COM method to specify both the printer destination and the document to print. When the access server receives such a print request, it impersonates the user by using the Windows API ImpersonateLoggedOnUser and the handle to the access token. Once the impersonation is successful, the access server checks if the user has the necessary authorization to print to the specified printer by using the Windows API OpenPrinter. If the Windows API OpenPrinter passes, it is indicated that the user has the authorization to print to the specified printer. Subsequently, the access server prints the document to the specified printer. For a document whose data is understandable by the specified printer (for example a text file), printing operation can be performed by using the Windows API CopyFile to copy the document directly to the specified printer.
In this way, the system allows an authorized user of the domain 100 at a client computer 101 , which is outside the domain 100, to access shared resources in the domain through the access server 104.