Bug 50272

Summary: Нет доступа из логон скриптов групповых политик к сетевым ресурсам, определённых в групповых политиках
Product: Branch p10 Reporter: rsrs <rstaganrog>
Component: gpupdateAssignee: Valery Sinelnikov <greh>
Status: REOPENED --- QA Contact: qa-p10 <qa-p10>
Severity: normal    
Priority: P5 CC: amakeenk, greh, lepata, rstaganrog, sin, zurabishvilinn
Version: не указана   
Hardware: x86_64   
OS: Linux   
Attachments:
Description Flags
Файл настроек сетевых дисков
none
скрипт для systemd-логон скрипта
none
логон скрипт для групповой политики
none
стартап скрипт для групповой политики
none
Логи
none
Не удалось подключиться к серверу домена, klist в норме
none
Стартап скрипт startup-script.sh
none
Настройка политики для стартап скрипта
none
Настройка политики для сетевого диска
none
policy-logs-2024-05-15.zip
none
logs-2024-05-15.zip
none
logs-2024-05-15-2.zip
none
policy-logs-2024-05-15-2.zip
none
Пример скрипта для работы из-под аккаунта машины none

Description rsrs 2024-05-03 13:05:18 MSK
Created attachment 16052 [details]
Файл настроек сетевых дисков

Имеется клиент Альт Рабочая станция К 10.2, обновлённая до 10.3 (dist-upgrade). Клиент введён в MS AD.

В соответствии с инструкциями
https://www.altlinux.org/Групповые_политики/Подключение_сетевых_дисков
https://www.altlinux.org/Групповые_политики/Управление_logon-скриптами

в групповой политике AD "alt-drives" в контексте "Компьютер" задано подключение сетевых дисков
- \\data2\Temporary с именем "Диск T"
- \\data2\Media с именем "Диск M"
- \\data2\Log$ с именем "Log$" (скрытый диск - /media/gpupdate/.drives.system/Log$)

в политике "alt-scripts" определены скрипты:
- сценарий автозагрузки startup-script.sh
- сценарий входа в систему logon-script.sh

Скрипт logon-script.sh
- создаёт в домашней папке текущего пользователя симлинки на сетевые диски "Диск T" и "Диск M"
- логгирует своё выполнение в локальной папке /log 
- (*) логгирует своё выполнение в сетевой папке /media/gpupdate/.drives.system/Log$

Скрипт startup-script.sh логгирует своё выполнение:
- в локальной папке /log 
- (**) в сетевой папке /media/gpupdate/.drives.system/Log$

Также в целях увеличения вероятности повторяемости ошибки в systemd-логон скрипт пользователя (см. logon-d-script.sh) включено выполнение gpupdate.

--

Суть проблемы состоит в следующем.

1. Сразу после установки ОС Альт 10.3 и ввода компьютера в домен включены (*) и (**), то 
- логгирование (*) происходит без ошибок несколько раз (от 1 до 5 раз, точную закономерность выявить не удалось). После чего логгирование в сеть (*) прекращается, в то время как логи в локальную папку /log, продолжают выполняться (что свидетельствует об исправности логон скриптов).
- логгирование (**) начинается не сразу, а после нескольких перезагрузок ОС. После этого (**) выполняется 1-5 раз и затем этого перестаёт выполняться совсем. После прекращения логгирования (**) также прекращается логгирование (*).

1.1. Если после прекращения логгирования (**) в скрипте startup-script.sh закомментировать (**) и пару раз перезагрузиться, то логгирование (*) снова восстанавливается.

2. Сразу после установки ОС Альт 10.3 и ввода компьютера в домен включено ТОЛЬКО логгирование (*), а логгирование (**) ОТКЛЮЧЕНО: закомментировано в скрипте startup-script.sh
- тогда логгирование (*) происходит без ошибок после некоторого количества перезагрузок компьютера (от 3-5, иногда количество перезагрузок заметно больше - до 10-20, точную закономерность выявить не удалось). После чего логгирование в сеть прекращается, в то время как логи в локальную папку /log продолжают выполняться (логон скрипты политики исправны).

Возникновение ошибки (2) иногда сопровождается:
2.1 просто пустыми папками "Диск T" и "Диск M"
2.2 пустыми папками "Диск T" и "Диск M" и при попытке открыть ADMC появлением окна с сообщением "Не удалось подключиться к серверу. Проверьте ваше соединение и убедитесь, что вы инициализировали свои учетные данные с помощью kinit.
  Ошибка сервера: Local error"
  
При этом ошибки входа в текущий сеанс доменного пользователя domainuser не было - вход в сессию происходил без каких-либо сообщений об ошибке.
Состояние билета при этой ошибке нормальное:
  [domainuser@alt10 ~]$ klist
  Ticket cache: KEYRING:persistent:1346204650:krb_ccache_w5J8rHx
  Default principal: domainuser@USZN.LOCAL
  
  Valid starting       Expires              Service principal
  03.05.2024 12:06:47  03.05.2024 22:06:47  krbtgt/USZN.LOCAL@USZN.LOCAL
          renew until 03.05.2024 22:06:47

2.3. Если при этой ошибке (2.1б 2.2) в этой же сессии запросить билет снова и выполнить kinit domainuser без ошибок при выполнении, то "Диск T" и "Диск M" снова оказываются не пустыми и ADMC снова без стартует ошибок.
2.4. Однако, если после этого перезагрузиться, то 2.2 повторяется снова. И логгирование (*) так и не восстанавливается.

2.5. ИНОГДА возобновить логгирование (*) получается только если в logon-script.sh закомментировать сетевое логгирование (*) - тогда через пару перезагрузок появляются непустые "Диск T" и "Диск M" и тогда уже можно снова включать (*), восстанавливая сетевое логгирование (*)
2.5.1. Чаще всего (2.5) не решает проблему - "Диск T" и "Диск M" и логгирование (*) после перезагрузки не восстанавливаются. В этом случае не помогает и полное отключение политики alt-scripts и несколько последующих перезагрузок.

3. Если средствами (2.5) проблему решить не удаётся, то остается единственный вариант - полная ПЕРЕУСТАНОВКА Альт 10.3 с нуля.

3.1. Правда была замечена такая особенность - вечером возникло состояние ошибки логгирования (*) и устранить ошибку не получилось. Альт клиент был выключен на ночь и запущен только на следующий день - в результате ошибка устранилась сам собой, без каких либо действий с моей стороны.
3.2. Отсюда можно предположить, что есть некоторая зависимость от продолжительности времени между загрузками ОС, устраняющей ошибку, но такая закономерность не выявлена.


