WO2002021332A2

WO2002021332A2 - System and method for central user management and authentication, authorization and accounting based on directory services and standard protocols

Info

Publication number: WO2002021332A2
Application number: PCT/IL2001/000849
Authority: WO
Inventors: Ilan Meller
Original assignee: Ilan Meller
Priority date: 2000-09-07
Filing date: 2001-09-07
Publication date: 2002-03-14
Also published as: AU2001290217A1; WO2002021332A3

Abstract

A system and method for automatically managing directory services across different operating systems, in order for such directory services to be managed centrally. Preferably, the present invention supports the management of directory services through Active DirectoryTM and NIS for computer operating according to the UNIX operating system, which provide such services through NIS. The system and method of the present invention enable databases associate with Active DirectoryTM and NIS to be managed at a single central administration facility, such that a single management tool can be used to manage a heterogeneous network. The present invention also enable the various utilities and tools available through NIS and Active DirectoryTM to be controlled through the GUI (graphic user interface) of Active DirectoryTM , thereby providing a more complete set of management features to the system administrator.

Description

SYSTEM AND METHOD FOR CENTRAL USER MANAGEMENT AND AUTHENTICATION, AUTHORIZATION AND ACCOUNTING BASED ON DIRECTORY

SERVICES AND STANDARD PROTOCOLS

FIELD OF THE INVENTION

The present invention relates to a system and a method for central management of directory services, and in particular, to such a system and method for management of information related to directory services, such as information concerning hosts, user groups and individual users, across a plurality of operating systems.

BACKGROUND OF THE INVENTION

Currently, corporate networks, as well as networks for other types of organizations, feature computers which have a plurality of different operating systems. For example, a single network may have computers which have one or more versions of the Windows™ operating systems (Microsoft Corp., USA), one or more versions of the UNIX operating system, and Macintosh™ computers (Apple Computers Inc., USA) which also have a different operating system. Each of these different operating systems manages services such as directory services, services which enable the user to log into the computer and/or network, and other types of services. Currently, management of these different services across different operating systems is extremely difficult, since the different operating systems do not automatically communicate. Therefore, if a new user needs to receive a password and user name, for example, this information must be separately entered into each type of database being accessed by a particular operating system. As an example of this problem with two popular operating systems, consider entering such information to the directory services of the UNIX operating system and the Windows NT™ operating system. The UNIX operating system provides such directory services through NIS (Network Information System, previously termed "Yellow Pages"), while the Windows NT™ operating system provides such services through Active Directory™. If new and/or changed user information is entered into the database for NIS, such information is currently not automatically entered into the database for Active Directory™. Therefore, the information must be manually entered into the latter database, or else a new user might not be able to log into the network through a computer which is in communication with a server running Windows NT™. Similarly, directory services for the entire network cannot be centrally managed through Active

Directory™, since information entered into the Active Directory™ database is not automatically accessible to computers operating according to UNIX.

A more useful solution would enable such new and/or changed information to be automatically mirrored to all databases, particularly between databases being controlled by NIS and those controlled by Active Directory™. Furthermore, such a solution should enable a heterogeneous network to be managed through Active Directory™. Unfortunately, such a solution is not currently available.

SUMMARY OF THE INVENTION

The background art does not teach or suggest a system and a method for enabling information related to directory services to be automatically mirrored between databases controlled by different software services provided by different operating systems. The background art also particularly does not teach such a system and method in order to provide central management of directory services in a heterogeneous network through Active Directory™.

The present invention overcomes these deficiencies of the background art by providing a system and a method for automatically managing directory services across different operating systems, in order for such directory services to be managed centrally. Preferably, the present invention supports the management of directory services through Active Directory™ for computers operating according to a different operating system, which is more preferably the UNIX operating system. The UNIX operating system provides such services through NIS. The system and method of the present invention enable databases associated with Active Directory™ and NIS to be managed at a single central administration facility, such that a single management tool can be used to manage a heterogeneous network. The present invention also enables the various utilities and tools available through NIS and Active Directory™ to be controlled through the GUI (graphic user interface) of Active Directory™, thereby providing a more complete set of management features to the system administrator.

