Windows GSSAPI ssh connection via cross-realm authentication problems

Douglas E. Engert deengert at anl.gov
Mon Aug 21 18:36:33 EDT 2006



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.

Good.

> 
> 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.

Its not the non-windows KDC that is that needs to have trust, it will
issues a ticket to any user in the cross realm. It only authenticates.
Its the local machine that needs to accepts the authentication, then
authorize the use of the local account. the ~/.k5login is an ACL for the
account.

> Any suggestions as to how I might approach this?

replace the krb5_userok routine with your own on each client. Since Windows
also adds a PAC in the ticket, which has group info, you might be able
to use that for some authorization decisions, looking for the support rep
group, using some local unix account.


> 
> 
> 
> On 8/21/06, Jason Mogavero <chemhead at gmail.com> 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 at anl.gov> 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 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
>> >
>>
>>
> 

-- 

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



More information about the Kerberos mailing list