Ошибка аутентификации

tnPlayer

New member
Сообщения
5
#1
Добрый день. Нарвался вот на такую интересную проблему, сразу оговорюсь что с миром Linux почти не знаком, а потому мне сложно даже представить, какие логи, как и откуда могли бы помочь. Значит дано: Astra Linux Special Edition 1.7.3, установлен пакет fly-admin-ad-client, система подключена к домену на Windows Server 2019, авторизация через доменного юзера, с помощью pam_mount смонтирована сетевая папка с одного из серверов. На первый взгляд все отлично работает. Но возникла проблема.

Насколько мне удалось выяснить проблема возникает после того как компьютер уснет. Оставил я работающий ноутбук от батареи, заряд кончился, он уснул. Заряжаю, пробуждаю и на экране авторизации пробую ввести пароль от пользователя под которым был авторизован в момент работы (доменного). Получаю ошибку "авторизация не пройдена". Если попытаться создать новую сессию и войти все с теми же логином и паролем, просто получаем ошибку "вход не выполнен". Под локального пользователя авторизация проходит.
 

tnPlayer

New member
Сообщения
5
#3
Спасибо, попробую еще раз поймать этот баг и посмотреть.
 

tnPlayer

New member
Сообщения
5
#5
kvv-vp
Failed to start networkmanager.service: Unit networkmanager.service not found.
Alex-der
Зашел под локального администратора, сеть есть, контроллер домена пингуется, брандмауэр на контроллере отключен. Перезагрузил систему, авторизация прошла. Отправил в сон в ручную, разбудил все снова вошло, попробовал так же с гибернацией, тоже все отлично. Такое ощущение что он либо должен уйти в сон сам и тогда глюк проявляется, либо должен провести там какое-то продолжительное время (звучит бредово, понимаю, но ощущается вот так). Ощущаю себя блондинкой.

UPD: поигрался с сетью, убрал локальный DNS сервер, чтобы система не могла найти контроллер домена, в итоге при попытке авторизоваться получаю сообщение: "domain controller unreachable using cached credentials instead. network resources may be unavailable", но в авторизация проходит, судя по всему из кеша. Делаю вывод, что даже при отсутствии подключения, я бы смог обратно авторизоваться после сна.
 
Последнее редактирование:

Montfer

New member
Сообщения
2 167
#6
может быть баг, т. к. люди жаловались, что не могли автризоваться в заблокированную учетку
 

Alex-der

New member
Сообщения
33
#7
UPD: поигрался с сетью, убрал локальный DNS сервер, чтобы система не могла найти контроллер домена, в итоге при попытке авторизоваться получаю сообщение: "domain controller unreachable using cached credentials instead. network resources may be unavailable", но в авторизация проходит, судя по всему из кеша.
Давайте вернёмся к основам и отделим мух от котлет:
1. "Убрать локальный DNS-сервер" - решение почти правильное: незачем плодить лишние сущности на каждой машине в сети. Двух-максимум, трёх DNS-серверов в сети вполне достаточно, чтобы потом самому не путаться. Два - достаточно для большой сети, третий - для ОЧЕНЬ большой сети. Второй и третий - это уже для резервирования, если упал первый. Но, в случае отсутствия (отключения/удаления) службы, для корректной работы компьютера в сети, в параметрах сети (а точнее - в системе) должен быть указан DNS-сервер(ы) сети.
2. Широко ныне известная фирма M$ с давних пор известна тем, что не любит ходить по давно наезженным дорогам и пробивает через тернии свой путь, в конце концов, возвращаясь на ту же самую дорогу: когда ЭВМ были действительно большими, а в общество пробивались ПЭВМ, фирма M$ осознала трудности управления большим парком ПЭВМ и "изобрела" сеть, в основе которой лежал WINS (тыц1 и тыц2, но лучше, всё-таки тыц3). И до сих пор (windows10 и windows11) в основе одноранговой сети или домена M$ (AD) лежит этот WINS. Нет, конечно, M$ почти признала свою ошибку, и сейчас DNS, по сути, является главной службой в любой сети, но WINS никто не ликвидировал до сих пор (для обратной совместимости). Но SAMBA разрабатывалась, уже опираясь на успех, достигнутый M$ в сетях для малых предприятий и, естественно, работает с WINS, и даже может работать (главным) сервером WINS в локальной сети.

Вывод из этого всего: для подключения к домену и шарам вполне достаточно samba-клиента, который встроен в fly-fm. Но для более или менее полноценной работы в сети (с выходом в Интернет) нужно обязательно указывать DNS-сервер. В современных реализациях AD, чтобы не ловить дополнительные глюки, в качестве DNS-сервера нужно первым указывать адрес контроллера домена. Зачастую (если ADDC имеет выход в Интернет) этого вполне достаточно, но конфигурации сетей бывают разные и порой стоит указывать дополнительный DNS-сервер.
Делаю вывод, что даже при отсутствии подключения, я бы смог обратно авторизоваться после сна.
Верно лишь частично. Если бы не было подключения, авторизоваться в сети или подключиться по сети к чужой шаре невозможно. В зависимости от степени параноидальности настроек средств защиты, можно войти локально на данный компьютер, но порой всякие DallasLock-и и SecretNet-ы затирают кэш, чтобы исключить подобный хак. Как оно настроено у вас - можно лишь гадать. Мог элементарно протухнуть ключ сессии (мы же не знаем, сколько времени ноут был разряжен, сколько валялся в отключке и сколько он потом заряжался) и при пытке обновить сессию после включения, без сети это, естественно, не удалось. Т.к. Астра преднастроена на безопасность в соответствии с требования ФСТЭК и ФСБ, логично, что она вас больше в себя не пустила. Хотя точно это могут объяснить лишь разработчики.
 

