Оффлайн вход под учеткой AD

[electronik-tomk]

Здравствуйте. Ввожу машину в домен 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. Подскажите куда копать дальше)

[slant]

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

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

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

[electronik-tomk]

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

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

[slant]

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

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

[rogoznik]

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

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

[electronik-tomk]

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

[electronik-tomk]

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

[madesta]

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

[slant]

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

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

[madesta]

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

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

Не по теме

А вообще интересно - как крупные компании полагают: нужно ли и далее платить за лицензии Microsoft или повернуться к вопросу подсчёта накладных расходов и хотя бы частично заменить сетевые решения на какие-нибудь из области open source. Хотя данный вопрос из области концептуальных и не относится к теме обсуждения автора.