directory-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Enrique Rodriguez" <enriqu...@gmail.com>
Subject Re: [ApacheDS] 1.5 Experience and Kerberos (any Kerberos experts out there?)
Date Wed, 25 Apr 2007 03:00:04 GMT
On 4/23/07, CORUM, M E [AG/1000] <m.e.corum@monsanto.com> 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/EXAMPLE.COM@EXAMPLE.COM</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 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

Mime
View raw message