ldap-overlay с фиксированными атрибутами по умолчанию
у меня огромная база пользователей (>> 1000), которые должны иметь возможность коллективно использовать некоторую службу совместного использования.
база пользователей медленно, но постоянно меняется.
особенно нас не интересует разделение привилегий (все пользователи равны), поэтому с точки зрения привилегий они могут использовать одну учетную запись. однако по соображениям безопасности мы не можем использовать общие учетные данные. к счастью, у всех пользователей есть собственное имя пользователя и пароль, доступные через LDAP.
поэтому мы реализовали сервер входа в систему (ssh в Debian), где люди аутентифицируются через PAM и OpenLDAP.
теперь LDAP-сервер мало что дает информация, только имя пользователя и возможность аутентификации.
особенно, в нем отсутствует объектный класс : posixAccount и сопутствующие атрибуты
uidNumbergidNumberloginShellhomeDirectory
мой доступ к LDAP-серверу очень ограничен (особенно, i не может запрашивать добавление тех или иных атрибутов), в основном это позволяет мне только аутентифицировать пользователей.
Теперь хорошая новость заключается в том, что мне все равно, если все пользователи имеют одинаковые значения для этих атрибутов .
поэтому я закончил реализацию сервера proxy-ldap, который использует полупрозрачный оверлей для добавления недостающих атрибутов.
данные наложения генерируются с помощью сценария, который создает урезанный LDIF-файл из исходных данных LDAP, который затем используется для заполнения полупрозрачной базы данных.
это работает нормально, но мне это не нравится из-за удобства обслуживания POV: поскольку база пользователей меняется, мне нужно регулярно обновлять базу данных вручную (она меняется достаточно редко - каждые несколько месяцев - так что работы не так много, но ее также легко забыть)
, потому что оверлейные данные являются так тривиально (одни и те же атрибуты / значения для всех объектов), я думаю, что должен быть лучший способ. в идеале я хотел бы иметь наложение, которое добавляло бы эти атрибуты к всем объектам (соответствующие заданному поисковому запросу).
чтобы немного усложнить ситуацию, мы также аутентифицируем другую пользовательскую базу по другому LDAP -сервер, который предоставляет posixAccount -данные; пользователи этой группы, конечно, не должны подвергаться воздействию всей магии оверлея, необходимой для другой группы; что, я думаю, исключает любую магию, совершаемую на стороне PAM.
Исходное предложение:
Я бы предложил используя nss-pam-ldapd и используйте отображение nslcd для предоставления значений по умолчанию для учетных записей пользователей, когда значение не поступает из ldap.
Согласно документации для nslcd.conf, uid / gid также может быть получен:
Атрибуты uidNumber и gidNumber в картах passwd и group могут быть сопоставлены с objectSid, за которым следует SID домена, чтобы получить числовые идентификаторы пользователя и группы из SID (например, objectSid: S-1-5-21-3623811015-3361044348 -30300820).
Вариант № 2a:
Итак, исходя из того, что вы упомянули, похоже, что вам нужно сохранить зеркало каталога.
Не могли бы вы просто обновить имеющийся у вас сценарий, чтобы он работает неразрушающим образом (то есть добавляет только учетные записи / атрибуты, которые не находит локально) и запускается ли он один раз в день через cron?
Вариант № 2b
Вариантом этого может быть установка встроенного 1 -way репликация LDAP (из вышестоящего каталога в ваш локальный каталог), а затем использовать либо оверлей, либо скрипт (который, в свою очередь, выполняет локальную ldapmodify) запускается событиями в журнале, чтобы предоставить недостающие атрибуты?