hi ! I am using KRB5 API to fetch TGT and then GSS API to generate negotiate tokens. (then I add these tokens into HTTP headers when needed). I am using Heimdal v. 1.4. This works in all cases, but in one specific scenario, Scenario (I just made up names): - Client ([hidden email]) obtains TGT from KDC1: krbtgt/[hidden email] - Client obtains a cross-realm ticket-granting ticket: krbtgt/[hidden email] - Client obtains service ticket: HTTP/[hidden email] This works, but next time I call GSS API, cached service tickets are ignored and for each and every resource a new service ticket is obtained (thus flooding KDC server and also filling up local client's cache). After debugging and code reading, I have established the root cause: 1. new requests are done because "check_cc" function (in check_cc.c file) is given a wrong server name: check_cc(krb5_context context, krb5_flags options, krb5_ccache ccache, krb5_creds *in_creds, krb5_creds *out_creds) gets this "HTTP/[hidden email]" instead of "HTTP/[hidden email]" 2. "in_creds->server->realm" gets overridden in import_name.c file, in function _gsskrb5_canon_name: When gsskrb5_get_creds calls _gsskrb5_canon_name function, it passes correct creds with "EAST.TESTNET.NET" as a realm. but here, in this place: /* If its not a hostname */ if (krb5_principal_get_type(context, p) != MAGIC_HOSTBASED_NAME_TYPE) { ret = krb5_copy_principal(context, p, out); } else if (!use_dns) { ret = krb5_copy_principal(context, p, out); if (ret) goto out; krb5_principal_set_type(context, *out, KRB5_NT_SRV_HST); if (sourcename) ret = krb5_principal_set_realm(context, *out, sourcename->realm); } else { ....... "sourcename" is client principal ("[hidden email]") - in_creds cred's realm is overwritten by one from "sourcename->realm" this issue is present in Heimdal versions in 1.4.x and 1.5.x. From v.7.0 and up, _gsskrb5_canon_name() has been reworked. so it is not possible to simply backport changes. is this normal? if so, why we need to overwrite it? regards, Alibek |
> On Aug 10, 2018, at 4:01 PM, Alibek Jorajev <[hidden email]> wrote: > > I am using KRB5 API to fetch TGT and then GSS API to generate negotiate tokens. > (then I add these tokens into HTTP headers when needed). I am using Heimdal v. 1.4. You really SHOULD NOT be using Heimdal 1.4. We only support Heimdal 7.x. -- Viktor. |
hi Viktor! I would be happy to use latest 7.x. but the upgrade will take time (it is on the roadmap). and I need to patch 1.4 for this specific defect. I have the following options (no question about moving to 7.x, that will be separate effort): - do not use realm from "source" in this specific scenario (cross-realm) - remove "source" all together - try to backport portion of code (if that code is still meaningful for 1.4) from latest 7.x do you know, why in 1.5.x series, it was needed to use "source" (client principal's realm)? regards, Alibek
On Friday, 10 August 2018, 22:17:59 GMT+1, Viktor Dukhovni <[hidden email]> wrote:
> On Aug 10, 2018, at 4:01 PM, Alibek Jorajev <[hidden email]> wrote: > > I am using KRB5 API to fetch TGT and then GSS API to generate negotiate tokens. > (then I add these tokens into HTTP headers when needed). I am using Heimdal v. 1.4. You really SHOULD NOT be using Heimdal 1.4. We only support Heimdal 7.x. -- Viktor. |
> On Aug 13, 2018, at 2:23 AM, Alibek Jorajev <[hidden email]> wrote: > > I have the following options (no question about moving to 7.x, that will be separate effort): > - do not use realm from "source" in this specific scenario (cross-realm) > - remove "source" all together > - try to backport portion of code (if that code is still meaningful for 1.4) from latest 7.x > > do you know, why in 1.5.x series, it was needed to use "source" (client principal's realm)? Sorry, can't help you with code that old. Perhaps someone else can, based on your original post, if it was sufficiently detailed. -- Viktor. |
In reply to this post by Viktor Dukhovni-2
hi everyone, I am trying to build latest 7.5.0 Heimdal and getting this error: CC libhcrypto_la-evp-cc.lo CC libhcrypto_la-evp-openssl.lo /Users/ajorajev/work5/depot/dev/gd/msdk/runtime/component/3rdparty/heimdal-7.5.0/src/heimdal-7.5.0/lib/hcrypto/evp-openssl.c:76:10: fatal error: 'openssl/evp.h' file not found #include <openssl/evp.h> ^ 1 error generated. make[2]: *** [libhcrypto_la-evp-openssl.lo] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all-recursive] Error 1 I ran configure with paths: --with-cross-tools=$CROSSROOT --with-openssl=$SSLROOT --with-openssl-include=$SSLROOT/include where SSLROOT is correct path to OpenSSL - this works with Heimdal v.1.4 but it is not working with 7.x can someone help me if it is quick? if not, no worries, I will keep working on it around myself. regards, Alibek |
> On Aug 17, 2018, at 12:06 PM, Alibek Jorajev <[hidden email]> wrote: > > I ran configure with paths: > > --with-cross-tools=$CROSSROOT --with-openssl=$SSLROOT --with-openssl-include=$SSLROOT/include > > where SSLROOT is correct path to OpenSSL - this works with Heimdal v.1.4 > but it is not working with 7.x > > can someone help me if it is quick? It works correctly with 7.x in my builds: --with-hcrypto-default-backend=ossl \ --with-openssl=/opt/openssl/1.1.0 I have not attempted cross-builds. -- Viktor. |
In reply to this post by Alibek Jorajev
On Fri, 17 Aug 2018, Alibek Jorajev wrote:
> I ran configure with paths: > --with-cross-tools=$CROSSROOT --with-openssl=$SSLROOT --with-openssl-include=$SSLROOT/include Alibek, which OpenSSL do you have? Do you have OpenSSL header files in $SSLROOT/include for sure? This file has been a part of OpenSSL since like forever. Marcin |
hi Marcin, thanks for looking into this. I have OpenSSL 1.0.2m. yes, I double checked, evp.h is there. (I also add "ls $GDSSLROOT/include/openssl/" and visually confirmed that this header file is there. I am using Xcode7.3.1 - same toolchain which can build 1.4. Alibek
On Friday, 17 August 2018, 17:24:02 GMT+1, Marcin Cieslak <[hidden email]> wrote:
On Fri, 17 Aug 2018, Alibek Jorajev wrote: > I ran configure with paths: > --with-cross-tools=$CROSSROOT --with-openssl=$SSLROOT --with-openssl-include=$SSLROOT/include Alibek, which OpenSSL do you have? Do you have OpenSSL header files in $SSLROOT/include for sure? This file has been a part of OpenSSL since like forever. Marcin |
In reply to this post by Marcin Cieslak-3
Hi Marcin! one more question, do I need to run autoreconf? I am now running this "autoreconf -f -i" it just mentions "configure" Now, I am trying to build for local native machine as a first step, so no cross compiling. I decided to go back to basics. Alibek
On Friday, 17 August 2018, 17:24:02 GMT+1, Marcin Cieslak <[hidden email]> wrote:
On Fri, 17 Aug 2018, Alibek Jorajev wrote: > I ran configure with paths: > --with-cross-tools=$CROSSROOT --with-openssl=$SSLROOT --with-openssl-include=$SSLROOT/include Alibek, which OpenSSL do you have? Do you have OpenSSL header files in $SSLROOT/include for sure? This file has been a part of OpenSSL since like forever. Marcin |
In reply to this post by Marcin Cieslak-3
I have installed openssl using homebrew and pointed it to /usr/local/opt/openssl/lib and /usr/local/opt/openssl/include and now it builds fine for native (MacOS). just a guess: I am using " -framework Security" in the LD_FLAGS.... and I have suspicion that MacOS 10.13.6 does not have OpenSSL.
On Friday, 17 August 2018, 17:24:02 GMT+1, Marcin Cieslak <[hidden email]> wrote:
On Fri, 17 Aug 2018, Alibek Jorajev wrote: > I ran configure with paths: > --with-cross-tools=$CROSSROOT --with-openssl=$SSLROOT --with-openssl-include=$SSLROOT/include Alibek, which OpenSSL do you have? Do you have OpenSSL header files in $SSLROOT/include for sure? This file has been a part of OpenSSL since like forever. Marcin |
In reply to this post by Marcin Cieslak-3
Hi guys ! Heimdal 1.4 used to have "compile_et" error table compiler tool (in usr/bin folder). after I have built Heimdal v.7.5.0, I do not see this tool anymore. (but there are error tables in the source code). is this normal? regards, Alibek |
In reply to this post by Viktor Dukhovni-2
I am trying to cross compile (to armv7s platform) and i am getting this: ... ... ... Making all in roken perl /Users/ajorajev/work5/depot/dev/gd/msdk/runtime/component/3rdparty/heimdal-7.5.0/src/heimdal-7.5.0/cf/roken-h-process.pl \ -c ../../include/config.h \ -p /Users/ajorajev/work5/depot/dev/gd/msdk/runtime/component/3rdparty/heimdal-7.5.0/src/heimdal-7.5.0/lib/roken/roken.h.in -o roken.h failed parse: (!defined(HAVE_STRERROR_R) make[1]: *** [roken.h] Error 25 make: *** [all-recursive] Error 1 ..... .... did anyone came across this error? I did find that in the previous versions of Heimdal, roken-h-process.pl was patched. Heimdal - General - x86_64 cross-compile failing on a i686 32 bit system
but I I assume that it was old change and should be already in the newest versions of Heimdal? regards, Alibek |
Free forum by Nabble | Edit this page |