According to preferred embodiments of the present invention, an implementation of the services of NIS is provided on a computational device being operated according to the

Windows™ operating system. This computational device is a server on a heterogeneous network which includes both computational devices with UNIX and computational devices with the Windows™ operating system. The server of the present invention is able to both respond to requests for NIS services from UNIX-operated computational devices, and to read from, and write to, a database controlled by Active Directory™. Preferably, directory services for the heterogeneous network are controlled through Active Directory™. More preferably, the system administrator is able to manage these directory services for the entire network through the GUI (graphical user interface) for Active Directory™, such as MMC for example. Thus, more preferably the present invention enables all of the directory services information to be stored at a central database, most preferably- the Active Directory™ database, yet to be provided to computational devices on the heterogeneous network according to requests from both NIS and Active Directory™ processes. Most preferably, such an implementation is provided by simulating NIS server services through a server which is operated according to the Windows 2000™, or other similar operating system, rather than according to the Unix operating system. In addition, these services are preferably provided through the Windows™ directory service, rather than accessing data which is stored in flat files as for the existing NIS servers. Therefore, the services of the second operating system (in this example UNIX) are provided through the operation of a server according to the first operating system (in this example a Windows™ operating system).

Hereinafter, the term "Windows™" includes but is not limited to any operating systems by Microsoft Corp. (USA) or any similar operating systems.

Hereinafter, the term "UNIX' refers to any UNIX-compliant operating system. For the present invention, a software application could be written in substantially any suitable programming language, which could easily be selected by one of ordinary skill in the art. The programming language chosen should be compatible with the computational device according to which the software application is executed. Examples of suitable programming languages include, but are not limited to, C, C++ and Java. In addition, the present invention could be implemented as software, firmware or hardware, or as a combination thereof. For any of these implementations, the functional steps performed by the method could be described as a plurality of instructions performed by a data processor.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention is herein described, by way of example only, with reference to the accompanying drawings, wherein:

FIG 1. is a schematic block diagram of a background art NIS system; and FIG. 2 is a schematic block diagram of a system according to the present invention, for communication between NIS and Active Directory™ processes.

DESCRIPTION OF THE PREFERRED EMBODIMENTS The present invention is of a system and a method for automatically managing directory services across different operating systems, in order for such directory services to be managed centrally. Preferably, the present invention supports the management of directory services through Active Directory™ for computers operating according to a different operating system, which is more preferably the UNIX operating system. The latter system provides such services through NIS. The system and method of the present invention enable databases associated with Active Directory™ and NIS to be managed at a single central administration facility, such that a single management tool can be used to manage a heterogeneous network.

The present invention also enables the various utilities and tools available through NIS and Active Directory™ to be controlled through the GUI (graphic user interface) of Active Directory™, thereby providing a more complete set of management features to the system administrator.

Network Information Service (NIS) is a known Unix mechanism for managing distributed information. The information is organized in maps, which are collections of entries. Each entry has a key and data. The NIS protocol enables several basic, read only, operations on maps. These operations include retrieving the data of an entry identified by a key (match), retrieving the data of a map (all), etc. Unix computers, through the NIS client process (ypbind), perform such operations on the data by connecting to the NIS servers (machines running the ypserv process). For a plurality of servers, one of the NIS servers is defined as the NIS master, while the other servers are referred to as NIS slaves. NIS slaves retain a copy of the information, as it is kept on the NIS master, to be used as mirrored data for NIS client requests.

The information contained in the NIS maps can be updated only by the NIS master. After such an update the NIS master performs a process called a push, a process of populating the updated map information to all the other NIS servers (the NIS slaves).

