I'm currently looking at why kinit can not give a decent error message
on the easy fact that a credential has expired. Well, now with 7.4.0
it handles "password expired" but "principal expired" still gives:
kinit: krb5_get_init_creds: No ENC-TS found
which is very broken from a user support grou
It would be nice if someone who actually knows what these functions
do, goes through the krb5_storage(3) manual page and looks at all the
"the storage buffer to write to"
"the storage buffer to write too" (oh, this one, too :-)
"the storage buffer to read from"
text strings and fix so that o
By looking at the code of send_diffs (ipropd_master.c:666) it looks to
me that there somewhere at the beginning of that long function, before
plowing through the log on the master, there should be something like
if (current_version == 0 || s->version == 0){
(...)
return send_complete (...
Well, I' making some progress.
The context I get when krb5_init_creds_get() returns is
$23 = {etypes = 0x0, cfg_etypes = 0x0, etypes_des = 0x0, as_etypes = 0x0,
tgs_etypes = 0x0, permitted_enctypes = 0x0, default_realms = 0x0,
max_skew = 300, kdc_timeout = 30, host_timeout = 3, max_retries
I wrote:
> + strncat(cstr, ", ", sizeof(buf));
> + return strdup(strncat(cstr, str, sizeof(buf)));
which is broken and buggy usage of strncat(), so don't copy that.
Harald.
On Thu, Oct 05, 2017 at 10:37:26AM +0200, Harald Barth wrote:
> I'm currently looking at why kinit can not give a decent error message
> on the easy fact that a credential has expired. Well, now with 7.4.0
> it handles "password expired" but "principal expired" still gives:
>
> kinit: krb5_get_ini
On Thu, Oct 05, 2017 at 10:37:26AM +0200, Harald Barth wrote:
> I'm currently looking at why kinit can not give a decent error message
> on the easy fact that a credential has expired. Well, now with 7.4.0
> it handles "password expired" but "principal expired" still gives:
So, to reproduce just m
On 10/05/2017 07:52 AM, Harald Barth wrote:
> And because the return code ret is the same as the error_code in the
> context, krb5_get_error_message() just copies the string from the
> context. However, if krb5_get_error_message() does its own lookup of
> -1765328383 it gets "Client's entry in data
On October 5, 2017 12:06:51 PM EDT, Greg Hudson wrote:
>On 10/05/2017 07:52 AM, Harald Barth wrote:
>> And because the return code ret is the same as the error_code in the
>> context, krb5_get_error_message() just copies the string from the
>> context. However, if krb5_get_error_message() does its
On Thu, Oct 05, 2017 at 12:06:51PM -0400, Greg Hudson wrote:
> If my theory is correct, the KDC is sending unhelpful e_text and/or
> Heimdal is too trusting in using the e_text in preference to the string
> corresponding to the error code. In this case, concatenating the error
> code string with t
On Thu, Oct 05, 2017 at 12:28:29PM -0400, Jeffrey Hutzelman wrote:
> Both, I think. kinit (and other clients) ought to report something
> like "error_message (e_text)", unless the e_text is empty or the same
> as the message for the error code. of course, more complex variations
> are possible, wha
> I looked for that and couldn't find it.
I may have found it! The 1.5.X KDC has a mile long function
_kdc_as_rep() which in the middle somewhere has
e_text = "No ENC-TS found";
That function looks quite different in 7.X
> So, to reproduce just mark a principal as expired and try to kinit
On Thu, Oct 05, 2017 at 08:01:00PM +0200, Harald Barth wrote:
> I may have found it! The 1.5.X KDC has a mile long function
> _kdc_as_rep() which in the middle somewhere has
>
> e_text = "No ENC-TS found";
Ahh, ok, got it.
Nico
--
13 matches
Mail list logo
