Bug 50272
| Summary: | Нет доступа из логон скриптов групповых политик к сетевым ресурсам, определённых в групповых политиках | ||
|---|---|---|---|
| Product: | Branch p10 | Reporter: | rsrs <rstaganrog> |
| Component: | gpupdate | Assignee: | 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: | |||
Created attachment 16053 [details]
скрипт для systemd-логон скрипта
Created attachment 16054 [details]
логон скрипт для групповой политики
Created attachment 16055 [details]
стартап скрипт для групповой политики
1. Сейчас выключил политику alt-scripts от подразделения, в котором находится клиент Альт. 2. Несколько раз перезагрузил компьютер. 3. Диски "Диск T" и "Диск M" появились. 4. Включил снова политику alt-scripts, однако после этого скрипт (*) после нескольких загрузок так и не стал выполняться, хотя локальное логгирование в папку /log скриптом политики выполняется. Такое впечатление, что периодически вов время выполнения логон скриптов сетевые диск оказываются "не вполне готовы" к использованию в скриптах, что приводит к более серьёзным последствиям как для самих сетевых дисках, так и к нестыковкам в билетной авторизации (см. п.2.1) - билет вроде бы и есть, но ADMC при запуске выдаёт ошибку. В этом случае диски "Диск T" и "Диск M" появляются и запускается ADMC только если в этой же сессии выполнить kinit domainuser. Может быть можно сделать какие-либо настройки в групповых политиках, чтобы обеспечивать стартап и логон скриптам (из групповых политик) гарантированный доступ к сетевым дискам, подключаемых групповыми политиками? (Ответ для rsrs на комментарий #4) > 1. Сейчас выключил политику alt-scripts от подразделения, в котором > находится клиент Альт. > 2. Несколько раз перезагрузил компьютер. > 3. Диски "Диск T" и "Диск M" появились. > 4. Включил снова политику alt-scripts, однако после этого скрипт (*) после > нескольких загрузок так и не стал выполняться, хотя локальное логгирование в > папку /log скриптом политики выполняется. Дополнение этому описанию: после нескольких перезагрузок на шаге 4 логгирование (*) стало выполняться снова. Можете пожалуйста предоставить логи # gpupdate &> gpupdate.log # gpoa --loglevel 0 &> gpoa.log Приложите файлы gpupdate.log и gpoa.log сюда (Ответ для 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 Также прилагаю вывод: [domainuser@alt10 ~]$ gpupdate Apply group policies for computer. Apply group policies for domainuser. По не понятной причине в этом обсуждении исчезла кнопка прикрепить файлы. Поэтому я выложил логи на яндекс диск (см. посты выше). Можно ли вернуть кнопку прикрепления файлов? Если у Вас есть соответствующие права, прикрепите пожалуйста эти логи к обсуждению: https://disk.yandex.ru/d/SvtzzmO1ODUpEA ps: Может быть я не могу прикрепить файлы потому, что заявка имеет статус UNCONFIRMED? Created attachment 16058 [details]
Логи
(Ответ для 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 Сейчас ошибка не воспроизводится. Может быть дождаться, когда она начнёт проявляться и собрать в этот момент какие-то максимально подробные логи о ходе загрузки, выполнениях скриптов и подключениях сетевых дисков? Могли бы Вы заранее указать, как и что можно собрать в таком случае? Кроме того, я хотел бы обратить внимание на п.2.2-2.4 из первого сообщения. Здесь, скорее всего, не проблема непосредственно с политиками (скрипты выполняются, пишут в локальные логи) - а возникают непонятки с авторизацией: с одной стороны вход в сессию доменного пользователя проходит без ошибок, klist показывает, что всё в порядке, но ADMC не стартует с ошибкой "Не удалось подключиться к серверу. Проверьте ваше соединение и убедитесь, что вы инициализировали свои учетные данные с помощью kinit. Ошибка сервера: Local error" После выполнения kinit ADMC запускается, но после перезагрузки история с ошибкой снова проявляется. Т.е. как бы klist говорит, что всё хорошо, но ADMC так не считает и проблему устраняет до перезагрузки выполнение kinit. Только что добился ситуации с появлением ошибки "Не удалось подключиться к серверу. Проверьте ваше соединение и убедитесь, что вы инициализировали свои учетные данные с помощью kinit. Ошибка сервера: Local error" Кнопка прикрепления файла опять исчезла. Прилагаю так скриншот ошибки и состояние klist во время ошибки: https://disk.yandex.ru/i/MhXmUTlEYABm_Q Что можно сейчас собрать? Created attachment 16059 [details]
Не удалось подключиться к серверу домена, klist в норме
Скриншот ошибки прикрепить получилось)
(Ответ для rsrs на комментарий #15) > Только что добился ситуации с появлением ошибки "Не удалось подключиться к > серверу. Проверьте ваше соединение и убедитесь, что вы инициализировали свои > учетные данные с помощью kinit. > Ошибка сервера: Local error" > > Кнопка прикрепления файла опять исчезла. > > Прилагаю так скриншот ошибки и состояние klist во время ошибки: > https://disk.yandex.ru/i/MhXmUTlEYABm_Q > > Что можно сейчас собрать? Мне не удалось воспроизвести ошибку, по логам которые вы предоставили явных ошибок не увидел, сравнивали ли аналогичные логи при появление ошибки с kinit ? Также можно дополнительно проверить сообщения # dmesg и # journalctl. Проявляется ли проблема на других образах Альт например на рабочей станции 10.2 ? В том-то и сложность воспроизведения. Иногда ошибка проявляется после 3-5 последовательных, одна за другой перезагрузок, а иногда через десяток другой перезагрузок.
Версия 10.2 из коробки, видимо, значительно более сырая в плане политик. Там вообще из трех сетевых дисков определённых в политике почему-то после применения политики монтируется только один. Хотя если после обновиться до 10.3 (dist_upgrade) и после обновления перезагрузиться, то появляются все три диска. Поэтому с 10.2, думаю, вообще нет смысла возиться.
> сравнивали ли аналогичные логи при появление ошибки с kinit
Да, в п.2.2 я описывал klist именно в момент, когда ADMC не загружается. Т.е. ADMC не запускается, сетевые диски не подключены, при этом klist сообщает, что билет в порядке - в этом состоянии (в этом же сеансе), несмотря на отсутствие ошибки в klist делаю приеудительно kint и gpupdate и диски подключаются и ADMC запускается.
(Ответ для rsrs на комментарий #14) > возникают непонятки с авторизацией: > с одной стороны вход в сессию доменного пользователя проходит без ошибок, > klist показывает, что всё в порядке, но ADMC не стартует с ошибкой "Не > удалось подключиться к серверу. Проверьте ваше соединение и убедитесь, что > вы инициализировали свои учетные данные с помощью kinit. > Ошибка сервера: Local error" > > После выполнения kinit ADMC запускается, но после перезагрузки история с > ошибкой снова проявляется. > > Т.е. как бы klist говорит, что всё хорошо, но ADMC так не считает и проблему > устраняет до перезагрузки выполнение kinit. Ожидаемо, см. https://www.altlinux.org/ADMC#Запуск_программы (Ответ для 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 снова стартует без ошибок. Прошу изменить статус ошибки как нерешённой. Перевожу на мейнтейнера. Уточню. Стартап- и логон- скрипты в какой-то момент перестают логгировать на сетевой диск из политики потому, что в какой-то момент после какого-то количества циклов перезагрузок ОС этот сетевой диск становится не доступен. Хотя в предыдущих циклах он был доступен и стартап- и логон- скрипты писали туда без проблем. (Ответ для Alexander Makeenkov на комментарий #22) > Перевожу на мейнтейнера. Состояние почему-то осталось RESOLVED, а не REOPENED. (Ответ для rsrs на комментарий #24) > Состояние почему-то осталось RESOLVED, а не REOPENED. Вы сами его вернули в это значение https://bugzilla.altlinux.org/show_bug.cgi?id=50272#c23 (Ответ для Alexander Makeenkov на комментарий #25) > (Ответ для rsrs на комментарий #24) > > Состояние почему-то осталось RESOLVED, а не REOPENED. > > Вы сами его вернули в это значение > https://bugzilla.altlinux.org/show_bug.cgi?id=50272#c23 Как-то непонятно получилось) Извините) Продолжая попытки выявить закономерность потери доступа к сетевым ресурсам из старап- и логон- скриптов (см. первый пост в заявке: startup-script.sh и logon-script.sh), сегодня с нуля, на Альт 10.2 сразу после установки, я выполнил dist-upgrade до текущей версии Альт 10.3. В результате, все политики успешно применились - в том числе скриптовые политики и подключение сетевых. Сетевые диски, определяемые политиками подключились. Стартап- и логон- скрипты также каждый раз успешно выполняются, о чём свидетельствует запись ими в папку /log на локальном компьютере. Однако эти же скрипты теперь ни разу не оставили записи о своём выполнении в сетевой лог (ресурс \\data2\Log$, монтируемый политикой в локальную папку Log$). При этом После загрузки ОС папка Log$ вполне успешно подключена, отображая содержимое ресурса \\data2\Log$. Не знаю, связано ли это с текущим, сегодняшним, обновлением (dist-upgrade) или нет, но ранее стартап-скрипт логгировал свое выполнение в сетевую папку раз-другой, после чего перезагрузка компьютера уже не приводила к логгированию скрипта в сетевую папку. Аналогично этому логон-скрипт "держался" заметно большее количество перезагрузок - переставал логгировать своё выполнение в сетевую папку уже после примерно 5-20 перезагрузки (точная систематичность так и не установлена). Теперь же стартап- и логон- скрипты не пишут в сетевую папку Log$ НИ РАЗУ, при том что в локальный лог эти же скрипты так и пишут каждый раз. Собственно главный вопрос: как обеспечить для стартап- и логон- скриптов, заданных в групповых политиках доступ к сетевым ресурсам, определённым в групповых же политиках? Ранее скрипты такой доступ имели периодически. Теперь, скорее всего, после обновления dist-upgrade - доступа к сетевым ресурсам скрипты не имеют ВООБЩЕ н разу. Всё что ранее говорилось о билетах и странностях авторизации в домене было лишь косвенным признаком того, что логон-скрипты переставали логгировать на сетевой ресурс. Т.е. это было вторичным признаком, первичная же проблема состояла в неожиданном прекращении логгирования скриптов в сетевой ресурс. Created attachment 16117 [details]
Стартап скрипт startup-script.sh
Created attachment 16118 [details]
Настройка политики для стартап скрипта
Created attachment 16119 [details]
Настройка политики для сетевого диска
Предлагаю для начала сосредоточиться на одной части ошибки - отсутствует доступ из стартап скрипта к сетевому ресурсу на 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 создаёт запись на сетевом диске, но происходит это уж совсем редко, и если вдруг происходит - то только один раз, после чего повторяется ситуация (Б). -- Описанное выше поведение заставляет думать, что причиной проблемы является попытка обращения к сетевому диску из стартап скрипта. Т.е. если стартап скрипт не пишет в сетевой лог, а пишет только в локальный лог, то ситуация (В), скорее всего не возникает. "Но это не точно" ;) Т.е. похоже, что обращение из стартап скрипта к сетевому диску после нескольких последовательных таких перезагрузок ОС и выполнения скрипта как бы "портит" механизм авторизации в домене и получение билета в домене. После восстановления снимка ОС в виртуальной машине (А) к исходному состоянию ошибка снова исчезает и начинает опять проявляться после какого-то количества перезагрузок ОС. Created attachment 16122 [details]
policy-logs-2024-05-15.zip
Created attachment 16123 [details]
logs-2024-05-15.zip
Сейчас, около 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 Т.е. для начала хорошо бы разобраться с тем, почему стартап скрипт не пишет а сетевой диск. Created attachment 16124 [details]
logs-2024-05-15-2.zip
Created attachment 16125 [details]
policy-logs-2024-05-15-2.zip
Продолжил последовательные перезагрузки компьютера после состояния, описанного в этом сообщении: 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 собраны в состоянии (В) Очень трудно вычитать и понять текущий статус по рассматриваемой проблеме. Обсудил сегодня некоторые детали. Выяснилось, что один из рассматриваемых вариантов использования состоит в том, чтобы получить доступ к "сетевым ресурсам, определённым в групповых политиках"... в стартап-скриптах из-под рута! Давайте, отдельно рассмотрим этот вариант использования и, если других вариантов здесь нет, то дадим разъяснения по этому варианту и закроем эту задачу. Если же другие варианты имеются, то давайте разнесём эту задачу на отдельные подзадачи. ___________________ Возможно, дело в документировании поведения, которое очевидно только для разработчиков, знакомых с архитектурой 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. Пример 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, то запрос на доработку требуется оформить отдельной задачей.
Created attachment 16150 [details]
Пример скрипта для работы из-под аккаунта машины
Для работы из-под учётных машины необходимо:
1) выделить новое хранилище для кеша ключей;
2) обеспечить его очистку после завершения скрипта;
3) рассчитывать на выполнение необходимых действий только при доступности контроллеров домена во время загрузки для стартап-скриптов.
________________________________
Дополнительно. некорректно настроенная сеть (прежде всего DNS), наполовину рабочие или доступные КД в сети и т.п. проблемы могут также приводит странному и волшебному поведению.
Только более подробная диагностика состояния сетевых настроек и сервисов самой сети, может дать возможность определиться с причинами некоторого поведения, которое обсуждается в этой раздутой и довольно нечёткой задаче.
Предлагаю, всё-таки, сделать новые задачи по каждому рассматриваемому техническому вопросу.
Как минимум,
- не смешивать логику и проблемы логон-скриптов и стартап-скриптов;
- отделить проблемы получения учётных данных машины для "рутового" пользователя в драйвере cifs из специального (не глобального) кеша ключей.
(Ответ для 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. В приведенном же скриншоте текущего времени, по отношению к времени в системе явно не видно. |
Description
rsrs 2024-05-03 13:05:18 MSK