What is LDAP? (Transfer from http://www.sczg.com/) LDAP "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 you to get all the applications running on almost all computer platforms 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 within the internal query information, and even the main data sources can be placed anywhere. The advantage of the LDAP directory If you need to develop a system that provides public information queries, the general design method of the Web may be used in web-based database design, that is, the front-end uses the browser and the rear end uses the Web server plus the relational database. The rear end is typically implemented in Windows NT IIS Acess database or SQL server, IIS, and databases are connected by ASP technology with ODBC, reaching the functionality of filling out form query data; typical rear end in Linux system Implementation may be Linux Apache PostgreSQL, Apache, and databases are connected via a function provided by 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 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, client connection package and query command. Unlike LDAP, if the software monographer wants to integrate support to DBMS in software products, it is usually customized to each database server. Not like a lot of commercial relational databases, you don't have to connect to each client connection of LDAP or to pay most of the LDAP server 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, the database manufacturer will pay an additional fee and it is 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 work location and office number of the employee, but do not allow other domains in the record. ACI can access data, access to what data, and other data, and other access to data. Because these are all done by the LDAP directory server, so you don't have to worry about whether you want to perform a security check on the approved application. LDAP (LightWeight Directory Acess Protocol) is an implementation of directory services on TCP / IP (RFC 1777 V2 and RFC 2251 V3). It is a transplantation of the X500 directory protocol, but simplifies the implementation method, so it is called a lightweight directory service. In the LDAP, the directory is composed of the tree structure organization, the directory is composed of entry (entry), the entry is equivalent to the record of the table in the relational database; the entry is the attribute (attribute) collection of DNTINGUISHED NAME, DN is equivalent to the relationship Primary Key in the database table; the property consists of type (type) and multiple values (VALUES), which is equivalent to the domain (field) in the relational database consists of domain name and data type, just to facilitate retrieval, The Type in the LDAP can have multiple values instead of all domains implemented in the relational database to reduce the redundancy requirements of data. 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 the DN naming method, access control method, search format, replication method, URL format, development interface, etc. LDAP is most useful for such storage such that data is used, that is, data needs to be read from different locations, but No need to update frequently. For example, this information is stored in the LDAP directory is very valid: l Company employee's phone number book and organizational structure diagram l Customer contact information l Computer management needs, including NIS mapping, email fake name, etc. L package Configuration Information L Users When you use LDAP storage data, most of the LDAP servers use LDAP servers 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 method: If you can save your label in a piece of card, you can easily put 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's ACI, you can complete: l Give users their own phone numbers and home addresses, but limits them to other data (eg, job names, manager login names, etc.) only "read only" permissions. 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 Create, delete, and edit anyone in the "Host-Admins" group, all saved information about the computer host in the LDAP server, allows members in the "Foobar-Sales" group to choose or disable the members in the "FOOBAR-SALES" group. They read some of the customer's read rights. 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, it will be very useful) l Via the web, allowing the owner of the group to delete or add members of their group. 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. The structure of the LDAP directory tree 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 IDUISHED NAME (DN) of the LDAP directory record 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 be encountered: L If you want to "push" all the contact information of all US customers ("push" to the LDAP server in the Seattle Office (responsible for marketing), you don't want to put the company's asset management information "
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. Subject to the planing: the top of the benchmark DN LDAP directory tree is root, which is the so-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 in X.500 format) In this example, O = foobar, incm, indicating 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 (Baseline DN of DNS Domain Name) is like 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 Read), and this format divides the 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, simply use "DC = COM" as a base 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 next level: 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 still retains the naming rules of OU =, but expands the scope of the classification, can be classified as: OU = people, ou = groups, ou = devices, and more.
The lower level of OU is sometimes used for finer classification. For example: LDAP directory tree (excluding separate records) may be like this: DC = foobar, DC = COM ou = Customers OU = asia = Europe = 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 in the LDAP directory has 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 LDAP record items Ou = Recipes L My LDAP record item RDN set to CN = OATMEAL DELUXE Top these forms of oatmeal Complete DN of LDAP Record of Porridge Recipe. Remember, DN's reading and DNS host name are similar. Here is a complete DN: CN = OATMEAL DELUXE, OU = Recipes, DC = FOOBAR, DC = COM to explain that DN now sets 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 is a DN of Fran Smith (FSMITH) can be the following two formats: uid = fsmith, ou = Employees, DC = FOOBAR, DC = COM (based on login) LDAP (and X.500) UID means "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 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. Types of custom directory You can store various types of data objects with LDAP, as long as these objects can be represented by properties, the following is some information that can be stored in LDAP: l Employee information: Name, login name, password , Employee, his manager's login name, mail server, etc.
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 "properties pairs", each record items including attribute types and attribute values (this is fundamentally different from the relational database lines and columns). Here is my present as part of the recipe record 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 Please note that each of the ingredients 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 following example. 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 Smith cn: 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 The value of the / bin / bash property is saved when saved, 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 item, including the full path to 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 can assign multiple object types 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: Fran Smith CN: FRAN SMITH CN: FRAN SMITH TelephonEnumber: 510-555-1234 Roomnumber: 122g o: Foobar, Inc., UID said 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 the people of the 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 is like now, and 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 administrator puts all users password map information also exists in LDAP in. 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 of the 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 has optionally 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 "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 be easily connected 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. How does SAS interact with LDAP? SAS Integration Technologies software provides application interfaces that enable you to develop SAS programs using either the DATA step or SAS Component Language (SCL) that utilize directory services. These interfaces enable SAS distributed application components to share a common application directory with components that execute in other Run-Time Environments Across The Distributed Enterprise.