Прилагаю файлы: настроек сетевых дисков, логон скрипты групповых политик и скрипт для systemd-логон скрипта.
Comment 1 rsrs 2024-05-03 13:06:07 MSK
Created attachment 16053 [details]
скрипт для systemd-логон скрипта
Comment 2 rsrs 2024-05-03 13:06:48 MSK
Created attachment 16054 [details]
логон скрипт для групповой политики
Comment 3 rsrs 2024-05-03 13:07:09 MSK
Created attachment 16055 [details]
стартап скрипт для групповой политики
Comment 4 rsrs 2024-05-03 14:02:44 MSK
1. Сейчас выключил политику alt-scripts от подразделения, в котором находится клиент Альт.
2. Несколько раз перезагрузил компьютер.
3. Диски "Диск T" и "Диск M" появились.
4. Включил снова политику alt-scripts, однако после этого скрипт (*) после нескольких загрузок так и не стал выполняться, хотя локальное логгирование в папку /log скриптом политики выполняется.
Comment 5 rsrs 2024-05-03 14:17:26 MSK
Такое впечатление, что периодически вов время выполнения логон скриптов сетевые диск оказываются "не вполне готовы" к использованию в скриптах, что приводит к более серьёзным последствиям как для самих сетевых дисках, так и к нестыковкам в билетной авторизации (см. п.2.1) - билет вроде бы и есть, но ADMC при запуске выдаёт ошибку. В этом случае диски "Диск T" и "Диск M" появляются и запускается ADMC только если в этой же сессии выполнить kinit domainuser.

