2017-06-14 2 views
0

Nach der Aktualisierung eines kerberized Hortonworks-Clusters von 2.5.3 auf 2.6.1, alle Dienste (hdfs, Bienenstock, Funken, Tierpfleger usw.) erhalten keine Anmeldeinformationen über Kerberos mit den folgenden Fehlern :Hortonworks Kerberos: KRBError: Fehlercode ist 14

>>>KRBError: 
     sTime is Wed Jun 14 11:52:10 CEST 2017 1497433930000 
     suSec is 825974 
     error code is 14 
     error Message is **KDC has no support for encryption type** 
     sname is krbtgt/[email protected] 
     msgType is 30 
>>> Credentials acquireServiceCreds: no tgt; searching thru capath 
>>> Credentials acquireServiceCreds: no tgt; cannot get creds 
KrbException: Fail to create credential. (63) - No service creds 

die /etc/krb5.conf-Datei nicht verändert hat (und es vor dem Upgrade gearbeitet hat):

[libdefaults] 
renew_lifetime = 7d 
    forwardable = true 
    default_realm = BIGDATACLUSTER.EXAMPLE.COM 
    ticket_lifetime = 10h 


[domain_realm] 
    .EXAMPLE.com = JUST.EXAMPLE.COM 
    .BIGDATACLUSTER.EXAMPLE.com = BIGDATACLUSTER.EXAMPLE.COM 
    BIGDATACLUSTER.EXAMPLE.com = BIGDATACLUSTER.EXAMPLE.COM 

[realms] 
    BIGDATACLUSTER.EXAMPLE.COM = { 
    admin_server=MACHINE1.EXAMPLE.com 
    rdns = false 
    kdc = MACHINE1.EXAMPLE.com 
    default_tkt_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 
    default_tgs_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 
    permitted_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 
    } 

[capaths] 
     JUST.EXAMPLE.COM = { 
       BIGDATACLUSTER.EXAMPLE.COM = . 
     } 

der Trust wie folgt aussieht:

addprinc -e "aes256-cts:normal aes128-cts:normal arcfour-hmac:normal" krbtgt/[email protected] 

Dies ist, was wir versucht haben:

  • Verified Java und JCE, alle ok
  • alle keytabs regenerierte und neu gestartet Cluster - Auf der "Die andere Domäne unterstützt Kerberos AES-Verschlüsselung aktivieren" für die Vertrauen, es ist überprüft.

Bitte beachten Sie die Antwort. Es scheint, dass dieser letzte Punkt das Problem war.

+0

Aus Neugier: das (Fragment von) Kerberos Spuren zeigen eine Fehlermeldung von einem KDC ausgegeben für Reich "Just", die nicht in '[realms] definiert ist,' (es ist über einen DNS-Alias ​​gefunden und hat keine spezifischen params). Haben Sie eine Kontrolle über dieses KDC, d. H. Können Sie auf die serverseitigen Protokolle zugreifen? –

+0

Guter Fang, der Fehler war wegen eines bereichsübergreifenden Problems auf dem anderen Realm. Bitte sehen Sie meine Antwort. – Cos

Antwort

0

Wir haben es endlich behoben.

Obwohl ich in meiner Frage geschrieben habe, dass wir das Kontrollkästchen "Die andere Domäne unterstützt Kerberos AES-Verschlüsselung" für das Trust aktiviert hat, scheint es, dass dieses Kontrollkästchen seitdem geändert wurde (niemand kann erklären, wie oder warum). Das hat dazu geführt, dass die AES-Verschlüsselung unseres Vertrauens vom anderen Trust abgelehnt wurde.

Setzen Sie einfach das Kontrollkästchen, um die Fehler zu beheben.

enter image description here