Re: KTH support for openldap

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 04:01 PM 9/30/99 -0700, Booker Bense wrote:
>[ My horror at the suggested use of AFS krb libraries deleted]
>> All true.  I wouldn't suggest supporting the use of AFS Kerberos
>> libraries.  AFAIK, UMich LDAP 3.3 didn't support the use of AFS
>> Kerberos libraries.  What it did do, is support an alternate
>> string-to-key function in ud.  I don't think that's terribly hard to
>> support, since the string-to-key function is already in the ud code.
>- This is one place ( among many ) where KTH gets it spot on. 
>It automagically works whether you're using afs_string_to_key
>or des_string_to_key. 
>
>- Everything has compiled out of the box except ud and the
>back-ldbm. The common problem between them is that 
>
>	ac/unistd.h 
>
>includes  /usr/include/crypt.h.

Needed to get the crypt(3) prototype on some systems.  We
currently just test for the existence of the header.  Looks
like we should look for specifically for the the prototype
and only include <crypt.h> as needed.

>This causes a prototype clash
>for the des_encrypt function. Ud requires another simple fix 
>to allow it to use krb_get_pw_in_tkt rather than krb_get_in_tkt. 
>
>- I have #ifdef HAVE_KTH_KERBEROS code that fixes both problems,
>but I don't have a test to set HAVE_KTH_KERBEROS. There is at least
>one include file that looks like it would be a pretty good flag
>that you have KTH kerberos:
>
>	krb-archaeology.h

We could easily add AC_CHECK_HEADERS( krb-archaelogoy.h ) and
use the result to set HAVE_KTH_KERBEROS if there are no
better flags (such as Kth specific #define).

I assume Kth uses the relies on the k4 detection checks
being positive.  We might want to add --with-kerberos=kth
to require successful Kth detection.

>- Anyway, let me know how you'd like to deal with this.

I would think adding the Kth specific support would be quite
appropriate.  I'd happy to work with you on integrating whatever
changes you have to offer.

Kurt