LinuxMint.com.ru

Здравствуйте. Ввожу машину в домен Windows по этой статье https://help.ubuntu.ru/wiki/%D0%B2%D0%B ... BD_windows. В общем то все успешно, за исключениям оффлайновой авторизации - если отрубить инет и попробовать перезайти, то оффлайн авторизация отрабатывает, но после перезагрузки системы, зайти уже невозможно. Судя по всему чиститься кэш winbinda. В статьях указано что он пользуется кэшем kerbera, но как показала практика : файл кэша затирался после закрытия сессии - вход был; файл подкидывался после ребута входа не было. - т.е. никак не влияет на winbind. Причем kerber сам затирает свой кэш при ребуте (меняли область хранения файла таже фигня). Система linux mint 20.2 CInnamon. Версия ядра 5.4.0-91-generic. Подскажите куда копать дальше)

electronik-tomk писал(а): ↑

03 дек 2021, 09:47

Судя по всему чиститься кэш winbinda. В статьях указано что он пользуется кэшем kerbera, но как показала практика : файл кэша затирался после закрытия сессии - вход был; файл подкидывался после ребута входа не было. - т.е. никак не влияет на winbind.

Тут ошибка методики теста. Подкинуть файл просто так - не имеет смысла, AD его содержимое не приймет - т.к. оно уже устарело. В процессе генерации ticket участвуют две стороны - и клиент и контроллер AD с взаимным удостоверением друг друга. Подсовывая другой файл вы подсовываете ticket который уже "протух" у работать не будет.

Копать тут стоит в документацию по kerberos и в гугл по ключевым словам "сохранить ticket kerberos после перезагрузки"
Кроме того, эти нюансы поведения могут быть заданы политиками AD на контроллерах домена - имеет смысл покопаться и проверить.

slant писал(а): ↑

03 дек 2021, 13:26

Тут ошибка методики теста. Подкинуть файл просто так - не имеет смысла, AD его содержимое не приймет - т.к. оно уже устарело.

В данном случае AD ничего не принимает - связи с доменом нет! winbind в случае недоступности доменоконтроллера использует сохранненый кэш. Политики AD тут не пирчем, иначе не получалось бы войти в случае выхода входа пользователя без перезагрузки. Повторяю, оффлайн вход работает, но только если машина не выключалась. Сохранять тикет кербероса получалось после некоторых манипуляций, но только если он был получен из под локальной учетки. Из под доменной, они продолжали затираться. В любом случае, даже после ручного удаления тикета kerberosa, на который winbind по идее должен ссылаться, вход при выключенной сети и если комп не перезагружался был возможен!

electronik-tomk писал(а): ↑

03 дек 2021, 14:31

В данном случае AD ничего не принимает - связи с доменом нет! winbind в случае недоступности доменоконтроллера использует сохранненый кэш.

Вы упускаете, что кеш не из воздуха образовался. Информацию о том, что с ним потом делать winbind может взять из политик домена вместе с получением тикета, когда связь с AD есть. А привязок и проверок там много - убедится что подсунутый кеш не легитимный - ему хватает.

electronik-tomk писал(а): ↑

03 дек 2021, 09:47

В общем то все успешно, за исключениям оффлайновой авторизации - если отрубить инет и попробовать перезайти, то оффлайн авторизация отрабатывает, но после перезагрузки системы, зайти уже невозможно.

Собственно винда так же поступает. Только она поступает глупее и дает n успешных попыток войти, а потом все - хочет AD

В общем после вывода winbinda из тихого режима и просмотра логов удалось выяснить что он все же определяет юзера из кэша kerbera, но этот кэш он все же затирается у доменного пользователя. Способ из этой статьи https://forum.ubuntu.ru/index.php?topic=260309.0 не сработал - почему то при получении билета под локальной учеткой все нормально и он находится в указанной папке, но под доменной учеткой он сохранется по дефолту в tmp и после перезагрузки чистится. Если удалить все тикеты, отключить сеть и попробовать перезайти, то оффлайн вход работает, а в логах написано что юзер установлен из файла кеша который по идее удален ручками.

В общем спустя долгое время поисков и экспериментов получилось легко и непринужденно ввести минт в домен с помощью буквально 5 команд и все работает. Делалось по сокращенной методике в конце статьи https://habr.com/ru/post/437546/ .

Понравился комментарий к статье: "Скажите, а с какой практической целью вы добавляете Linux машины в AD? Групповых политик нет — т.е. управлять данной машиной на ровне с Windows не получится." Разве что по шарам ходить, но, как мне думается, это можно было бы и без ввода в домен делать, просто прописывая нужного юзера в формате записи AD. Как второй вариант: навешать лапши проверяющим, типа "мы ваши требования выполнили, все машины в домене, администратор с руководством рулят ...".

madesta писал(а): ↑

22 дек 2021, 17:50

Разве что по шарам ходить, но, как мне думается, это можно было бы и без ввода в домен делать, просто прописывая нужного юзера в формате записи AD.

Вообще-то в AD можно и кастомные записи делать. С ними можно научить систему запрашивать индивидуальные конфиги/параметры для авторизированного пользователя прямо из AD. Можно и полноценный "перемещаемый профиль" замутить (или сетевой на основе NFS). Вполне удобно там, где линукс служит неиндивидуальным но не публичным рабочим местом - например: на кассе, где может сесть любой из кассиров.
Я когда делал подобное на базе Mint17 - это были места для тех-поддержки, там персональный конфиг SIP телефонии вполне себе успешно прямо из AD вытаскивался. Разумеется писалась эта фича вручную, штатных средств действительно нету. Но AD - это разновидность LDAP, а с клиентами к нему проблем не имеется... На стороне же винды и AD записи юзеру делались штатными средствами...

slant писал(а): ↑

22 дек 2021, 18:03

персональный конфиг SIP телефонии вполне себе успешно прямо из AD вытаскивался.

С подобными дополнительными решениями - тогда да, согласен. Но, как поясняете, писать нужно вручную, администратор всегда себе работу найдёт