On 4/23/07, CORUM, M E [AG/1000] wrote: > (Just an aside on the issue of not being able to load the ldif file on > startup in Windows. It appears to be somehow related to the filename > itself. I found that if the ldif filename started with "ad", then the > weird parsing took place and it always failed. Perhaps this is an issue > that only occurs on Windows.) 'a' and 'd' happen to be valid HEX, so I'd bet the lack of escaped '\' made something in the Java File/FileInputStream, etc., classes think you were escaping unicode or the Windows char set. For 1.5.1 I hope to have an interceptor that automatically generates keys and we'll remove the entire "Kerberos-aware" LDIF loader. I currently have this working with DES keys. This is tracked in JIRA: https://issues.apache.org/jira/browse/DIRSERVER-897 > Since I was trying to do Kerberos anyway, I found that > kerberos-example.ldif file and modified it for my environment. I was > able to get it loaded. I am using a different domain than example.com > so I'm wondering if something in the server is hard-coded to > example.com. I had lots of trouble getting it to recognize anything > other than example.com. I do have a partition matching my new domain > and was able to load the file from the startup and verify the entries in > JXplorer. The server isn't hard-coded, but you do need to specify the realm. The following set of config for 1.5 and earlier (the "before") should cover 99% of config. EXAMPLE.COM krbtgt/EXAMPLE.COM@EXAMPLE.COM ou=users,dc=example,dc=com secret des-cbc-md5 In 1.5.1 this will change to the Spring bean-based config you see in the Sandbox' wiki pages. You may want to start working with the trunk for 1.5.1 after the SASL branch is merged. We have a pile of work merging in. > Now, here is my next problem. In my test code, I'm using JAAS with a > callbackhandler to just shove in a password (rather than using a keytab) > since all of this is just for test code. I'm trying to figure out what > value I need to provide for the userid (principal) from JAAS code. For > now, I use userid@MY.DOMAIN.COM with the appropriate values of course. > When I do this, it fails with the following message in the IDE: > > [ERROR] Mon Apr 23 10:33:02 CDT 2007 jcsi.kerberos: login failed: > Kerberos error creating ticket: > com.dstc.security.kerberos.KerberosError: Integrity checked on decrypted > field failed (Integrity check on decrypted field failed) > ... Typically this means there is a mismatch between the combined password+principal name. Forgive me if you meant this, but more than the passwords need to match; the principal name is also used (as "salt") in the string-to-key derivation function that produces the symmetric key in use here. If you were using the wrong encryption type you should have seen KDC_ERR_ETYPE_NOSUPP, aka "KDC has no support for encryption type," since we don't support RC4-HMAC. More below. > ... > By the way, I'm wondering if the default algorithm for the key is > different. I'm on Windows and use to using 23. I noticed that the > Krb5EncryptionType is 3 rather than 23 in the directory so I'll look > into that to see if that is my problem with Kerberos. The default algorithm for Apache Directory in 1.5 and before is DES-CBC-MD5, which, yes, is type 3. Type 23 is RC4-HMAC, the Windows default. We don't currently support RC4-HMAC, though I read RFC 4757 this weekend on a plane and we have a JIRA issue for it. It is low priority since even the RFC discourages its use (in favor of AES256). RFC 4757: http://www.ietf.org/rfc/rfc4757.txt JIRA for RC4-HMAC: https://issues.apache.org/jira/browse/DIRSERVER-156 JIRA for AES: https://issues.apache.org/jira/browse/DIRSERVER-142 Incidentally I have the hard parts of AES256, AES128, and DES3-CBC-SHA1-KD done so I expect to drop that in just after the SASL merge. Getting AES and DES3 support added is a bit of a prerequisite for the key derivation interceptor in DIRSERVER-897. The key derivation interceptor should produce keys for all three cipher types, namely DES, DES3, and AES. https://issues.apache.org/jira/browse/DIRSERVER-897 Enrique