SPNEGO / ActiveDirectory / AES256: Checksum failed
Asked Answered
C

1

6

I am trying to use SPNEGO / Kerberos5 authentication with Active Directory 2008 and Java. I followed this guide: http://spnego.sourceforge.net/ - "preflight" went well, but later I get the famous exception:

Exception in thread "main" GSSException: Failure unspecified at GSS-API level (Mechanism level: Checksum failed)
    at sun.security.jgss.krb5.Krb5Context.acceptSecContext(Krb5Context.java:856)
    at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:342)
    at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:285)
    at sun.security.jgss.spnego.SpNegoContext.GSS_acceptSecContext(SpNegoContext.java:906)
    at sun.security.jgss.spnego.SpNegoContext.acceptSecContext(SpNegoContext.java:556)
    at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:342)
    at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:285)
    at de.meona.auth.spnego.TestSpnegoAes.main(TestSpnegoAes.java:45)
Caused by: KrbException: Checksum failed
    at sun.security.krb5.internal.crypto.Aes256CtsHmacSha1EType.decrypt(Aes256CtsHmacSha1EType.java:102)

I had a close look at this post, as the problem seems similar: checksum failed: Kerberos / Spring / Active Directory (2008)

In order to make the problems reproducible, I wrote a small Java class. I was able to single-step to the line where the exception happens. I think it is because the secret service key used for decryption is different from the secret service key the Active Directory used to encrypt the service ticket. How can this be?

public class TestSpnegoAes {

