[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: ud Kerberos support (was Re: KTH support for openldap)

Sounds like a good idea....  comments?

At 11:03 PM 1/13/00 -0500, wesley.craig@umich.edu wrote:
>[I'm aware that I'm replying to a really old message, I was going
>through the list archives to find if anyone had decided how to fix the
>ldapmodify kerberos core dumps.  Looks like not.]
>Kurt Zeilenga wrote:
>>Booker Bense wrote:
>>> -P.S. The more I think about it, it seems to me that if you had
>>> all kerberos versions use krb_get_pw_in_tkt then you could use
>>> the same source for all and dump the HAVE_AFS flag.  That flag
>>> is only used in one place, ud/auth.c. It's a hack to allow you
>>> to get a ticket from an AFS K4 server with an unaltered MIT K4
>>> library. I guess it was useful at Umich, but it seems very odd
>>> to me that you would have AFS and not a K4 library that handles
>>> this for you. SOP in the afs world is that you use MIT K4 libraries
>>> with a hacked in string_to_key, so you don't have to put this code
>>> in every app that wants to get a tgt.
>>Comments from AFS users?
>What I've done here, to support disabled all the krbname and AFS
>cleverness in ud.  I believe it's inappropriate for non-kerberos code
>to know anything about the string-to-key function.  On our machines, we
>have exactly one program that knows which string-to-key function to
>use, kinit.  Everyone else just works, regardless of the kerberos
>libraries it was linked with.  If we're interested gutting ud's
>knowledge of kerberos internals, let me know, I've got the diffs

Kurt D. Zeilenga		<kurt@boolean.net>
Net Boolean Incorporated	<http://www.boolean.net/>