Привилегии при выполнении sudo другому пользователю домена

Question

Привилегии при выполнении sudo другому пользователю домена

Предположим, у меня есть корпоративный домен mydomain используя MS Active Directory. В домене у меня есть пользователи myuser а также youruser, Теперь на одной конкретной машине с Ubuntu mymachine, myuser имеет права sudo и делает sudo su youruser (или же sudo -u youruser sh). Так как myuser имеет необходимую конфигурацию sudoers, ему не нужно вводить пароль вашего пользователя, и он станет вашим пользователем на этом компьютере.

Какого рода youruser привилегии будут myuser есть на данный момент? Очевидно, если youruser также есть домашний каталог на машине, myuser Теперь можете получить к нему доступ и читать его личные локальные файлы. Но что произойдет, если вы попытаетесь получить доступ к ресурсу сетевого домена с помощью Kerberos, Samba и т. Д.? Я думаю, так как он никогда не вошел youruserпароль, он не аутентифицирован как пользователь домена, не имеет билета Kerberos и т. д. Итак, если есть сетевой сервис, который проверяет членство в группах по его идентификатору пользователя, это тоже не сработает? Как это работает? Считается ли он другим пользователем, скажем, mymachine\\youruser в отличие от mydomain\\youruser?
Предположим, что на компьютере работает веб-служба в качестве демона, использующая выделенного пользователя домена myserviceuser, Если этому веб-сервису требуется доступ к сетевым ресурсам, т. Е. Аутентификация с помощью Kerberos, как настроить демона, например, из сценария upstart? Обычно вы начинаете, используя что-то вроде sudo -u myserviceuser <cmd>, но учитывая вышеизложенные предположения, предоставит ли это веб-службе какие-либо права на доступ к сетевым ресурсам? Разве пароль для этого пользователя не должен быть где-то введен?

6

linux authentication kerberos sudo upstart

Источник

JHH 24 июн '15 в 05:33

2 ответа

Другие вопросы по тегам linux authentication kerberos sudo upstart

Andy 24 июн '15 в 08:46 2015-06-24 08:46 · Answer 1 · 2015-06-24 08:46

Там нет почти достаточно четкой документации по этому материалу IMO.

Вы правы - если служба защищена Kerberos, то su /sudo недостаточно для обхода необходимой авторизации (ЕСЛИ У целевого пользователя нет кэшированного билета, поскольку он в данный момент вошел в систему, или таблица ключей). Большинство ресурсов (например, локальная файловая система) полагаются на uidnumber и gidnumber для идентификации пользователя и могут быть обойдены доступом root /sudo
Это забавно, с которым я имею дело в настоящее время на работе. Скажем, учетная запись службы Apache должна получить доступ к общедоступному ресурсу NFS. Вам необходимо экспортировать keytab для apache в локальную файловую систему и исходный код, который при запуске службы периодически обновляет свой тикет, возможно, через cron. У RHEL7 есть gssproxy, который, кажется, упрощает это, но я еще не дошел до этого момента.

Keytab - это фактически сохраненные учетные данные. Если кто-то может получить к нему доступ, он может маскироваться под этого пользователя. Экспорт новой таблицы ключей в IPA и AD изменяет пароль учетной записи.

Microsoft Kerberos немного отличается, но большинство правил все еще применяются.

Brian Topping 08 апр '18 в 20:21 2018-04-08 20:21 · Answer 2 · 2018-04-08 20:21

Я нахожусь в аналогичной ситуации с домашними каталогами autofs в каталогах Kerberized NFSv4:

Если я работаю с другого компьютера с керберизацией, я могу подключиться к целевому компьютеру по протоколу SSH с помощью перенаправляемого TGT, и моя учетная запись на целевом компьютере обычно входит в систему с моим автоматически подключаемым домашним каталогом.
Если я не прихожу с другого компьютера с керберизацией, я могу (при условии локального ACL) войти в систему с паролем к этому компьютеру, и PAM сгенерирует билет. Автомонтированный домашний каталог также подходит в этой ситуации.
Я не могу войти в эту машину, если я зависим от учетной записи, имеющей запись в ~/.ssh/authorized_keys потому что домашний каталог недоступен для демона SSH на цели. Он не недоступен, потому что он отключен, скорее он недоступен, потому что демон SSH не имеет TGT для доступа к домашнему каталогу, содержащему authorized_keys файл.
После того, как я получил доступ к машине, независимо от sudo разрешения, я не могу sudo su к учетной записи другого пользователя без доступа к его домашнему каталогу - опять же у меня нет их TGT.
На этой машине я могу su в свою учетную запись и их домашний каталог будет доступен при входе в систему, если у меня есть их пароль, потому что вход через su проходит через PAM, и это дает мне TGT, который позволит автомонтирование для успеха.
На архитектурах, где TGT хранится в доступном хранилище ключей (например, системной цепочке для ключей), TGT не стирается при выходе из системы, если не выполняется явное kdestroy, Теперь я могу sudo su к учетной записи этого пользователя, и домашний каталог automount будет успешным.

Общая нить здесь заключается в том, что TGT недоступен, если пересылаемый билет не передан с другого компьютера, или у пользователя нет пароля для получения билета с какой-либо формой входа в систему или kinit,

Разрешение на то, что учетные записи службы могут иногда размещать пользователей (скажем, для централизации сложной конфигурации, такой как ~/.kube/) недостаточно поместить таблицу ключей в каталог учетной записи по той же причине, что authorized_keys не работает. Также недостаточно полагаться на тикеты с большим временем жизни и заданиями cron для пополнения системной цепочки для ключей, потому что перезагрузка уничтожит цепочку для ключей, и она будет недоступна до следующего вызова cron (что, вероятно, будет некоторое время). Также беспорядок в настройке cron на кластере машин.