GSS -API -Fehler akzeptieren Kontext: Serviceschlüssel nicht verfügbar - Solaris Code, Windows KDC

Question

Ich versuche, ein Test -Kerberos -Client/Serverpaar gegen Active Directory zu erhalten. Ich habe drei Benutzer in einer Ersatzdomäne in unserem Unternehmensnetzwerk "Richardc", "Server1" und "Server2" erstellt. Meine Serverbenutzer wurden auf verschiedene Service -Hauptnamen mit kRB5_NT_PRINCIPAL zugeordnet, die andere mit krb5_nt_srv_host.

ktpass -out server2.keytab 
          -princ server2/serbia.mydomain.com@BENCHMARKING.RDDEV.LOCAL
          -mapuser ServerUser2@BENCHMARKING.RDDEV.LOCAL
          -pass ThePassword
          -crypto All
          -pType KRB5_NT_SRV_HOST
          -kvno 2

Ich habe diesmal die +Deonly -Option nicht verwendet, in der Hoffnung, dass ich in den heutigen Systemen DES nicht brauche. Ich habe den wahren Domain -Namen durch MyDomain in dieser Frage ersetzt, um die Bedenken des Managements zu vermeiden.

Das gibt mir einen Keytab. Ich kann es kleben:

KVNO Principal
---- --------------------------------------------------------------------------
   2 server2/serbia.mydomain.com@BENCHMARKING.RDDEV.LOCAL (DES cbc mode with CRC-32)
   2 server2/serbia.mydomain.com@BENCHMARKING.RDDEV.LOCAL (DES cbc mode with RSA-MD5)
   2 server2/serbia.mydomain.com@BENCHMARKING.RDDEV.LOCAL (ArcFour with HMAC/md5)
   2 server2/serbia.mydomain.com@BENCHMARKING.RDDEV.LOCAL (AES-256 CTS mode with 96-bit SHA-1 HMAC)
   2 server2/serbia.mydomain.com@BENCHMARKING.RDDEV.LOCAL (AES-128 CTS mode with 96-bit SHA-1 HMAC)

Ich kann sogar Kinit -K verwenden, um mich mit dem Schlüssel aus dem KeyTab anzumelden - also scheint es zu funktionieren.

Ich habe sowohl mein eigenes Testprogramm als auch das Testprogramm aus dem Testprogramm aus http://download.oracle.com/docs/cd/e19683-01/816-1331/sampleprogs-1/index.html. In diesem Programm habe ich auf dem Server gss_c_nt_hostbased_Service in gss_c_nt_user_name mit beiden Keytabs geändert, damit er den Namen erkennt. Ich führe den Oracle Demo Server als Ausführungskraft als

./gss-server -mech 1.2.840.113554.1.2.2 server2/serbia.mydomain.com    

und der Kunde

./gss-client -mech 1.2.840.113554.1.2.2 serbia.mydomain.com server2 "Hello"

Das Ergebnis:

GSS-API error accepting context: Invalid credential was supplied
GSS-API error accepting context: Service key not available

In diesem Fall und mit meinem eigenen Testcode tritt der Fehler auf, nachdem der Client sein erstes Token gesendet hat, während der Server versucht, ihn zu dekodieren.

KList zeigt den für den Kunden gewährten Schlüssel. Es verwendet Arcfour, das sich im KeyTab befindet

Default principal: RichardC@BENCHMARKING.RDDEV.LOCAL

Valid starting                Expires                Service principal
07/25/11 17:36:49  07/26/11 03:35:18  krbtgt/BENCHMARKING.RDDEV.LOCAL@BENCHMARKING.RDDEV.LOCAL
    renew until 08/01/11 17:36:49
07/25/11 17:36:03  07/26/11 03:35:18  server2/serbia.mydomain.com@BENCHMARKING.RDDEV.LOCAL
    renew until 08/01/11 17:36:03

Die UNIX -Maschine (Serbien) könnte möglicherweise zu einem anderen Bereich gehören (das, den ich hier Mydomain.com genannt habe), obwohl sie nicht Kerberos -Setup zu haben scheint. Ich verwende eine lokale KRB5.Conf -Datei, auf die ich auf den Reich von Benchmarking.rddev.local hingewiesen habe. Wenn die Maschine versucht, den DNS mit seinem Hostnamen zu verwenden, kann dies die falsche Antwort erhalten. Mein KRB5.Conf hat

