I recently moved from IBM 7 to IBM 8 and when I tried to bind to AD it fails.
The error i am getting 'Invalid Credentials error' during the SASL bind so it looks like the tickets are replaced well.
The credencials are OK(simple bind operation works well).
GSSAPIBindRequestProperties gssapiProperties = new GSSAPIBindRequestProperties(userUPN, password);
gssapiProperties.setKDCAddress(kdcDnsName);
gssapiProperties.setRealm(realm);
gssapiProperties.setAllowedQoP(SASLQualityOfProtection.AUTH_CONF);
BindRequest bindRequest = new GSSAPIBindRequest(gssapiProperties);
BindResult bindResult = connection.bind(bindRequest);
I'm not aware of an issue in the LDAP SDK, although it's not tested with IBM's Java implementation as extensively as it is with the Oracle and OpenJDK implementations. But if something worked in IBM's Java 7 but not their Java 8, and as long as nothing else changed except that Java release that you're using, then that sounds like a backwards compatibility issue.
As far as I can tell, the only Kerberos-related change that IBM made between their Java 7 and 8 implementations is to add support for the MS-SFU extensions described at http://openjdk.java.net/jeps/113. I don't think that should affect existing use, but I can't find any documentation on this other than to say that it was added.
Everything that I can find using the AD error that you're getting suggests that it could be an issue with the credentials (either a principal that isn't exactly right, or the wrong password), but just changing the Java version shouldn't have any effect on that.
I would recommend would be to turn debugging on in the client (via GSSAPIBindRequestProperties.setEnableGSSAPIDebugging), and also look at any debugging that your directory server and/or the KDC may provide. Perhaps that output, or comparing the difference in that output between the working Java 7 and non-working Java 8 runs will provide a clue as to what's going on.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It looks like the default for authenticator encryption was changed between java 7 to java 8.
Also, with oracle jre, it is working fine.
I wonder wheather you guess from the setEnableGSSAPIDebugging, what went wrong.
Client debugs are:
[JGSS_DBG_CRED] main JAAS config: debug=true [JGSS_DBG_CRED] main JAAS config: credsType=initiate only [JGSS_DBG_CRED] main config: useDefaultCcache=false [JGSS_DBG_CRED] main config: useCcache=null [JGSS_DBG_CRED] main config: useDefaultKeytab=false (default) [JGSS_DBG_CRED] main config: useKeytab=null [JGSS_DBG_CRED] main JAAS config: forwardable=false (default) [JGSS_DBG_CRED] main JAAS config: renewable=false (default) [JGSS_DBG_CRED] main JAAS config: proxiable=false (default) [JGSS_DBG_CRED] main JAAS config: tryFirstPass=false (default) [JGSS_DBG_CRED] main JAAS config: useFirstPass=false (default) [JGSS_DBG_CRED] main JAAS config: moduleBanner=false (default) [JGSS_DBG_CRED] main JAAS config: interactive login? yes [JGSS_DBG_CRED] main Retrieving Kerberos creds from cache for principal=null [JGSS_DBG_CRED] main No Kerberos creds in cache for principal testUser@DOMAIN.EXAMPLE.COM [JGSS_DBG_CRED] main Doing Kerberos login for principal testUser@DOMAIN.EXAMPLE.COM [JGSS_DBG_CRED] main Doing Kerberos login for principal: testUser@DOMAIN.EXAMPLE.COM [JGSS_DBG_CRED] main Kerberos login complete [JGSS_DBG_CRED] main Login successful [JGSS_DBG_CRED] main kprincipal : testUser@DOMAIN.EXAMPLE.COM [JGSS_DBG_CRED] main testUser@DOMAIN.EXAMPLE.COM added to Subject [JGSS_DBG_CRED] main Kerberos ticket added to Subject [JGSS_DBG_CRED] main added key of type aes256-cts-hmac-sha1-96 [JGSS_DBG_CRED] main added key of type aes128-cts-hmac-sha1-96 [JGSS_DBG_CRED] main added key of type des3-cbc-sha1 [JGSS_DBG_CRED] main added key of type rc4-hmac
Ldap error: 80090308: LdapErr: DSID-0C090503, comment: AcceptSecurityContext error, data 5, v2580
Thanks in advance
Eran
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As far as I can tell, for both the Oracle and IBM Java implementations, there is no way to configure the set of Kerberos encryption ciphers through Java code. It is dependent upon the underlying system configuration, for example via krb5.conf if you're using the MIT Kerberos implementation.
The only possibility that I can think of is that perhaps your Java 7 installation included the JCE unlimited strength jurisdiction policy file in place but your Java 8 installation does not. Without this policy file in place, you're limited to 128-bit AES, but the unlimited strength policy allows for 256-bit AES. The debug output references 256-bit AES ("added key of type aes256-cts-hmac-sha1-96"), so that's a strong possibility. See http://www.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/com.ibm.java.security.component.80.doc/security-component/sdkpolicyfiles.html for more information.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The java 7 and java 8 have the same JCE unlimited strength jurisdiction policy jars.
At least, this is the one that available to download from IBM.
I am using these files (otherwise java 7 wouldn't have worked as well).
I will continue to investigate and update.
Thanks a lot
Eran G
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Happy to update that problem was identified in IBM java 8.
Fix suppose to be included in Java 8 SR4.
At the moment I am using the krb5.conf for limiting the TGS encryption (until I will move to the new version).
Thanks a lot
Eran G
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi All
I recently moved from IBM 7 to IBM 8 and when I tried to bind to AD it fails.
The error i am getting 'Invalid Credentials error' during the SASL bind so it looks like the tickets are replaced well.
The credencials are OK(simple bind operation works well).
GSSAPIBindRequestProperties gssapiProperties = new GSSAPIBindRequestProperties(userUPN, password);
gssapiProperties.setKDCAddress(kdcDnsName);
gssapiProperties.setRealm(realm);
gssapiProperties.setAllowedQoP(SASLQualityOfProtection.AUTH_CONF);
BindRequest bindRequest = new GSSAPIBindRequest(gssapiProperties);
BindResult bindResult = connection.bind(bindRequest);
Have you encountered such error?
Ldap error:
80090308: LdapErr: DSID-0C090503, comment: AcceptSecurityContext error, data 5, v2580
The unboundid version is 2.3.6
Thanks in advance
Eran
I'm not aware of an issue in the LDAP SDK, although it's not tested with IBM's Java implementation as extensively as it is with the Oracle and OpenJDK implementations. But if something worked in IBM's Java 7 but not their Java 8, and as long as nothing else changed except that Java release that you're using, then that sounds like a backwards compatibility issue.
As far as I can tell, the only Kerberos-related change that IBM made between their Java 7 and 8 implementations is to add support for the MS-SFU extensions described at http://openjdk.java.net/jeps/113. I don't think that should affect existing use, but I can't find any documentation on this other than to say that it was added.
Everything that I can find using the AD error that you're getting suggests that it could be an issue with the credentials (either a principal that isn't exactly right, or the wrong password), but just changing the Java version shouldn't have any effect on that.
I would recommend would be to turn debugging on in the client (via GSSAPIBindRequestProperties.setEnableGSSAPIDebugging), and also look at any debugging that your directory server and/or the KDC may provide. Perhaps that output, or comparing the difference in that output between the working Java 7 and non-working Java 8 runs will provide a clue as to what's going on.
Hi Neil
It looks like the default for authenticator encryption was changed between java 7 to java 8.
Also, with oracle jre, it is working fine.
I wonder wheather you guess from the setEnableGSSAPIDebugging, what went wrong.
Client debugs are:
[JGSS_DBG_CRED] main JAAS config: debug=true
[JGSS_DBG_CRED] main JAAS config: credsType=initiate only
[JGSS_DBG_CRED] main config: useDefaultCcache=false
[JGSS_DBG_CRED] main config: useCcache=null
[JGSS_DBG_CRED] main config: useDefaultKeytab=false (default)
[JGSS_DBG_CRED] main config: useKeytab=null
[JGSS_DBG_CRED] main JAAS config: forwardable=false (default)
[JGSS_DBG_CRED] main JAAS config: renewable=false (default)
[JGSS_DBG_CRED] main JAAS config: proxiable=false (default)
[JGSS_DBG_CRED] main JAAS config: tryFirstPass=false (default)
[JGSS_DBG_CRED] main JAAS config: useFirstPass=false (default)
[JGSS_DBG_CRED] main JAAS config: moduleBanner=false (default)
[JGSS_DBG_CRED] main JAAS config: interactive login? yes
[JGSS_DBG_CRED] main Retrieving Kerberos creds from cache for principal=null
[JGSS_DBG_CRED] main No Kerberos creds in cache for principal testUser@DOMAIN.EXAMPLE.COM
[JGSS_DBG_CRED] main Doing Kerberos login for principal testUser@DOMAIN.EXAMPLE.COM
[JGSS_DBG_CRED] main Doing Kerberos login for principal: testUser@DOMAIN.EXAMPLE.COM
[JGSS_DBG_CRED] main Kerberos login complete
[JGSS_DBG_CRED] main Login successful
[JGSS_DBG_CRED] main kprincipal : testUser@DOMAIN.EXAMPLE.COM
[JGSS_DBG_CRED] main testUser@DOMAIN.EXAMPLE.COM added to Subject
[JGSS_DBG_CRED] main Kerberos ticket added to Subject
[JGSS_DBG_CRED] main added key of type aes256-cts-hmac-sha1-96
[JGSS_DBG_CRED] main added key of type aes128-cts-hmac-sha1-96
[JGSS_DBG_CRED] main added key of type des3-cbc-sha1
[JGSS_DBG_CRED] main added key of type rc4-hmac
Ldap error: 80090308: LdapErr: DSID-0C090503, comment: AcceptSecurityContext error, data 5, v2580
Thanks in advance
Eran
Hi Neil
I have 1 more additinal question.
Is there a way to control the kerberos encryptions that are used on each phase by using the unbound-id sdk?
Thanks in advance
Eran
As far as I can tell, for both the Oracle and IBM Java implementations, there is no way to configure the set of Kerberos encryption ciphers through Java code. It is dependent upon the underlying system configuration, for example via krb5.conf if you're using the MIT Kerberos implementation.
The only possibility that I can think of is that perhaps your Java 7 installation included the JCE unlimited strength jurisdiction policy file in place but your Java 8 installation does not. Without this policy file in place, you're limited to 128-bit AES, but the unlimited strength policy allows for 256-bit AES. The debug output references 256-bit AES ("added key of type aes256-cts-hmac-sha1-96"), so that's a strong possibility. See http://www.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/com.ibm.java.security.component.80.doc/security-component/sdkpolicyfiles.html for more information.
Hi Neil
The java 7 and java 8 have the same JCE unlimited strength jurisdiction policy jars.
At least, this is the one that available to download from IBM.
I am using these files (otherwise java 7 wouldn't have worked as well).
I will continue to investigate and update.
Thanks a lot
Eran G
Hi Neil
Happy to update that problem was identified in IBM java 8.
Fix suppose to be included in Java 8 SR4.
At the moment I am using the krb5.conf for limiting the TGS encryption (until I will move to the new version).
Thanks a lot
Eran G