Во-первых, сам по себе LDAP - это просто протокол, он ничего не делает, если не существует сервера LDAP для взаимодействия с ним.
Это позволяет вам получить доступ к каталогу на сервере LDAP; Хорошей аналогией будет бумажный телефонный справочник или справочник услуг (последний, вероятно, лучше). Если вы хотите найти место для ремонта вашего автомобиля, предполагая, что вы не знакомы с местными гаражами, вы можете найти бумажный каталог услуг, чтобы найти механиков в вашем районе.
Точно так же LDAP позволяет вам искать информацию в LDAP-совместимом каталоге, работающем на сервере. Каждая запись в каталоге является «объектом», который может иметь различные свойства, и приложение, которое взаимодействует с каталогом, ожидает, что объекты будут отформатированы определенным образом. По своему дизайну он гибкий и расширяемый, поэтому вы не ограничены тем, о чем кто-то мог подумать.
Возвращаясь к аналогии с механикой, информация может содержать имя, адрес, стоимость в час, известно ли о том, что он саботирует вашу машину, чтобы он мог получить дополнительную прибыль от вас, размер пива и так далее. Автомобильная механика может храниться в одном узле дерева каталогов, hi-fi ремонтники могут храниться в другом. Каждый такой тип объекта не обязательно должен иметь одинаковые свойства, поэтому некоторая информация для автомеханика не будет присутствовать у мастера по ремонту Hi-Fi, который, в свою очередь, будет иметь свой собственный набор уникальной информации, которая относится исключительно к нему.
Он чаще всего используется для хранения информации о пользователях в сети, но теоретически вы можете поместить в нее что угодно . В сетевом сценарии мы говорим об организационной информации о человеке, а также, возможно, о безопасности, информации о конфигурации приложений и так далее. Поскольку все это хранится централизованно, вы можете легко и гибко централизовать МНОГО информации в единую базу данных, которая оптимизирована для сверхбыстрого поиска и доступна для любого совместимого приложения.