Может быть можно сделать какие-либо настройки в групповых политиках, чтобы обеспечивать стартап и логон скриптам (из групповых политик) гарантированный доступ к сетевым дискам, подключаемых групповыми политиками?
Comment 6 rsrs 2024-05-03 14:25:52 MSK
(Ответ для rsrs на комментарий #4)
> 1. Сейчас выключил политику alt-scripts от подразделения, в котором
> находится клиент Альт.
> 2. Несколько раз перезагрузил компьютер.
> 3. Диски "Диск T" и "Диск M" появились.
> 4. Включил снова политику alt-scripts, однако после этого скрипт (*) после
> нескольких загрузок так и не стал выполняться, хотя локальное логгирование в
> папку /log скриптом политики выполняется.

Дополнение этому описанию: после нескольких перезагрузок на шаге 4 логгирование (*) стало выполняться снова.
Comment 7 Nikolai Zurabishvili 2024-05-03 18:57:17 MSK
Можете пожалуйста предоставить логи 

# gpupdate &> gpupdate.log 
# gpoa --loglevel 0 &> gpoa.log


Приложите файлы gpupdate.log и gpoa.log сюда
Comment 8 rsrs 2024-05-03 19:50:12 MSK
(Ответ для Nikolai Zurabishvili на комментарий #7)
> Можете пожалуйста предоставить логи 
> 
> # gpupdate &> gpupdate.log 
> # gpoa --loglevel 0 &> gpoa.log
> 
> 
> Приложите файлы gpupdate.log и gpoa.log сюда

Почему-то в ответе сейчас отсутствует кнопка прикрепления файлов. Поэтом положу логи на Яндекс Диск:
https://disk.yandex.ru/d/SvtzzmO1ODUpEA

В прилагаемом архиве логи собраны так:

# [от имени пользователя] Проверить состояние службы запуска скриптов пользователя:
systemctl --user status gpupdate-scripts-run-user.service &> gpupdate-scripts-run-user.service-$USER.txt

# [от имени root]

gpupdate-setup status &> gpupdate-setup-root.txt

systemctl status gpupdate-scripts-run.service &> gpupdate-scripts-run.service-root.txt

ls -Rl /var/cache/gpupdate_scripts_cache/ &> gpupdate_scripts_cache-root.txt

gpoa --loglevel 0 &> gpoa-root.txt

gpoa --loglevel 0 domainuser &> gpoa-domainuser.txt
Comment 9 rsrs 2024-05-04 11:56:30 MSK
Также прилагаю вывод:

[domainuser@alt10 ~]$  gpupdate
Apply group policies for computer.
Apply group policies for domainuser.
Comment 10 rsrs 2024-05-04 11:58:24 MSK
По не понятной причине в этом обсуждении исчезла кнопка прикрепить файлы.
Поэтому я выложил логи на яндекс диск (см. посты выше).

Можно ли вернуть кнопку прикрепления файлов?
Comment 11 rsrs 2024-05-04 12:01:09 MSK
Если у Вас есть соответствующие права, прикрепите пожалуйста эти логи к обсуждению:
https://disk.yandex.ru/d/SvtzzmO1ODUpEA

ps: Может быть я не могу прикрепить файлы потому, что заявка имеет статус UNCONFIRMED?
Comment 12 rsrs 2024-05-04 18:47:56 MSK
Created attachment 16058 [details]
Логи
Comment 13 rsrs 2024-05-04 18:51:25 MSK
(Ответ для Nikolai Zurabishvili на комментарий #7)
> Можете пожалуйста предоставить логи 
> 
> # gpupdate &> gpupdate.log 
> # gpoa --loglevel 0 &> gpoa.log
> 
> 
> Приложите файлы gpupdate.log и gpoa.log сюда

[domainuser@alt10 ~]$  gpupdate
Apply group policies for computer.
Apply group policies for domainuser.

Теперь получилось прикрепить здесь логи - файл logs.zip

Повторюсь, собраны они так:

# [от имени пользователя] Проверить состояние службы запуска скриптов пользователя:
systemctl --user status gpupdate-scripts-run-user.service &> gpupdate-scripts-run-user.service-$USER.txt

# [от имени root]

gpupdate-setup status &> gpupdate-setup-root.txt

systemctl status gpupdate-scripts-run.service &> gpupdate-scripts-run.service-root.txt

ls -Rl /var/cache/gpupdate_scripts_cache/ &> gpupdate_scripts_cache-root.txt

gpoa --loglevel 0 &> gpoa-root.txt

gpoa --loglevel 0 domainuser &> gpoa-domainuser.txt
Comment 14 rsrs 2024-05-04 21:09:34 MSK
Сейчас ошибка не воспроизводится. Может быть дождаться, когда она начнёт проявляться и собрать в этот момент какие-то максимально подробные логи о ходе загрузки, выполнениях скриптов и подключениях сетевых дисков?

Могли бы Вы заранее указать, как и что можно собрать в таком случае?

Кроме того, я хотел бы обратить внимание на п.2.2-2.4 из первого сообщения. Здесь, скорее всего, не проблема непосредственно с политиками (скрипты выполняются, пишут в локальные логи) - а возникают непонятки с авторизацией: с одной стороны вход в сессию доменного пользователя проходит без ошибок, klist показывает, что всё в порядке, но ADMC не стартует с ошибкой "Не удалось подключиться к серверу. Проверьте ваше соединение и убедитесь, что вы инициализировали свои учетные данные с помощью kinit.
  Ошибка сервера: Local error"

После выполнения kinit ADMC запускается, но после перезагрузки история с ошибкой снова проявляется.

Т.е. как бы klist говорит, что всё хорошо, но ADMC так не считает и проблему устраняет до перезагрузки выполнение kinit.
Comment 15 rsrs 2024-05-04 21:39:00 MSK
Только что добился ситуации с появлением ошибки "Не удалось подключиться к серверу. Проверьте ваше соединение и убедитесь, что вы инициализировали свои учетные данные с помощью kinit.
Ошибка сервера: Local error"

Кнопка прикрепления файла опять исчезла.

Прилагаю так скриншот ошибки и состояние klist во время ошибки: https://disk.yandex.ru/i/MhXmUTlEYABm_Q

Что можно сейчас собрать?
Comment 16 rsrs 2024-05-04 21:40:03 MSK
Created attachment 16059 [details]
Не удалось подключиться к серверу домена, klist в норме

Скриншот ошибки прикрепить получилось)
Comment 17 Nikolai Zurabishvili 2024-05-06 16:30:06 MSK
(Ответ для rsrs на комментарий #15)
> Только что добился ситуации с появлением ошибки "Не удалось подключиться к
> серверу. Проверьте ваше соединение и убедитесь, что вы инициализировали свои
> учетные данные с помощью kinit.
> Ошибка сервера: Local error"
> 
> Кнопка прикрепления файла опять исчезла.
> 
> Прилагаю так скриншот ошибки и состояние klist во время ошибки:
> https://disk.yandex.ru/i/MhXmUTlEYABm_Q
> 
> Что можно сейчас собрать?

Мне не удалось воспроизвести ошибку, по логам которые вы предоставили явных ошибок не увидел, сравнивали ли аналогичные логи при появление ошибки с kinit ? Также можно дополнительно проверить сообщения # dmesg и # journalctl. Проявляется ли проблема на других образах Альт например на рабочей станции 10.2 ?
Comment 18 rsrs 2024-05-06 16:40:45 MSK
В том-то и сложность воспроизведения. Иногда ошибка проявляется после 3-5 последовательных, одна за другой перезагрузок, а иногда через десяток другой перезагрузок.

Версия 10.2 из коробки, видимо, значительно более сырая в плане политик. Там вообще из трех сетевых дисков определённых в политике почему-то после применения политики монтируется только один. Хотя если после обновиться до 10.3 (dist_upgrade) и после обновления перезагрузиться, то появляются все три диска. Поэтому с 10.2, думаю, вообще нет смысла возиться.

>  сравнивали ли аналогичные логи при появление ошибки с kinit 
Да, в п.2.2 я описывал klist именно в момент, когда ADMC не загружается. Т.е. ADMC не запускается, сетевые диски не подключены, при этом klist сообщает, что билет в порядке - в этом состоянии (в этом же сеансе), несмотря на отсутствие ошибки в klist делаю приеудительно kint и gpupdate и диски подключаются и ADMC запускается.
Comment 19 Alexander Makeenkov 2024-05-07 09:36:42 MSK
(Ответ для rsrs на комментарий #14)
> возникают непонятки с авторизацией:
> с одной стороны вход в сессию доменного пользователя проходит без ошибок,
> klist показывает, что всё в порядке, но ADMC не стартует с ошибкой "Не
> удалось подключиться к серверу. Проверьте ваше соединение и убедитесь, что
> вы инициализировали свои учетные данные с помощью kinit.
>   Ошибка сервера: Local error"
> 
> После выполнения kinit ADMC запускается, но после перезагрузки история с
> ошибкой снова проявляется.
> 
> Т.е. как бы klist говорит, что всё хорошо, но ADMC так не считает и проблему
> устраняет до перезагрузки выполнение kinit.

Ожидаемо, см. https://www.altlinux.org/ADMC#Запуск_программы
Comment 20 rsrs 2024-05-07 15:01:04 MSK
(Ответ для Alexander Makeenkov на комментарий #19)
> (Ответ для rsrs на комментарий #14)
> > возникают непонятки с авторизацией:
> > с одной стороны вход в сессию доменного пользователя проходит без ошибок,
> > klist показывает, что всё в порядке, но ADMC не стартует с ошибкой "Не
> > удалось подключиться к серверу. Проверьте ваше соединение и убедитесь, что
> > вы инициализировали свои учетные данные с помощью kinit.
> >   Ошибка сервера: Local error"
> > 
> > После выполнения kinit ADMC запускается, но после перезагрузки история с
> > ошибкой снова проявляется.
> > 
> > Т.е. как бы klist говорит, что всё хорошо, но ADMC так не считает и проблему
> > устраняет до перезагрузки выполнение kinit.
> 
> Ожидаемо, см. https://www.altlinux.org/ADMC#Запуск_программы

Думаю, что НЕ ожидаемо.

Повторю ещё раз. 

Итак, штатный сценарий. Загрузка ОС и вход в сессию Рабочего стола доменным пользователем: после входа в Рабочий стол действует билет, полученный пользователем при входе в сессию. С этим билетом открываются, в частности, подключённые сетевые диски (определяемые групповой политикой), ADMC и пр. При включении компьютера и входе пользователя также выполняются стартап- и логон- скрипты, соответственно. Оба скрипта логгируют свой запуск 1) в локальную папку /log и 2) в сетевой диск, подключаемый групповой политикой.

Если в таком сценарии последовательно многократно загружать ОС, для контроля возникновения ошибки проверять наличие сетевых дисков и возможность запуска ADMC и в случае успеха опять перезагружать ОС, то какое-то число таких циклов сетевые диски после загрузки открываются, ADMC без ошибок запускаются. Всё это происходит, естественно, потому, что для доменного пользователя действует билет, выданный ему при входе в сессию Рабочего стола. В локальных и сетевых логах отражается выполнение стартап- и логон- скриптов. 


Однако, через какое-то количество циклов в локальные логи продолжает фиксироваться выполнение стартап- и логон- скриптов, а в сетевые логи эти скрипты уже ничего не пишут. Вход в доменного пользователя сессию Рабочего стола при этом так и продолжается без ошибок, но сетевые диски из политик уже не подключаются (их папки просто пусты, без ошибок) и ADMC тоже не открывается с сообщением "Не удалось подключиться к серверу. Проверьте ваше соединение и убедитесь, что вы инициализировали свои учетные данные с помощью kinit. Ошибка сервера: Local error". Хотя с момента входа в Рабочий стол доменного пользователя никаких ошибок (в том числе и на тему авторизации) не было. Мало того, если посмотреть klist - то тоже буде показано, что билет актуален.

И вот если при этих условиях (актуальном с момента входа в Рабочий стол билете), несмотря на актуальность билета запросить его заново (kinit) и после этого выполнить gpupdate - то появляются сетевые диски от политики и ADMC снова стартует без ошибок.
Comment 21 rsrs 2024-05-07 15:06:48 MSK
Прошу изменить статус ошибки как нерешённой.
Comment 22 Alexander Makeenkov 2024-05-07 15:09:23 MSK
Перевожу на мейнтейнера.
Comment 23 rsrs 2024-05-07 15:10:55 MSK
Уточню. Стартап- и логон- скрипты в какой-то момент перестают логгировать на сетевой диск из политики потому, что в какой-то момент после какого-то количества циклов перезагрузок ОС этот сетевой диск становится не доступен. Хотя в предыдущих циклах он был доступен и стартап- и логон- скрипты писали туда без проблем.
Comment 24 rsrs 2024-05-07 15:21:20 MSK
(Ответ для Alexander Makeenkov на комментарий #22)
> Перевожу на мейнтейнера.

Состояние почему-то осталось RESOLVED, а не REOPENED.
Comment 25 Alexander Makeenkov 2024-05-07 15:22:45 MSK
(Ответ для rsrs на комментарий #24)
> Состояние почему-то осталось RESOLVED, а не REOPENED.

Вы сами его вернули в это значение https://bugzilla.altlinux.org/show_bug.cgi?id=50272#c23
Comment 26 rsrs 2024-05-07 15:24:05 MSK
(Ответ для Alexander Makeenkov на комментарий #25)
> (Ответ для rsrs на комментарий #24)
> > Состояние почему-то осталось RESOLVED, а не REOPENED.
> 
> Вы сами его вернули в это значение
> https://bugzilla.altlinux.org/show_bug.cgi?id=50272#c23

Как-то непонятно получилось) Извините)
Comment 27 rsrs 2024-05-13 14:05:07 MSK
Продолжая попытки выявить закономерность потери доступа к сетевым ресурсам из старап- и логон- скриптов (см. первый пост в заявке:  startup-script.sh и logon-script.sh), сегодня с нуля, на Альт 10.2 сразу после установки, я выполнил dist-upgrade до текущей версии Альт 10.3.

В результате, все политики успешно применились - в том числе скриптовые политики и подключение сетевых. Сетевые диски, определяемые политиками подключились. Стартап- и логон- скрипты также каждый раз успешно выполняются, о чём свидетельствует запись ими в папку /log на локальном компьютере. Однако эти же скрипты теперь ни разу не оставили записи о своём выполнении в сетевой лог (ресурс \\data2\Log$, монтируемый политикой в локальную папку Log$). При этом После загрузки ОС папка Log$ вполне успешно подключена, отображая содержимое ресурса \\data2\Log$.

Не знаю, связано ли это с текущим, сегодняшним, обновлением (dist-upgrade) или нет, но ранее стартап-скрипт логгировал свое выполнение в сетевую папку раз-другой, после чего перезагрузка компьютера уже не приводила к логгированию скрипта в сетевую папку.
Аналогично этому логон-скрипт "держался" заметно большее количество перезагрузок - переставал логгировать своё выполнение в сетевую папку уже после примерно 5-20 перезагрузки (точная систематичность так и не установлена).

Теперь же стартап- и логон- скрипты не пишут в сетевую папку Log$ НИ РАЗУ, при том что в локальный лог эти же скрипты так и пишут каждый раз.
Comment 28 rsrs 2024-05-13 14:20:56 MSK
Собственно главный вопрос: как обеспечить для стартап- и логон- скриптов, заданных в групповых политиках доступ к сетевым ресурсам, определённым в групповых же политиках?

Ранее скрипты такой доступ имели периодически. Теперь, скорее всего, после обновления dist-upgrade - доступа к сетевым ресурсам скрипты не имеют ВООБЩЕ н разу.

Всё что ранее говорилось о билетах и странностях авторизации в домене было лишь косвенным признаком того, что логон-скрипты переставали логгировать на сетевой ресурс. Т.е. это было вторичным признаком, первичная же проблема состояла в неожиданном прекращении логгирования скриптов в сетевой ресурс.
Comment 29 rsrs 2024-05-15 12:40:38 MSK
Created attachment 16117 [details]
Стартап скрипт startup-script.sh
Comment 30 rsrs 2024-05-15 12:41:33 MSK
Created attachment 16118 [details]
Настройка политики для стартап скрипта
Comment 31 rsrs 2024-05-15 12:44:41 MSK
Created attachment 16119 [details]
Настройка политики для сетевого диска
Comment 32 rsrs 2024-05-15 12:45:21 MSK
Предлагаю для начала сосредоточиться на одной части ошибки - отсутствует доступ из стартап скрипта к сетевому ресурсу на windows-сервере.

И скрипт и подключение к windows-сетевому ресурсу определены в групповой политике.

Ситуация воспроизводится ПРИМЕРНО так.

Создаём групповую политику для:
- подключения СКРЫТОГО сетевого диска на windows-сервере (см. скриншот "Сетевой диск.png").
- выполнения скрипта включения компьютера startup-script.sh (см. скриншот "Стартап скрипт.png")

Скрытый сетевой диск монтируется в /media/gpupdate/.drives.system/Log$

Скрипт startup-script.sh (см. прилагаемый startup-script.sh) пишет строку с текущей датой в заранее созданные папки:
- локальная папка /log (ЛОКАЛЬНЫЙ лог)
- подключённая групповой политикой сетевая папка /media/gpupdate/.drives.system/Log$/Alt/startup-logon (СЕТЕВОЙ лог)

--

Разворачиваем в виртуальной машине ОС Альт Рабочая станция К 10.2 и обновляем её до версии 10.3 (dist-upgrade).

Вводим компьютер в домен в подразделение с включённой описанной выше групповой политикой.

Делаем снимок виртуальной машины (А).

--

Убедиться в том, что связка скрипта startup-script.sh и сетевых дисков, определённых в групповой политике, работоспособна
можно применив политику (gpupdate) и выполнив после этого команды:
- cd /media/gpupdate/.drives.system/Log$/Alt/startup-logon # проверка подключения сетевого диска
- bash /var/cache/gpupdate_scripts_cache/machine/STARTUP/00000_STARTUP-SCRIPT.SH # скрипт на локальной машине, созданный после выполнения gpupdate

В результате такой проверки в двух папках /log и /media/gpupdate/.drives.system/Log$/Alt/startup-logon окажутся текстовые файлы, содержащие текущую дату.

--

Теперь можно приступить к попытке воспроизвести неработспособность созданной выше конфигурации - воспроизвести ошибку.

Ошибка проявляется следующим образом - в локальный лог запись происходит успешно (это говорит о успешном запуске скрипта),
а в это время в СЕТЕВОЙ лог ничего НЕ пишется и при этом:
(Б) либо после очередной перезагрузки компьютера загрузка ОС происходит без ошибки и сетевой диск подключён доступен
(В) либо после очередной перезагрузки компьютера загрузка ОС происходит без ошибки, НО сетевой диск уже НЕ подключён и НЕ доступен

После восстановления снимка (А) к исходному состоянию ситуация (Б) может происходить после 5-6, иногда 8-10 или 1-2 последовательных перезагрузок ОС.

В какой-то момент после очередной такой перезагрузки с ситуацией (А) наступает ситуация (В).

--

Замечу, что в ситуации (В) в том числе, имеют место и признаки описанные выше, связанные и с невозможностью запустить ADMC, и странным поведением klist/kinit/gpupdate, описанными в этой заявке ранее.
Но, повторюсь, это только лишь одни из признаков наступления ситуации (В).

В ситуации (Б) никаких проблем с ADMC и klist/kinit/gpupdate нет, вплоть до очередной перезагрузки ОС, когда наступает ситуация (Б).

Иногда скрипт startup-script.sh создаёт запись на сетевом диске, но происходит это уж совсем редко, и если вдруг происходит - то только один раз, после чего повторяется ситуация (Б).

--


Описанное выше поведение заставляет думать, что причиной проблемы является попытка обращения к сетевому диску из стартап скрипта. 
Т.е. если стартап скрипт не пишет в сетевой лог, а пишет только в локальный лог, то ситуация (В), скорее всего не возникает.
"Но это не точно" ;)
Comment 33 rsrs 2024-05-15 12:58:21 MSK
Т.е. похоже, что обращение из стартап скрипта к сетевому диску после нескольких последовательных таких перезагрузок ОС и выполнения скрипта как бы "портит" механизм авторизации в домене и получение билета в домене.
Comment 34 rsrs 2024-05-15 13:04:49 MSK
После восстановления снимка ОС в виртуальной машине (А) к исходному состоянию ошибка снова исчезает и начинает опять проявляться после какого-то количества перезагрузок ОС.
Comment 35 rsrs 2024-05-15 15:05:18 MSK
Created attachment 16122 [details]
policy-logs-2024-05-15.zip
Comment 36 rsrs 2024-05-15 15:06:20 MSK
Created attachment 16123 [details]
logs-2024-05-15.zip
Comment 37 rsrs 2024-05-15 15:09:48 MSK
Сейчас, около 14 часов 15.05.2024, я развернул снимок виртуальной машины с Альт К 10.3. Эта машина введена в домен, к ней применена политика подключения сетевого диска и стартап скрипта, выполняемого при включении компьютера.

Описание логики воспроизведения ошибки см. здесь: https://bugzilla.altlinux.org/show_bug.cgi?id=50272#c32

Выполнено около 13-14 последовательных перезагрузок ОС. НИ РАЗУ во время загрузки стартап скрипт НЕ произвёл запись в СЕТЕВОЙ лог, при этом запись в ЛОКАЛЬНЫЙ лог УСПЕШНО выполнялось при каждом включении компьютера.

При этом каждый после каждой перезагрузки в ФМ успешно отображается содержимое сетевой папки /media/gpupdate/.drives.system/Log$, т.е. имеем ситуацию (Б) из описания здесь:
https://bugzilla.altlinux.org/show_bug.cgi?id=50272#c32

После описанных выше перезагрузок собраны логи journalctl и dmesg и информация о политиках - см. прикреплённые файлы:
policy-logs-2024-05-15.zip
logs-2024-05-15.zip
Comment 38 rsrs 2024-05-15 15:15:13 MSK
Т.е. для начала хорошо бы разобраться с тем, почему стартап скрипт не пишет а сетевой диск.
Comment 39 rsrs 2024-05-15 15:54:27 MSK
Created attachment 16124 [details]
logs-2024-05-15-2.zip
Comment 40 rsrs 2024-05-15 15:55:05 MSK
Created attachment 16125 [details]
policy-logs-2024-05-15-2.zip
Comment 41 rsrs 2024-05-15 16:01:41 MSK
Продолжил последовательные перезагрузки компьютера после состояния, описанного в этом сообщении:
https://bugzilla.altlinux.org/show_bug.cgi?id=50272#c37

Примерно после 25-й перезагрузки (от момента разворачивания снимок виртуальной машины с Альт К 10.3 в 14 часов 15.05.2024) возникло состояние (В), описанное здесь:
https://bugzilla.altlinux.org/show_bug.cgi?id=50272#c32

Т.е. сейчас в этом состоянии сетевой диск /media/gpupdate/.drives.system/Log$ перестал быть доступен, ADMC не запускается с ошибкой "Не удалось подключиться к серверу. Проверьте ваше соединение и убедитесь, что вы инициализировали свои учетные данные с помощью kinit. Ошибка сервера: Local error"

klist в этом состоянии показывает, что с билетом проблем нет:
$ klist
Ticket cache: KEYRING:persistent:1346204650:krb_ccache_pN65NCC
Default principal: domainuser@USZN.LOCAL

Valid starting       Expires              Service principal
15.05.2024 15:40:27  16.05.2024 01:40:27  krbtgt/USZN.LOCAL@USZN.LOCAL
        renew until 16.05.2024 01:40:27
[domainuser@alt10-vb-91 2]$ 

Прилагаю собранные в этом состоянии (В) логи:
policy-logs-2024-05-15-2.zip
logs-2024-05-15-2.zip

Логи аналогичны тем, что собраны после 13-14-й перезагрузки в сообщении https://bugzilla.altlinux.org/show_bug.cgi?id=50272#c37

Только логи
  policy-logs-2024-05-15.zip
  logs-2024-05-15.zip
собраны в состоянии (Б), а
  policy-logs-2024-05-15-2.zip
  logs-2024-05-15-2.zip
собраны в состоянии (В)
Comment 42 Evgeny Sinelnikov 2024-05-19 05:07:18 MSK
Очень трудно вычитать и понять текущий статус по рассматриваемой проблеме.

Обсудил сегодня некоторые детали. Выяснилось, что один из рассматриваемых вариантов использования состоит в том, чтобы получить доступ к "сетевым ресурсам, определённым в групповых политиках"... в стартап-скриптах из-под рута!

Давайте, отдельно рассмотрим этот вариант использования и, если других вариантов здесь нет, то дадим разъяснения по этому варианту и закроем эту задачу. Если же другие варианты имеются, то давайте разнесём эту задачу на отдельные подзадачи.

___________________

Возможно, дело в документировании поведения, которое очевидно только для разработчиков, знакомых с архитектурой Active Directory. Важно в этом плане зафиксировать:

1) Доступ к шарам, монтируемым через automount с аутентификацией через Kerberos из-под рута, равносилен подключению к шаре из-под локального пользователя с очевидным, возможным отказом в доступе.

2) Получение учётных данных какого-либо пользователя в скриптах автоматически выполняемых из-под локальных скриптов машины равносильно "забиванию" пароля пользователя в настройках системы.

3) Таким образом кеширование TGT-билетов для пользователя root в стандартном кеше ключей является потенциальной угрозой.

4) То есть, если для доменного пользователя после логина вот такое допустимо:

------------------------
------- пример 1 -------

$ klist
Ticket cache: KEYRING:persistent:XXXX01104:krb_ccache_SBvYWvA
Default principal: sin@SMB.BASEALT.RU

Valid starting       Expires              Service principal
19.05.2024 01:44:58  19.05.2024 11:44:58  krbtgt/SMB.BASEALT.RU@SMB.BASEALT.RU
        renew until 26.05.2024 01:44:58

$ ls /net
docs  iso  share

$ mount | grep "on /net"
/etc/auto.cifs on /net type autofs (rw,relatime,fd=15,pgrp=2252,timeout=120,minproto=5,maxproto=5,indirect,pipe_ino=20214)

$ ls /net/docs
arch  integration  work  вакансии  инструкции

$ klist
Ticket cache: KEYRING:persistent:XXXX01104:krb_ccache_SBvYWvA
Default principal: sin@SMB.BASEALT.RU

Valid starting       Expires              Service principal
19.05.2024 03:04:59  19.05.2024 11:44:58  cifs/pve@
        renew until 26.05.2024 01:44:58
        Ticket server: cifs/pve@SMB.BASEALT.RU
19.05.2024 01:44:58  19.05.2024 11:44:58  krbtgt/SMB.BASEALT.RU@SMB.BASEALT.RU
        renew until 26.05.2024 01:44:58

--- конец примера 1 ---
------------------------

то для рута это же самое выглядит достаточно сомнительно.

И, соответственно, вот такое поведение выглядит вполне правильным:

------------------------
------- пример 2 -------

$ sudo su -

# klist
klist: Credentials cache keyring 'persistent:0:0' not found

# ls /net
docs  iso  share

# ls /net/docs
ls: невозможно открыть каталог '/net/docs': Нет такого файла или каталога

--- конец примера 2 ---
-----------------------

Настройка у меня, при этом, выглядит вот так:

# grep ^docs /etc/auto.cifs
docs -fstype=cifs,noperm,cruid=$USER,sec=krb5,multiuser,mfsymlinks,vers=2.1 ://pve/docs

и может отличаться от настройки, которую генерирует gpupdate в текущей реализации.


5) возникает вопрос: "А как же должны работать тогда стартап-скрипты с общими каталогами для рута?"