The present invention is able to simulate an NIS master for the NIS clients and an LDAP client for the ActiveDirectory™ clients. Therefore, NIS client machines may optionally be configured as clients of the server according to the present invention (shown as the "master environment" below). In contrast to the structure of NIS maps and associated operations, Active Directory™ services rely upon the provision of objects, stored according to a hierarchical structure. These objects contain the necessary data to provide the directory services, and feature a unique name, composed of the relative name of the object and the path to that object from the top level. Each object has a set of attributes; each attribute may have several values. The directory services themselves are structured as a network databasej which is not contained on a single server, but instead may "float" on the network by being stored in pieces on several different servers. Lightweight Directory Access Protocol (LDAP) is one example of a standard protocol which is used to query the directory. Therefore, the present invention may also optionally be viewed as providing a mechanism for converting data stored according to one type of structure, such as the "flat" collection of entries, each of which has a key and data, for NIS protocol, to a second type of data structure, such as the hierarchical collection of objects of the ActiveDirectory™ format. In addition, the mechanism of the present invention also enables such data to be managed through the second type of services, while still supporting the actions of clients for the first type of services and architecture (in this case NIS clients).

According to preferred embodiments of the present invention, an implementation of the services of NIS is provided on a computational device being operated according to the Windows™ operating system. This computational device is a server on a heterogeneous network which includes both computational devices with UNIX and computational devices with the Windows™ operating system. The server of the present invention is able to both respond to requests for NIS services from UNIX-operated computational devices, and to read from, and write to, a database controlled by Active Directory™. Preferably, directory services for the heterogeneous network are controlled through Active Directory™. More preferably, the system administrator is able to manage these directory services for the entire network through the GUI (graphical user interface) for Active Directory™, such as MMC for example. Thus, more preferably the present invention enables all of the directory services information to be stored at a central database, most preferably the Active Directory™ database, yet to be provided to computational devices on the heterogeneous network according to requests from both NIS and Active Directory™ clients.

According to other preferred embodiments of the present invention, the server which operates the NIS processes through the Windows™ operating system is also able to operate a software module for automatically collecting information from computational devices on the heterogeneous network. More preferably, this software module is able to collect such information from NIS databases, thereby enabling the central Active Directory™ database to be constructed and/or updated with information from these databases. Optionally and most preferably, this software module is able to both collect this information from NIS databases for updating the central Active Directory™ database, and to update the NIS databases according to information entered into the central Active Directory™ database.

The principles and operation of the present invention may be better understood with reference to the drawings and the accompanying description.

Referring now to the drawings, Figure 1 shows a background NIS system 10 for managing directory services for the UNIX operating system. Directory services are generally implemented by organizations in order to centralize the management of user information, including user names and passwords, directory permissions, the operation of applications, and other elements of the system.

System 10 employs a source file 12 at a master server 14, which is the master server for controlling directory services. Source file 12 contains user information, such as the previously described user name and password. Source file 12 is turned into a binary file 16 for actual access, for example in order to check if the password which the user has entered is correct. Binary file 16 actually contains a map of the directory information, such as the previously described user information. If the user or system administrator wants to change user information, such as the password of the user for example, the user or system administrator needs to operate a yppassword process 18 at a ypclient computational device 20, which in turn communicates the new password information to a rpc.yppassword daemon 22. Rpc.yppassword daemon 22 in turn sends the information to a pwupdate process 24, to update binary file 16 at master server 14. Binary file 16 may be mirrored as a binary file 26 at a slave server 28, which is a slave server controlled by master server 14. Slave server 28 is used in order to increase the scalability of the system. If source file 12 is updated at master server 14, one of two processes may be employed in order to change binary file 16 at master server 14, and also binary file 26 at slave server 28. The first such process involves the "make" command, and hence a make process 30, in order to completely recreate binary file 16; however, for incremental changes, such as changing a single password for example, pwupdate process 24 is used to update binary file 16 with the new information.

The changes to binary file 16 at master server 14 are then propagated to binary file 26 at slave server 28 through a ypxfrd process 32, which communicates with a ypxfr process 34 at slave server 28 to change binary file 26.

If a password or other information is changed, binary file 26 at slave server 28 is updated through ypxfrd 32 and ypxfr 34 processes. Yppush 36 is activated and sends a command to ypserv process 40 at slave server 28 to refresh itself. Ypserv process 40 then creates a new process, ypxfr process 34 in order to permit ypserv process 40 to continue serving other clients. Ypxfr process 34 requests the entire binary file 26 from ypxfrd process 32, such that binary file 26 is then received. Another method is to optionally retrieve the map record by record through the ypserv process on master server 14. Yppush process 36 then receives a message from ypxfr process 34 indicating that the make process is complete.

