Many netizens may be like me, to learn LDAP, but it is still very strange! So I sorted out my learning experience, sharing with everyone, learn it before, know what it is? And know what the function is? Especially LDAP, what do you want to understand? How is it arranged!
OK, then let's know what is LDAP, here there are two more authoritative information, divided into English! Thank you for expressing your author's Open spirit!
Attachment: Tongxo's E text is not very good, watching English version is very hard! There are two Chinese and English comparisals. They have helpful to learn LDAP and E Wen, huh, really so-called stone two birds, huh, is also an arrow and carved! Ah...
Original address: http://ldapman.org/Articles/intro_to_ldap.html
An Introduction to LDAP
Michael Donnelly
If you work in the computing industry, the chances are good that you've heard of LDAP by now. Wondering what all the excitement is about? Want to know a little more about the underlying technology? You've come to the right place. This introduction - the first in a series of articles describing how to design, implement, and integrate an LDAP environment at your company -. will familiarize you with the concepts behind LDAP while leaving the really hardcore details for later Here, we'll touch on The Following Topics:
What is LDAP, anyway? When should you use LDAP to store your data? The structure of an LDAP directory tree Individual LDAP records Customizing your directory's object classes An example of an individual LDAP entry LDAP replication Security and access control
To start with, what's happening with LDAP today is exciting. A company-wide LDAP implementation can enable almost any application, running on almost any computer platform, to obtain information from your LDAP directory. And that directory can be used to store a broad range of data: email address and mail routing information, HR data, public security keys, contact lists, and much more By making an LDAP directory a focal point in your systems integration, you're providing one-stop shopping whenever people go looking for. information within your company - even if the primary source of the data lives elsewhere.But wait, you say you're already using an Oracle, Sybase, Informix, or Microsoft SQL database to store much of that same data How is LDAP different.. ? What makes it beetter? Read on.
What is ldap, annily?
The Lightweight Directory Access Protocol, better known as LDAP, is based on the X.500 standard, but significantly simpler and more readily adapted to meet custom needs. Unlike X.500, LDAP supports TCP / IP, which is necessary for Internet access. .
"LDAP" in A Sentence in Everyday Conversation, You'll Hear Well-Intentioned People Say Things Like, "Should We Be Storing That In LDAP?" OR "Just Get That Data from the LDAP DATABASE," OR "HOW WE go about tying LDAP into an RDB? "Strictly speaking, though, LDAP is not a database at all, but a protocol used to access information stored in an information directory (also known as an LDAP directory). A more precise formulation might look something like this: "Using LDAP, data will be retrieved from (or stored in) the correct location within our information directory." But you will not find me correcting anyone on this point: either way, you get the idea across, and that's what counts.Is an LDAP information directory a database? Just as a Database Management System (DBMS) from Sybase, Oracle, Informix, or Microsoft is used to process queries and updates to a relational database, an LDAP server is used to process queries And Updates to an LDAP Information Directory. in Other Words, AN L DAP information directory is a type of database, but it's not a relational database And unlike databases that are designed for processing hundreds or thousands of changes per minute -. Such as the Online Transaction Processing (OLTP) systems often used in e-commerce - LDAP Directories Are Heavily Optimized for Read Performance.
The advantages of LDAP directories Now that we've straightened that out, what are the advantages of LDAP directories? The current popularity of LDAP is the culmination of a number of factors. I'll give you a few basic reasons, provided you keep in Mind That It's Just Part of The Story.
Perhaps the biggest plus for LDAP is that your company can access the LDAP directory from almost any computing platform, from any one of the increasing number of readily available, LDAP-aware applications. It's also easy to customize your company's internal applications to add LDAP support .The LDAP protocol is both cross-platform and standards-based, so applications need not worry about the type of server hosting the directory. In fact, LDAP is finding much wider industry acceptance because of its status as an Internet standard. Vendors are more willing to write LDAP integration into their products because they do not have to worry about what's at the other end. Your LDAP server could be any one of a number of open-source or commercial LDAP directory servers (or perhaps even a DBMS server WITH An LDAP Interface, Since Interacting With Any True LDAP Server Involves The Same Protocol, Client Connection Package, And Query Commands. by Contrast, Vendors Looking To Integrate Directly with a DBMS Usually Must Tailor Their Product To Work with Each Database Server Vendor Individally.
Unlike Many Relational Databases, You Do Not Have To Pay for Either Client Connection Software or for Licensing.
Most LDAP Servers Are Simple To Install, Easily Maintained, And Easily Optimized.
LDAP servers can replicate either some or all of push via their data or pull methods, allowing you to push data to remote offices, to increase security, and so on. The replication technology is built-in and easy to configure. By contrast, many Of The Big DBMS Vendors Charge Extra for this Feature, And It's Far More Difficult to Manage.
LDAP allows you to securely delegate read and modification authority based on your specific needs using ACIs (collectively, an ACL, or Access Control List). For example, your facilities group might be given access to change an employee's location, cube, or office number , but not be allowed to modify entries for any other fields. ACIs can control access depending on who is asking for the data, what data is being asked for, where the data is stored, and other aspects of the record being modified. This is all done through the LDAP directory directly, so you need not worry about making security checks at the user application level.LDAP is particularly useful for storing information that you wish to read from many locations, but update infrequently. for example, your company could Store All of The Following Very EfficIntly in an LDAP Directory:
The company employee phone book and organizational chart External customer contact information Infrastructure services information, including NIS maps, email aliases, and so on Configuration information for distributed software packages Public certificates and security keys
When SHOULD you use ldap to store your data?
Most LDAP servers are heavily optimized for read-intensive operations. Because of this, one can typically see an order of magnitude difference when reading data from an LDAP directory versus obtaining the same data from a relational database server optimized for OLTP. Because of this optimization , however, most LDAP directories are not well suited for storing data where changes are frequent. for instance, an LDAP directory server is great for storing your company's internal telephone directory, but do not even think of using it as a database back end for Your High-Volume E-Commerce Site.if The Answer To Each of The Following Questions IS YES, The Storing Your Data IN LDAP IS A Good Idea.
Would you like your data to be available cross-platform? Do you need to access this data from a number of computers or applications? Do the individual records you're storing change a few times a day or less, on average? Does it make SENSE TO STORE THISTABASE INSTETA IN A FLAT DATABASE INSTET OF A RELATIONAL DATABASE? THAT IS, COLD YOU EFFECTILY STORE ALL THE DATA for A GIVEN ITEM IN A SINGLE RECORD?
This final question often gives people pause, because it's very common to access a flat record to obtain data that's relational in nature. For example, a record for a company employee might include the login name of that employee's manager. It's fine to use LDAP to Store this Kind of Information. rule of thumb: if you can images, you.................. ..
The Structure of An LDAP Directory Tree
LDAP directory servers store their data hierarchically. If you've seen the top-down representations of DNS trees or UNIX file directories, an LDAP directory structure will be familiar ground. As with DNS host names, an LDAP directory record's Distinguished Name (DN for short) is read from the individual entry, backwards through the tree, up to the top level More on this point later.Why break things up into a hierarchy There are a number of reasons Here are a few possible scenarios.?.:
You may wish to push all your US-based customer contact information to an LDAP server in the Seattle office (which is devoted to sales), whereas you probably do not need to push the company's asset management information there. You may wish to grant permissions to a group of individuals based on the directory structure. In the example listed below, the company's asset management team might need full access to the asset-mgmt section, but not to other areas. Combined with replication, you can tailor the layout of Your Directory Structure To Minimize Wan Bandwidth Utilization. Your Sales Office In Seattle Might Need Up-to-The Minute Updates for US Sales Contacts, But Only Hourly Updates for European Sales Information.
Getting to the root of the matter: Your base DN and you The top level of the LDAP directory tree is the base, referred to as the A base DN usually takes one of the three forms listed here Let's assume I "base DN.". Work at a US Electronic Commerce Company Called Foobar, Inc., Which is on the Internet at foobar.com.
O = "FOOBAR, INC.", C = US (Base DN IN X.500 Format) in this Example, O = FOOBAR, Inc. Refers to the Organization, Which in this context shouth the company name. .. c = US indicates that the company headquarters is in the US Once upon a time, this was the preferred method of specifying your base DN Times and fashions change, though; these days, most companies are (or plan to be) on the Internet. And what with Internet globalization, using a country code in the base DN probably made things more confusing in the end. in time, the X.500 format evolved into the other formats listed below.o = foobar.com (base DN derived from the company's Internet presence) This format is fairly straightforward, using the company's Internet domain name as the base. Once you get past the o = portion (which stands for organization =), everyone at your company should know where the rest came from. This Was, UnTil Recently, Probably the MOST Common of The Currently Used Formats.
dc = foobar, dc = com (base DN derived from the company's DNS domain components) As with the previous format, this uses the DNS domain name as its basis. But where the other format leaves the domain name intact (and thus human-readable ), this format is split into domain components: foobar.com becomes dc = foobar, dc = com In theory, this could be slightly more versatile, though it's a little harder for end users to remember By way of illustration, consider foobar.. .com. When foobar.com merges with gizmo.com To Go. (of Course, this approach doesn't help if foobar.com merges with wocket.edu.) this is the format'd recomment for any new installations. Oh, and if you're planning to use activ directory, Microsoft Has Already Decided for you today this is the format you wanted.time to branch: how to Organize your data in your directory Tree in a Unix File System, The Top Level Is The Root. Beneath The root you have.com. AS Mentioned Above, LDAP Directories Are Set Up in Much The Same Manner.
Underneath your directory's base, you'll want to create containers that logically separate your data. For historical (X.500) reasons, most LDAP directories set these logical separations up as OU entries. OU stands for "Organizational Unit," which in X .500 was used to indicate the functional organization within a company:. sales, finance, et cetera Current LDAP implementations have kept the ou = naming convention, but break things apart by broad categories like ou = people, ou = groups, ou = devices And So on. Lower Level Ous Are Sometimes Used to Break Categories Down Further. for Example, An LDAP Directory Tree (Not Including Individual Entries) Might Look 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
Individual LDAP Records
? What's in a name The DN of an LDAP entry All entries stored in an LDAP directory have a unique "Distinguished Name," or DN The DN for each LDAP entry is composed of two parts:. The Relative Distinguished Name (RDN) and the Location within the ldap directory where the record resides.
The RDN is the portion of your DN that is not related to the directory tree structure. Most items that you'll store in an LDAP directory will have a name, and the name is frequently stored in the cn (Common Name) attribute. Since nearly everything has a name, most objects you'll store in LDAP will use their cn value as the basis for their RDN. If I'm storing a record for my favorite oatmeal recipe, I'll be using cn = Oatmeal Deluxe as the Rdn of my entry.
My directory's base DN is dc = foobar, dc = com I'm storing all the LDAP records for my recipes in ou = recipes The RDN of my LDAP record is cn = Oatmeal DeluxeGiven all this, what's the full DN of the LDAP record for THIS OATMEAL RECIPE? Remember, IT Reads Backwards - Just Like A Host Name in DNS.
CN = OATMEAL DELUXE, OU = Recipes, DC = FOOBAR, DC = COM
People are always more trouble than inanimate objects Now it's time to tackle the DN of a company employee. For user accounts, you'll typically see a DN based either on the cn or on the uid (User ID). For example, the DN For Foobar's Employee Fran Smith (Login Name: fsmith) Might Look Like Either of these Two Formats:
UID = fsmith, oo = Employees, DC = FOOBAR, DC = COM (login-based) LDAP (AND X.500) USE Uid to mean "user id", not to be confused with the unix uid number. MOST companies TRY TO give everyone a unique login name, so this approach makes good sense for storing information about employees. you do not have to worry about what you'll do when you hire the next Fran Smith, and if Fran changes her name (marriage? divorce ? Religious Experience?), you Won't have to change the dn of the ldap entry.
CN = FRAN Smith, OU = Employees, DC = FOOBAR, DC = Com (name-based) Here We See The Common Name (CN) Entry Used. in The Case of An LDAP Record for a Person, Think of The Common Name AS . their full name One can easily see the downside to this approach:. if the name changes, the LDAP record has to "move" from one DN to another As indicated above, you want to avoid changing the DN of an entry whenever possible.
Customizing your directory's object classes
You can use LDAP to store data on almost any type of object, as long as that object can be described in terms of various attributes Here are a few examples of information you might store:. Employees: What's the employee's full name, login name, ? password, employee number, manager's login, mail server Asset tracking: What's the computer name, IP address, asset tag, make and model information, physical location Customer contact lists:? What's the customer's company name The primary contact's phone, fax,? and email information Meeting room information:? What's the room name, location, seating capacity, telephone number Is there wheelchair access Is there an overhead projector Recipe information:??? Give the name of the dish, the list of ingredients, the type of Cuisine, And Instructions for preparing it.
Because your LDAP directory can be customized to store any type of text or binary data, what you store is really up to you. LDAP directories use the concept of object classes to define which attributes are allowed for objects of any given type. In almost every ....................
LDAP directories store all information for a given record's entries as a series of attribute pairs, each one consisting of an attribute type and an attribute value. (This is completely different from the way relational database servers store data, in columns and rows.) Consider This Portion of My Recipe Record, AS Stored In An LDAP Directory:
DN: CN = OATMEAL DELUXE, OU = Recipes, DC = FOOBAR, DC = COM
CN: Instant Oatmeal Deluxe
Recipecuisine: BreakfastRecipeingred: 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 in this case, each ingredient is listed as a value of attribute type recipeIngredient. LDAP directories are designed to store multiple values of a single type in this fashion, rather than storing the entire list in a single database field with some sort of delimiter To distinguish the individual value.
Because the data is stored in this way, the shape of the database can be completely fluid - you do not need to recreate a database table (and all its indexes) to start tracking a new piece of data Even more important, LDAP directories. Use no memory or storage to handle "Empty" Fields - in Fact, Having Unused Optional Fields COSTS You Nothing At ALL.
An Example of An Individual LDAP Entry
Let's look at an example. We'll use the LDAP record of Fran Smith, our friendly employee from Foobar, Inc. The format of this entry is LDIF, the format used when exporting and importing LDAP directory entries.
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 / bin / bash
To start with, attribute values are stored with case intact, but searches against them are case-insensitive by default. Certain attributes (like password) are case-sensitive when searching.Let's break this entry down and look at it piece by piece.
DN: uid = fsmith, ou = Employees, DC = FOOBAR, DC = COM
THIS IS The Full DN of Fran's LDAP Entry, Including The Whole path to the entry in The Directory Tree. LDAP (AND X.500) User ID, "NOT to be confused with the unix uid number.
ObjectClass: Person
ObjectClass: OrganizationalPerson
ObjectClass: inetorgperson
ObjectClass: FooBarperson
One can assign as many object classes as are applicable to any given type of object. The person object class requires that the cn (common name) and sn (surname) fields have values. Object Class person also allows other optional fields, including givenname, telephonenumber, and so on. The object class organizationalPerson adds more options to the values from person, and inetOrgPerson adds still more options to that (including email information). Finally, foobarPerson is Foobar's customized object class that adds all the custom attributes they wish to TRACK AT THEIR Company.
Uid: fsmith
Givenname: Fran
SN: Smith
CN: Fran Smith
CN: FRANCES Smith
Telephonenumber: 510-555-1234
Roomnumber: 122g
o: Foobar, Inc.
AS Mentioned Before, Uid Stands for User ID. Just Translate It in Your Head to "Login" WHENEVER YOU SEE IT.
Note that there are multiple entries for the CN. As mentioned above, LDAP allows some attributes to have multiple values, with the number of values being arbitrary. When would you want this? Let's say you're searching the company LDAP directory for Fran's phone number. While you might know her as Fran (having heard her spill her guts over lunchtime margaritas on more than one occasion), the people in HR may refer to her (somewhat more formally) as Frances. Because both versions of her name are stored , Either Search Will SuccessFully Look Up Fran's Telephone Number, Email, Cube Number, And so on.mailroutingaddress: fsmith@foobar.com
Mailhost: mail.foobar.com
.
Userpassword: {crypt} 3x1231v76t89n
UidNumber: 1234
GidNumber: 1200
Gecos: Frances Smith
Homedirectory: / home / fsmith
Loginshell: / usr / local / bin / bash
Note that Foobar's systems administrators store all the NIS password map information in LDAP as well. At Foobar, the foobarPerson object class adds this capability. Note that the user password is stored in UNIX crypt format. The UNIX uid is stored here as uidnumber. Mind You, There's A WHOLE RFC ON Storing NIS Information In LDAP. I'll Talk About NIS Integration In A Future Article.
LDAP Replication
LDAP Servers Can Be Set To Replicate Some OR All of their Data, ON A Push OR A Pull Basis, Using Simple Authentication or Certificate-Based Authentication.
For example, Foobar has a "public" LDAP server running on ldap.foobar.com, port 389. This server is used by Netscape Communicator's pinpoint email addressing feature, the "ph" command from UNIX, and other locations where a user would want to query for the phone number of an employee or customer contact. The company's master LDAP server is running on the same system, but on port 1389 instead.You would not necessarily want employees searching the directory to query against asset management or recipe data, nor would it be desirable to see IT accounts (like "root") showing up on the company directory. to accomodate these unpleasant realities, Foobar replicates selected directory subtrees from its master LDAP server to its "public" server. The replication excludes subtrees containing To Keep Things Current At All Times, The Master Directory Server IS Set To Do Immediate Push-Based Synchronization. Note That This Approach Is Designed for Convenience, Not Security: The Idea is to allow power users to simply query the Other LDAP port if the want to search all available data.
Let's say Foobar is managing its customer contact information via LDAP, over a low bandwidth connection between Oakland and Europe They might set up replication from ldap.foobar.com:1389 to munich-ldap.foobar.com:389 as follows.:
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 connections would keep things in sync every 15 minutes, which would probably be just fine in this scenario. The push connection would guarantee that any change made to the European contact information would be pushed out to Munich immediately.Given this replication scheme, where would users connect to access their data? Users in Munich could simply connect to their local server. If they were making changes to the data, the local LDAP server would refer those changes to the master LDAP server, which would then push all the changes back to the local LDAP server to keep it in sync This is of tremendous benefit to the local user:. all their LDAP queries (mostly reads) are against their local server, which is substantially faster When it's time to make a change to their information. .
Security and Access Control
LDAP provides for a complex level of access control instances, or ACIs. Because the access can be controlled on the server side, it's much more secure than security methods that work by securing data through client software.
WITH LDAP Acis, You Can do Things Like:
Grant users the ability to change their home phone number and home address, while restricting them to read-only access for other data types (such as job title or manager's login). Grant anyone in the group "HR-admins" the ability to modify any user's information for the following fields: manager, job title, employee ID number, department name, and department number There would be no write permission to other fields Deny read access to anyone attempting to query LDAP for a user's password, while still.. allowing a user to change his or her own password. Grant managers read-only permission for the home phone numbers of their direct reports, while denying this privilege to anyone else. Grant anyone in the group "host-admins" to create, delete, and edit all aspects of host information stored in LDAP. Via a Web page, allow people in "foobar-sales" to selectively grant or deny themselves read access to subsets of the customer contact database. This would, in turn, allow these individuals todownload the customer contact information to their local laptops or to a PDA. (This will be most useful if your sales force automation tool is LDAP-aware.) Via a Web page, allow any group owner to add or remove any entries from groups they own. for example, this would allow sales managers to grant or remove access for salespeople to modify Web pages. This would allow owners of mail aliases to add and remove users without having to contact IT. Mailing lists designated as "public" could allow users To Add or Remove Themselves (But Only Themsels) To or from Those Mail Aliases. Restrictions Can Also Be Based ON IP Address or Hostname. For Example, Fields Can Be Made Readable Only If The User '
s IP address begins with 192.168.200. *, or if the user's reverse DNS hostname maps to * .foobar.com.This will give you an idea what's possible using access control with LDAP directories, but be aware that a correct implementation requires much I'll Discuss Access Control in Greater Detail In A Future Article.
That's it for now. I Hope You've Found this Article Useful. If You Have to donnelly@ldapman.org.
28 April 2000
Introduce LDAP
Original: http://ldapman.org/articles/intro_to_ldap.html
Original author: Michael Donnelly
Translation: brimmer
If you work in your computer industry, then you can hear the LDAP. Do you want to know about LDAP in depth? So you can read this article well. This introductory article is a series of articles describing how to design, implement and integrate LDAP environments in the enterprise. Mainly let you be familiar with the basic concepts of LDAP, and those more difficult details will be discussed later. In this article we will introduce:
What is LDAP?
When should I store data with LDAP?
LDAP directory tree structure
Separate LDAP record
A separate data item as an example
LDAP replication
Safety and access control
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. If similar data has been stored in Oracle, Sybase, Informix, or Microsoft SQL database, what is the difference between LDAP and these databases? What makes it more advantageous? Please continue to read it!
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.
How to use LDAP term?
In the day-to-day conversation, you may hear some people say: "Do we want to exist in ldap?", Or "Take out those data from the LDAP database!", Or "How do we put LDAP and relationships Database integration? ". Strictly speaking, LDAP is not a database at all, but is used to access the information stored in the information directory (which is the LDAP directory). More exactly and formal statements should be like this: "By using LDAP, you can read (or store) data at the correct location of the information directory." However, there is no need to get fit, although it is not accurate enough, we also know what the other party is saying. Is the LDAP directory be a database?
Like Sybase, Oracle, Informix, or Microsoft's Database Management (DBMS) is used to handle queries and update relational databases, the LDAP server is also used to process queries and update LDAP directories. In other words, the LDAP directory is also a type of database, but it is not a relational database. Databases that need to be handled into hundreds of data changes are required per minute, such as the online transaction processing (OLTP) system that is often used in e-commerce, LDAP mainly optimizes the performance of data read.
Advantages of the LDAP directory
It is now what the LDAP directory is now. Now the pop of LDAP is the result of many factors. I am talking about it here is just some basic reasons, please pay attention to this is just a small part of the reason.
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.
You don't have to pay for each client of LDAP or licenses for each client connection.
Most LDAP servers are installed very simple 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 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's phone number book and organizational structure Figure 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 I store data with LDAP?
Most LDAP servers are specifically optimized 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.
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 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 / 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 that FOOBAR's 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.
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. This is just letting you understand what access control can be made to the LDAP directory. It is actually much more work that needs to do. I will discuss access control in detail in the subsequent article.
