У меня большая база пользователей (>> 1000), которые должны иметь возможность коллективно использовать какой-то сервис совместного использования.
база пользователей медленно, но постоянно меняется.
особенно нас не интересует разделение привилегий (все пользователи равны), поэтому с точки зрения привилегий они могут использовать одну учетную запись. однако по соображениям безопасности мы не можем использовать общие учетные данные. К счастью, у всех пользователей есть собственное имя пользователя / пароль, доступный через LDAP.
поэтому мы реализовали сервер входа в систему (ssh в Debian), где люди проходят аутентификацию через PAM и OpenLDAP.
теперь LDAP-сервер не предоставляет много информации, только имя пользователя и возможность аутентификации. особенно, в нем отсутствует objectClass: posixAccount и сопутствующие атрибуты
uidNumbergidNumberloginShellhomeDirectoryмой доступ к LDAP-серверу очень ограничен (особенно, я не могу попросить добавить те или иные атрибуты), в основном он позволяет мне только аутентифицировать пользователей.
Теперь хорошая новость заключается в том, что мне все равно, будут ли у всех пользователей одинаковые значения этих атрибутов.
так что я закончил реализацию прокси-ldap-сервера, который использует translucent наложение, чтобы добавить недостающие атрибуты. данные наложения генерируются с помощью сценария, который создает урезанный LDIF-файл из восходящих данных LDAP, который затем используется для заполнения полупрозрачной базы данных.
это работает нормально, но мне это не нравится с точки зрения ремонтопригодности: поскольку база пользователей меняется, мне нужно регулярно обновлять базу данных вручную (она меняется достаточно редко - каждые несколько месяцев - так что это не так много работы, но она тоже легко забыть).
поскольку данные наложения настолько тривиальны (это одни и те же атрибуты / значения для всех объектов), я думаю, что должен быть лучший способ. в идеале я хотел бы иметь наложение, которое добавляло бы эти атрибуты в все объекты (соответствующие заданному поисковому запросу).
чтобы немного усложнить ситуацию, мы также аутентифицируем другую пользовательскую базу на другом 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) .
Вариант №2а:
Итак, исходя из того, что вы упомянули, похоже, что вам нужно сохранить зеркало каталога.
Не могли бы вы просто обновить имеющийся у вас скрипт, чтобы он работал неразрушающим образом (т.е. добавлял только учетные записи / атрибуты, которые не находит локально), и запускал его один раз в день через cron?
Вариант # 2б
Вариантом этого было бы, если бы вы могли настроить собственную одностороннюю репликацию LDAP (из вышестоящего каталога в ваш локальный каталог), а затем использовать либо оверлей, либо сценарий (который, в свою очередь, выполняет локальную ldapmodify), запускаемый событиями в log, чтобы указать недостающие атрибуты?