Текущая ситуация

У меня есть файловый сервер OmniOS, который ранее был в режиме рабочей группы и использовал локальных пользователей / группы (созданные на самом сервере) и локальные passwd пароли для аутентификации пользователей, имеющих доступ к общим папкам Windows CIFS / SMB. Все работает как положено, /usr/bin/ls -V показывает имена локальных пользователей и групп в списках ACL, а разрешения также могут быть установлены и изменены на вкладке безопасности Windows проводника пользователями Windows.

Планируемый результат и предпринятые шаги

Теперь я хочу переместить этот сервер в домен Active Directory, обслуживаемый samba4 AD DC (режим домена). Чтобы упростить последующее добавление дополнительных серверов, я хочу отказаться от использования локальных учетных данных и вместо этого использовать центральную AD для пользователей, групп и паролей. Файловый сервер без проблем был включен в тестовый домен, затем я добавил элементарное сопоставление для учетной записи администратора:

root@omnios:/root# idmap list
add     winuser:administrator@ad.testdomain.com        unixuser:root
add     wingroup:administrators@ad.testdomain.com      unixgroup:root

После этого можно было войти в систему как администратор, дать разрешения пользователям и группам AD с помощью вкладки безопасности проводника, а затем получить доступ к папкам с этими учетными записями пользователей Windows. Никакой дополнительной настройки не потребовалось, и разрешения работали должным образом (при открытии вкладки безопасности перевод из SID в имена пользователей AD был виден на очень короткий момент).

Поскольку нет локальных пользователей / групп, кроме системных, /usr/bin/ls -V показывает числовые идентификаторы, которые создаются автоматически (за исключением пользователя root / Administrator, сопоставление которого жестко запрограммировано в idmap).

drwx------+  3 root     root           3 Oct 17 13:45 test
    user:root:rwxpdDaARWcCos:fd----I:allow
    user:2147483651:rwxpdDaARWcCos:fd----I:allow

Согласно документации, они должны быть потеряны при перезагрузке, но в моем простом тестовом примере они, похоже, сохранились. (Изменить: я, кажется, недооценил это, после перезагрузки файлового сервера разрешения сохраняются, но они удаляются и меняются на nobody после перезагрузки контроллера домена.) Я немного опасаюсь использовать этот простой режим из-за возможных проблем в будущем (см. Третий вопрос).

Вопросы

Я прочитал документация по различным вариантам нейминговых сервисов, но некоторые детали мне все еще непонятны.

• Многие из примеров относятся к двум различным наборам учетных записей пользователей (Unix / Windows), которые следует преобразовать, чтобы пользователь, введенный в AD, также мог войти в систему Solaris, имел оболочку и так далее. Часто необходимо отображать / переводить разные имена (например, JohnDoe@ad.testdomain.com <=> jdoe). В моем случае, с другой стороны, учетные записи пользователей не должны храниться на хостах Solaris, не требуется вход в систему и не должно выполняться никаких преобразований имен. Требуется ли по-прежнему создавать эти учетные записи пользователей (с помощью сценария или вручную) на каждом хосте Solaris в дополнение к AD, если впоследствии спискам ACL следует правильно назвать?
• AD DC уже установил автоматически сгенерированные значения UID и GID для каждого вновь созданного пользователя в качестве атрибутов LDAP - возможно / целесообразно использовать их вместо имен пользователей / имен групп? Я предполагаю, что это будет версия IDMU на стороне Solaris, но в документации не упоминается, что необходимо помимо изменения настройки.
• В документации никогда не упоминается, что произойдет, если сервер будет удален из домена, перемещен в другой домен, запущен без доступного контроллера домена, снова переведен в режим рабочей группы или добавлен второй сервер с идентичной конфигурацией. В моих текущих настройках все локальные пользователи всегда будут оставаться такими же, поэтому до тех пор, пока комбинации пользователь / пароль от клиентов верны, им будет предоставлен доступ. Предполагая, что установка изменится на режим домена, после потери контроллера домена все ACL будут бесполезны (и их придется воссоздавать вручную), потому что новый домен будет использовать новые идентификаторы безопасности и сопоставление по имени пользователя не может быть выполнено, правильно ли это ? Если да, что обычно делается для предотвращения такой ситуации?

В дополнение к ответу на эти три вопроса я ищу своего рода передовой опыт или резюме, которое направит меня на правильный путь. Я предполагаю, что это будет сопоставление имен на основе каталогов с использованием AD или LDAP (у меня есть и то, и другое, и они синхронизируются автоматически), но я не совсем уверен. Я не хочу в дальнейшем копаться в яме (утерянные или непригодные для использования ACL) или выполнять дополнительную работу даром (настраивать дополнительные информационные системы имен, которые никогда не понадобятся в действительности). Мне очень понравилась простота использования и стабильность совместного использования CIFS на основе ядра, и я хотел бы найти решение, которое продолжит это, только с именами пользователей / паролями в AD / LDAP вместо локальных систем.