ActiveDirectory Kerberos Keytab unter Linux unbrauchbar

7

Ich konfiguriere die Kerberos-Authentifizierung für das vollständig in Java implementierte Alfresco CIFS-Protokoll (JLAN-Projekt). Das ist nicht das erste Mal, dass ich es in einem einzigen Schuss richtig eingerichtet habe.

Im selben Netzwerk habe ich mit einem ActiveDirectory Windows 2008R2 und demselben Verfahren das Setup für zwei Umgebungen bereits erfolgreich durchgeführt, aber die Produktionsumgebung bereitet mir Probleme.

Das Produktions-Keytab wurde von ktpasson ActiveDirectory mit RC4-HMAC wie für andere Umgebungen generiert . Das Konto AlfrescoCifsPist für die Produktion und nur für diesen Service bestimmt:

ktpass -princ cifs/[email protected]
       -mapuser MYDOMAIN\AlfrescoCifsP -pass <password>
       -crypto RC4-HMAC-NT -ptype KRB5_NT_PRINCIPAL -out c:\temp\prod.keytab

Jetzt versuche ich, es auf RedHat 5.8 mit MIT Kerberos-Bibliotheken und -Dienstprogrammen in Version 1.6.1-70-el4 zu verwenden, und es wurde der folgende Fehler angezeigt :

$ kinit -k -t prod.keytab cifs/myserver.mydomain.com
kinit(v5): Key table entry not found while getting initial credentials

Folgendes habe ich (oft) überprüft:

  • Mein krb5.confist OK, wenn der Standardbereich festgelegt ist
  • Ich kann offen prod.keytabmit ktutilund schreiben Sie den Steckplatz fürcifs/myserver.mydomain.com
  • Ich kann mich mit Passwort und Befehl authentifizieren kinit cifs/myserver.mydomain.com
  • kvno cifs/myserver.mydomain.com Gibt dieselbe Schlüsselnummer zurück wie aus dem Keytab-Eintrag
  • Ich habe auch das ActiveDirectory-Konto gelöscht und mache das Zeug noch einmal. Immer noch das gleiche Ergebnis.

Es wurde also alles getan, um erfolgreich zu sein. Es war erfolgreich für zwei Dienstkonten und schlug für das dritte fehl. Der einzige Unterschied kann die SPN-Länge sein, die etwas länger als bei anderen ist, aber weit unter der SPN-Grenze von 260 Zeichen.

Ich habe den Befehl verschobenkinit -k -t prod.keytab cifs/... und habe gerade den Lesevorgang für die Keytab-Datei und direkt hinter der Ausgabe der Fehlermeldung an stderr gesehen.

Gibt es ein bekanntes Problem, das zu meinen Problemen in einer ähnlichen Umgebung passt?

Wie kann die Ursache dieses Problems diagnostiziert werden?

Was können die Hauptgründe für einen solchen Fehler sein?

Was soll ich versuchen, um einen Ausweg zu finden?

Yves Martin
quelle

Antworten:

4

Dank einer Netzwerkerfassung fand der Administrator meines Kunden ein von Novell dokumentiertes Übereinstimmungsproblem: http://www.novell.com/support/viewContent.do?externalId=7005039&sliceId=1

Ich habe die folgenden Zeilen hinzugefügt, krb5.confum das Problem mit Kerberos 1.6.1-Bibliotheken zu umgehen:

 default_tkt_enctypes = rc4-hmac
 default_tgs_enctypes = rc4-hmac

Meiner Meinung nach sind diese Zeilen für neuere MIT Kerberos-Bibliotheken nicht erforderlich.

Yves Martin
quelle
Gleiches Problem unter Debian 6 mit libkrb5-3in Version 1.8.3+dfsg-4squeeze6. Gleiche Arbeit-around, ich habe hinzugefügt enctypesin krb5.conf.
Yves Martin
-1

Zunächst sollten Sie überprüfen, ob auf Ihrem Computer, auf dem mit SPN referenzierte Dienste ausgeführt werden, eine Vertrauensbeziehung zum Domänencontroller besteht (Domänennetzwerk in "Open Network and Sharing Center"). Sobald OK, generieren Sie das Ticket erneut und führen Sie kinit wie folgt aus:

kinit -k -t prod.keytab cifs/[email protected]

Fazit: Ihnen fehlt das REALM (@ MYDOMAIN.COM)

HINWEIS: GÜLTIG FÜR WINDOWS 2008 EE X64 R2

Mauricio
quelle
Der Realm fehlt für den Befehl kinit nicht, da er korrekt als Standard-Realm meines Linux-Systems /etc/krb5.conf deklariert ist.
Yves Martin
Dann muss ein Linux-System nicht "zu einer Vertrauensbeziehung verbunden" werden (in Microsoft-Begriffen - und für Linux bedeutet dies häufig die Ausführung von Samba), um die Kerberos-Authentifizierung für verschiedene Dienste wie HTTP oder CIFS bereitzustellen. In meinem Fall werden diese beiden Protokolle von einer Java-Anwendung bereitgestellt, in der die Kerberos-Authentifizierung implementiert wurde.
Yves Martin