Fwd: krbdev Digest, Vol 186, Issue 6

Joshua Acosta joshuacosta6 at gmail.com
Mon Oct 8 07:25:45 EDT 2018


Hi Greg,

About 1. Re: krbdev Digest, Vol 186, Issue 4 (Joshua Acosta)
We finally found the problem in the protocol and we think that's is a
problem in the code on "leash dll".

Remembering the problem: we had a failed authentification with users that
we force a password change. If the change is through command line all works
fine but if we use the api leask_kinit it doesn't.

Studing we found a new important info: the new password defined -that the
user knows and must introduce, after system ask for a new one- have minus
characters than the max limit (in our case new password was 6 and the size
limit is 8). This is the problem.

The password entered by the user (6 characters) always obtain a wrong
validation by zOS system, of course, if we defined a password with a size
of 8 charcters all works fine (and this is what we do now). We supose that
somezing is wrong, like a dummy character, in the password sending to zOs.

And we have a last question: is possible to change the language of the
window thats shows in the execution of leask_kinit when the password is
expierd? Like in Linux, with parameters in krb5.ini (parameters that we not
found), or, maybe is more simple, is possible to avoid that this windows
appears?.

Regardless, thanks in advance.

Joshua


---------- Forwarded message ---------
From: Joshua Acosta <joshuacosta6 at gmail.com>
Date: mié., 11 jul. 2018 a las 17:38
Subject: Re: krbdev Digest, Vol 186, Issue 6
To: <krbdev at mit.edu>


Hi Greg,

I'm very sorry for delay. We have been retrieving the most cleary
information that we can offer to you.

Let's go.

- The environment
  =============
  PC with Kerberos for Windows 4.1 & IBM Host ZOs
  Account in IBM Host with password expiration


- First test
  =======
  kinit with comand, result OK

The commands are:
c:\program files\mit\kerberos\bin\kinit it00046 at PGME.DESE
Password for it00046 at PGME.DESE:
Password expired. You must change it now.
Enter new password:

The behaviour is OK.

The info that offers WireShark is:

1 Computer -> Host: AS-REQ
2 Host -> Computer: KRB Error: KRB5KDC_ERR_KEY_EXP
3 Computer -> Host: AS-REQ
4 Host -> Computer: KRB Error: KRB5KDC_ERR_PREAUTH_FAILED
5 Computer -> Host: AS-REQ
6 Host -> Computer: KRB Error: KRB5KDC_ERR_PREAUTH_REQUIRED
7 Computer -> Host: AS-REQ
8 Host -> Computer: AS-REP

The steps 1-6 ocurrs when we do "kinit it00046 at PGME.DESE".
Steps 7-8 at "Password for ...".


The ZOs debug's info at point 7/8 (AS-REQ/AS-REP) is:

 180711 13:51:07 (00000001) DBG8 KRB/KRB_CRYPTO k5_aes_decrypt(): Software
AES256 decryption performed for 44 bytes
 180711 13:51:07 (00000001) DBG1 KRB/KRB_GENERAL krb5_c_decrypt_int(): <--
krb5_c_decrypt_int(1): Status 0x0
 180711 13:51:07 (00000001) DBG1 KRB/KRB_GENERAL krb5_c_make_random_key():
--> krb5_c_make_random_key(): Enctype 18
 180711 13:51:07 (00000001) DBG1 KRB/KRB_GENERAL
crypto_generate_random_bytes(): --> crypto_generate_random_bytes(): Length
32
 180711 13:51:07 (00000001) DBG1 KRB/KRB_GENERAL
crypto_generate_random_bytes(): <-- crypto_generate_random_bytes(1): Status
0x0
 180711 13:51:07 (00000001) DBG1 KRB/KRB_GENERAL krb5_c_make_random_key():
<-- krb5_c_make_random_key(1): Status 0x0
 180711 13:51:07 (00000001) DBG1 KRB/KRB_GENERAL krb5_c_encrypt_length():
--> krb5_c_encrypt_length(): Enctype 18, Length 166
 180711 13:51:07 (00000001) DBG1 KRB/KRB_GENERAL krb5_c_encrypt_length():
<-- krb5_c_encrypt_length(1): Status 0x0, Encrypted length
 180711 13:51:07 (00000001) DBG1 KRB/KRB_GENERAL krb5_c_encrypt_int(): -->
krb5_c_encrypt_int(): Enctype 18, Usage 2, Length 166
... <very more lines but all ok>


