Re: Windows GSSAPI ssh connection via cross-realm authentication problems

Jason:

I think you misunderstand the role of Kerberos here. Kerberos is being
using to authenticate the user by name. If the SSH service is in realm
"A.EXAMPLE.COM" and the user is in realm "B.EXAMPLE.COM", the after
successful authentication the SSH service knows the name as something
like "name@xxxxxxxxxxxxx". The question that then must be answered is this:

Is name@xxxxxxxxxxxxx authorized to access this account on this
machine?

The answer to that question is an authorization decision and it is made
independently of the KDCs for A.EXAMPLE.COM. The default method
provided in the Kerberos libraries is to perform a lookup in a file
~/.k5login to see if the authenticated name is listed. You can replace
this mechanism with one of your own choosing but it requires that the
Kerberos function krb5_kuserok() not be used to make the authorization
decision by the application.

Jeffrey Altman


Jason Mogavero wrote:
Ok, I should note that adding a .k5login file to the home directory of the
user I want to log in as did work. However, this setup won't work for us in
the long run.

The ultimate goal is to have tech support reps be able to ssh into our
multitude of hosted web servers to perform basic troubleshooting, but we
have hundreds of servers and cannot reasonable manage that many local
databases. The idea is to use sudo for priveleges (via sudo's LDAP
support) and kerberos for authentication. Control over the user database
needs to lie entirely within the AD, hence the need for authentication
without the .k5login files. The non-Windows KDC needs to trust any user
with Windows kerberos tickets, regardless of presence of a local account.
Any suggestions as to how I might approach this?



On 8/21/06, Jason Mogavero <chemhead@xxxxxxxxx> wrote:
There is no .k5login file in the home directory...though the user account
does exist on the machine, eventually the user database is going be stored
on LDAP and there will not be individual user accounts on the ssh servers.


Shouldn't the ACL take precedence anyway? I don't have a .k5login in the
kdcadmin user's home directory and that one can authenticate just fine.
(albeit from a ticket granted by the non-windows kdc and not the AD and the
kdcadmin user principal is in the non-windows kerberos database)

Is there some blanket way of telling the non-Windows kerberos service to
authenticate any principle @KDCTEST.COM? (the Windows KDC) I thought
the kadm5.acl would allow me to do that.




On 8/21/06, Douglas E. Engert <deengert@xxxxxxx> wrote:
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@xxxxxxxxxxx for
host/kdcvps1.kdctest.com@xxxxxxxxxxxxxxx
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@xxxxxxxxxxx for
host/kdcvps1.kdctest.com@xxxxxxxxxxxxxxx

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@xxxxxxxxxxxxxxx (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@xxxxxxx> 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@xxxxxxxxxxxxxxx principal on both sides. You can
use
mmc
and ADSIEdit to look at AD at the aco*** 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@xxxxxxx>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444

--

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


________________________________________________
Kerberos mailing list Kerberos@xxxxxxx
https://mailman.mit.edu/mailman/listinfo/kerberos

.