JP2001075857A - Directory system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To make preventable a wrong attribute value from being registered by allowing a directory server to previously hold attribute values which can be registered. SOLUTION: The directory server 2 receives various directory access requests that a directory client 1 issues by a communication control part 11 and requests a retrieving and updating process for directory information of an entry management part 4 after a protocol analysis part 10 analyzes access contents. When an access object is permissible value information, the entry management part 4 requests the process of a permissible value management part 8. The permissible value management part 8 finds a line where the same name is stored as an attribute name by retrieval from a permissible value management table 9, takes out a combination of the reported attribute name and its value, and repeats a confirming process as all reported attributes. Then when a reported attribute value is different from a registered value, the entry management part 4 is informed of that and then notified that an updating process can not be performed for the client 1.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a directory system comprising a plurality of information processing devices connected to a network.

[0002]

2. Description of the Related Art LAN (Local Area Network) is a means for realizing smooth communication within a company and between companies.
k) PC (Personal Computer) via a network such as
E-mail systems that send and receive documents created by information processing devices such as e.g.
Directory services such as the X.500 (ISO9594) recommendation have begun to be used.

[0003] An X.500-compliant directory service has a hierarchically managed data model as a tree structure (directory tree). Directory entries are arranged at locations corresponding to the branches and leaves of the tree. Each entry is uniquely identified by a name that includes hierarchical information (dn: Distinguished Name), in addition to the user's email address, first and last name, phone number,
Various information, such as a fax number and a photograph, can be stored as attributes.

[0004] X.500 employs a client-server type distributed system architecture. As a communication protocol between information processing apparatuses serving as a client and a server, a DAP conforming to a seven-layer structure of OSI (Open Systems Interconnection) is used. (Directory Access Protocol). On the other hand, the Internet Engineering Task Force (IETF),
LDAP: Lightweight Directory Access Pro as a directory client-server protocol on CP / IP
tocol (RFC2251) ". A user accesses a directory server such as X.500 using DAP or LDAP from an application program on a client, and searches for desired information such as a user's mail address. Further DAP
Alternatively, LDAP also specifies directory update requests such as entry addition, deletion, update, and entry name change. FIG.
2 shows an LDAP protocol element defined in RFC2251. 48 is a search request instructing to search for an entry matching the search conditions (baseObject, scope, filter); 49 is an entry addition request instructing the addition of one entry; 50 is an entry instructing the deletion of one entry The deletion request 51 is an entry update request instructing addition, deletion, and replacement of values for at least one or more attributes included in one entry.

Prior to the operation of the directory service, the system administrator must define a directory usage rule called a directory schema in advance, as described in Japanese Patent Application Laid-Open No. Hei 7-52619.

The X.501 recommendation includes a directory schema, a directory tree structure, an object class,
A method for defining attribute types is defined.

[0007] The directory tree structure definition refers to the hierarchical relationship between the entries in the tree structure, such as, for example, "an organizational unit entry must always be an organization entry or an organizational unit entry". It is specified. The object class definition defines a list of attributes that can be held in an entry and whether each attribute is indispensable or optional for the entry. For example, in the case of a person entry, the surname (sn) is a required attribute and the telephone number (telephoneNumber) is an optional attribute.
On the other hand, the attribute type definition defines a syntax such as a character string or binary, a matching rule such as whether or not to ignore all or partial matches, or differences between uppercase and lowercase characters, and the like. For example, an attribute representing a name such as a first name or a last name is generally defined as a character string type in which uppercase and lowercase alphabetic characters are treated the same at the time of search and a partial match search is possible.

[0008] When an entry or attribute is added to the directory server, it must follow the above-defined schema. Many distributed directory servers have a function of rejecting a directory update request that violates the schema.

As described above, the schema in the directory service is a very useful function for regularly classifying various kinds of information.

[0010]

The prior art described above is a means for defining the interrelationship between entries and the attribute types and attribute types that can be held by the entries. However, actual attribute values are considered except for the type. No, there were the following problems.