tnPlayer

New member
Сообщения
5
#8
Давайте вернёмся к основам и отделим мух от котлет:
1. "Убрать локальный DNS-сервер" - решение почти правильное: незачем плодить лишние сущности на каждой машине в сети. Двух-максимум, трёх DNS-серверов в сети вполне достаточно, чтобы потом самому не путаться. Два - достаточно для большой сети, третий - для ОЧЕНЬ большой сети. Второй и третий - это уже для резервирования, если упал первый. Но, в случае отсутствия (отключения/удаления) службы, для корректной работы компьютера в сети, в параметрах сети (а точнее - в системе) должен быть указан DNS-сервер(ы) сети.
2. Широко ныне известная фирма M$ с давних пор известна тем, что не любит ходить по давно наезженным дорогам и пробивает через тернии свой путь, в конце концов, возвращаясь на ту же самую дорогу: когда ЭВМ были действительно большими, а в общество пробивались ПЭВМ, фирма M$ осознала трудности управления большим парком ПЭВМ и "изобрела" сеть, в основе которой лежал WINS (тыц1 и тыц2, но лучше, всё-таки тыц3). И до сих пор (windows10 и windows11) в основе одноранговой сети или домена M$ (AD) лежит этот WINS. Нет, конечно, M$ почти признала свою ошибку, и сейчас DNS, по сути, является главной службой в любой сети, но WINS никто не ликвидировал до сих пор (для обратной совместимости). Но SAMBA разрабатывалась, уже опираясь на успех, достигнутый M$ в сетях для малых предприятий и, естественно, работает с WINS, и даже может работать (главным) сервером WINS в локальной сети.

Вывод из этого всего: для подключения к домену и шарам вполне достаточно samba-клиента, который встроен в fly-fm. Но для более или менее полноценной работы в сети (с выходом в Интернет) нужно обязательно указывать DNS-сервер. В современных реализациях AD, чтобы не ловить дополнительные глюки, в качестве DNS-сервера нужно первым указывать адрес контроллера домена. Зачастую (если ADDC имеет выход в Интернет) этого вполне достаточно, но конфигурации сетей бывают разные и порой стоит указывать дополнительный DNS-сервер.Верно лишь частично. Если бы не было подключения, авторизоваться в сети или подключиться по сети к чужой шаре невозможно. В зависимости от степени параноидальности настроек средств защиты, можно войти локально на данный компьютер, но порой всякие DallasLock-и и SecretNet-ы затирают кэш, чтобы исключить подобный хак. Как оно настроено у вас - можно лишь гадать. Мог элементарно протухнуть ключ сессии (мы же не знаем, сколько времени ноут был разряжен, сколько валялся в отключке и сколько он потом заряжался) и при пытке обновить сессию после включения, без сети это, естественно, не удалось. Т.к. Астра преднастроена на безопасность в соответствии с требования ФСТЭК и ФСБ, логично, что она вас больше в себя не пустила. Хотя точно это могут объяснить лишь разработчики.
1) Я не имел ввиду, что на машине был поднят DNS сервер. Я убрал в настройках сетевого подключения, локальный (в смысле внутренний), тот что поднимается автоматический с AD, дабы проверить будет ли работать авторизация без доступа к серверу и как показала практика будет (из кеша, само собой если предварительно был хотя бы один вход).
2) Это понятно, потому вторым DNS-ом указан уже провайдерский.
3) Никаких доп. защит вроде секрет нета не установлено, по сути голая система, а если быть точнее ноутбук с уже предустановленной системой. Все что я пока сделал, это только установил fly-admin-ad-client и вогнал систему в домен. Возможно вы правы и "стух ключ сессии" но почему она не попыталась запросить его заново? Как я уже писал выше в итоге сеть та работает, я проверил под локальной учетной записью и тот же контроллер домена отлично пингуется :)

Оставил ноутбук на очередной тест, посмотрим что будет в понедельник, когда снова вернусь на работу.
 
Последнее редактирование:

kvv-vp

New member
Сообщения
157
#9
Failed to start networkmanager.service: Unit networkmanager.service not found.
Забыл, что с этим товарищем на Вы нужно. Сеть у вас не отваливается, попробуйте переподключить сеть: sudo systemctl restart NetworkManager.
Можно сравнить запущенные юниты после удачной авторизации и после пробуждения :
systemctl list-units. Возможно что-то отваливается после пробуждения, не стартует.
 

oko

New member
Сообщения
1 180
#10
*в сторону*
Гадать можно до бесконечности, а модуль экстрасенсорики под конец года уже окончательно...
Логи контроллера домена - первое, с чего следует начинать. Логи используемого для ALSE auth-клиента (что там? sssd?). Логи обмена Kerberos-билетами. И вообще /var/log/syslog и /var/log/messages...
 

tnPlayer

New member
Сообщения
5
#11
Снова нарвался на этот глюк. В этот раз ноутбук был оставлен под локальным администратором, после долгого простоя при попытке зайти под любую доменную учетную запись, получаю ошибку "Вход не выполнен".
Команда sudo systemctl restart NetworkManager результата не дала, служба перезагрузилась, линк поднялся, но авторизация так и не заработала.
Прикладываю файлы /var/log/syslog и /var/log/messages

Ребут системы и снова все работает...
 

Вложения

Denisssss

New member
Сообщения
1
#12
Что то решилось по этой проблеме? Столкнулся с теми же граблями