☰

Проверка TGT не удалась, но только для одного пользователя

tag-icon • tag-icon linux active-directory kerberos redhat
Проверка TGT не удалась, но только для одного пользователя

Я вижу здесь нечто странное. У меня есть пара машин RHEL3, 4 и 5, которые проверяют учетные данные пользователей через Kerberos с контроллером домена Active Directoy в качестве KDC.

Это работает для всех моих пользователей, кроме одного. Естьодинучетная запись, которая не может войти в машины RHEL3 Linux и генерирует там следующие ошибки:

May 31 13:53:19 mybox sshd(pam_unix)[7186]: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.0.0.1  user=user
May 31 13:53:20 mybox sshd[7186]: pam_krb5: TGT verification failed for `user'
May 31 13:53:20 mybox sshd[7186]: pam_krb5: authentication fails for `user'

Другие аккаунты, как и мой собственный, в порядке:

May 31 17:25:30 mybox sshd(pam_unix)[12913]: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.0.0.1  user=myuser
May 31 17:25:31 mybox sshd[12913]: pam_krb5: TGT for myuser successfully verified
May 31 17:25:31 mybox sshd[12913]: pam_krb5: authentication succeeds for `myuser'
May 31 17:25:31 mybox sshd(pam_unix)[12915]: session opened for user myuser by (uid=0)

Как видите, проверка TGT не проходит. Это происходит только для этого конкретного аккаунта, а не для любого другого.

Пароль неисправной учетной записи пользователя был сброшен, я проверил оба объекта пользователя в Active Directory, но ничего необычного не увидел.

Если у меня есть неисправный useraccount, вошедший в систему RHEL4 или 5, то это не проблема, так что это должно быть специфично для RHEL3, но тот факт, что только один аккаунт страдает от этого, намекает мне. Может быть, кто-то уже видел это?

решение1

Можете ли вы kinitкак работающий и неработающий пользователь, из Unix box? Если да, то что говорит klistдля каждого?

После этого попробуйте воспользоваться одним из билетов и посмотрите, что покажет klist для каждого из них.

Если kinitэто работает и полученные вами тикеты работают (например, попробуйте снова подключиться к ящику по ssh), то что-то действительно странное, и я не уверен, что делать дальше, не имея возможности прикоснуться к ящику.

решение2

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

Kerberos, который является компонентом Active Directory, имеет свойство под названием «MaxTokenSize». По умолчанию оно установлено на 12 000 байт. В более старых версиях Active Directory оно составляет 8 000 байт. Чаще всего вы видите, как люди сталкиваются с этой проблемой, когда они помещают пользователей в слишком много групп (где-то в диапазоне от 70 до 100 групп). Наличие таких больших объектов пользователей приводит к тому, что MaxTokenSize становится слишком маленьким для буфера, необходимого для аутентификации, согласноэта статья TechNet.

Мне не удалось найти никаких источников, которые бы говорили об этой проблеме применительно к клиентам, работающим под управлением Linux, но я нашелэтот сайтоб OpenAFS (использующем Kerberos), где говорится о слишком больших билетах при использовании Kerberos AD.

Короче говоря, пользователь, с которым у меня возникли проблемы, не входил ни в одну группу, но, как я уже сказал, у него был огромный сертификат в объекте LDAP, что делало его довольно большим.

Удаление сертификата уменьшило объект пользователя достаточно, чтобы повторно включить аутентификацию Kerberos в RHEL3.

Связанный контент