Цербероводам. Как сделать блок-лист?

Я правильно понимаю, это для того, что бы при валидном тикете сказать ограничить пользователя от подключения к некоторым керберизованным сервисам?

Вообщем-то примерно так. Пользователь и сервис сидят в одном и том же релме, пользователь может получить TGT от цербера, но при попытке получить билет на какой-нибудь из сервисов, цербер проверяет пользователя и сервис по блэк-листу и либо дает, либо не дает пользователю service ticket.

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

я не уверен, но думаю, что приложение должно само контролировать этот вопрос.

глянь вот сюда, кстати. http://www.padl.com/Products/KerberosAuthenticationPlu-2.html

вообще, нужно внимательнее про kerberos authorization читать.

Да, конечно, авторизация в Цербере есть, только никто ею не пользуется (за исключением M$ - но они понятное дело нам не указ). Т.е. клиент может засунуть некоторую авторизационную информацию в запрос к Церберу, а Цербер запихнет ее в билетик, который потом окажется у сервися, но в настоящее время как серверы так и клиенты эту возможность не используют (им просто плевать, что написано в этом поле, Церберу тем более - его задача получил-отправил).

Вроде бы пропатчить n функций из API Цербера, чтобы они делали проверку по блэк-листам не сложно. Сложно доказать, что не найдется n+1 функция, с помощью которой слишком умный клиент не обойдет все эти проверки.

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

Есть кластер из нескольких компов внутри локальной сетки. Чтоб на нем можно было что-то считать некоторый набор пользователей должен иметь доступ к шеллу этих компьютеров. Поскольку на каждом из компов стоит диск, полный объем которых для расчетных целей не нужен, предполагается, что это дисковое пространство может быть использовано другим (большим) множеством пользователей для своих целей. Предполагается, что кластер экспортирует свои директории через старый добрый nfs. Проверка пользователей для доступа к nfs производится через их uid/gid (стандартный линуксовый вариант). Т.е. нам нужно обеспечить, чтобы uid/gid пользователя был глобален для всей сети. Отлично - организуем единую информационную службу, которая раздает системную информацию о пользователях по всей сети (поскольку nfs-clientы не обязаны входить в кластер). Но в этом случае получается, что пользователи nfs автоматически получают удаленный доступ к shell-у на кластере, что нам не нужно.Запретить только шелл для них не получается, т.к. та же самая системная информация используется на их рабочих станциях, а на них-то как раз доступ к shell очень даже нужен.

Если бы в Цербере был долбоеб-лист, то можно было бы просто запретить рользователям из этого списка получать билетик для принципалов host/claster.host@..., а вся остальная информация (список принципалов Цербера и авторизационная информация в информационной службе) по прежнему остается одинаковой для всей сети.

Вроде бы как-то так.

поэтому я и говорю - лучше делать это в приложении. как у тебя можно попасть на кластер? через kerberized ssh? ну, в openssh можно вообще AllowUsers сделать и не мучаться, но в общем случае - надо в приложении делать обращение в некий централизованный ресурс, таблицу, какие сервисы разрешены пользователю на каких хостах. Хранить ее можно в LDAP. Или в NIS(+), или что там у тебя.