Для ответа на этот вопрос, сначала требуется определиться: "А под какими учётными данными это должно выполняться?"

Тут уже возникает несколько вариантов (как минимум, два):

5.1) стартап-скрипты могут работать из-под гостя (желательно в варианте только для чтения).

Например, так:

------------------------
------- пример 3 -------

# klist
klist: Credentials cache keyring 'persistent:0:0' not found

# ls /data/mirrors
alt  get

# ls /data/mirrors/alt/p10/branch/
aarch64  armh  doc  files  i586  noarch  ppc64le  x86_64  x86_64-i586

# mount | grep "on /data"
/etc/auto.data on /data type autofs (rw,relatime,fd=12,pgrp=2252,timeout=120,minproto=5,maxproto=5,indirect,pipe_ino=1866)
10.XX.0.6:/store/mirrors on /data/mirrors type nfs4 (ro,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,soft,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.XX.XX.XX,local_lock=none,addr=10.XX.0.6)
10.XX.0.6:/archive on /data/archive type nfs4 (ro,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,soft,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.XX.XX.XX,local_lock=none,addr=10.XX.0.6)
10.XX.0.6:/store/mirrors/alt on /data/mirrors/alt type nfs4 (ro,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,soft,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.XX.XX.XX,local_lock=none,addr=10.XX.0.6)
...

