Допустим, у меня есть корпоративный домен 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, как следует настроить демон, например, из сценария выскочки? Обычно вы начинаете с чего-то вроде sudo -u myserviceuser <cmd>, но с учетом приведенных выше предположений предоставит ли это веб-службе какие-либо права на доступ к сетевым ресурсам? Разве нельзя где-то вводить пароль для этого пользователя?
ИМО, по этому поводу не хватает четкой документации.
Вы правы - если служба защищена Kerberos, то su / sudo недостаточно для обхода необходимой авторизации (ЕСЛИ целевой пользователь не имеет кэшированного билета, потому что он в настоящее время вошел в систему, или keytab). Большинство ресурсов (например, локальная файловая система) полагаются на uidnumber и gidnumber для идентификации пользователя, и их можно обойти с помощью root / sudo доступа.
Это забавный вопрос, с которым я сейчас работаю. Скажите сервисный аккаунт Apache требуется доступ к керберизованному общему ресурсу NFS. Вам нужно экспортировать keytab для Apache в локальную файловую систему и источник, который при запуске службы периодически обновляет свой билет, возможно, через cron. RHEL7 имеет gssproxy, который, кажется, упрощает это, но я еще не дошел до этого момента.
Keytab - это фактически сохраненные учетные данные. Если кто-то может получить к нему доступ, он может выдать себя за этого пользователя. Экспорт новой вкладки в IPA и AD изменяет пароль учетной записи.
Microsoft kerberos немного отличается, но большинство правил все еще применяется.
У меня аналогичная ситуация с домашними каталогами autofs в каталогах с Kerberized NFSv4:
~/.ssh/authorized_keys потому что домашний каталог недоступен для демона SSH на цели. Он не недоступен, потому что он отключен, скорее он недоступен, потому что демон SSH не имеет TGT для доступа к домашнему каталогу, содержащему authorized_keys файл.sudo разрешения, я не могу sudo su в учетную запись другого пользователя без недоступности их домашнего каталога - опять же, у меня нет их TGT.su в свою учетную запись и иметь доступ к их домашнему каталогу при входе в систему, если у меня есть их пароль, потому что вход через su проходит через PAM, и это дает мне TGT, который позволяет успешно выполнить автоматическое монтирование.kdestroy. Теперь я могу sudo su в учетную запись этого пользователя и домашний каталог автомонтирования будет успешным. Общая тенденция здесь заключается в том, что TGT недоступен, если перенаправляемый билет не передан с другого компьютера или если у пользователя есть пароль для получения билета с какой-либо формой входа в систему или kinit.
Разрешение, что учетные записи служб могут иногда принимать пользователей (например, для централизации сложной конфигурации, такой как ~/.kube/) недостаточно поместить keytab в каталог учетной записи по той же причине, что и authorized_keys не работает. Недостаточно также полагаться на билеты с длительным сроком службы и задания cron для пополнения системной связки ключей, потому что при перезагрузке связка ключей будет стерта, и она будет недоступна до следующего вызова cron (что, вероятно, займет некоторое время). Также беспорядок настраивать подобный cron на кластере машин.