1 Reply Latest reply on Jul 7, 2011 9:05 AM by 873607

    Secure LDAP connection using GSSAPI and  aes128-cts

      I am trying to establish a secure connection to an Windows 2008 Server Active Directory using a Kerberos Ticket obtained from the JAAS KerberosLoginModule.
      With the default kerberos encryption types the connection is established and "des-cbc-md5" is used for encryption.
      If I change the kerberos encryption types in "krb5.ini" to
      default_tgs_enctypes =  aes256-cts-hmac-sha1-96 aes128-cts   des3-cbc-sha1 des-cbc-md5 des-cbc-crc
      then i can see in the Ticket that aes128-cts is used, but I alway get the following error:

      +java.security.PrivilegedActionException: javax.naming.AuthenticationException: GSSAPI [Root exception is javax.security.sasl.SaslException: Final handshake failed [Caused by+ +GSSException: Token had invalid integrity check (Mechanism level: Corrupt checksum in Wrap token)]]+
      Caused by: GSSException: Token had invalid integrity check (Mechanism level: Corrupt checksum in Wrap token)
      at sun.security.jgss.krb5.WrapToken_v2.getDataFromBuffer(Unknown Source)
      at sun.security.jgss.krb5.WrapToken_v2.getData(Unknown Source)
      at sun.security.jgss.krb5.WrapToken_v2.getData(Unknown Source)
      at sun.security.jgss.krb5.Krb5Context.unwrap(Unknown Source)
      at sun.security.jgss.GSSContextImpl.unwrap(Unknown Source)

      With Wireshark I can see the following communication betwen the Client and the AD Server

      LDAP     bindRequest(1) "<ROOT>" sasl
      LDAP     bindResponse(1) saslBindInProgress
      +LDAP     bindRequest(2) "<ROOT>" [Malformed Packet]+
      LDAP     bindResponse(2) saslBindInProgress

      As far as I understand the Problem the client tries to verify the message from the Server by calculating an checksum (using aes128) and comparing this checksum with the value delivered in the Message and the Exception is thrown because the checksums do not match.

      I am using the following option to create the LDAP Context:

      environment.put("java.naming.factory.initial", "com.sun.jndi.ldap.LdapCtxFactory")
      environment.put("java.naming.security.authentication", "GSSAPI")
      environment.put("javax.security.sasl.qop", "auth-conf")
      environment.put("java.naming.provider.url", url)
      environment.put("java.security.krb5.conf", krb5)
      environment.put("javax.security.sasl.strength", "high")

      I am using Java(TM) SE Runtime Environment (build 1.6.0_22-b04) on the client side ( Windows XP and Windows 7 )

      Should aes128 encryption work in this context ?

      Any idea how to solve the problem (I have no idea if it is a problem on the server or on the client side) ?

      I want to use aes128, because i hope this allows my to change user passwords without the need for SSL /TSL. With des-cbc-md5 changing the password over LDAP results in the following error:

      +javax.naming.OperationNotSupportedException: [LDAP: error code 53 - 0000001F: SvcErr: DSID-031A11E5, problem 5003 (WILL_NOT_PERFORM), data 0 ]; remaining name 'CN=thomas,CN=Users,DC=sso,DC=test,DC=de'+

      Dose anyone know if this would work if aes128 would be used ?

      Thanks & Regards,

        • 1. Re: Secure LDAP connection using GSSAPI and  aes128-cts

          it seems to be a JRE Problem. When I use the Kerberos implementation from "Vintela Single Sign-On for Java" I can establish a "aes256" secured LDAP connection to the AD Server.
          This LDAP connection allows to change the passwords of the users stored in the AD.

          The problem is that "Vintela Single Sign-On for Java" is not free, so it would be nice to have a solution which works with the Kerberos implementation of the JRE.

          The error is the same for "aes128" and "aes256" encryption.

          And with Wireshark I can not see any differences in the packets send to the AD and received from the AD.