Вопросы Теги

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

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

  1. Какого рода? youruser полномочия будут myuser имейте в этой точке? Очевидно, если youruser также имеет корневой каталог на машине, myuser может теперь получить доступ к нему и считать его частные локальные файлы. Но что произойдет при попытке получить доступ к ресурсу сетевого домена с помощью kerberos, самба и т.д.? Я предполагаю, так как он никогда не входил youruserпароль он не аутентифицируется как пользователь домена, не имеет kerberos билета и т.д. Таким образом, если существует сетевая служба, которая проверяет составы группы на его идентификатор пользователя, который также перестанет работать? Как это работает? Он считается другим пользователем, скажем, mymachine\\youruser в противоположность mydomain\\youruser?

  2. Предположим, что существует веб-сервис, работающий как демон на машине, с помощью преданного пользователя домена myserviceuser. Если для этого веб-сервиса нужно к ресурсам сети доступа, т.е. пройдите проверку подлинности с Kerberos, как демон должен быть настроен, например, из новомодного сценария? Обычно Вы запускаете его с помощью чего-то как sudo -u myserviceuser <cmd>, но данный вышеупомянутые предположения, это предоставит веб-сервису какие-либо права на ресурсы сети доступа? Не был должен пароль для этого пользователя должен быть введен где-нибудь?

5
задан 24 June 2015 в 08:33
2 ответа

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

  1. Вы правы - если сервис защищен кербером, то su/sudo не достаточно, чтобы обойти необходимую авторизацию (НЕДОСТАТКО, чтобы у целевого пользователя был кэшированный билет, потому что он в данный момент входит в систему, или кэш-блок). Большинство ресурсов (например, локальная файловая система) полагаются на uidnumber и gidnumber для идентификации пользователя, и могут быть обойдены с помощью root/sudo доступа

  2. Это забавный случай, с которым я имею дело в настоящее время на работе. Скажем, служебная учетная запись apache должна получить доступ к керберизованному ресурсу NFS. Вам нужно экспортировать ключ для apache в локальную файловую систему и исходный код, который при запуске службы периодически обновляется, возможно, через cron. В RHEL7 есть gssproxy, что, похоже, упрощает эту задачу, но до этого момента я ещё не дошёл.

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

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

1
ответ дан 3 December 2019 в 02:02

Я нахожусь в аналогичной ситуации с домашними каталогами 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 в учетную запись этого пользователя, и домашний каталог будет выполнен автоматически.

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

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

0
ответ дан 3 December 2019 в 02:02

Теги

Похожие вопросы