Die TGT-Validierung schlägt fehl, aber nur für einen Benutzer

Question

Ich sehe hier etwas höchst Seltsames. Ich habe ein paar RHEL3-, 4- und 5-Maschinen, die Benutzeranmeldeinformationen über Kerberos mit einem Active Directory-Domänencontroller als KDC validieren.

Das funktioniert bei allen meinen Benutzern, bis auf einen. Es gibteinsKonto, das sich nicht bei RHEL3-Linux-Maschinen anmelden kann und dort die folgenden Fehler generiert:

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'

Andere Konten, wie mein eigenes, sind in Ordnung:

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)

Wie Sie sehen, schlägt die TGT-Validierung fehl. Dies geschieht nur für dieses bestimmte Konto, nicht für andere.

Das Kennwort des fehlerhaften Benutzerkontos wurde zurückgesetzt. Ich habe beide Benutzerobjekte im Active Directory überprüft, kann jedoch nichts Ungewöhnliches erkennen.

Wenn ich das fehlerhafte Benutzerkonto bei einer RHEL4- oder 5-Box anmelde, gibt es kein Problem, es muss also RHEL3-spezifisch sein, aber die Tatsache, dass nur ein Konto darunter leidet, ist mir ein Rätsel. Vielleicht hat das schon mal jemand gesehen?

Answer 1

Können Sie kinitals aktiver und nicht aktiver Benutzer von der Unix-Box aus arbeiten? Wenn ja, was sagt klistjeder?

Versuchen Sie anschließend, eines der Tickets zu verwenden und sehen Sie, was die Klist dann für jedes Ticket anzeigt.

Wenn kinites funktioniert und die Tickets, die Sie erhalten, funktionieren (versuchen Sie beispielsweise, sich noch einmal per SSH bei der Box anzumelden), dann stimmt tatsächlich etwas nicht und ich weiß nicht genau, was ich als Nächstes tun soll, ohne die Box berühren zu können.

Answer 2

Ich beantworte meine Frage schamlos selbst, denn wir haben die Antwort gefunden. Das Benutzerobjekt, dessen Authentifizierung fehlschlug, enthielt eine Art Zertifikat, was dieses Objekt im Vergleich zu anderen Benutzerobjekten ziemlich groß machte.

Kerberos, eine Komponente von Active Directory, hat eine Eigenschaft namens „MaxTokenSize“. Standardmäßig ist sie auf 12.000 Bytes eingestellt. In älteren Versionen von Active Directory sind es 8.000 Bytes. Die meisten Probleme damit treten auf, wenn Benutzer zu vielen Gruppen zugeordnet werden (zwischen 70 und 100 Gruppen). Wenn Benutzerobjekte dieser Größe vorhanden sind, ist die MaxTokenSize zu klein für den Puffer, der für die Authentifizierung benötigt wird.dieser TechNet-Artikel.

Ich konnte keine Quellen finden, die dieses Problem in Bezug auf Clients mit Linux behandeln, aber ich fandDiese Seitezu OpenAFS (das Kerberos verwendet); dort wird über zu große Tickets bei Verwendung von AD-Kerberos gesprochen.

Um es kurz zu machen: Der Benutzer, mit dem ich Probleme hatte, gehörte nicht zu besonders vielen Gruppen, aber wie gesagt hatte er ein riesengroßes Zertifikat in seinem LDAP-Objekt, was es ganz schön groß machte.

Durch das Entfernen des Zertifikats wurde das Benutzerobjekt ausreichend verkleinert, um die Kerberos-Authentifizierung auf RHEL3 wieder zu aktivieren.