First up, LDAP on it's own is just a protocol, it does nothing unless there is an LDAP server for it to interact with.
It lets you access a directory on the LDAP server; a good analogy would be a paper telephone directory or a directory of services (the latter is probably better). If you want to find somewhere to get your car repaired, assuming you're not familiar with the local garages, you might look up a paper directory of services to find mechanics in your area.
Similarly, LDAP lets you look up information in an LDAP-compliant directory running on a server. Each entry in the directory is an "object" that may have various properties, and an application that interacts with the directory expects things to be formatted in a certain manner. By design it's flexible and extensible, so you're not limited to what somebody else may have thought of.
Going back to the mechanic analogy, the info may be name, address, cost per hour, whether he's known to sabotage your car so he can get extra business off you, size of beer gut, and so on. Car mechanics might be stored in one node of the directory tree, hi-fi repairmen might be stored in another. Each such object type is not required to share the same properties, so some of the info for a car mechanic will not be present on a hi-fi repairman, who will in turn have his own set of unique info that relates solely to him.
It's most commonly used to hold info about users on a network, but in theory you could put anything into it. In a network scenario, we're talking about organisational info about the person, as well as perhaps security info, configuration info for applications, and so on. Because it's all stored centrally, you can easily and flexibly centralise a LOT of info into a single database that's optimised for ultra-fast lookups and is accessible by any compliant application.