Ist ein Dienstprinzipalname (SPN) an eine bestimmte Maschine gebunden?

Question

Im Moment bin ich immer ein KrbException: Integritätsprüfung auf entschlüsselten Feld fehlgeschlagen (31) mit meiner GSS Demo-Anwendung (auf der Serverseite). Jetzt bin ich auf der Suche nach dem Grund dafür. Ich habe den Verdacht, dass es aus der Tatsache, dass

1. der Client und der Server-Anwendung laufen auf der gleichen Maschine (localhost) und / oder
2. die SPN wurde für eine andere Maschine (Computer)
erzeugt

Die zweite bedeutet, dass das Service-Haupt für eine Maschine xxx0815.domain.net generiert wurde, so dass die SPN ist HTTP/xxx0815.domain.net@DOMAIN.NET. Und meine Maschine ist das nicht, aber ich habe die Keytab-Datei bekommt, so dass der Login-Methode des Servers erfolgreich ist.

Habe ich vermute, richtig oder bin ich wieder einen Fehler zu machen?

Server-Konfiguration und Quellcode:
server.conf

Server { 
    com.sun.security.auth.module.Krb5LoginModule 
        required 
        isInitiator=false 
        doNotPrompt=true 
        useKeyTab=true 
        keyTab="gssdemo.keytab" 
        storeKey=true 
        principal="HTTP/xxx0815.domain.net@DOMAIN.NET" 
        debug=true; 
};

GSSServer.java (entfällt die vorformulierten Sachen)

    GSSManager manager = GSSManager.getInstance();
    GSSName serverName = manager.createName(getServerName(), null);
    GSSCredential serverCred = manager.createCredential(serverName,
                                                        GSSCredential.INDEFINITE_LIFETIME,
                                                        createKerberosOid(),
                                                        GSSCredential.ACCEPT_ONLY);
    GSSContext context = manager.createContext(serverCred);
    System.out.println("Context created successfully. Now incoming tokens could be accepted.");

    ServerSocket serverSocket = new ServerSocket(55555);
    SocketAdapter ca = new SocketAdapter(serverSocket.accept());

    while (!context.isEstablished()) {
        byte[] inToken = ca.readToken();
        byte[] outToken = context.acceptSecContext(inToken, 0, inToken.length);

        if (outToken != null) {
            ca.sendToken(outToken);
        }
    }

    System.out.println("Context established");
    System.out.println("Connected user is: " + context.getSrcName());
    context.dispose();

Client-Konfiguration und Quellcode:
client.conf

Client {
    com.sun.security.auth.module.Krb5LoginModule
        required
        useTicketCache=true
        debug=true;
};

GssClient.java (vorformulierten weggelassen)

    GSSManager manager = GSSManager.getInstance();
    GSSName clientName = manager.createName(getClientName(), null);
    GSSCredential clientCred = manager.createCredential(clientName,
                                                        8 * 3600,
                                                        createKerberosOid(),
                                                        GSSCredential.INITIATE_ONLY);
    GSSName serviceName = manager.createName("HTTP/xxx0815.domain.net@DOMAIN.NET", null);

    GSSContext context = manager.createContext(serviceName,
                                               createKerberosOid(),
                                               clientCred,
                                               GSSContext.DEFAULT_LIFETIME);
    context.requestMutualAuth(true);
    context.requestConf(false);
    context.requestInteg(true);

    System.out.println("Establishing context");
    SocketAdapter ca = new SocketAdapter(new Socket("localhost", 55555));

    byte[] inToken = new byte[0];
    while (true) {
        byte[] outToken = context.initSecContext(inToken, 0, inToken.length);

        if (outToken != null) {
            ca.sendToken(outToken);
        }

        if (context.isEstablished()) {
            break;
        }

        inToken = ca.readToken();
    }

    System.out.println("Context established: " + context.isEstablished());

    context.dispose();

ich die abgehende und ankommende Netzdaten überprüft haben -. Ist es das gleiche auf beiden Seiten, so kann ich ein Problem ausschließen (ich habe die Ausgabe BASE64-codiert und dann einfach durch die Ströme senden Ich denke, es ist nicht viel das kann da schief gehen ...).

Die Ausnahme erhalte ich:

Caused by: GSSException: Failure unspecified at GSS-API level (Mechanism level: Integrity check on decrypted field failed (31))
    at sun.security.jgss.krb5.Krb5Context.acceptSecContext(Krb5Context.java:741)
    at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:323)
    at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:267)
    at de.westlb.mrm.sandbox.gss.GssServer.acceptAndEstablish(GssServer.java:88)
    at de.westlb.mrm.sandbox.gss.GssServer.run(GssServer.java:66)
    ... 4 more
Caused by: KrbException: Integrity check on decrypted field failed (31)
    at sun.security.krb5.internal.crypto.DesCbcEType.decrypt(DesCbcEType.java:154)
    at sun.security.krb5.internal.crypto.DesCbcMd5EType.decrypt(DesCbcMd5EType.java:33)
    at sun.security.krb5.internal.crypto.DesCbcEType.decrypt(DesCbcEType.java:125)
    at sun.security.krb5.internal.crypto.DesCbcMd5EType.decrypt(DesCbcMd5EType.java:33)
    at sun.security.krb5.EncryptedData.decrypt(EncryptedData.java:168)
    at sun.security.krb5.KrbApReq.authenticate(KrbApReq.java:267)
    at sun.security.krb5.KrbApReq.<init>(KrbApReq.java:134)
    at sun.security.jgss.krb5.InitSecContextToken.<init>(InitSecContextToken.java:79)
    at sun.security.jgss.krb5.Krb5Context.acceptSecContext(Krb5Context.java:724)
    ... 8 more

Answer 1

Wenn die Integritätsprüfung fehlschlägt, dass deutet darauf hin, dass die Daten nicht gesendet / empfangen richtig (das, oder ist dies eine falsche Fehlermeldung). Mit anderen Worten hat einige Änderung aufgetreten ist.

Ich weiß, dass Sie sagen, Sie überprüft haben, dass die gesendeten Daten die empfangenen Daten auf Netzwerkebene übereinstimmt, jedoch sind sicher, dass Sie es nicht vor beschädigt zu schicken, oder nach dem Empfang? Ich würde vorschlagen, dass Sie Ihren Code für dieses ersten überprüfen.

edit: In Antwort auf Ihre Frage, ein Dienstprinzipal (wirklich, jedes Ticket) an eine bestimmten Maschine gebunden werden, aber dies ist in der Regel in Bezug auf der IP-Adresse erfolgen. Auf jeden Fall so etwas sollte in einer anderen höheren Ebene Fehler.

Der Fehler Sie Töne sind immer wie es Schwierigkeiten haben, das Ticket an erster Stelle zu entschlüsseln. Eine mögliche Ursache dafür ist, dass es die falsche Taste verwendet, die auf Ihre Kopieren der keytab in Beziehung gesetzt werden kann. Ein falscher Schlüssel kann auch mit dem falschen Ticket verursacht werden (wie kerberos bietet grundsätzlich ein Schlüssel-Management-Protokoll). Ist es möglich, Sie haben ein altes / falsches Ticket zwischengespeichert?