[libdefaults]
    default_keytab_name = /users/dev/core/richardc/server1.keytab
    default_realm = BENCHMARKING.RDDEV.LOCAL
    dns_lookup_kdc = false
    default_tkt_types = DES-CBC-MD5

[realms]
BENCHMARKING.RDDEV.LOCAL = {
    kdc = gbha-dcbench01p.benchmarking.rddev.local
    admin_server = gbha-dcbench01p.benchmarking.rddev.local
}

[domain_realm]
benchmarking.rddev.local = BENCHMARKING.RDDEV.LOCAL
.benchmarking.rddev.local = BENCHMARKING.RDDEV.LOCAL
mydomain.com = BENCHMARKING.RDDEV.LOCAL
.mydomain.com = BENCHMARKING.RDDEV.LOCAL

Es sieht so aus, als ob Optionen wie default_tkt_types unwirksam waren.

Frage ist - wie behebe ich meinen Fehler?

Danke - Richard

Answer 1

Das Problem war in der

ktpass -out server2.keytab 
      -princ server2/serbia.mydomain.com@BENCHMARKING.RDDEV.LOCAL
      -mapuser ServerUser2@BENCHMARKING.RDDEV.LOCAL
      -pass ThePassword
      -crypto All
      -pType KRB5_NT_SRV_HOST
      -kvno 2

Dies führt dazu, dass Windows die Schlüsselversionsnummer erhöht. Der resultierende Schlüssel ist kein Problem für die Anmeldung von "Kinit -K" aus irgendeinem Grund, aber es führt zu, dass der GSS -API -Servercode mit dem nicht hilfreiche "Dienstschlüssel, der nicht verfügbar ist" auf Solaris -Systemen fehlschlägt.

Das Windows -System war 2008R2. Ich verstehe, dass das Verhalten dieses Befehls zwischen verschiedenen Versionen von Windows variiert hat.

Ich habe erfolgreich mit Deonly getestet. Ich müsste für alle anderen Tests in die arme, belagerte IT-Abteilung zurückkehren :-)

Die Lösung besteht darin, das Argument -kvno zu verpassen.

 ktpass -out server4.keytab 
      -princ server4/serbia.mydomain.com@BENCHMARKING.RDDEV.LOCAL
      -mapuser ServerUser4@BENCHMARKING.RDDEV.LOCAL
      -pass ThePassword
      -crypto DES-CBC-MD5
      -pType KRB5_NT_USER_PRINCIPAL

Dies gibt den Ausgang

Targeting domain controller: GBHA-DCBENCH01P.benchmarking.rddev.local
Using legacy password setting method
Successfully mapped server4/serbia.mydomain.com to Server4.
Key created.
Output keytab to server4.keytab:
Keytab version: 0x502
keysize 79 server4/serbia.mydomain.com@BENCHMARKING.RDDEV.LOCAL ptype 1
     (KRB5_NT_PRINCIPAL) vno 5 etype 0x3 (DES-CBC-MD5) keylength 8 (0xd1532a6d0f2a8631)
Account Server4 has been set for DES-only encryption.

Beachten Sie die "VNO 5" im Ausgang.

Ich habe mit beiden Werten für -ptype getestet. Beide arbeiten.

Mein GSS -Code verwendet GSS_C_NT_HOSTBASED_SERVICE, aber all dies scheint das Format zu ändern, das zum Eingeben des Namens erforderlich ist.

(Ich habe den Schlüssel oben geändert)

Nachtrag

Meine endgültige Lösung verwendet -PTYPE KRB5_NT_USER_PRINCIPAL

Mein GSS -Code verwendet GSS_C_NT_USER_NAME, um den Namen nach oben zu suchen, und ich geben den vollständigen Namen an server4/serbia.mydomain.com@benchmarking.rddev.local. Ich fand, dass nicht alle Plattformen, an denen ich gearbeitet habe, die GSS_C_NT_HOSTBASED_SERVICE akzeptierte, aber alle akzeptieren GSS_C_NT_USER_NAME.

Die Person, die unsere Serveranwendung installiert, legt den Server -Hauptnamen als Konfigurationsoption fest. Dies schien der zuverlässigste Weg zu sein. Die Person, die den Schlüssel eingerichtet hat, weiß also, was er ist, sagt der Anwendung direkt, welchen Schlüssel zu verwenden ist.