# grep ^store /etc/auto.data
store             -fstype=nfs,ro,soft 10.XX.0.6:/store

--- конец примера 3 ---
-----------------------

5.2) стартап-скрипты могут работать из-под учётной записи машины в домене:

------------------------
------- пример 4 -------

[root@xdt ~]# klist
klist: Credentials cache keyring 'persistent:0:0' not found

[root@xdt ~]# klist -ke | grep 'XDT\$'
  12 XDT$@SMB.BASEALT.RU (DEPRECATED:arcfour-hmac)
  12 XDT$@SMB.BASEALT.RU (aes128-cts-hmac-sha1-96)
  12 XDT$@SMB.BASEALT.RU (aes256-cts-hmac-sha1-96)

[root@xdt ~]# kinit -k XDT$

[root@xdt ~]# klist
Ticket cache: KEYRING:persistent:0:0
Default principal: XDT$@SMB.BASEALT.RU

Valid starting       Expires              Service principal
19.05.2024 03:22:44  19.05.2024 13:22:44  krbtgt/SMB.BASEALT.RU@SMB.BASEALT.RU
        renew until 26.05.2024 03:22:44

[root@xdt ~]# ls /net/docs
arch  integration  work  вакансии  инструкции

[root@xdt ~]# klist
Ticket cache: KEYRING:persistent:0:0
Default principal: XDT$@SMB.BASEALT.RU

