Я администрирую несколько серверов для небольшой организации, которая предлагает своим членам услуги, подобные ISP (веб-хостинг, почтовые адреса в нескольких доменах и связанные учетные записи IMAP, учетные записи Jabber), и я хочу централизовать все данные учетных записей в LDAP. Я новичок в LDAP, и теперь мне нужно спроектировать и организовать структуру каталога LDAP.
Самая большая проблема, с которой я борюсь, - это сопоставление пользователей с различными учетными записями, например одиночные пользователи в настоящее время имеют несколько учетных записей IMAP и Jabber, которые связаны с различными адресами в разных доменах, и каждая учетная запись имеет свой пароль, и мне нужно его сохранить.
Итак, как мне организовать структуру каталога LDAP?
Если пользователи и различные учетные записи находятся в разных деревьях, которые затем связаны через общий uid, то есть ou = people, dc = example, dc = net с inetOrgPersons, описывающим пользователя, а затем отдельные деревья для учетных записей, такие как ou = imapAccounts, dc = например, dc = net, ou = jabberAccounts, dc = example, dc = net и т. д. с настраиваемыми схемами? Или есть способ лучше, поскольку это слишком похоже на решение с использованием реляционной базы данных?
Какие-либо рекомендации ресурсов / книг / реальных примеров, которые здесь полезны? Большинство ресурсов, которые я видел, похоже, предполагают, что у одного человека есть только одна учетная запись mail / jabber и т. Д., И он хочет использовать для этого один пароль. Не могу поверить, что интернет-провайдеры редко позволяют своим клиентам иметь несколько учетных записей, например. чтобы позволить им разделять частную и рабочую почту или поощрять разные пароли для разных сервисов, чтобы сохраненный пароль Jabber, который был взломан, не привел к компрометации всех других сервисов этого клиента и т. д.
Я постараюсь уточнить свой вариант использования и объяснить свою текущую модель данных:
Есть уникальные пользователи, для которых мне нужны контактные данные и у которых есть (единственная) учетная запись оболочки в окне веб-хостинга. У каждого из этих уникальных пользователей может быть несколько учетных записей IMAP и Jabber.
Чтобы ответить на вопросы дизайна:
Вы подходите к этому неверно, поскольку выбрали технологию и теперь пытаетесь вставить в нее свою модель данных. Создайте свой МОДЕЛЬ ДАННЫХ сначала найдите технологию, которая упрощает реализацию.
Начните с доски и напишите то, что вам нужно отслеживать, а затем определите, как все они соотносятся друг с другом. Если вы столкнетесь с естественной иерархией / деревом, LDAP - хороший выбор. Если вы закончите с фанковой вещью, похожей на сеть, реляционная система может работать лучше.
Некоторые вопросы, которые нужно задать во время проектирования:
Является ли «пользователь» контейнером (который содержит учетные записи)?
(В этом случае каждая учетная запись будет указывать ровно на одного пользователя. На языке LDAP пользователь будет OU, и учетные записи будут созданы в этом OU. На языке отношений, Account будет иметь обязательный (НЕ NULL) внешний ключ, указывающий у пользователя)
Будут ли пользователи делиться аккаунтами?
(Здесь реляционное моделирование часто работает лучше)
Будут ли учетные записи перемещаться между пользователями (или пользователи перемещаются между учетными записями)?
Какие системы необходимо будет интегрировать с этим хранилищем данных?