For retrieving information, such as the password of the user for example, a ypbind process 38 is used by the client. This process then communicates with ypserv process 40, in order to retrieve the information from binary file 26 at slave server 28 or from binary files 16 at master server 14. Unfortunately, the background art system of Figure 1 does not permit communication between the NIS processes and the processes of Active Directory™. For example, the background art system of Figure 1 does not enable directory services information to be managed centrally through Active Directory™, nor does this system enable NIS processes to retrieve information from a database controlled through Active Directory™. Such communication between these different processes and central management of directory services is enabled by the system of the present invention, as shown in Figure 2. It should be noted that although this example is directed toward the management of directory services through operating systems of a similar type as the Windows™ operating system for UNIX-type operating systems, this is for the purposes of illustration only and is not intended to be limiting in any way. The present invention is useful for the provision and management of directory services by a first type of operating system for a second, different type of operating system, through the functions and adaptations described below.

As shown for an illustrative system 50, the master environment provides an implementation of NIS processes through a Windows™ operating system. It should be noted that optionally system 50 may only be implemented with the master environment; alternatively, as described in greater detail below, a slave environment may also optionally be provided. In the master environment, a directory process 58 represents the Active Directory™ process, which is known in the art and which contains an equivalent to the maps of the NIS system of Figure 1, for holding the directory information such as the previously described user information.

Information may optionally be placed into directory process 58 through the regular activity of the Active Directory™ process. Optionally and preferably, information may also be inserted through a build process 56. Build process 56 preferably reads directory information, such as user information for example, from a source file 54 which as previously described, holds such information for NIS (UNIX) based directory services. Build process 56 therefore enables information from sources external to the Active Directory™ format to be incorporated and used for the Active Directory™ process of directory services. Alternatively or additionally, information may optionally be read from a database 52, for example in order to convert information to the Active Directory™ format from a different type of operating system format.

Build process 56 is preferably assisted by information stored in one or more configuration and transformation files 57, which enable the information formatted according to the different (non- Active Directory™ type) operating system format to be translated into the Active Directory™ format. The operation of build process 56 may optionally be divided into four stages, in which the first stage describes the source of the information itself (IP address, type of protocol to be used, username, password and so forth; the username and password in this case are for accessing the source of information).

The second stage describes the query to be performed on the source of information, optionally with such object parameters as search paths, description of objects to be retrieved and so forth. The third stage is the transformation stage, for describing how to manipulate objects retrieved through the query of one type, such as NIS clients, in order to convert them into a format for clients being operated according to the second type of operating system (such as Active Directory™ queries); and the last stage describes the actual data structures being created, such as data in the Active Directory™ format for example. Information may also optionally be entered through a standard Windows™ management client 59, operating according to some version of the Windows™ operating system. Such a Windows™ management client 59 would typically enable directory-type information to be entered through a standard directory GUI (graphical user interface) 61, as is known in the art.

When new information, such as a new or changed user password, is sent to directory process 58, preferably several processes are triggered. The receipt of new or changed information by directory process 58 also triggers the activation of a simplement service 60 according to the present invention. Simplement service 60 optionally and preferably communicates with directory process 58 according to a protocol such as the LDAP (lightweight directory access protocol) specification. Simplement service 60 preferably receives information for building the maps which contain the user information from configuration and transformation files 57. Configuration and transformation files 57 also preferably contain the necessary information which enables simplement service 60 to transform information in the Active Directory™ format to the NIS map format, in a similar but opposite manner to that described previously for build process 56.

The trigger of simplement service 60 is preferably performed through a trigger process 62. Trigger process 62 may optionally poll directory process 58 regularly in order to receive the new information. Trigger process 62 may optionally also be triggered by a new version of a yppush process 64 according to the present invention. For example, yppush process 64 could be manually activated, similar to the "make" process of Figure 1. Yppush process 64 preferably causes trigger process 62 to refresh system 50, in order to accept new and/or changed information, for example.