Among the attributes stored in the directory server, there are attributes whose attribute values are not arbitrary and are always limited to any one of several values. For example, the address (postalAddres
s), telephone number (telephoneNumber), fax number (facsimi
The same value is often registered for attributes such as leTelephoneNumber) for users who work in the same office. In the title (title), any one of the titles existing in the organization, such as the president, the manager, the section manager, etc., should be stored as the attribute value of each user.

However, according to the above prior art, whether the entry to be added complies with the relational rule of the tree structure, whether the added attribute is an attribute that the entry can hold,
It is possible to check whether the attribute value to be added or the attribute value after change is of the defined type, but whether the attribute value to be added or the attribute value after change is the value intended by the system. Cannot check. For this reason,
For example, it is not possible to prevent a situation in which a post or an incorrect telephone number that does not exist in the organization is registered intentionally or by an erroneous operation, and the business may be hindered by erroneous information.

A conventional directory operation tool (directory client) for adding and deleting entries, updating attribute values, and the like generally uses a keyboard to input an attribute value to be added or an attribute value after change. . For this reason, when a large number of directory entries must be added or changed, such as when a new employee enters the company or changes in personnel, the directory service system administrator must key in the same attribute value many times. Maintenance work took a lot of time and effort.

In order to solve the above problem, a user can select a desired attribute value by using a list box as described on page 124 of “MFC Programming” published by ASCII Corporation. However, usually, the candidate values displayed in the list box are embedded in the program. For this reason, when adding or deleting candidate values, it is necessary to modify the client program, which requires labor and cost for development and testing. Even if the directory client has a function of customizing the displayed candidate values, the setting must be performed for each user who uses the client. For this reason, not only does it take time for the user, but if there is a user who has not set the candidate value,
Unintended attribute values may be registered on the server,
It may hinder business.

[0015] In addition, there is a form in which directory information editing work is realized using a form function of a Web server, which has become very popular in companies in recent years. In such a system, HTML (HyperText Markup Language) OPTION
By describing the choices of attribute values using tags and uploading the HTML file to the Web server, the user can enter several attribute values displayed on the Web browser without entering each attribute value The desired value can be selected from. However, HTML only controls screen display, and it is not possible to strictly regulate the registration value to the directory server, which is the first problem. For example, the accessed web page is temporarily saved as a file, and a new attribute value is added to the HTML file using a text editor or the like.
By adding it as an TION tag or changing the value of an already described OPTION tag, attribute values other than those described in advance can be easily registered in the directory server.

Accordingly, a first object of the present invention is to provide a directory attribute management method capable of preventing erroneous attribute value registration.

A second object of the present invention is to provide a directory attribute management method excellent in operability in which attribute values to be registered can be selected from candidates.

It is a further object of the present invention to provide a directory server, a directory client, a directory system, and a program for realizing these functions on a computer, using the directory attribute management method.

[0019]

In order to achieve the above object, a directory system according to the present invention has a directory server and a directory provided with means for registering an attribute value relating to a directory entry having at least one attribute. A directory system comprising a client, wherein the directory server previously holds a registerable attribute value, and a unit for determining whether an attribute value requested to be registered matches the held registerable attribute value. Means for rejecting registration of an attribute value that does not match the held registerable attribute value.

Further, in order to achieve the second object, the directory client of the present invention displays a registerable attribute value stored in the directory server and displays the obtained registerable attribute value as an option. Means.

By predefining the values allowed for the attributes in this way, it is possible to prevent the registration of erroneous attribute values beforehand, so that it is possible to manage and control the registration of directory information based on the types of the attributes and their values. The operability of the system can be improved. By obtaining the allowed attribute value from the server and displaying it as an option to the client,
The client user can select a desired attribute value from the candidates without having to input all the attribute values. Therefore, the usability can be improved, and the system administrator can manage and control the candidate values displayed on the client as options for the user of each client.

[0022]

DESCRIPTION OF THE PREFERRED EMBODIMENTS One embodiment of the present invention will be described below with reference to the drawings. In the following drawings, the same portions are denoted by the same reference numerals. First, the configuration of a directory system to which the present invention is applied will be described. FIG. 1 is a functional configuration diagram of a directory system to which the present invention is applied. A directory server 2 and a directory client 1 are connected via a network 3 such as a LAN.