    private static Oid spnegoOid = null;
    private static String negotiate = "YIIGowYGKwYBBQUCoIIGlzCCBpOgMDAuBgkqhkiC9xIBAgIGCSqGSIb3EgECAgYKKwYBBAGCNwICHgYKKwYBBAGCNwICCqKCBl0EggZZYIIGVQYJKoZIhvcSAQICAQBuggZEMIIGQKADAgEFoQMCAQ6iBwMFACAAAACjggTUYYIE0DCCBMygAwIBBaENGwtNRU9OQS5JTlRSQaIsMCqgAwIBAqEjMCEbBEhUVFAbGWV4ZS13dXR0a2UtMDMubWVvbmEuaW50cmGjggSGMIIEgqADAgESoQMCAQaiggR0BIIEcGT4WR3IzKSxdgGfSZwLUwXKs0AW+0MhOUR5NBQ7oFXdzBxPhEzZ+aNlYAGxiGgCiFFOIDFJuEJhsQ0+Iqd2EKf6VLYQXfRdGD0Zbi4Fzh1bpHzPzo+8UW1XffWg+nAUg7r/QKrkSLrLF0qIfRBseCP2khdKU0xwCRf197aPjJ8y35kGYF/IT3DRTJZbOCCCLPb7szhl3nnUuqfHLcoc//KzPuKKbMMdaw7w3ftZCk9Lx8GIxxxudSLsaa/v8jRtnFxvyLIz4j7CFJus98Qr9IB7oe/c2/L2CbrzdeBwX5MsYCHod0szWl/V7hs96RXtZauhw3dmB+W0PXEZiOBy50cfJLdIJjpPFTf/ET2+22lPbPsEWWxJwZegqMxFEuOTSIjcTigD3Ct5f5HqSuvNKY5J7e5Bk3sWNKdBxW73DRV7ncvX8CTdEVHubjKyc82cdVeOTHO6wGB0V+LQOrwhgmf16Ss5osynEv+rH38e2DH6rYCPKa3PrPnqHJfQ8kutjxjB8D6hQ1CHFXPrlY1j9j0ABJvZcL94N+BpRPLH+Ve78d4WBw3QBw3Aq0Xux/0NEjnznM6D2HEQpEoUZ+reVBp7wwZlXqOc9eVZH6IXys4nIrrQ13BLAi2KqLwZyglanL9vpVfA/zxT8lsZuzkhiowLniPs52kni04zVi5abu7QB0gTAUDAd44a9sXMGTj8UTZIef9TY3XBpKyyQGE5SJUdGSyh1SdhubErA0bHLWNsNhgKnFIA5gFimWA4LsLhEvnIK89vemlHj20VleU0Yre5tsdnMlOYsYOgsrBbL0wMqzIWXHAVjDLtC3+j2cW3PoSmC2FL7vDDPR7Y62x3o1pmyzioyId3LthqZA/G6f24w3xdiZKLCFEnAX3rY0jly7DwbWAByCJufJshGGZWOqOB39HPBxHhgrw/VtDWRGYBApfdSsmumZd3RsLM2xheodDHXjW4twFYM3M0CyvL97FuOuBGIdFceIGgI/kQENbaITLy7B9sxTVy+mT86Fac/a2wUWq+sdryLTdgtgMVZ/xlh79mReXXTdxnvchPtC68Q74KPNYAOitmDdM2tanIwLWcxdHAgMsEef605FDeuH+WjJyT8NomEtyaR9jTRK1/v2agbPZBAIlBkqMlC24/m5A6clxHDPtVKLKVl0/FfBIPdVx57FK6qrJu+QKcEU1sdkbAbanwq3EKCqHKwsyPFPjiP+ujqMF+h2fVD1hbLjaU3bGFodoT+mRQ7j/mwYE3YTBH/9rypzvO5MsVZDqkyqPbJcf/KX5I8Ta68wxaH32jxQBSAlQjVVqKYJNbB7ruJVLg5HZcMnFNz9d+jgYNVFDEl5Q2UgPYdfzspXpf22sX2NDHbhQOvAGXaIoTkhZIkBeCLEeiEE/VqPiqp9CdOtgwGDOzpt1U3Bd+i16MFC3Sd9zufWKQ+52E9r5sRjbypNG71xFykM3IzYMgGIk5/UDmJCHJ4JBGhK4VIoYOW73PU2ZMcu5GcbiSXDGXqTdHpIIBUTCCAU2gAwIBEqKCAUQEggFAJEhKQVHtVkOCR4BD4PkUujH+VvrWYRg2mGc3E4yxgs/asJqLKXHGjr2h08i89SAN63nG8VXuQt9Iwo50eqUOHVKtoRIyASzGQbTU/lIMVjyEg7++hf4Wq/7IJ1fQ4bKk8LSD7/ZawTmPTt0msKCfEDToc85h8fW0YH6SleqBVpbJDS+t2hVVHXhNLfqoC9CVsYsTWUqMLd0sno4b2bzyVxz15PBB007B/hv6JPiy6fH871HHZRImXJ+3pgQtNlVddpDI6dcPDi7+7CFSNnWwMYrixBMcsNj+GahROpiiEm8Mpu7zDNXVJNKmBufBBzE66YjuXYwFKIaVeTxo9/juv5Dy2gRxykoVR/Hq2J2aRuUWk69LbDu30mwQs1gw8n5V4vOujcXHqTJ59B9JixtOGLvNTCg25sVrk/+EmO/nhmc=";
    private static GSSManager manager;

    // -Dsun.security.krb5.debug=true
    // -Djava.security.auth.login.config=login.conf

    public static void main(String[] args) throws GSSException, LoginException, PrivilegedActionException {
        spnegoOid = new Oid("1.3.6.1.5.5.2");

        manager = GSSManager.getInstance();

        LoginContext loginContext = new LoginContext("spnego-server");
        loginContext.login();

        Subject subject = loginContext.getSubject();
        GSSCredential serviceCredentials = getServerCredential(subject);

        GSSContext context = manager.createContext(serviceCredentials);

        byte[] token = Base64.decode(negotiate);
        context.acceptSecContext(token, 0, token.length);
    }

    static GSSCredential getServerCredential(final Subject subject) throws PrivilegedActionException {

        final PrivilegedExceptionAction<GSSCredential> action = new PrivilegedExceptionAction<GSSCredential>() {
            public GSSCredential run() throws GSSException {
                return manager.createCredential(null, GSSCredential.INDEFINITE_LIFETIME, spnegoOid,
                        GSSCredential.ACCEPT_ONLY);
            }
        };
        return Subject.doAs(subject, action);
    }

}

This is my login.conf file:

spnego-server {
    com.sun.security.auth.module.Krb5LoginModule required
    useKeyTab=true
    storeKey=true
    isInitiator=false
    keyTab="file:///C:/Temp/krbtest/meona-service.keytab" 
    principal=meona-service;
};

