[2196] in Kerberos_V5_Development
Re: Krb5/NT patches
daemon@ATHENA.MIT.EDU (Richard Basch)
Fri Jan 31 23:31:54 1997
Date: Fri, 31 Jan 1997 23:30:01 -0500 (EST)
To: deengert@anl.gov
Cc: krbdev@MIT.EDU
From: "Richard Basch" <basch@lehman.com>
On Fri, 31 Jan 1997 19:31:34, Douglas Engert <deengert@anl.gov> wrote:
> Thanks for the patches to the krb5-nt-alpha1 code. I built
> the 32 bit version on Windows 95. The krb5.exe and my rlogin
> terminal emulator work without any additional modifications.
> But see below.
> I removed my krb5_dll_* routines, including the krb5_dll_malloc
> and krb5_dll_xfree, and went back to malloc and krb5_xfree.
> Replacing the crypto macros with functions works well, and
> the dynamic linking appears to have fixed the "two heap" problem.
> I did not have to change any link options with the Borland C++
> to get this to work either. The test in win-mac.c for _MSC_VER
> also worked with the Borland C++.
I am glad the patches worked as well as they did...
Without a Borland C++ compiler, I was uncertain if all the changes would
meet your needs.
> I will try and build a 16-bit version soon.
Before you do, apply the enclosed patch... Since it is only a one-line
change to krb5.hin (and the generated krb5.h), you might just opt to fix
it by hand in your tree. Without this patch, the build will fail on
lib\krb5\krb\crypto_glue.obj. Also, I recommend rebuilding
lib\krb5\krb\encode_kdc.obj. Essentially, I made a typo in the return
value of krb5_eblock_enctype, and the win32 compiler let it go, but VC++
1.52 was a bit more stringent.
--- 1.1 1997/02/01 04:09:58
+++ src/include/ChangeLog 1997/02/01 04:10:49
@@ -1,3 +1,9 @@
+Fri Jan 31 23:10:09 1997 Richard Basch <basch@lehman.com>
+
+ * krb5.hin:
+ Fixed improper declaration of krb5_eblock_enctype;
+ it returns a krb5_enctype, not a krb5_error_code.
+
Thu Jan 30 21:22:28 1997 Richard Basch <basch@lehman.com>
* krb5.hin
--- 1.1 1997/02/01 04:09:59
+++ src/include/krb5.hin 1997/02/01 04:11:34
@@ -386,7 +386,7 @@
krb5_const krb5_encrypt_block FAR * eblock,
krb5_pointer ptr,
krb5_keyblock FAR * FAR * keyblock));
-KRB5_DLLIMP krb5_error_code KRB5_CALLCONV krb5_eblock_enctype
+KRB5_DLLIMP krb5_enctype KRB5_CALLCONV krb5_eblock_enctype
KRB5_PROTOTYPE((krb5_context context,
krb5_const krb5_encrypt_block FAR * eblock));
KRB5_DLLIMP krb5_error_code KRB5_CALLCONV krb5_use_enctype
> There are still three issues which I see today:
> o The fwd_tgt.c needs a fix for cross-realm to get the
> forwarded ticket for the krbtgt/client.realm@client.realm
> This has been reported a number of times, and it was not
> in your code base.
We'll have to look through the GNATS database for this one.
> o I sent in a suggestion to look at using the windows registry
> to find where the cache is located. This would work well
> with the Gradient DCE doing the dce_login and getting the
> initial tgt. This also requires that the krb5_32.dll
> be linked with the advapi32.lib. You may want to add this
> lib, even if you don't add the code for Gradient.
I saw the patch, but decided to hold off for a few days while I give
this one some thought. I am not sure what the best way to tackle the
registry is, or whether the user profile in the registry may be the
better way of obtaining the information that is currently obtained from
the .ini file. That was why I didn't immediately integrate the patch.
> o preauth.c calls krb5_read_password, which does nothing,
> it should put out a dialog box to get the needed info.
> This would not be to hard, I could look at it if no one
> else does.
I noticed this one too... However, I was not sure that popping up a
dialog box is necessarily the appropriate action. For instance, what is
the proper method for popping up a dialog box in GINA; it is not the
normal Windows interface, but GINA, being an integral part of the NT
login, will require the password. Building dependencies on libraries
that would create problems for building GINA services and "system"
Kerberos services was the main reason I left this one alone. If you
have some thoughts, ideas, suggestions, or fixes for this issue, we
would love to hear them.
> Keep up the good work, This is comming together nicely!
Thanks. Also, thank you for all the work, testing, and comments that
you have provided thus far.