The directory server 2 includes a communication control unit 11 for executing communication processing with the client 1, a protocol analysis unit 10 for analyzing received access requests, a DB 5 for storing directory entry information, and a received access request. An entry management unit 4 for searching and updating the DB5, a schema management table 7 for storing schema information such as a directory tree structure, an object class, and an attribute type, and a schema management unit for referencing and registering schema information according to a request.
6. It comprises an allowable value management table 9 for storing values (allowable value information) permitted to be registered for each attribute, and an allowable value management unit 8 for executing reference and registration of the allowable value information according to a request.

FIG. 2 shows the directory server 2 of the present embodiment.
1 is a system configuration diagram of FIG. The directory server 2 includes a central processing unit CPU 12, a magnetic disk 15 such as a hard disk device, a main memory 13, a bus 14, a display 16, a keyboard 18, and a mouse 17. DB5, schema management table 7, and allowable value management table 9 in FIG.
Stored as a file on 15. The main memory 13 stores a communication control program 11, a protocol analysis program 10, an entry management program 4, a schema management program 6, and an allowable value management program 8. These programs are initially stored on a magnetic disk 15 from a portable storage medium such as an FD or from another server via a wired or wireless transmission medium, and then transferred to the main memory 13 as necessary. Is executed by the CPU 12.

FIG. 3 is a functional configuration diagram of the directory client 1 shown in FIG. The directory client 1 is a communication control unit that executes communication processing with the server 2.
11. Directory access unit 19 that issues a directory access request such as search and update to server 2, schema acquisition unit 21 that acquires schema information registered from server 2, and schema information set by the user to server 2. It comprises a schema definition unit 20 to be registered, an allowable value acquisition unit 23 to obtain the allowable value information registered from the server 2, and an allowable value definition unit 22 to register the allowable value information set by the user in the server 2. In the following description, the server access processing of the schema acquisition unit 21, the schema definition unit 20, the allowable value acquisition unit 23, and the allowable value definition unit 22 is performed by the directory access unit 19 and the communication control unit.
11 shall be realized.

In this embodiment, the directory server
2 and each program of the directory client 1 operate under the control of the basic software (OS) of each device, and perform various inputs and outputs via the OS.
Each program may directly input and output without going through the OS.

Next, an example of the information structure of the allowable value management table 9 of this embodiment will be described with reference to FIG.

The allowable value management table 9 has a two-dimensional table format, and one row is assigned to each attribute. The first column 25 is an area for storing the name (or object identifier) of each attribute, and at least one subsequent column 26 is an area for storing a value allowed for each attribute. For example, when an allowable value is set as shown in FIG. 8, a value that can be registered as a post attribute is any of "President", "Manager", and "Engineer".

Many distributed directory servers have a function of registering and referencing schema information from a directory client via a network, in addition to the device itself that constitutes the server. In this case, the server can register and refer to the schema information using the existing directory access protocol by representing the set schema information as a special directory entry. Therefore, the present embodiment also includes means for converting the permissible value information into a permissible value reference directory entry.

The same effect can be obtained by storing the allowable value management table 9 of this embodiment as a directory entry in DB5. In this embodiment, the allowable value management unit 8
Performs reference and registration of allowable value information to DB5.

FIG. 9 shows an example of the directory information structure when the allowable value information is expressed as an entry. 27 is the server
2 An entry called rootDSE that represents its own configuration information, 28
Is an entry representing schema information. The rootDSE entry 27 is a special entry having no unique dn value, and is always present in each server 2, and includes a directory tree (namingContexts) and a schema entry managed by the server 2.
dn (subschemaSubentry), protocol version (sup
portedLDAPVersion) is retained as an attribute. The schema entry 28 includes definition information (objectclasses) related to an object class and definition information (att
ributetypes) are held as attributes. The subschemaSubentry attribute of the rootDSE entry 27 is a pointer to the schema entry 28. When acquiring schema information, the search request 48 Can be used to refer to the actual schema entry 28.