Valid starting       Expires              Service principal
19.05.2024 03:23:18  19.05.2024 13:22:44  cifs/pve@
        renew until 26.05.2024 03:22:44
        Ticket server: cifs/pve@SMB.BASEALT.RU
19.05.2024 03:22:44  19.05.2024 13:22:44  krbtgt/SMB.BASEALT.RU@SMB.BASEALT.RU
        renew until 26.05.2024 03:22:44

[root@xdt ~]# mount | grep "on /net"
/etc/auto.cifs on /net type autofs (rw,relatime,fd=15,pgrp=2252,timeout=120,minproto=5,maxproto=5,indirect,pipe_ino=20214)
//pve/docs on /net/docs type cifs (rw,relatime,vers=2.1,sec=krb5,cruid=0,cache=strict,multiuser,uid=0,noforceuid,gid=0,noforcegid,addr=10.XX.0.6,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,mfsymlinks,noperm,rsize=1048576,wsize=1048576,bsize=1048576,echo_interval=60,actimeo=1,closetimeo=1)

--- конец примера 4 ---
-----------------------

Этот вариант допустим лишь в той мере, в которой рутовым приложениям, вообще могут быть даны права хоть на какие-либо действия в домене.

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

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

_________________________________________________________


Что же делать, если требуется авторизованный доступ к шаре из-под локального администратора (скрипты от имени рута - это не что иное, как выполнение кода из-под локального пользователя с uid = 0) в стартап-скрипте к некой шаре?

Рекомендации такие:

1) Желательно обойтись доступом только для чтения;
2) Если это допустимо, то проще обойтись при обращении к шаре гостевым доступом;
3) Если требуется авторизованный доступ из-под аккаунта машины, то скрипт следует написать так, чтобы учётные данные машины для каждой операции получались отдельно в отдельный кеш-ключей и после завершения операции полученный кеш-ключей сразу же очищался.

Пример переключения глобального кеша ключей:

# klist 
klist: Credentials cache keyring 'persistent:0:0' not found

# control krb5-conf-ccache
keyring

