On 4/23/07, CORUM, M E [AG/1000] <[EMAIL PROTECTED]> 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.
<prop key="kdc.realm">EXAMPLE.COM</prop>
<prop key="kdc.principal">krbtgt/[EMAIL PROTECTED]</prop>
<prop key="kdc.entryBaseDn">ou=users,dc=example,dc=com</prop>
<prop key="kdc.java.naming.security.credentials">secret</prop>
<prop key="kdc.encryption.types">des-cbc-md5</prop>
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 [EMAIL PROTECTED] 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
