Как бы вы объяснили LDAP системному администратору, который слышал о нем и, возможно, взаимодействовал с ним, но так и не понял?
Аналогии хороши, но, пожалуйста, включите некоторые важные технические детали, которые помогут их обосновать.
Спросил в духе Объяснение Active Directory
я написал Эта статья несколько лет назад, что объясняет основы LDAP
LDAP (облегченный протокол доступа к каталогам) - это протокол прикладного уровня, который позволяет клиентам взаимодействовать с соответствующими службами каталогов для управления объектами каталога или запроса информации в каталоге. Одно из его основных преимуществ - предоставление стандартизованного интерфейса для систем на нескольких платформах.
В большинстве систем каталогов LDAP - не единственный интерфейс, доступный для связи с сервером. Обычно существуют другие собственные интерфейсы, которые могут обеспечить производительность и другие преимущества.
Стандартная концепция сеанса LDAP такова:
Запросы можно выполнять следующим образом:
Поскольку каталоги могут быть очень распределенными и содержать чрезмерное количество информации, администраторам каталогов обычно предоставляется возможность ограничить запросы LDAP определенным количеством результатов (1000 - это общий максимум для набора результатов).
Думайте об этом как о базе данных, организованной в виде дерева, так, например, вы можете иметь типичную структуру компании, организованную естественным образом. Компания верхнего уровня с группами / отделами в подчинении и сотрудниками в конце, которые сами могут иметь несколько свойств (например, имя, телефон, почту, адрес и т. Д.). Затем скажите ему, что он также подходит для любых других данных, которые организованы аналогичным образом и что доступ к ним осуществляется по открытому протоколу с различных платформ / языков.
Кроме того, из википедии: «Каталог - это набор объектов с атрибутами, организованными логическим и иерархическим образом. Наиболее распространенным примером является телефонный справочник, который состоит из серии имен (лиц или организаций), организованных в алфавитном порядке, с к каждому имени прилагается адрес и номер телефона ".
Это самое удобное для новичков объяснение, которое я могу придумать, не вдаваясь в технические детали.
Это централизованная система, предназначенная для обеспечения быстрого доступа к данным, где фактические данные структурированы в виде древовидной структуры. Язык, который вы используете для связи с этой централизованной системой, называется LDAP, это просто протокол, во многом похожий на протокол POP и IMAP. Он имеет возможность обновления и поиска данных по дереву.
Во-первых, LDAP сам по себе - это просто протокол, он ничего не делает, если нет сервера LDAP, с которым он мог бы взаимодействовать.
Это позволяет получить доступ к каталог на сервере LDAP; хорошей аналогией может служить бумажный телефонный справочник или справочник услуг (последнее, вероятно, лучше). Если вы хотите найти место, где можно отремонтировать свой автомобиль, при условии, что вы не знакомы с местными гаражами, вы можете поискать в бумажном справочнике услуг, чтобы найти механиков в вашем районе.
Точно так же LDAP позволяет вам искать информацию в LDAP-совместимом каталоге, запущенном на сервере. Каждая запись в каталоге представляет собой «объект», который может иметь различные свойства, и приложение, которое взаимодействует с каталогом, ожидает, что вещи будут отформатированы определенным образом. По дизайну он гибкий и расширяемый, поэтому вы не ограничены тем, о чем кто-то мог подумать.
Возвращаясь к аналогии с механикой, информацией могут быть имя, адрес, стоимость часа, известно ли, что он саботировал вашу машину, чтобы получить от вас дополнительные дела, размер пивной кишки и так далее. Автомеханика может храниться в одном узле дерева каталогов, а ремонтники Hi-Fi - в другом. Необязательно, чтобы у каждого такого типа объекта были одни и те же свойства, поэтому некоторая информация для автомеханика не будет присутствовать на мастере по ремонту Hi-Fi, который, в свою очередь, будет иметь свой собственный набор уникальной информации, относящейся исключительно к нему.
Чаще всего он используется для хранения информации о пользователях в сети, но теоретически вы можете поместить что-нибудь внутрь. В сетевом сценарии мы говорим об организационной информации о человеке, а также, возможно, информации о безопасности, информации о конфигурации приложений и т. Д. Поскольку все это хранится централизованно, вы можете легко и гибко централизовать МНОГО информации в единой базе данных, оптимизированной для сверхбыстрого поиска и доступной для любого совместимого приложения.