In this embodiment, the client 1
Enter the information stored in the allowable value management table 9 into the allowable value entry
Show as 9. The allowable value entry 29 expresses a combination of an attribute name and an allowable value as an attribute of the entry for each attribute for which an allowable value is set. When a plurality of allowable values are set, the attribute is a multi-value attribute. In addition, client 1
Allowed value entry 2 in rootDSE entry 27 to find allowed value entry 29 as well as schema entry 28
Add an allowableValues attribute as an attribute to hold 9 dns.

Next, an example of an operation for defining an allowable value will be described with reference to FIG.

The user sets each parameter using the display, keyboard, mouse and the like of the client 1. The screen 30 is a display example of an allowable value definition, a list 31 for selecting an attribute for setting an allowable value, a list 32 for displaying a list of set allowable values, and a button 3 for adding a new allowable value.
3, button 3 to delete the value selected in the allowable value list 32
4, Button 3 to change the value selected in the allowable value list 32
5, and button 36 to determine all the information set,
It consists of a button 37 for canceling all information being set. A screen 38 is an example of a screen display for adding a permissible value. An area 39 for inputting a permissible value to be added and an OK button 3
6. Consists of a cancel button 37.

When receiving an instruction to start the allowable value definition from the user, first, the allowable value defining unit 22 requests the schema obtaining unit 21 to obtain all the attributes. The schema acquisition unit 21 issues a search request 48 to the server 2 and all attributes in the schema entry 28
Get etypes attribute. An attribute name is described in each attributetypes attribute. Using the information, the allowable value definition unit 22 generates an attribute list in the list 31. Next, when the user selects one attribute from the list 31, the allowable value definition section
22 requests the allowable value acquiring unit 23 to acquire the allowable value of the selected attribute. The allowable value acquiring unit 23 issues a search request 48 to the server 2 and acquires the selected attribute existing in the allowable value entry 29. Using the obtained result, the allowable value definition unit 22 generates a list of allowable values in the list 32. When the add button 33 is pressed, the allowable value definition unit 22 displays a screen 38 and waits for a new allowable value to be added to the area 39. Similarly, when the change button 35 is pressed, the allowable value definition unit 22 displays a screen similar to the screen 38, and waits for the changed allowable value to be added to the area 39. Finally, when the user presses the OK button 36 on the screen 30, the allowable value definition unit 22 assembles an entry update request 51 based on the additions, deletions, and changes made up to that time, and issues the request to the server 2. The server 2 that has received the request 51 changes the allowable value management table 9 that stores the information of the allowable value entry 29.

The operation of the directory server according to this embodiment will be described below. In the following figures, the directory server 2 of this embodiment receives various directory access requests issued by the client 1 by the communication control unit 11, analyzes the access contents by the protocol analysis unit 10, and then sends the request to the entry management unit 4. Request for directory information search and update processing. The entry management unit 4 allocates the process to the schema management unit 6 when the access target is the schema information, and allocates the process to the allowable value management unit 8 when the access target is the allowable value information.

FIG. 5 is a flowchart showing the operation of the allowable value management unit 8 relating to the allowable value extraction processing.
It works when displaying the list 32 of 30.

Upon receiving the search request 48 referring to the allowable value entry 29, the allowable value management unit 8
One name of the extraction attribute specified by the ibuteType parameter is extracted, and the allowable value management table 9 is searched to find a row in which the same name is stored in the attribute name 25. If found, the value stored in the allowable value area 26 of that row is copied to the work area on the memory 13 (S501). Tolerance value management unit 8, S501
AttributeType included in request 48
After repeating all the extraction attributes specified by the parameters (S502, S504), all information copied to the work area on the memory 13 is put together and returned to the client 1 as a search result (S503).

FIG. 6 is a flowchart showing the operation of the allowable value management unit 8 relating to the allowable value registration processing.
It operates when the OK button 36 on 30 is pressed.