# control krb5-conf-ccache help
keyring: Keyring persistent cache stored in unswappable kernel memory
tmpfile: Traditional, simplest and most portable cache stored in temporary file
rundir: Directory cache stored in run-time variable data
kcm: Kerberos credential manager (requires service like sssd-kcm)
default: Default credential cache (usualy same as temporary file)

# control krb5-conf-ccache rundir
# klist 
klist: No credentials cache found (filename: /run/user/0/krb5cc/tkt)

# control krb5-conf-ccache tmpfile
# klist 
klist: No credentials cache found (filename: /tmp/krb5cc_0)

# control krb5-conf-ccache default
# klist 
klist: No credentials cache found (filename: /tmp/krb5cc_0)

# control krb5-conf-ccache keyring
# klist 
klist: Credentials cache keyring 'persistent:0:0' not found

Скрипт, который не использует глобальный кеш ключей пользователя (в том числе и рута) должен получится примерно такой:

------------------------
------- пример 5 -------

[root@xdt ~]# klist 
klist: Credentials cache keyring 'persistent:0:0' not found

[root@xdt ~]# ./my-service-script.sh 
Ticket cache: FILE:/tmp/.private/root/my-service.jMGY1OpH/krb5cc
Default principal: XDT$@SMB.BASEALT.RU

Valid starting       Expires              Service principal
19.05.2024 05:10:34  19.05.2024 15:10:34  krbtgt/SMB.BASEALT.RU@SMB.BASEALT.RU
        renew until 26.05.2024 05:10:34
WARNING: The option -k|--kerberos is deprecated!

        Sharename       Type      Comment
        ---------       ----      -------
        sysvol          Disk      
        netlogon        Disk      
        IPC$            IPC       IPC Service (Samba 4.19.4)
SMB1 disabled -- no workgroup available
Ticket cache: FILE:/tmp/.private/root/my-service.jMGY1OpH/krb5cc
Default principal: XDT$@SMB.BASEALT.RU

Valid starting       Expires              Service principal
19.05.2024 05:10:34  19.05.2024 15:10:34  krbtgt/SMB.BASEALT.RU@SMB.BASEALT.RU
        renew until 26.05.2024 05:10:34
19.05.2024 05:10:35  19.05.2024 15:10:34  cifs/dc.smb.basealt.ru.@SMB.BASEALT.RU
        renew until 26.05.2024 05:10:34

[root@xdt ~]# klist 
klist: Credentials cache keyring 'persistent:0:0' not found

# bash -x ./my-service-script.sh 
+ PROG=my-service
+ tmpdir=
+ ccname=
++ mktemp -dt my-service.XXXXXXXX
+ tmpdir=/tmp/.private/root/my-service.iTByjqxY
+ ccname=FILE:/tmp/.private/root/my-service.iTByjqxY/krb5cc
+ trap cleanup_handler EXIT
+ trap cleanup_handler HUP PIPE INT QUIT TERM
+ export KRB5CCNAME=FILE:/tmp/.private/root/my-service.iTByjqxY/krb5cc
+ KRB5CCNAME=FILE:/tmp/.private/root/my-service.iTByjqxY/krb5cc
++ testparm -s '--parameter-name=netbios name'
+ m=XDT
++ testparm -s --parameter-name=realm
++ tr '[:upper:]' '[:lower:]'
+ d=smb.basealt.ru
+ p='XDT$'
+ kinit -k 'XDT$'
+ klist
Ticket cache: FILE:/tmp/.private/root/my-service.iTByjqxY/krb5cc
Default principal: XDT$@SMB.BASEALT.RU

Valid starting       Expires              Service principal
19.05.2024 05:11:48  19.05.2024 15:11:48  krbtgt/SMB.BASEALT.RU@SMB.BASEALT.RU
        renew until 26.05.2024 05:11:47
++ host -t srv _kerberos._udp.smb.basealt.ru
++ sed 's/[^ ]\+ has SRV record [0-9]\+ [0-9]\+ [0-9]\+ //'
++ head -1
+ dc=dc.smb.basealt.ru.
+ smbclient -k -L dc.smb.basealt.ru.
WARNING: The option -k|--kerberos is deprecated!

        Sharename       Type      Comment
        ---------       ----      -------
        sysvol          Disk      
        netlogon        Disk      
        IPC$            IPC       IPC Service (Samba 4.19.4)
SMB1 disabled -- no workgroup available
+ klist
Ticket cache: FILE:/tmp/.private/root/my-service.iTByjqxY/krb5cc
Default principal: XDT$@SMB.BASEALT.RU

Valid starting       Expires              Service principal
19.05.2024 05:11:48  19.05.2024 15:11:48  krbtgt/SMB.BASEALT.RU@SMB.BASEALT.RU
        renew until 26.05.2024 05:11:47
19.05.2024 05:11:48  19.05.2024 15:11:48  cifs/dc.smb.basealt.ru.@SMB.BASEALT.RU
        renew until 26.05.2024 05:11:47
+ cleanup_handler
+ '[' -z FILE:/tmp/.private/root/my-service.iTByjqxY/krb5cc ']'
+ kdestroy -c FILE:/tmp/.private/root/my-service.iTByjqxY/krb5cc
+ '[' -z /tmp/.private/root/my-service.iTByjqxY ']'
+ rm -rf -- /tmp/.private/root/my-service.iTByjqxY

--- конец примера 5 ---
-----------------------

До выполнения скрипта нет полученного TGT.
После выполнения скрипта нет ни TGT, ни TGS, полученных в процессе его работы.
Доступ к общему ресурсу осуществлен.

Проблемы "хождения" через cifs-upcall из ядра (модуля драйвера cifs, который отвечает за монтирование сетевой шаре) это описание пока не решает. Но эта уже другая проблема.

Для начала мы рассмотрели вопрос о том, "Откуда, вообще, у рута могут взяться учетные данные для домена?" И тут стоит понимать, что, системно, введение машины в домен ещё не делает действия выполняемые из-под рута выполняемыми из-под учётных данных машины, которую в этот домен ввели.

Каждое такое действия необходимо специально прописывать. А то, что по какой-то причине, это просто так, само по себе, почему-то "работает" - это недоработка. Не должно, вообще, просто так оно работать.

Возможная причина: неаккуратно выполненный из-под рута kinit в пользователя (или в аккаунт машины), после использования которого был забыт сделан kdestroy.
Comment 43 Evgeny Sinelnikov 2024-05-19 05:36:06 MSK
Пример 3 оказался неудачным. В нём указан NFS.

Вот аналогичный пример для CIFS:

# klist 
klist: Credentials cache keyring 'persistent:0:0' not found

