Windows GSSAPI ssh connection via cross-realm authentication problems

Mon Aug 21 17:28:44 EDT 2006

Do you have a .k5login file in the home directory on the
machine with the sshd? It should list the principals that
are allowed to access this unix account.

Note the return codes from the mm_answer_gss_userok is 1 when it
worked, 0 when it did not. So it looks like the gss authenticated you
but the principal was not allowed to use the unix account.

Jason Mogavero wrote:

> Ok, I found part one of my problem, in that on the non-windows KDC I had 
> not
> specified an encryption type and whatever is the default was not working
> with the windows DC.  I've fixed that and I can now get issued tickets by
> the non-windows KDC.  Here is the kdc.log entry for my ticket generation:
> 
> Aug 21 13:59:47 kdcdmz.kdctest.com krb5kdc[29511](info): TGS_REQ (5 etypes
> {23 3 1 24 -135}) 172.16.102.28: ISSUE: authtime 1156189823, etypes {rep=3
> tkt=16 ses=1}, jason.mogavero at KDCTEST.COM for
> host/kdcvps1.kdctest.com at DMZ.KDCTEST.COM
> Aug 21 13:59:47 kdcdmz.kdctest.com krb5kdc[29511](info): TGS_REQ (5 etypes
> {23 3 1 24 -135}) 172.16.102.28: ISSUE: authtime 1156189823, etypes {rep=3
> tkt=16 ses=1}, jason.mogavero at KDCTEST.COM for
> host/kdcvps1.kdctest.com at DMZ.KDCTEST.COM
> 
> However, GSSAPI is still failing.  The logging in PuTTY shows a general 
> SSPI
> failure, but nothing specific other than the ssh server is kicking back a
> reject.  (note that GSSAPI works on a Linux system that connects via 
> openssh
> and is authenticated the the non-windows KDC)
> 
> I ran sshd in debug mode, and compared the output from a rejected GSSAPI
> session and an accepted one.  Here is the accepted:
> 
> Aug 21 14:21:30 kdcvps1 sshd[19893]: debug1: Received some client
> credentials
> Aug 21 14:21:30 kdcvps1 sshd[19893]: debug3: mm_request_send entering: type
> 41
> Aug 21 14:21:30 kdcvps1 sshd[19893]: debug3: mm_request_receive entering
> Aug 21 14:21:30 kdcvps1 sshd[19893]: debug3: monitor_read: checking request
> 44
> Aug 21 14:21:30 kdcvps1 sshd[19893]: debug3: mm_request_send entering: type
> 45
> Aug 21 14:21:30 kdcvps1 sshd[19893]: debug3: mm_request_receive entering
> Aug 21 14:21:30 kdcvps1 sshd[19893]: debug3: monitor_read: checking request
> 42
> Aug 21 14:21:30 kdcvps1 sshd[19893]: Authorized to kdcadmin, krb5 principal
> kdcadmin at DMZ.KDCTEST.COM (krb5_kuserok)
> Aug 21 14:21:30 kdcvps1 sshd[19893]: debug3: mm_answer_gss_userok: sending
> result 1
> Aug 21 14:21:30 kdcvps1 sshd[19893]: debug3: mm_request_send entering: type
> 43
> Aug 21 14:21:30 kdcvps1 sshd[19893]: debug3: mm_request_receive_expect
> entering: type 47
> Aug 21 14:21:30 kdcvps1 sshd[19893]: debug3: mm_request_receive entering
> Aug 21 14:21:31 kdcvps1 sshd[19893]: debug3: PAM: do_pam_account
> pam_acct_mgmt = 0
> Aug 21 14:21:31 kdcvps1 sshd[19893]: debug3: mm_request_send entering: type
> 48
> Aug 21 14:21:31 kdcvps1 sshd[19893]: Accepted gssapi-with-mic for kdcadmin
> from 172.16.102.112 port 32957 ssh2
> 
> And here is the failed one:
> 
> Aug 21 14:01:35 kdcvps1 sshd[19853]: debug1: Received some client
> credentials
> Aug 21 14:01:35 kdcvps1 sshd[19853]: debug3: mm_request_send entering: type
> 41
> Aug 21 14:01:35 kdcvps1 sshd[19853]: debug3: mm_request_receive entering
> Aug 21 14:01:35 kdcvps1 sshd[19853]: debug3: monitor_read: checking request
> 44
> Aug 21 14:01:35 kdcvps1 sshd[19853]: debug3: mm_request_send entering: type
> 45
> Aug 21 14:01:35 kdcvps1 sshd[19853]: debug3: mm_request_receive entering
> Aug 21 14:01:35 kdcvps1 sshd[19853]: debug3: monitor_read: checking request
> 42
> Aug 21 14:01:35 kdcvps1 sshd[19853]: debug3: mm_answer_gss_userok: sending
> result 0
> Aug 21 14:01:35 kdcvps1 sshd[19853]: debug3: mm_request_send entering: type
> 43
> Aug 21 14:01:35 kdcvps1 sshd[19853]: Failed gssapi-with-mic for
> jason.mogavero from 172.16.102.28 port 4292 ssh2
> 
> So it seems that even though I am getting a tgt from the non-Windows KDC, I
> am not being authorized by this "checking request 42" which I imagine 
> checks
> against the non-Win KDC.  I don't need to have every user in the Windows AD
> in the non-Windows KDC user database as well, do I?  I thought the point of
> the one-way trust was to allow users authenticated in one realm to have
> access to resources in another.  Is this an ACL issue?  I have an entry in
> the kadm5.acl file on the non-windows KDC that says:
> 
> *@KDCTEST.COM *
> 
> Is not not correct syntax?
> 
> On 8/18/06, Douglas E. Engert <deengert at anl.gov> wrote:
> 
>>
>>
>>
>> Jason Mogavero wrote:
>>
>> > Hello all,
>> >
>> >    I am implementing a Kerberos/GSSAPI solution in a test environment
>> and I
>> > am experiencing some issues with allowed windows ssh clients to be
>> granted
>> > acess to the ssh server.
>> >
>> > The background:
>> >
>> > Windows AD is primary kdc with realm name KDCTEST.COM and hostname
>> > adauth.kdctest.com
>> > MIT kdc (on CentOS 4.3, installed from rpms) is DMZ.KDCTEST.COM
>> >
>> > ssh server is hostname kdcvps1.kdctest.com
>> > ssh client (linux) is kdcvps2.kdctest.com
>> > windows ssh client is kdctest01.kdctest.com
>> >
>> > I am able to passwordlessly log into the ssh server from the Linux ssh
>> > client via gssapi.  When I connect from PuTTY or SecureCRT in GSSAPI
>> mode,
>> > it fails.  PuTTY prompts me for a password and SecureCRT errors out 
>> with
>> > "All available GSSAPI mechanisms failed"  Here is the kdc.log entry I
>> get:
>>
>> Sounds like the cross realm keys are not setup correctly, i.e. the kvno
>> key or enc types are different in AD and krb KDC for the
>> krbtgt/KDCTEST.COM at DMZ.KDCTEST.COM principal on both sides. You can use
>> mmc
>> and ADSIEdit to look at AD at the acocunt you created for the trust to 
>> see
>> the key version number on 2003.
>>
>> You could use ethereal (wireshark) on Windows to watch the client contact
>> the
>> AD to get a cross realm ticket, then try and use it with the krb KDC to
>> get
>> the service ticket. It would show the kvno and enctypes being used.
>>
>> It could also be the keys don't match, because of the way they where
>> generated from passwords on each side. I assume you used the 2003 ktpass
>> Getting a keytab with the out option could help identify problems too.
>>
>> ---snip--
>> -- 
>>
>>   Douglas E. Engert  <DEEngert at anl.gov>
>>   Argonne National Laboratory
>>   9700 South Cass Avenue
>>   Argonne, Illinois  60439
>>   (630) 252-5444
>>
> 

-- 

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