Upon receiving the request 51 for updating the allowable value entry 29, the allowable value management unit 8
Extract one combination of n parameter (update type) and modification parameter (update attribute name and attribute value),
Update the allowable value management table 9 according to the contents (S60
1). For example, when the update type is "add" or "replace", the allowable value management table 9 is searched to find a row in which the same name as the requested update attribute is stored in the attribute name 25. If found and the update type is "add", the requested attribute value is registered in an unused part of the allowable value area 26 of the row. If the update type is "replace", first delete all the permissible value information registered in the row, and then register the requested attribute value. If not found,
The requested update attribute name and attribute value are registered in the unused row areas 25 and 26, respectively. The allowable value management unit 8
The above processing is repeated for all attributes included in the n parameter. If the update type is "delete", the allowable value management table 9 is searched to find a row in which the same name as the requested update attribute is stored in the attribute name 25, and the requested attribute value is stored in the area. Remove from 26. The allowable value management unit 8
The above process is repeated for all attributes included in the ation parameter. The permissible value management unit 8 performs the permissible value extraction process in S601 with the operation parameter
After repeating for all combinations of ion parameters (S
602, S604), and returns the success of the update to the client 1 (S603).

FIG. 13 shows a sequence of a protocol transmitted and received between the directory client and the directory server according to the present embodiment.

FIG. 7 is a flowchart showing the operation of the allowable value management unit 8 relating to the allowable value confirmation processing. The entry management unit 4 determines that the received access request 52 is a request to add a new attribute value to a normal entry, for example, the entry addition request 49 or the operation parameter is “add” or “rep”.
In the case of the entry update request 51 which is “lace”, the request 52 is requested to confirm the allowable value set in the allowable value management unit 8.
Is notified of a combination of at least one attribute name and a new attribute value.

The allowable value managing unit 8 requested to confirm the allowable value from the entry managing unit 4 takes out one of the notified combinations of the attribute name and the value, searches the allowable value management table 9, and A row in which the same name as the extracted attribute is stored in the attribute name 25 is found (S701). If found, it is determined that the attribute is an attribute for which an allowable value has been set, and it is further confirmed that the extracted attribute value exists in the allowable value area 26 of the row (S702). After repeating the above confirmation process for all the notified attributes (S703, S705), the allowable value management unit 8 notifies the entry management unit 4 that the allowable value restriction is not violated (S704). In response, the entry management unit 4
After updating the above target entry information, the client 1 is notified of success as the processing result 53. On the other hand, in S702, when the notified attribute value is different from any of the values registered in the allowable value area 26, the allowable value management unit 8 notifies the entry management unit 4 of the fact (S706). In response to this, the entry management unit 4 notifies the client 1 as a processing result 53 that the update process cannot be completed due to an allowable value violation without updating the target entry information in the DB 5.

Although the present embodiment describes a graphical user interface for defining allowable values, a text-format allowable value definition file is provided, and a system administrator adds, deletes, or changes allowable values. in case of,
The contents of the file may be edited.

The embodiment of the directory attribute management method according to the present invention has been described above. The prior art is a method of restricting registration according to the type of attribute, in other words, a method in which only a device for storing an attribute value is determined, and the value contained therein does not matter. For this reason, it is not possible to prevent a situation in which an attribute value that is not intended as a system is registered intentionally or due to an erroneous operation, and the operation may be hindered by erroneous information. On the other hand, the directory attribute management method according to the present invention is a method in which registration permitted by a value is allowed in addition to the type of the attribute by defining in advance the value allowed for the attribute. Thereby, registration of an incorrect attribute value can be prevented beforehand, and operability of the directory system can be improved.

Next, an embodiment relating to an entry registration method using the directory attribute management method of the present invention will be described.

FIG. 4 is a functional configuration diagram of the directory client 1 of the present embodiment. The directory server 2 of this embodiment has the same configuration as that of the first embodiment.

The directory client 1 performs communication processing with the server 2, the directory access unit 19 which issues a directory access request such as search and update to the server 2, and registers from the server 2. Schema acquisition unit 21 that acquires the schema information that was obtained, server 2
Allowed value acquisition unit 23 that acquires allowed value information registered from
The entry editing unit 24 registers entry information set by the user in the server 2. In the following description, it is assumed that the server access processing of the schema acquisition unit 21, the allowable value acquisition unit 23, and the entry editing unit 24 is realized via the directory access unit 19 and the communication control unit 11.

