[
https://issues.apache.org/jira/browse/DIRKRB-100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13915608#comment-13915608
]
Eirik Bjorsnos commented on DIRKRB-100:
---------------------------------------
KdcConfig.getEncyptionTypes returns null, so I'm instead stealing the contents
from KdcConfig.DEFAULT_ENCRYPTION_TYPES (which is a private static variable,
not accessible from anywhere).
So my code now looks something like this:
{code}
KdcConfig config = KdcConfig.getDefaultConfig();
Set<EncryptionType> encTypes = new HashSet<EncryptionType>();
encTypes.add(AES256_CTS_HMAC_SHA1_96);
encTypes.add(AES128_CTS_HMAC_SHA1_96);
//encTypes.add(RC4_HMAC);
encTypes.add(RC4_HMAC_EXP);
encTypes.add(DES3_CBC_SHA1_KD);
encTypes.add(DES_CBC_MD5);
encTypes = KerberosUtils.orderEtypesByStrength(encTypes);
config.setEncryptionTypes(encTypes);
{code}
The result from this is that I get an AS_REP back with encryption type
RC4_HMAC_EXP (weaker RC4?).
RC4_HMAC_EXP is not supported by the client code "KerberosException: KDC has no
support for encryption type".
So removing RC4_HMAC_EXP, I get a somewhat strange behaviour.
Wireshark now shows an AP_REP with end-type des-cbc-md5. Additionally,
wireshark says "NT Status: Unknown error code 0x544e414b". I think this is just
a bug in Wireshark: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6234
Anyhow, the client side code fails:
{code}
Exception in thread "main"
org.apache.directory.shared.kerberos.exceptions.KerberosException: Integrity
check on decrypted field failed
at
org.apache.directory.server.kerberos.shared.crypto.encryption.AesCtsSha1Encryption.getDecryptedData(AesCtsSha1Encryption.java:110)
at
org.apache.directory.server.kerberos.shared.crypto.encryption.Aes256CtsSha1Encryption.getDecryptedData(Aes256CtsSha1Encryption.java:30)
at
org.apache.directory.server.kerberos.shared.crypto.encryption.CipherTextHandler.decrypt(CipherTextHandler.java:121)
at
org.apache.directory.kerberos.client.KdcConnection._getTgt(KdcConnection.java:318)
at
org.apache.directory.kerberos.client.KdcConnection.getTgt(KdcConnection.java:181)
{code}
Not sure why it chose Aes256CtsSha1Encryption?
> Active Directory support for KdcConnection
> ------------------------------------------
>
> Key: DIRKRB-100
> URL: https://issues.apache.org/jira/browse/DIRKRB-100
> Project: Directory Kerberos
> Issue Type: Improvement
> Reporter: Eirik Bjorsnos
> Assignee: Emmanuel Lecharny
>
> I'm testing KdcConnection.getTgt() with Microsoft Active Directory.
> My first test failed with AD responding with first saying
> KRB5KRB_ERR_PREAUTH_REQUIRED (expected), then KRB5KRB_ERR_PREAUTH_FAILED (not
> expected).
> Since PREAUTH_FAILED is what you'll also get if your password is wrong, I
> enabled "Do not use pre authentication" for the account being tested and
> verified via kinit on OS X that no pre authentication was sent there.
> When testing getTgt with no preauth, I now get the following exception:
> Exception in thread "main"
> org.apache.directory.server.kerberos.changepwd.exceptions.ChangePasswordException:
> Request failed due to being malformed.
> at
> org.apache.directory.server.kerberos.protocol.codec.KerberosDecoder.decodeEncTgsRepPart(KerberosDecoder.java:684)
> at
> org.apache.directory.kerberos.client.KdcConnection._getTgt(KdcConnection.java:329)
> at
> org.apache.directory.kerberos.client.KdcConnection.getTgt(KdcConnection.java:181)
> at
> org.apache.directory.kerberos.client.KdcConnection.getTgt(KdcConnection.java:145)
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
