I agree that setting up the GSSAPI bit for Kerberos is terribly opaque and difficult to troubleshoot, but in the grand scheme of things (i.e. emulating the Negotiate/NTLM authentication that comprises Integrated Windows Authentication over HTTP), it's actually the easy part because clients on a domain tend to behave consistently. The main problem is with clients not on a domain, which tend to deviate from the protocol specifications or negotiate Microsoft-specific protocols that either can't be handled properly or need special handling. And even then there are inconsistencies between operating systems, browser versions (namely of IE), and in the most egregious case, between systems that have Windows Live Sign-In Assistant installed and systems that do not.
If I had to guess as to what might be wrong with your setup, there are two main possibilities. The first is that principal generated by the client does not match the principal specified in your keytab and JAAS configuration (you may need to watch out for port number mismatches depending on the client). The only way to check this is with a packet capture. The second is that there's a mismatch in the key version number (kvno) of the keys in your keytab as compared to the kvno of the keys on the KDC. This can again be checked with a packet capture (i.e. the client will receive a key from the KDC with a particular kvno - this should match the kvno for the corresponding key in the keytab). If you still can't figure out what's wrong and can provide a packet capture, send another message to this list and I'll contact you directly to see if I can spot anything obviously wrong (this particular e-mail address will discard any messages not sent to the list, so don't send messages directly to this address or I'll never get them). 2011/9/29 Michał Minicki - [email protected] > This is no simple task. I have tried using experimental spring > security code ( > http://blog.springsource.com/2009/09/28/spring-security-kerberos/) > and I have hit a wall on the go. Unfortunately the problems I'm having > are all inside the GSS API. Right now I'm on the verge of throwing it > into trash. > > Everything is configured, principals, keytab, krb.ini, correct > enctypes at the server, keytab and client level, and still. This > security related Java code simply does not provide enough information > to get it working on your own [1] > > But, if any of you needs a tester for the Shiro plugin then let me > know, I'll gladly help by testing it on my environement (Windows > Active Directory). I can also provide some help on the go but I'm no > expert in this kind of authentication mechanisms. > > Specifics: > > 2011-08-28 13:34:11,824 DEBUG > > [org.springframework.security.extensions.kerberos.KerberosServiceAuthenticationProvider] > Try to validate Kerberos Token > 2011-08-28 13:34:12,027 INFO [STDOUT] Found key for > HTTP/doswok005.polsatc:8080@POLSATC(23) > 2011-08-28 13:34:12,027 INFO [STDOUT] Entered > Krb5Context.acceptSecContext with state=STATE_NEW > 2011-08-28 13:34:12,058 INFO [STDOUT] >>> EType: > sun.security.krb5.internal.crypto.ArcFourHmacEType > 2011-08-28 13:34:12,324 ERROR [STDERR] Checksum failed ! > 2011-08-28 13:34:12,355 WARN > > [org.springframework.security.extensions.kerberos.web.SpnegoAuthenticationProcessingFilter] > Negotiate Header was invalid: Negotiate YIIHMgYGKwYBBQUCoIIHJjCCByK > (/snip/ - a very long header) pauQON9eA== > org.springframework.security.authentication.BadCredentialsException: > Kerberos validation not succesfull > at > > org.springframework.security.extensions.kerberos.SunJaasKerberosTicketValidator.validateTicket(SunJaasKerberosTicketValidator.java:69) > at > > org.springframework.security.extensions.kerberos.KerberosServiceAuthenticationProvider.authenticate(KerberosServiceAuthenticationProvider.java:86) > (…) > Caused by: java.security.PrivilegedActionException: GSSException: > Failure unspecified at GSS-API level (Mechanism level: Checksum > failed) > at java.security.AccessController.doPrivileged(Native > Method) > at javax.security.auth.Subject.doAs(Subject.java:396) > at > > org.springframework.security.extensions.kerberos.SunJaasKerberosTicketValidator.validateTicket(SunJaasKerberosTicketValidator.java:67) > ... 28 more > Caused by: GSSException: Failure unspecified at GSS-API level > (Mechanism level: Checksum failed) > 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) > (…) > Caused by: KrbException: Checksum failed > at > > sun.security.krb5.internal.crypto.ArcFourHmacEType.decrypt(ArcFourHmacEType.java:85) > at > > sun.security.krb5.internal.crypto.ArcFourHmacEType.decrypt(ArcFourHmacEType.java:77) > at > sun.security.krb5.EncryptedData.decrypt(EncryptedData.java:168) > (…) > Caused by: java.security.GeneralSecurityException: Checksum failed > at > > sun.security.krb5.internal.crypto.dk.ArcFourCrypto.decrypt(ArcFourCrypto.java:388) > at > sun.security.krb5.internal.crypto.ArcFourHmac.decrypt(ArcFourHmac.java:74) > at > > sun.security.krb5.internal.crypto.ArcFourHmacEType.decrypt(ArcFourHmacEType.java:83) > ... 45 more > > > Best regards, > Michał > > On Tue, Sep 27, 2011 at 10:29, Minas Manthos <[email protected]> > wrote: > > +1 > > > > -- > > View this message in context: > http://shiro-user.582556.n2.nabble.com/SSO-with-Active-Directory-Kerberos-tp6781650p6835133.html > > Sent from the Shiro User mailing list archive at Nabble.com. > > > > > > -- > Pozdrawiam, > Michał Minicki > >