Next, an example of the operation when adding an entry is shown in FIG.
This will be described with reference to FIG. In FIG. 13, reference numeral 54 denotes the search request 48 of FIG. The screen 40 is a display example when a new entry is added, areas 41 to 47 for setting attribute values, a button 36 for determining all set information, and a button for canceling all set information. Consists of 37.

Upon receiving an instruction to start the allowable value definition from the user, first, the entry editing unit 24 requests the schema obtaining unit 21 to obtain all the attributes that can be held by the entry to be added.
The schema acquisition unit 21 issues a search request 48 to the server 2,
The attribute corresponding to the object class of the entry to be added among the objectclasses attributes of the schema entry 28 is acquired. In the obtained objectclasses attribute, a list of attribute names and the like that can be held by the object class is described. Using the information, the entry editing unit 24 determines the number of attribute value setting areas (41 to 47) to be displayed on the screen 40 and the item names. Next, the entry editing unit 24 requests the allowable value obtaining unit 23 to obtain the allowable value of each determined attribute. The allowable value acquisition unit 23 issues a search request 54 for extracting the requested attributes to the server 2. The server 2 searches for the permissible value of each requested attribute according to the processing of FIG. 5 and returns it as a processing result 55. Using the information obtained by the allowable value obtaining unit 23, the entry editing unit 24 of the client 1 sets the setting area of each attribute to be displayed to an area for inputting a character string of a value or a list area for selecting a value Is determined. For example, when the permissible value information shown in FIG. 8 is registered, as shown in FIG. 11, the area of the name and surname attribute where the permissible value is not set is the character string input area (41, 42), and the permissible value is Set title,
The address, telephone number, and fax number attribute areas are listed (43
From 46). In the case of an attribute for which an allowable value is set, the allowable value of the attribute acquired by the allowable value acquiring unit 23 is displayed as a list as an option. At this time, the entry editing unit 24 refers to the attribute list acquired by the schema acquiring unit 21 and checks whether the attribute is essential for the object class. If it is an optional attribute, add "None" to the choices in the list area. When the user inputs attribute values in the areas 41 and 42 and selects each attribute value from the list of the areas 43 to 46, and presses an OK button 36, the entry editing unit 24
Assembles an entry addition request 49 based on the input or selected contents and issues it to the server 2. The server 2 receiving the request 49 updates the target entry information on the DB5.

In this embodiment, the screen and the operation when adding an entry have been described as an example. However, the directory attribute management method of the present invention is also effective for adding and changing the attribute value in a registered entry. Some things are obvious.

When the directory client 1 of this embodiment is used, an attribute value is selected from predefined allowable values, so that an unacceptable attribute value is not registered in the directory server 2. For this reason, if all the directory clients in the system adopt the configuration of FIG. 4, the allowable value confirmation processing (FIG. 7) of the directory server 1 in the first embodiment is not necessarily required.

The embodiment of the directory attribute management method according to the present invention has been described above. A conventional directory client used for directory operation has only means for inputting an attribute value to be added or an attribute value after change from a keyboard, and a lot of time and effort is required for maintenance work on directory information. On the other hand, when the directory attribute management method of the present invention is used, the client can acquire the option of the attribute value to be registered from the server. This allows the user to select a desired attribute value from the candidates without having to input all the attribute values, thereby improving the usability and allowing the system administrator to select an application to be used by each user. Can be controlled.

In each of the above embodiments, the permissible value information which is a feature of the present invention is provided separately from the conventional schema information. However, it is clear that a similar effect can be obtained even if the allowable value information is included in the schema information. For example, the attributetypes attribute that holds the type of each attribute may hold the allowable value of that attribute.

Note that among the attributes held by the directory server 2, there is an attribute such as a mail address, which is an arbitrary character string as a whole but partially becomes a predetermined character string. .