- Second test
  =========
  kinit with leash_kinit, result KO

Code program:

result = Leash_kinit((char *)User.c_str(), (char *)Password.c_str(),
(int)P_LifeTime);

WireShark info's:

1 Computer -> Host: AS-REQ
2 Host -> Computer: KRB Error: KRB5KDC_ERR_KEY_EXP
3 Computer -> Host: AS-REQ
4 Host -> Computer: KRB Error: KRB5KDC_ERR_PREAUTH_FAILED
5 Computer -> Host: AS-REQ
6 Host -> Computer: KRB Error: KRB5KDC_ERR_PREAUTH_REQUIRED
7 Computer -> Host: AS-REQ
8 Host -> Computer: KRB Error: KRB5KDC_ERR_PREAUTH_FAILED (!)


The ZOs debug's info at point 7/8 (AS-REQ with preauth fail) is:

180711 13:51:56 (00000001) DBG8 KRB/KRB_CRYPTO k5_aes_decrypt(): Software
AES256 decryption performed for 44 bytes
180711 13:51:56 (00000001) DBG1 KRB/KRB_GENERAL krb5_c_decrypt_int(): <--
krb5_c_decrypt_int(1): Status 0x96c73a1f (!)
 180711 13:51:56 (00000001) DBG6 KDC/KRB_KDC kdc_preauth_timestamp():
PREAUTH: krb5_c_decrypt_int() failed: Status 0x96c73a1f
 180711 13:51:56 (00000001) DBG6 KDC/KRB_KDC kdc_as_process_request():
AS_REQ: kdc_preauth_process_padata() failed: Status 0x18
 180711 13:51:56 (00000001) DBG8 KDC/KRB_KDC kdc_audit_login(): RACF: Audit
AS_REQ for pg807002: Function 2
 EUVF04039W Kerberos login failed for pg807002 at PGME.DESE at
10.120.232.18:63980: KDC status 0x96c73a18 - Preauthentication failed.
 180711 13:51:56 (00000001) DBG1 KDC/KRB_KDC kdc_as_process_request():
AS_REQ: KDC error 24 processing request from pg807002 at PGME.DES


Do you think that leash_kinit make a bad encryptation in the AS-REQ?, maybe
a problem with timestamp?.

More info: the only diference that we have found in the conversation
between the partners is that in "ok case", at first AS-REQ (point 1), the
kdc-options are "renewable-ok", in the wrong case are
"forwardable,renewable". The rest are exactly equal.



Thanks in advance.
Josep Maria.


El mar., 19 jun. 2018 a las 18:00, <krbdev-request at mit.edu> escribió:

> Send krbdev mailing list submissions to
>         krbdev at mit.edu
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://mailman.mit.edu/mailman/listinfo/krbdev
> or, via email, send a message with subject or body 'help' to
>         krbdev-request at mit.edu
>
> You can reach the person managing the list at
>         krbdev-owner at mit.edu
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of krbdev digest..."
>
>
> Today's Topics:
>
>    1. Re: obscured error code (was Re: krbdev Digest, Vol 186,
>       Issue 4) (Greg Hudson)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 18 Jun 2018 12:25:58 -0400
> From: Greg Hudson <ghudson at mit.edu>
> Subject: Re: obscured error code (was Re: krbdev Digest, Vol 186,
>         Issue 4)
> To: Joshua Acosta <joshuacosta6 at gmail.com>, krbdev at mit.edu
> Message-ID: <39b95f13-4992-75d3-7aff-e575450cebf9 at mit.edu>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> On 06/18/2018 07:21 AM, Joshua Acosta wrote:
> > The problem that we have is when we demand a ticket TGT of a user that is
> > in "renewal state", the function leash_kinit doesn't inform about this
> > situacion, that has a return code KRB5KDC_ERR_KEY_EXP, instead of this
> > value the code returned is KRB5KDC_ERR_PREAUTH_FAILED.
> >
> > We are "sniffing" the conversation between client and Host IBM and can
> see
> > that the error of key expired is fired, but is hiding by the next error:
> > preauth fail.
>
> Can you share more details of the packet trace?  I do not know
> immediately know why the exchange would not end at the
> KRB5KDC_ERR_KEY_EXP response and yield that error code.
>
>
> ------------------------------
>
> _______________________________________________
> krbdev mailing list
> krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
>
>
> End of krbdev Digest, Vol 186, Issue 6
> **************************************
>


More information about the krbdev mailing list