I you would like to reproduce, I am happy to give the keytab file as well. It was produced on the PDC using "kpass /out keytab /princ [email protected] /pass ... /crypto AES256-SHA1 /ptype KRB5_NT_PRINCIPAL".

As the LoginContext login succeeds, I think the key is recovered successfully.

This is the stdout:

Java config name: null
Native config name: C:\Windows\krb5.ini
Found KeyTab C:\Temp\krbtest\meona-service.keytab for [email protected]
Found KeyTab C:\Temp\krbtest\meona-service.keytab for [email protected]
Entered Krb5Context.acceptSecContext with state=STATE_NEW
>>> KeyTabInputStream, readName(): MEONA.INTRA
>>> KeyTabInputStream, readName(): meona-service
>>> KeyTab: load() entry length: 75; type: 18
Looking for keys for: [email protected]
Added key: 18version: 1
>>> EType: sun.security.krb5.internal.crypto.Aes256CtsHmacSha1EType
Exception in thread "main" GSSException: Failure unspecified at GSS-API level (Mechanism level: Checksum failed)
    at sun.security.jgss.krb5.Krb5Context.acceptSecContext(Krb5Context.java:856)

If I do not use a keytab, but use pre-authentication, I am able to recover the key, but get the same error later on.

Any ideas?

Here is the krb5.conf I used to generate the SPNEGO negotiate header.

[libdefaults]
    default_tkt_enctypes = aes256-cts-hmac-sha1-96 aes128-cts rc4-hmac des3-cbc-sha1 des-cbc-md5 des-cbc-crc
    default_tgs_enctypes = aes256-cts-hmac-sha1-96 aes128-cts rc4-hmac des3-cbc-sha1 des-cbc-md5 des-cbc-crc
    permitted_enctypes   = aes256-cts-hmac-sha1-96 aes128-cts rc4-hmac des3-cbc-sha1 des-cbc-md5 des-cbc-crc
    default_realm = MEONA.INTRA

[realms]
    MEONA.INTRA = {
        kdc = pdc.meona.intra
        default_domain = MEONA.INTRA
}

[domain_realm]
    .MEONA.INTRA = MEONA.INTRA 

I tried different variants (with/without ".intra", uppercase/lowercase), without success. But after changing the ticket encryption (using the settings of the AD service user) to ARC4/HMAC1, everything works as expected - what is the problem with AES256?

Caricaria answered 1/5, 2016 at 10:11 Comment(9)
With RC4-HMAC1, it works... ;-(Caricaria
I am facing exactly the same problem. Not working with any AES, but working with RC4-HMAC. Checksum failed all the time...Maccabees
on the AD account, did you check the boxes for "this account supports Kerberos AES 128/256 bit encryption"?Unreason
No, I didn't. But I receive a Kerberos ticket encrypted with AES256 - I suppose because this is the default in newer Windows versions.Caricaria
I have posted an answer to a similar question here.Pernas
Is this system still up and running? I have some ideas we can try out.Breeze
Despite the question being old, the issue is still current. So: Thank you very much, any help is appreciated! ;)Caricaria
I am seeing the same problem with arc hour hmac when using Java 1.8 SPENGO to forward tickets. Were you able to resolve this by selecting the check boxes on SPN to support AES128 + AES256 in AD? Should they be selected and what about pre-authentication? It fails in java debug right before then trys then keytab which returns this.Osteoid
Looks like you never read the (in)famous GitBook "Hadoop and Kerberos, the Madness beyond the Gate" by Steve Loughran -- there are two chapters about cryptic error messages and some possible root causes steveloughran.gitbooks.io/kerberos_and_hadoop/content/sections/…Kammerer
J
0

I seen this issue while using Java 17 and Spnego

My Keytab-file contained entries for AES128/256. We have enabled AES-token for the AD account through Support. Then I see a error "checksum failed" (KVN and password are not changed). Support generates keytab via ktpass. I replace it on the server and after restarting the application the error was resolved.

I re-generated the keytab-file via ktab with the new kvn - keytab also worked.

After enabling AES, you need "refresh" the account in AD for change the KVN parameter. And then the integration will work.

Jarad answered 23/12, 2021 at 13:51 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.