In order to cope with such attributes, FIG.
, An allowable value definition using a wild card (*) may be provided. For example, when an allowable value is defined as shown in FIG. 8, a request to add or change an email address attribute (49 or 5
When 1) is received, the allowable value management unit of the directory server 2
8 is "@ abc.com" after the attribute value after addition or change
The request will be granted only if it contains, otherwise (for example, "@ abcd.com") will violate the allowable value.

In this case, the entry editing unit 24 in the directory client 1 of the second embodiment is
The screen 40 may be generated such that a part corresponding to a wild card is input as in the mail address input area 47 of the above.

[0058]

According to the present invention, registration of an erroneous attribute value can be prevented beforehand, and the operability of the directory system can be improved. Further, according to the present invention, it is possible to improve the usability when the user inputs the attribute value.

[Brief description of the drawings]

FIG. 1 is a functional configuration diagram of a directory server in a first embodiment.

FIG. 2 is a system configuration diagram of a directory server in the first embodiment.

FIG. 3 is a functional configuration diagram of a directory client used for defining an allowable value in the first embodiment.

FIG. 4 is a functional configuration diagram of a directory client used for entry editing in a second embodiment.

FIG. 5 is an explanatory diagram of an operation related to an allowable value extraction process in the first embodiment.

FIG. 6 is an explanatory diagram of an operation related to an allowable value registration process in the first embodiment.

FIG. 7 is an explanatory diagram of an operation related to an allowable value confirmation process in the first embodiment.

FIG. 8 is a diagram illustrating a configuration example of allowable value definition information according to the first embodiment.

FIG. 9 is a diagram illustrating an example of a directory tree according to the first embodiment.

FIG. 10 is a diagram illustrating a screen display example of an allowable value defining operation in the first embodiment.

FIG. 11 is a diagram illustrating a screen display example of an entry addition operation according to the second embodiment.

FIG. 12 is an explanatory diagram of a directory access request.

FIG. 13 is a diagram showing a communication sequence in the first and second embodiments.

[Explanation of symbols]

 DESCRIPTION OF SYMBOLS 1 ... Directory client, 2 ... Directory server, 3 ... Network, 4 ... Entry management part, 5 ... DB, 6 ... Schema management part, 7 ... Schema management table, 8 ... Permissible value management part, 9 ... Permissible value management table, DESCRIPTION OF SYMBOLS 10 ... Protocol analysis part, 11 ... Communication control part, 19 ... Directory access part, 20 ... Schema definition part, 21 ... Schema acquisition part, 22 ... Permissible value definition part, 23 ... Permissible value acquisition part, 24 ... Entry editing part.

Continued on the front page (72) Inventor Kenta Shiga 1099 Ozenji Temple, Aso-ku, Kawasaki City, Kanagawa Prefecture Inside System Development Laboratory, Hitachi, Ltd. In System Development Laboratory (72) Inventor Hakuyasu Kotaki 5030 Totsuka-cho, Totsuka-ku, Yokohama-shi, Kanagawa Prefecture F-term in Hitachi Software Co., Ltd. F-term (reference) 5B082 EA01 HA00

Claims (6)

[Claims] 1. A directory system comprising: a directory server having means for registering an attribute value related to an attribute of a directory entry having at least one attribute; and a directory client, wherein the directory server has a registrable attribute value. Characterized in that the directory system has means for preliminarily storing the information. 2. The directory system according to claim 1, wherein the directory server determines whether an attribute value requested to be registered matches the held registerable attribute value, and A directory system comprising means for rejecting registration of an attribute value that does not conform to a possible attribute value. 3. The directory system according to claim 1, wherein the directory client acquires a registerable attribute value held in the directory server, and displays the acquired registerable attribute value as an option. A directory system comprising: 4. The directory system according to claim 1, wherein said directory server has means for converting information relating to said registerable attribute value into a reference directory entry of said information. 5. The directory system according to claim 1, wherein said directory server has a directory entry holding information on said registerable attribute value. 6. The directory system according to claim 2, wherein said matching determination means with said registrable attribute value makes a determination based on a full match or a partial match.