Problem with MIT Kerberos v1.4, OpenSSH 3.9p1 and Active Directory

[Douglas E. Engert]

Sam Evans wrote:

> -SNIP-
> 
>>Do you have any more of the sshd trace?
>>
> 
> 
> I do.  Here is the trace from start to finish (using sshd -ddd):
> 
> -- START --
> debug2: input_userauth_request: try method keyboard-interactive
> debug1: keyboard-interactive devs
> debug1: auth2_challenge: user=testuser devs=
> debug1: kbdint_alloc: devices 'pam'
> debug2: auth2_challenge_start: devices pam
> debug2: kbdint_next_device: devices <empty>
> debug1: auth2_challenge_start: trying authentication method 'pam'
> debug3: mm_sshpam_init_ctx
> debug3: mm_request_send entering: type 46
> debug3: monitor_read: checking request 46
> debug3: mm_answer_pam_init_ctx
> debug3: mm_request_send entering: type 47
> debug3: mm_request_receive entering
> debug3: mm_sshpam_init_ctx: waiting for MONITOR_ANS_PAM_INIT_CTX
> debug3: mm_request_receive_expect entering: type 47
> debug3: mm_request_receive entering
> debug3: mm_sshpam_init_ctx: pam_init_ctx failed
> Failed keyboard-interactive for testuser from 10.104.40.162 port 33336 ssh2
> debug1: userauth-request for user testuser service ssh-connection
> method password
> debug1: attempt 5 failures 5
> debug2: input_userauth_request: try method password
> debug3: mm_auth_password entering
> debug3: mm_request_send entering: type 10
> debug3: monitor_read: checking request 10
> debug1: temporarily_use_uid: 500/500 (e=0/0)
> debug3: mm_auth_password: waiting for MONITOR_ANS_AUTHPASSWORD
> debug3: mm_request_receive_expect entering: type 11
> debug3: mm_request_receive entering
> debug1: restore_uid: 0/0
> debug1: Kerberos password authentication failed: ASN.1 encoding ended
> unexpectedly
> debug1: krb5_cleanup_proc called
> debug3: mm_answer_authpassword: sending result 0
> debug3: mm_request_send entering: type 11
> debug3: mm_auth_password: user not authenticated
> Failed password for testuser from 10.104.40.162 port 33336 ssh2
> Failed password for testuser from 10.104.40.162 port 33336 ssh2
> debug3: mm_request_receive entering
> Connection closed by 10.104.40.162
> debug1: Calling cleanup 0x806d410(0x0)
> debug1: Calling cleanup 0x8060f88(0x8090c50)
> debug1: krb5_cleanup_proc called
> 
> -- END --
> 
> 
> 
>>Sounds like a big ticket problem.  We have seen problems with AFS
>>(which has been reported and fixed in the CVS) when the ticket is big.
>>
>>I have not seen this, and just did a test with my 2003 AD user which
>>is in too many groups. It worked fine with OpenSSH-3.9p1 with MIT krb5-1.4
>>running on Solaris. But maybe my test user is not in enough groups to cause
>>this problem.
>>
> 
> 
> I think this is exactly what is happening.  We have some users who are
> members of hundreds of groups (don't ask me why, long overdrawn story)
> which is likely causing the problem.

Hundreds? Thats more then test user I was using, it only has about 50.

> 
> 
> 
>>The OpenSSH may be finding an older krb5 shared library, that has problems.
>>Does it also have PAM? Is the pam_krb5 loading an old Kerberos?
>>
>>Does "ldd sshd" show that all new krb5 libs are being used?
> 
> 
> Yes, it is pointing to the MIT Kerberos v1.4 library, so all should be
> good there.
>

See if you can run the sshd without using PAM. Either remove
the pam_krb5 from the ppam.conf for SSH or set in the sshd_config UsePAM no.

It might be that the pam_krb5 was linked against a different
version of the kerberos libs, and some how the two versions
are getting combined.

Its an easy test and could rule out conflicts of libs.

> 
>>If you run Ethereal, how big is the bad ticket vs the good ticket.
>>
> 
> 
> The bad ticket appears about about ~70 bytes larger than the working
> one.  With an additional 2 continuation packets as compared to the 1
> continuation for the working ticket.
> 
> I think it is likely the same issue that you ran into with large
> ticket sizes. 

The problem I ran it to was with AFS, not OpenSSH. It was in the AFS RX
protocol. OpenSSH has in packet.c:  max_packet_size = 32768 by default,
but looks like session.c can let the client set the size. But
I don't see the OpenSSH client changing this.


  Perhaps I will try the version of OpenSSH that's
> currently in CVS.
> 
> Thanks for your help!
> 
> -Sam
> 
> 
> 

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444