Назад | Перейти на главную страницу

Локальная блокировка учетной записи пользователя при включенном Kerberos

Я пытаюсь настроить учетные записи под управлением Chef для группы машин со следующими характеристиками:

У меня столько работы.

Но последнее, что я хочу сделать, это отключить вход в учетную запись, локально заблокировав пароль (например, используя usermod -L). Проблема в том, что когда локальный пароль заблокирован, PAM возвращается к Kerberos ... и разрешает доступ.

Есть ли способ настроить PAM так, чтобы, если локальный пароль существует, но он заблокирован, он не пытался использовать Kerberos?

Лучшее, что я могу придумать до сих пор, - это заблокировать учетную запись, взломав локальный пароль чем-то непонятным. Но это немного грубо и не очень хорошо, если кто-то не «соблюдает процедуру» ...

Я согласен с комментариями Майкла Хэмптона - вы можете и должны использовать Kerberos для этого. Но если вы все же хотите сделать это, изменив что-то на локальном компьютере, вот решение, которое должно сработать.

В твоем sshd_config, добавьте строку

DenyGroups blocked

Создайте группу с названием «заблокировано». При блокировке локального пароля пользователя также добавляйте его в группу «заблокировано».

ПРЕДУПРЕЖДЕНИЕ! Это ужасно уродливый кладж, которого не должно быть в нормальном мире. Однако он может быть полезен в том доме, в котором мы живем.

Эта проблема в основном является следствием того, что pam_unix.so проверяет блокировку учетных записей в auth стек вместо account, что немного противоречит интуиции для новичков в PAM. Бухгалтерские решения должен быть сделано в accountне auth, но теневые блокировки учетных записей выполняются на основе поля пароля. Это делает его необходимым компромиссом.

Прежде чем продолжить и решить, как внедрить исправление, давайте рассмотрим группы управления, определенные PAM:

  • auth - Проблемы с аутентификацией. Ограничьте свои настройки решениями, основанными на учетных данных, которые пользователь отправляет для аутентификации, особенно потому, что программы могут полностью обойти этот модуль, если они реализуют свою собственную схему аутентификации. (пример, который все забывают: sshd пропускает auth если аутентификация по ключу SSH включена и успешно)
  • account - Тот, который не замечает большинство новичков в PAM. Если аутентификация удалось но пользователю все равно должно быть отказано в доступе, это решение должно быть принято здесь. (sshd воля не пропустите этот модуль, если аутентификация ключа SSH прошла успешно, в отличие от auth)
  • passwd - Изменение паролей, связанных с услугами, которые вы определили в auth.
  • session - Разные задачи, которые обычно мало связаны с успешностью аутентификации. Лесозаготовки, монтажные работы и др.

На основе описания вашей проблемы:

  1. Нам нужен auth стек, который отдает приоритет локальным учетным данным над учетными данными krb5, но один из двух должен быть успешным. Похоже, вы это прикрыли.
  2. Нам нужен account стек, который запрещает доступ, если локальный пользователь не определен. Как было сказано ранее, pam_unix.so подводит нас в этом отношении.
  3. passwd значения по умолчанию, вероятно, подходят для изменения локальных паролей.
  4. У нас нет непосредственной причины трогать session.

Основываясь на предложенном вами самоответе, похоже, вы знаете, где его взять.

Мне нужно проверить это на работе, но я считать Я мог бы добавить запись «pam_exec» в стек после записи «pam_krb5». Это может запустить сценарий, который использует «passwd -S» для проверки того, что ввод пароля для пользователя не заблокирован.

Или я мог бы сделать это, поместив пользователя в «заблокированную» группу и используя pam_succeed_if следующим образом:

auth required pam_succeed_if.so quiet_success user notingroup blocked

Для общего использования я не рекомендую смешивать локальные учетные записи и учетные записи Kerberos. Однако этот стек auth pam должен работать для наших целей. (У вас может быть другой кусок, например pam_env.so что вы включите.)

auth     requisite     pam_unix.so nullok
auth     sufficient    pam_krb5 ignore_root use_first_pass
auth     required      pam_deny.so

Если локальный пароль пользователя неверен или заблокирован, аутентификация не удастся. Если у пользователя нет локального пароля, для аутентификации используется Kerberos (не GSSAPI), если это не удается, аутентификация не удастся.