Picking to http://www.igenus.org/old_version/resource/ldap/ldap.htm
What is LDAP?
LDAP's English full name is Lightweight Directory Access Protocol, generally referred to as LDAP. It is based on X.500 standard, but it is more simple and can be customized as needed. Unlike X.500, LDAP supports TCP / IP, which is necessary to access the Internet. The core specification of LDAP is defined in RFC, all of which are found in the LDAPMAN RFC web page. Now LDAP technology has not only developed very quickly and is also exciting. Implementing LDAP within an enterprise allows all applications running on almost all computer platforms to get information from the LDAP directory. Various types of data can be stored in the LDAP directory: email address, mail routing information, human resource data, public key, contact list, and more. By putting the LDAP directory as an important part of the system integration, you can simplify the steps of the employee's internal query information, and even the main data sources can be placed anywhere.
Advantages of the LDAP directory
If you need to develop a system that provides a public information query may be a web-based database design method, that is, the front-end uses a browser and the back office uses the web server plus a relational database. The rear end is typically implemented in Windows, which may be a Windows NT Iis Acess database or SQL server, IIS, and databases are connected by ASP technology using ODBC to reach the function of filling out form query data;
The rear end is a typical implementation of the Linux system probably Linux Apache PostgreSQL, Apache and the database to connect through the function provided by the PHP3. The disadvantage of using the above method is that the introduction of the backend relational database is caused by the overall performance reduction of the system and the management of the system, because the confirmation of the verification of the data type is required and the integrity of the transaction; and the front-end user's control is not enough to control the data. Flexible, the settings of user privileges can only be set at the table level instead of setting the recording level.
The launch of directory services is mainly to solve problems in the above database. The directory is similar to the relational database, refers to the descriptive property-based record collection, but its data type is primarily characteristic. In order to retrieve the need to add BIN (binary data), CIS (ignore the case), CES (size) Write sensitive), Tel (phone type), Syntax, rather than the integer, floating point, date, currency, etc. provided by the relational database, the same, not to provide a large number of functions contained in the relational database, it mainly Data Query Services (query and modification operation ratio is generally greater than 10: 1), no rollback mechanism for transactions, its data modification uses simple lock mechanism to implement all-or-nothing, its goal is fast Responsive and large-capacity queries and provide information replication capabilities for multi-directory servers.
It is now what the LDAP directory is now. Now the pop of LDAP is the result of many factors. Possible LDAP's biggest advantage is to access the LDAP directory on any computer platform, client programs that are easy to get and the number of LDAPs that are easy to obtain. And it is also easy to customize the application to add LDAP support.
The LDAP protocol is a cross-platform and standard protocol, so the application is not worried on what kind of server that is put on the LDAP directory. In fact, LDAP has been widely recognized because it is the standard of Internet. The manufacturer is willing to join the support for LDAP in the product because they don't have to consider the other end (client or server). The LDAP server can be any of the development source code or commercial LDAP directory server (or may also be a relational database with an LDAP interface) because the same protocol can be used to interact with the LDAP server with the same protocol. Unlike LDAP, if the software monographer wants to integrate support to DBMS in software products, you usually have to customize each database server. Not like a lot of commercial relational databases, you don't have to connect to each client connection of LDAP or a lot of LDAP servers to be installed and easy to maintain and optimize. The LDAP server can replicate some or all data with "push" or "pull" method, for example: push data "to" to remote office to increase data security. The replication technology is built in the LDAP server and it is easy to configure. If you want to use the same replication function in DBMS, database products will have to pay additional costs and are difficult to manage.
LDAP allows you to use ACI (generally referred to as ACL or Access Control List) as needed to control permissions to data read and write. For example, the device administrator can have the right to change the staff's work location and office numbers, but do not allow other domains in the record. ACI can access data, what is accessible, and other data exists and other data existence. Because these are done by the LDAP directory server, don't worry about whether security checks are required on the client's application.
LDAP (LightWeight Directory Acess Protocol) is an implementation of directory services on TCP / IP (RFC 1777 V2 and RFC 2251
V3 version). It is a transplantation of the X500 directory protocol, but simplifies the implementation method, so it is called a lightweight directory service. The directory in the LDAP is based on the tree structure organization, the directory consists of entry (entry), the entry is equivalent to the record of the table in the relational database; the entry is the distinction name DN (Distinguisheduished
Name) Attribute (Attribute) Collection, DN is equivalent to keywords in relational database tables (Primary
Key); Property consists of type (Type) and multiple values (VALUES), which is equivalent to the domain in the relational database consists of domain name and data type, just for convenient retrieval, Type in the LDAP can have multiple Value, rather than all domains implemented in reducing data redundancy in relational databases must be unrelated. The organizations in the LDAP are generally organized in accordance with geographic and organizational relationships. LDAP stores the data in the file and uses an index-based file database to improve efficiency, not a relational database. The LDAP protocol set also specifies DN naming methods, access control methods, search formats, replication methods, URL formats, development interfaces, etc.
LDAP is most useful for such storage such information, that is, data needs to be read from different locations, but do not need to be updated frequently.
For example, this information is stored in the LDAP directory:
l Company employee phone number book and organizational map
l Customer contact information
l Computer management needs, including NIS mapping, email fake name, etc.
l Configuration information of the package
l Public certificate and security key
When should most of the LDAP storage data is a special optimization for read-intensive operations. Therefore, when reading data from the LDAP server, you will read the data faster than a quantity level in a relational database that is specifically OLTP optimized. It is also because of the optimization of read performance, most of the LDAP directory servers are not suitable for storing data that requires frequent changes. For example, using an LDAP server to store a phone number is a good choice, but it cannot be used as a database server in an e-commerce site.
If the answer to each question below is "YES", it is a good idea to exist in LDAP.
l Do you need to read data on any platform?
l Every individual record item does not change every day?
l Do you have a flat database (FLAT DATABASE) instead of the relational database? In other words, no matter what paradigm is not paradigital, there is a record in a record (almost just satisfying the first paradigm).
The last problem may be put someone, and it is also very common to store some relationships with a flat database. For example, a record of a company employee can contain managed names. It is convenient to store such information with LDAP. A simple judgment: If you can put the guaranteed data in a card, you can easily exist it in the LDAP directory.
Safety and access control
LDAP provides a very complex different level of access control or ACI. Because these accesss can be controlled at server-side, this is much more secure than using the client's software.
With LDAP ACI, you can complete:
l Give the user to change their own phone number and home address, but restrict them for other data (eg, job name, manager's login name, etc.) only "Read" permission.
l Given all human rights in the "HR-Admins" group to change the information about these users: manager, work name, employee number, department name and department number. But there is no write permission to other domains.
l Disable anyone from querying the user password on the LDAP server, but can allow users to change his or her password.
l Give the manager to access the only-read permissions of their superiors, but others have this permission.
l Creating, deleting, and editing all of the "Host-Admins" groups all saved in the LDAP server information related to the computer host
l Vials through the web, allowing members in the "FOOBAR-SALES" group to choose or prohibit them from reading some client contact data. This will allow them to download customer contact information to a local laptop or personal digital assistant (PDA). (If the salesperson's software supports LDAP, this will be very useful)
l Via the web, allowing the owner of the group to delete or add members of the group they own. For example: The sales manager can be allowed to give or prohibit the privileges of the salesperson to change the Web page. You can also allow the owner of mail aliase to delete or add users directly from the mail pseudonym without IT technicians. "Public" mailing list should allow users to add or delete themselves from the mail pseudonym (but can only be themselves). You can also limit the IP address or host name. For example, some domains only allow user IP addresses to be read by 192.168.200. *, Or the user reverse lookup DNS is * .foobar.com.
LDAP directory tree structure
The LDAP directory stores data in a tree hierarchy. If you are familiar with the directory tree of the top DNS tree or UNIX file, it is easy to master the concept of the LDAP directory tree. Like the host name of DNS, the Distinguished Name, DN) is used to read a single record, and back to the top of the tree. It will be described in detail later. Why use hierarchies to organize data? There are many reasons. Below is some of the cases that may encounter:
l If you want to "push all the contact information of all US customers" to the LDAP server where you go to the Seattle Office (responsible for marketing), you don't want to put the company's asset management information "push" there.
l You may want to give different permissions of different employee groups according to the structure of the directory tree. In the following example, the Asset Management Group has full access to the "Asset-Mgmt" section, but it cannot be accessed elsewhere.
l Combine the LDAP storage and replication capabilities to customize the structure of the directory tree to reduce the requirements for WAN bandwidth. The marketing office in Seattle requires information about the US sales status updated per minute, but the sales of Europe will be updated once every hour.
Plane roots: Benchmark DN
The top of the LDAP directory tree is root, which is called "baseline DN". Benchmark DN usually uses one of the three formats listed below. Assume that I worked in an e-commerce company called Foobar, the name on the Internet is foobar.com.
o = "FOOBAR, INC.", C = US
(Baseline DN represented in X.500 format)
In this example, o = foobar, Inc. represents the organization name, here is the synonym of the company name. C = US is the company's headquarters in the United States. In this way, this approach is generally used to represent the reference DN. But things are always changing, and now all companies have (or planned) on the Internet. With the globalization of the Internet, it is easy to confuse in the base DN. Now, the X.500 format is developed into the two formats listed below.
o = foobar.com
(Baseline DN represented by the company's Internet address)
This format is very intuitive, and the company's domain name is used as a reference DN. This is also the most common format now.
DC = foobar, DC = COM
(Better DN of different parts of DNS domain name)
As in the format above, this format is also based on the DNS domain name, but the format above does not change the domain name (it is more readily read), and this format is divided into domain name: foobar.com into two parts DC = FOOBAR , DC = COM. In theory, this format may be more flexible, but it is more difficult to remember for end users. Consider the example of foobar.com. When FOOBAR.COM and GIZMO.COM merge, "DC = COM" can be used as a reference DN. Put new records in the existing DC = GizMo, DC = COM directory, which simplifies a lot of work (of course, if foobar.com and wocket.edu merge, this method can not be used). If the LDAP server is new, I suggest you use this format. Please note that if you plan to use the ACTRIVE DIRECTORY, Microsoft has restricted you must use this format.
More on the top floor: How to organize data in the directory tree
In the UNIX file system, the top layer is root (root). There are a lot of files and directories below the root directory. As mentioned above, the LDAP directory is also organized in the same way. In the root directory, you want to separate the data from logically. Because of the cause of history (X.500), most LDAP directories are separated from logically to logically. OU means "Organization Unit", in the X.500 protocol, is used to represent the company's internal organization: sales department, finance department, and so on. Now LDAP also retains the OU = this naming rule, but expands the scope of the classification, can be classified as: ou = people, ou = groups, ou = devices, and so on. The lower level of OU is sometimes used for finer classification. For example: the LDAP directory tree (excluding separate records) may be like this:
DC = foobar, DC = COM
Ou = Customers
Ou = asia
OU = Europe
OU = USA
OU = Employees
Ou = rooms
Ou = groups
OU = assets-mgmt
Ou = nisgroups
OU = Recipes
Separate LDAP record
DN is the name of the LDAP record item
All record items in the LDAP directory have a unique "distinguished name", which is DN. The DN of each LDAP record is composed of two parts: relative DN (RDN) and the location recorded in the LDAP directory.
RDN is a portion that is independent of the structure of the directory tree in DN. There is a name in the record item stored in the LDAP directory, which typically exists in the CN (Common Name) attribute. Because almost all things have a name, the object stored in LDAP uses their CN value as the foundation of RDN. If I put the favorite oatmeal recipe as a record, I will use CN = OATMEAL DELUXE as the RDN of the record.
l My LDAP directory benchmark DN is DC = FOOBAR, DC = COM
l I put my own recipe as an LDAP record item in Ou = Recipes
l My LDAP record item RDN is set to CN = OATMEAL DELUXE
The above constituting the complete DN of the LDAP record of oatmeal recipes. Remember, DN's reading and DNS host name are similar. Here is the complete DN:
CN = OATMEAL DELUXE, OU = Recipes, DC = FOOBAR, DC = COM
To give an actual example to explain DN
Now set a DN for the company's employees. CN or UID (User ID) can be used as a typical user account. For example, Fran Smith of FOOBAR Fran Smith can be the following two formats:
Uid = fsmith, ou = Employees, DC = FOOBAR, DC = COM
(Based on login)
LDAP (and X.500) uses UID to "User ID", do not confuse it and Unix's UID number. Most companies will give each employee's only login name, so this approach can save the employee's information. You don't have to worry that there will be a joined company named Fran Smith, if Fran changed her name (marriage? Divorce? Or religious cause?), It also does not need to change the DN of the LDAP record.
CN = fran smith, ou = Employees, DC = FOOBAR, DC = COM
(Based on the name)
You can see that this format uses Common Name (CN). You can regard the common name as a person's full name. This format has a significant disadvantage that if the name is changed, the LDAP record will be transferred from one DN to another DN. However, we should avoid changing the DN of a record item as much as possible.
Table type of directory
You can store various types of data objects with LDAP, as long as these objects can be represented by properties, below is some information that can be stored in LDAP:
l Employee information: Name, login name, password, employee number, his manager's login name, email server, and so on.
l Item tracking information: computer name, IP address, tag, model, location, and more.
l Customer contact list: Customer name, main contact phone, fax, email, etc.
l Conference Hall Information: The name of the conference hall, location, how many people can sit, phone numbers, whether there is a projector.
l Recipe information: Name, ingredient, cooking method, and preparation method.
Because the LDAP directory can be customized to store any text or binary data, what to do in the end is determined by yourself. The concept of the LDAP directory type (Object class "is defined what properties of which type of object running. In almost all LDAP servers, you have to create new object types or extend existing object types based on your own ability to extend basic LDAP directories.
The LDAP directory stores records in a series of "property pairs", each record item including attribute type and attribute value (which is fundamentally different from the relational database use row and columns). Below is a part of the recipe record I have in the LDAP directory:
DN: CN = OATMEAL DELUXE, OU = Recipes, DC = FOOBAR, DC = COM
CN: Instant Oatmeal Deluxe
Recipecuisine: Breakfast
Recipeingredient: 1 packet instant oatmeal
RecipeingRedient: 1 Cup Water
Recipeingredient: 1 Pinch Salt
RecipeingRedient: 1 TSP Brown Sugar
Recipeingredient: 1/4 Apple, Any Type
Note that each of the ingredients above is used as an attribute RecipeingRedient value. The LDAP directory is designed to save multiple values as an attribute, rather than separate a series of values in the back of each attribute.
Because stored data in this way, the database has great flexibility, and you don't have to recreate the tables and indexes for adding some new data. More importantly, the LDAP directory does not have to spend memory or hard disk space to process "empty" domain, that is, do not take any resources without using the optional domain.
A separate data item as an example
Let's take a look at the example below. We use Foobar, Inc. employee Fran Smith's LDAP record. The format of this record is LDIF to import and export record items for the LDAP directory.
DN: uid = fsmith, ou = Employees, DC = FOOBAR, DC = COM
ObjectClass: Person
ObjectClass: OrganizationalPerson
ObjectClass: inetorgperson
ObjectClass: FooBarperson
Uid: fsmith
Givenname: Fran
SN: Smith
CN: FRAN SMITHCN: FRANCES SMITH
Telephonenumber: 510-555-1234
Roomnumber: 122g
o: Foobar, Inc.
MailroutingAddress: fsmith@foobar.com
Mailhost: mail.foobar.com
Userpassword: {crypt} 3x1231v76t89n
UidNumber: 1234
GidNumber: 1200
Homedirectory: / home / fsmith
Loginshell: / usr / local / bin / bash
The value of the attribute is to keep the case in the preserved, but it is not case sensitive when searching by default. Some special properties (for example, password) require case sensitive when searching.
Let us analyze the above record items at a point.
DN: uid = fsmith, ou = Employees, DC = FOOBAR, DC = COM
This is the full DN of the FRAN's LDAP record, including the full path in the directory tree. LDAP (and X.500) uses the UID (User ID), do not confuse it with the UNIX UID number.
ObjectClass: Person
ObjectClass: OrganizationalPerson
ObjectClass: inetorgperson
ObjectClass: FooBarperson
Multiple object types can be assigned to any object as needed. The Person object type requires CN (Common Name) and SN (Surname) these two domains cannot be empty. The Persion object type allows other available domains, including Givenname, TelephoneNumber, and more. Organizational Person adds more optional domains to Person, iNetorgPerson add more optional domains (including email messages). Finally, FooBarPerson is a type of object customized object to the Foobar, joining a lot of custom properties.
Uid: fsmith
Givenname: Fran
SN: Smith
CN: Fran Smith
CN: FRANCES SMITH
Telephonenumber: 510-555-1234
Roomnumber: 122G
o: Foobar, Inc.
I have said before, the UID represents the User ID. When you see the UID, I want to "login" in my head.
Note that CN has multiple values. As mentioned above, LDAP allows some values to be available. Why is there a number of values? Assume that you look for FRAN's phone numbers in the company's LDAP server. You may only know that her name is Fran, but her official name is FRANCES for people in Human Resources. Because of her two names, I can find FRAN's phone number, email and office room number, and so on with any name.
MailroutingAddress: fsmith@foobar.com
Mailhost: mail.foobar.com
Just like most companies now, Foobar sends mail and handles external mail routing information with Sendmail. Foobar exists in LDAP on all users' mail messages. The latest version of Sendmail supports this feature.
Userpassword: {crypt} 3x1231v76t89n
UidNumber: 1234
GidNumber: 1200
Gecos: Frances Smith
Homedirectory: / home / fsmith
Loginshell: / usr / local / bin / bash note, FOOBAR system administrators also exist in LDAP in LDAP in LDAP. The object of the FoobarPerson type has this ability. Note, the user password is stored in the password format of UNIX. UNIX's UID is here UidNumber. Remind you that there is a complete RFC on how to save NIS information in LDAP. In the later article, I talk about NIS integration.
LDAP replication
LDAP servers can use "push" or "pull" technology, with simple or security-based security verification, copy part or all data.
For example, foobar has a "common" LDAP server, address is ldap.foobar.com, with port 389. Netscape Communicator's email query feature, UNIX's "ph" command To use this server, users can also query employees and customer contact information on this server anywhere. The company's primary LDAP server runs on the same computer, but the port number is 1389.
You may not want employees to query asset management or recipe information, and do not want information technicians to see the LDAP directory of the entire company. In order to solve this problem, Foobar selectively copy the subdirectory tree from the primary LDAP server to the "public" LDAP server, and does not require hidden information. In order to keep the data, the primary directory server is set to instantly "push" synchronization. These methods are mainly for convenience, not safety, because if there is permissionable user wants to query all the data, you can use another LDAP port.
Assume that Foobar contacts LDAP management clients with LDAP management clients from LDAP to Europe's low-bandwidth data. You can create data from ldap.foobar.com: 1389 to Munich- LDap.foobar.com: 389, like this:
Periodic Pull: OU = Asia, Ou = Customers, O = Sendmail.com
Periodic Pull: OU = US, OU = Customers, o = sendmail.com
Immediate push: ou = europe, ou = customers, o = sendmail.com
The "pull" connection is synchronized every 15 minutes, which is sufficient to assume it above. "Push" connection guarantees that any European contact information is immediately "pushed" to Munich.
Use the above copy mode, which server needs to be connected to the data? Users in Munich can easily connect to the local server. If they change the data, the local LDAP server will pass these changes to the primary LDAP server. Then, the primary LDAP server puts these changes "push" back to the local "public" LDAP server to keep data synchronization. This has a great advantage for local users, because all queries (mostly reading) are on the local server, and the speed is very fast. When you need to change information, the end user does not need to reconfigure the client's software because the LDAP directory server has completed all of the data exchanges.