Simplement service 60 also preferably contains new versions of ypxfrd process 66, yppasswd process 68 and ypserv process 70, which retain certain functionality from the equivalent versions of these processes from the background art NIS system, but which are preferably operated according to the Windows™ operating system as shown for the purposes of this example. Yppasswd process 18 preferably communicates with new yppasswd process 68 in order to perform the equivalent updating processes for Active Directory™ directory services. The information is then passed to directory process 58, for storage according to the Active Directory™ format.

For example, if the user wishes to change the user password, the user can enter the new password through the background art yppasswd process 18 of the UNIX client environment, which in this example is shown as being operated by a UNIX client 71. Yppasswd process 18 then communicates with yppasswd process 68 of simplement service 60. The new information is then provided to directory process 58, for storage in the Active Directory™ format. More preferably, however, management of the heterogeneous network is provided through Active Directory™, and in particular through standard directory GUI 61.

A slave server 74 is optionally present, but is not necessary. If present, a ypbind process 38 at UNIX client 71 may optionally communicate with either the master environment (simplement service 60) or alternatively may communicate with a ypserv process 40 of slave server 74. As shown for the purposes of this example, slave server 74 is optionally a UNIX-type server. If ypserv process 40 receives the command from new yppush process 64, then ypserv process 40 preferably generates a new ypxfr process 34 of slave server 74.

Ypxfr process 34 may optionally and preferably communicate with ypxfrd process 66 of simplement service 60 (through the arrow shown as "new"), which is equivalent to the process for NIS in which the NIS maps are transferred directly as binary files through ypxfrd. Alternatively ypxfr process 34 may communicate with ypserv process 70 of simplement service 60 (through the arrow shown as "old"), which is equivalent to the original process for map transfer through the NIS protocol, in which the map data is transferred record by record. After completion of the process, ypxfr process 34 preferably sends a response to yppush 64 (through the arrow marked as "response"). Directory services information can be requested either from the Windows™ environment, for example from a standard directory services GUI 61, or from the UNIX environment, through ypbind process 38. Standard directory services GUI 61 would communicate with directory process 58 of the master server, as both are operated according to the Windows™ operating system. Similarly, ypbind 38 can receive the necessary information from the new ypserv process 70 of simplement service 60, and/or from the actual ypserv process 40 of slave server 74, without requiring any modification of ypbind process 38.

As a particular example of the operation of the system of the present invention, each map contains objects which have an attribute, such as "name", and a value, such as "John". If a query for the value of a particular object is sent from the NIS system client of UNIX to the simplement service at the master server, then optionally and preferably the query is answered by using the NIS map information, which is more preferably contained in memory.

Alternatively, the query itself is translated by the simplement service of the master server into an Active Directory™ format query, for example by a process of symbolic substitution. For example, if a request is made in which the user name is the key for retrieving information, then the retrieved account name forms the initial part of the translated query, followed by the necessary data fields such as the user password and group name in the correct formatting.

According to preferred embodiments of the present invention, management of the directory services for this heterogeneous network is provided through Active Directory™. More preferably, management is provided through standard directory GUI 61 for managing Active Directory™. An example of such a GUI is the MMC GUI (Microsoft Corp.). Therefore, the system administrator is able to manage both Active Directory™ and NIS processes and information through MMC. For example, the system administrator is preferably able to update user passwords and other user information for both NIS and Active Directory™ through MMC. In addition, this preferred embodiment of the present invention supports the employment of a single Active Directory™ database for storing all directory services information in the heterogeneous network. This database is then managed through MMC.

Although system 50 according to the present invention has been described with regard to communication between the UNIX and Windows™ operating systems for directory services, this is intended as an example only and is without any intention of being limiting. Other examples of protocols which can optionally be supported by the present invention across different operating systems include, but are not limited to, FTP (file transfer protocol) and RADIUS (an authentication protocol for users who use a telephony modem to connect to a server from remote sites). The present invention is optionally and preferably used to support a central authentication system which would enable all of these protocols to be managed from a central interface. Currently, each of these authentication systems has a separate database and separate authentication mechanism, which increases the difficulty of managing such systems, particularly in a heterogeneous networking environment. The present invention is not limited to regular computational environments, but could also optionally be used with cellular telephones, for example for authentication through WAP (wireless application protocol). The present invention could also optionally be extended to central management of such services as accounting and billing administration, for example, or license administration, as another example.