# ls -l /net/alt/p10/branch/
итого 0
drwxr-xr-x 2 root root 0 сен 13  2020 aarch64
drwxr-xr-x 2 root root 0 сен 13  2020 armh
drwxr-xr-x 2 root root 0 мар 23  2010 doc
drwxr-xr-x 2 root root 0 мая 18 04:03 files
drwxr-xr-x 2 root root 0 сен 13  2020 i586
drwxr-xr-x 2 root root 0 сен 13  2020 noarch
drwxr-xr-x 2 root root 0 сен 13  2020 ppc64le
drwxr-xr-x 2 root root 0 сен 13  2020 x86_64
drwxr-xr-x 2 root root 0 сен 14  2020 x86_64-i586

# klist 
klist: Credentials cache keyring 'persistent:0:0' not found

# grep alt /etc/auto.cifs
alt -fstype=cifs,noperm,guest,vers=2.1 ://pve/alt

# mount | grep /alt
//pve/alt on /net/alt type cifs (rw,relatime,vers=2.1,sec=none,cache=strict,uid=0,noforceuid,gid=0,noforcegid,addr=10.XX.0.6,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,noperm,rsize=1048576,wsize=1048576,bsize=1048576,echo_interval=60,actimeo=1,closetimeo=1)

Настройка на сервер должна допускать в шару гостя:

[root@pve ~]# grep -A5 '\[alt\]' /etc/samba/smb.conf
[alt]
    comment = Mirrors
    path = /store/mirrors/alt
    guest ok = Yes
    writable = no

____________________________________

В этом плане очень важная возможность Samba, по отношению к smb-файловому серверу в Windows:
Один и тот же каталог можно "расшарить" с разными правами для разных пользователей.

Например, зеркало с ПО всем на чтение, как одну шару, и админам на запись, как другую.

_________________________

Стоит отметить, что покрыть все варианты использования с помощью групповых политик сразу не представляется возможным. Поэтому, если данный вариант сетевой шары только для чтения не покрыт в текущем функционале gpupdate, то запрос на доработку требуется оформить отдельной задачей.
Comment 44 Evgeny Sinelnikov 2024-05-19 05:54:16 MSK
Created attachment 16150 [details]
Пример скрипта для работы из-под аккаунта машины

Для работы из-под учётных машины необходимо:

1) выделить новое хранилище для кеша ключей;

2) обеспечить его очистку после завершения скрипта;

3) рассчитывать на выполнение необходимых действий только при доступности контроллеров домена во время загрузки для стартап-скриптов.

________________________________

Дополнительно. некорректно настроенная сеть (прежде всего DNS), наполовину рабочие или доступные КД в сети и т.п. проблемы могут также приводит странному и волшебному поведению.

Только более подробная диагностика состояния сетевых настроек и сервисов самой сети, может дать возможность определиться с причинами некоторого поведения, которое обсуждается в этой раздутой и довольно нечёткой задаче.

Предлагаю, всё-таки, сделать новые задачи по каждому рассматриваемому техническому вопросу.

Как минимум,
- не смешивать логику и проблемы логон-скриптов и стартап-скриптов;
- отделить проблемы получения учётных данных машины для "рутового" пользователя в драйвере cifs из специального (не глобального) кеша ключей.
Comment 45 Evgeny Sinelnikov 2024-05-19 06:23:11 MSK
(Ответ для rsrs на комментарий #16)
> Создано вложение 16059 [details] [подробности]
> Не удалось подключиться к серверу домена, klist в норме
> 
> Скриншот ошибки прикрепить получилось)

Мне всё больше кажется, что в этой задаче всё смешалось - и мёд, и гвозди...

Для диагностики кеша ключей не обязательно выполнять запуск ADMC. Гораздо правильнее выполнять простой запрос к службам MS-RPC через libsmbclient (протокол SMB/CIFS) или к службе каталогов (протокол LDAP) через ldapsearch:

$ kinit 
Password for sin@SMB.BASEALT.RU: 
Warning: Your password will expire in 153 days on Сб 19 окт 2024 07:27:54

$ klist 
Ticket cache: KEYRING:persistent:XXXX01104:krb_ccache_SBvYWvA
Default principal: sin@SMB.BASEALT.RU

Valid starting       Expires              Service principal
19.05.2024 07:06:20  19.05.2024 17:06:20  krbtgt/SMB.BASEALT.RU@SMB.BASEALT.RU
        renew until 26.05.2024 07:06:13

$ smbclient -k -L //dc
WARNING: The option -k|--kerberos is deprecated!

        Sharename       Type      Comment
        ---------       ----      -------
        sysvol          Disk      
        netlogon        Disk      
        IPC$            IPC       IPC Service (Samba 4.19.4)
SMB1 disabled -- no workgroup available

$ klist 
Ticket cache: KEYRING:persistent:XXX01104:krb_ccache_SBvYWvA
Default principal: sin@SMB.BASEALT.RU

Valid starting       Expires              Service principal
19.05.2024 07:07:01  19.05.2024 17:06:20  cifs/dc@SMB.BASEALT.RU
        renew until 26.05.2024 07:06:13
19.05.2024 07:06:20  19.05.2024 17:06:20  krbtgt/SMB.BASEALT.RU@SMB.BASEALT.RU
        renew until 26.05.2024 07:06:13


$ ldapsearch -Q -LLL -Y GSSAPI -H ldap://dc.smb.basealt.ru -b "dc=smb,dc=basealt,dc=ru" "(sAMAccountName=sin)" displayName dn
dn: CN=Evgeny Sinelnikov,OU=Developers,OU=Saratov,DC=smb,DC=basealt,DC=ru
displayName: Evgeny Sinelnikov

# refldap://smb.basealt.ru/CN=Configuration,DC=smb,DC=basealt,DC=ru

# refldap://smb.basealt.ru/DC=DomainDnsZones,DC=smb,DC=basealt,DC=ru

# refldap://smb.basealt.ru/DC=ForestDnsZones,DC=smb,DC=basealt,DC=ru

$ klist 
Ticket cache: KEYRING:persistent:XXXX01104:krb_ccache_SBvYWvA
Default principal: sin@SMB.BASEALT.RU

Valid starting       Expires              Service principal
19.05.2024 07:10:51  19.05.2024 17:06:20  ldap/dc.smb.basealt.ru@
        renew until 26.05.2024 07:06:13
        Ticket server: ldap/dc.smb.basealt.ru@SMB.BASEALT.RU
19.05.2024 07:07:01  19.05.2024 17:06:20  cifs/dc@SMB.BASEALT.RU
        renew until 26.05.2024 07:06:13
19.05.2024 07:06:20  19.05.2024 17:06:20  krbtgt/SMB.BASEALT.RU@SMB.BASEALT.RU
        renew until 26.05.2024 07:06:13


_________________________________________

Стоит отметить также и указать на время и дату. Нельзя просто так восстановить машину из снапшота в некотором состоянии и рассчитывать на то, что кеш ключей не "протух". Если время, на которое были выданы ключи, прошло, то их не не получится просто так восстановить без повторной процедуры kinit.

В приведенном же скриншоте текущего времени, по отношению к времени в системе явно не видно.