While the invention has been described with respect to a limited number of embodiments, it will be appreciated that many variations, modifications and other applications of the invention may be made.

Claims

WHAT IS CLAIMED IS:

1. A method for supporting communication between a directory service of a first operating system and a directory service of a second operating system, each of said directory services being provided through a computational device operated according to one of the first and second operating systems, the method comprising: providing a first database format for formatting information related to the directory service of the first operating system, and a second database format for formatting information related to the directory service of the second operating system; translating information from said first database format into said second database format; and storing said translated information.

2. The method of claim 1, wherein said first database format has a flat structure, and said second database format has a hierarchical structure.

3. The method of claims 1 or 2, wherein the first operating system is UNIX and the second operating system is Windows™.

4. The method of claim 3, wherein the process of translation is controlled by a master server, said master server being operated according to Windows™ operating system, and wherein the directory service is provided according to Active Directory™.

5. The method of any of claims 1-4, further comprising: managing said translated information according to the directory service of the second operating system.

6. The method of claim 5, wherein said translated information is managed through a Windows™ directory GUI (graphical user interface).

7. The method of any of claims 1-6, further comprising: receiving a request from a client of the first operating system for a directory service; and performing said directory service according to said translated information.

8. The method of any of claims 3-7, wherein a database containing information in said first database format is controlled by a slave server, said slave server being operated according to UNIX operating system, and wherein translating said translated information further comprises: receiving a request by a user to change a user password from a yppasswd process being performed according to UNIX; changing said user password at said second database of said master server; activating a yppush interface process at said master server, said yppush interface process communicating with a ypserv process at said slave server; and updating said user password at said database of said slave server.

9. The method of any of claims 1-8, wherein said translation is performed in response to a request from a central management interface, said central management interface being operated according to one of the first or second operating systems.

10. The method of claim 9, wherein the first operating system is UNIX and the second operating system is Windows™, and wherein said central management interface controls an Active Directory™ database for storing directory services information.

11. The method of any of claims 1-10, wherein said translation is performed in response to a request from a client, said client being operated according to one of the first or second operating systems.

12. The method of claims 1 or 2, wherein the first operating system is Windows™ and the second operating system is UNIX.

13. The method of claim 12, wherein the process of translation is performed in response to a request from a NIS client.

14. The method of claims 12 or 13, wherein said translation is controlled by a master server, said master server being operated according to Windows™ operating system, and wherein the directory service is provided according to NIS.

15. A system for managing directory services for both NIS processes operated according to UNIX operating system and Active Directory™ processes operated according to Windows™ operating system, the system comprising:

(a) an Active Directory™ database for storing directory services information;

(b) a UNIX computational device for requesting directory services information according to NIS processes; and

(c) a central management server for reading information from, and writing information to, said Active Directory™ database, and for responding to a NIS request from said UNIX computational device.

16. The system of claim 15, wherein said central management server is controlled through a Windows™ GUI (graphical user interface).

17. The method of claims 15 or 16, wherein said central management server creates a NIS map for responding to said NIS request.

18. The method of claims 15 or 16, wherein said central management server translates said NIS request to an Active Directory™ format.

19. A method for simulating a plurality of standard operating system protocols between a client and a server, the method comprising the steps of:

(a) operating a directory service by the server through a first protocol as a central source for authentication and authorization; and

(b) receiving a request from the client by the server for said directory service according to a standard operating system protocol.

20. The method of claim 19, wherein the client is operated according to a first operating system, and the server is operated according to a second operating system, such that said first operating system is different from said second operating system.

21. The method of claims 19 or 20, wherein said standard operating system protocols include at least two or more of NIS, Radius, FTP, and HTTP .

22. The method of any of claims 19-21, wherein said first protocol is LDAP (lightweight directory access protocol).