Windows GSSAPI ssh connection via cross-realm authentication problems - Kerberos

This is a discussion on Windows GSSAPI ssh connection via cross-realm authentication problems - Kerberos ; 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 ...

+ Reply to Thread
Results 1 to 11 of 11

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

  1. Windows GSSAPI ssh connection via cross-realm authentication problems

    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:

    Aug 17 15:18:09 kdcdmz.kdctest.com krb5kdc[29511](info): TGS_REQ (5 etypes
    {23 3 1 24 -135}) 172.16.102.28: PROCESS_TGS: authtime 0,
    for host/kdcvps1.kdctest.com@DMZ.KDCTEST.COM, Key table entry not found
    Aug 17 15:18:09 kdcdmz.kdctest.com krb5kdc[29511](info): TGS_REQ (5 etypes
    {23 3 1 24 -135}) 172.16.102.28: PROCESS_TGS: authtime 0,
    for host/kdcvps1.kdctest.com@DMZ.KDCTEST.COM, Key table entry not found

    Here's the ktutil output from the kdc showing that I have keytabs for the
    ssh server. Note that I have no idea why it has so many entries.

    [root@kdcdmz ~]# ktutil
    ktutil: rkt /etc/krb5.keytab
    ktutil: l
    slot KVNO Principal
    ---- ----
    ---------------------------------------------------------------------
    1 3 host/kdcdmz.kdctest.com@DMZ.KDCTEST.COM
    2 3 host/kdcdmz.kdctest.com@DMZ.KDCTEST.COM
    3 4 host/kdcvps1.kdctest.com@DMZ.KDCTEST.COM
    4 4 host/kdcvps1.kdctest.com@DMZ.KDCTEST.COM
    5 3 host/kdcvps1.kdctest.com@DMZ.KDCTEST.COM
    6 3 host/kdcvps1.kdctest.com@DMZ.KDCTEST.COM
    7 3 host/kdcdmz.kdctest.com@DMZ.KDCTEST.COM
    8 3 host/kdcdmz.kdctest.com@DMZ.KDCTEST.COM
    9 4 host/kdcvps1.kdctest.com@DMZ.KDCTEST.COM
    10 4 host/kdcvps1.kdctest.com@DMZ.KDCTEST.COM
    11 5 host/kdcvps1.kdctest.com@DMZ.KDCTEST.COM
    12 5 host/kdcvps1.kdctest.com@DMZ.KDCTEST.COM
    13 3 host/kdcdmz.kdctest.com@DMZ.KDCTEST.COM
    14 3 host/kdcdmz.kdctest.com@DMZ.KDCTEST.COM
    15 3 host/kdcdmz.kdctest.com@DMZ.KDCTEST.COM
    16 3 host/kdcdmz.kdctest.com@DMZ.KDCTEST.COM
    17 4 host/kdcvps1.kdctest.com@DMZ.KDCTEST.COM
    18 4 host/kdcvps1.kdctest.com@DMZ.KDCTEST.COM
    19 5 host/kdcvps1.kdctest.com@DMZ.KDCTEST.COM
    20 5 host/kdcvps1.kdctest.com@DMZ.KDCTEST.COM

    The keytab from the ssh server:

    [root@kdcvps1 pam-krb5-2.0]# ktutil
    ktutil: rkt /etc/krb5.keytab
    ktutil: l
    slot KVNO Principal
    ---- ----
    ---------------------------------------------------------------------
    1 6 host/kdcvps1.kdctest.com@DMZ.KDCTEST.COM
    2 6 host/kdcvps1.kdctest.com@DMZ.KDCTEST.COM

    Listing the keytabs in kadmin shows matching encryption types. Here's my
    /etc/krb5.conf file from the kdc:

    [root@kdcdmz ~]# more /etc/krb5.conf
    [logging]
    kdc = FILE:/var/kerberos/krb5kdc/kdc.log
    admin_server = FILE:/var/kerberos/krb5kdc/kadmin.log

    [libdefaults]
    default_realm = DMZ.KDCTEST.COM
    dns_lookup_realm = false
    dns_lookup_kdc = false

    [kdc]
    profile = /var/kerberos/krb5kdc/kdc.conf

    [appdefaults]
    pam = {
    [root@kdcdmz ~]# cat /etc/krb5.conf
    [logging]
    kdc = FILE:/var/kerberos/krb5kdc/kdc.log
    admin_server = FILE:/var/kerberos/krb5kdc/kadmin.log

    [libdefaults]
    default_realm = DMZ.KDCTEST.COM
    dns_lookup_realm = false
    dns_lookup_kdc = false

    [kdc]
    profile = /var/kerberos/krb5kdc/kdc.conf

    [appdefaults]
    pam = {
    debug = false
    ticket_lifetime = 36000
    renew_lifetime = 36000
    forwardable = true
    krb4_convert = false
    }

    [realms]
    DMZ.KDCTEST.COM = {
    kdc = kdcdmz.kdctest.com:88
    admin_server = kdcdmz.kdctest.com:749
    }

    KDCTEST.COM = {
    kdc = adauth.kdctest.com:88

    }

    [domain_realm]
    kdctest01.kdctest.com = KDCTEST.COM
    .kdctest.com = DMZ.KDCTEST.COM
    kdctest.com = DMZ.KDCTEST.COM


    I am thinking that this is some problem with the cross realm
    auththentication, but I've created the principals in the Linux kdc for the
    cross-realm trust and configured it on the Windows2003 side via a one-way
    domain trust. (tickets issued in the AD are trusted in the linux kdc) I'm
    using NetIDMgr to manage the windows tickets.

    Here's the list of principals on the linux side:
    kadmin: listprincs
    K/M@DMZ.KDCTEST.COM
    admin/admin@DMZ.KDCTEST.COM
    host/kdcvps1.kdctest.com@DMZ.KDCTEST.COM
    host/kdcvps1@DMZ.KDCTEST.COM
    jason.mogavero@DMZ.KDCTEST.COM
    kadmin/admin@DMZ.KDCTEST.COM
    kadmin/changepw@DMZ.KDCTEST.COM
    kadmin/history@DMZ.KDCTEST.COM
    kdcadmin/admin@DMZ.KDCTEST.COM
    kdcadmin@DMZ.KDCTEST.COM
    krbtgt/DMZ.KDCTEST.COM@DMZ.KDCTEST.COM
    krbtgt/DMZ.KDCTEST.COM@KDCTEST.COM
    krbtgt/KDCTEST.COM@DMZ.KDCTEST.COM

    On the windows side, I've used ksetup.exe to configure both realms. Here's
    the output:

    C:\Documents and Settings\Administrator.ADAUTH>ksetup
    default realm = kdctest.com (NT Domain)
    DMZ.KDCTEST.COM:
    kdc = kdcdmz.kdctest.com
    Realm Flags = 0x0 none
    KDCTEST.COM:
    kdc = adauth.kdctest.com
    Realm Flags = 0x6 TcpSupported Delegate
    Mapping all users (*) to a local account by the same name (*).

    I've checked "allow des encryption" and "account is trusted for delegation"
    in the AD user manager for the user I am connecting as. I've also allowed
    the windows ssh client computer to be trusted for delegation. I'm pretty
    sure the cross-realm part is working because, in Windows, I am issued a tgt
    for the linux kdc. (krbtgt/DMZ.KDCTEST.COM@KDCTEST.COM)

    So tell me, what am I missing? The windows username is not being
    propagated, linux kdc reads it as and it is reporting that
    the ssh server has no keytab, which is does. (because it works on a linux
    ssh connection) Any point in the right direction would be great.
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  2. Re: Windows GSSAPI ssh connection via cross-realm authenticationproblems

    A "klist -k -e" on the server keytab would be useful.

  3. Re: Windows GSSAPI ssh connection via cross-realm authenticationproblems



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


    >
    > Aug 17 15:18:09 kdcdmz.kdctest.com krb5kdc[29511](info): TGS_REQ (5 etypes
    > {23 3 1 24 -135}) 172.16.102.28: PROCESS_TGS: authtime 0,
    > for host/kdcvps1.kdctest.com@DMZ.KDCTEST.COM, Key table entry not found
    > Aug 17 15:18:09 kdcdmz.kdctest.com krb5kdc[29511](info): TGS_REQ (5 etypes
    > {23 3 1 24 -135}) 172.16.102.28: PROCESS_TGS: authtime 0,
    > for host/kdcvps1.kdctest.com@DMZ.KDCTEST.COM, Key table entry not found
    >
    > Here's the ktutil output from the kdc showing that I have keytabs for the
    > ssh server. Note that I have no idea why it has so many entries.
    >
    > [root@kdcdmz ~]# ktutil
    > ktutil: rkt /etc/krb5.keytab
    > ktutil: l
    > slot KVNO Principal
    > ---- ----
    > ---------------------------------------------------------------------
    > 1 3 host/kdcdmz.kdctest.com@DMZ.KDCTEST.COM
    > 2 3 host/kdcdmz.kdctest.com@DMZ.KDCTEST.COM
    > 3 4 host/kdcvps1.kdctest.com@DMZ.KDCTEST.COM
    > 4 4 host/kdcvps1.kdctest.com@DMZ.KDCTEST.COM
    > 5 3 host/kdcvps1.kdctest.com@DMZ.KDCTEST.COM
    > 6 3 host/kdcvps1.kdctest.com@DMZ.KDCTEST.COM
    > 7 3 host/kdcdmz.kdctest.com@DMZ.KDCTEST.COM
    > 8 3 host/kdcdmz.kdctest.com@DMZ.KDCTEST.COM
    > 9 4 host/kdcvps1.kdctest.com@DMZ.KDCTEST.COM
    > 10 4 host/kdcvps1.kdctest.com@DMZ.KDCTEST.COM
    > 11 5 host/kdcvps1.kdctest.com@DMZ.KDCTEST.COM
    > 12 5 host/kdcvps1.kdctest.com@DMZ.KDCTEST.COM
    > 13 3 host/kdcdmz.kdctest.com@DMZ.KDCTEST.COM
    > 14 3 host/kdcdmz.kdctest.com@DMZ.KDCTEST.COM
    > 15 3 host/kdcdmz.kdctest.com@DMZ.KDCTEST.COM
    > 16 3 host/kdcdmz.kdctest.com@DMZ.KDCTEST.COM
    > 17 4 host/kdcvps1.kdctest.com@DMZ.KDCTEST.COM
    > 18 4 host/kdcvps1.kdctest.com@DMZ.KDCTEST.COM
    > 19 5 host/kdcvps1.kdctest.com@DMZ.KDCTEST.COM
    > 20 5 host/kdcvps1.kdctest.com@DMZ.KDCTEST.COM
    >
    > The keytab from the ssh server:
    >
    > [root@kdcvps1 pam-krb5-2.0]# ktutil
    > ktutil: rkt /etc/krb5.keytab
    > ktutil: l
    > slot KVNO Principal
    > ---- ----
    > ---------------------------------------------------------------------
    > 1 6 host/kdcvps1.kdctest.com@DMZ.KDCTEST.COM
    > 2 6 host/kdcvps1.kdctest.com@DMZ.KDCTEST.COM
    >
    > Listing the keytabs in kadmin shows matching encryption types. Here's my
    > /etc/krb5.conf file from the kdc:
    >
    > [root@kdcdmz ~]# more /etc/krb5.conf
    > [logging]
    > kdc = FILE:/var/kerberos/krb5kdc/kdc.log
    > admin_server = FILE:/var/kerberos/krb5kdc/kadmin.log
    >
    > [libdefaults]
    > default_realm = DMZ.KDCTEST.COM
    > dns_lookup_realm = false
    > dns_lookup_kdc = false
    >
    > [kdc]
    > profile = /var/kerberos/krb5kdc/kdc.conf
    >
    > [appdefaults]
    > pam = {
    > [root@kdcdmz ~]# cat /etc/krb5.conf
    > [logging]
    > kdc = FILE:/var/kerberos/krb5kdc/kdc.log
    > admin_server = FILE:/var/kerberos/krb5kdc/kadmin.log
    >
    > [libdefaults]
    > default_realm = DMZ.KDCTEST.COM
    > dns_lookup_realm = false
    > dns_lookup_kdc = false
    >
    > [kdc]
    > profile = /var/kerberos/krb5kdc/kdc.conf
    >
    > [appdefaults]
    > pam = {
    > debug = false
    > ticket_lifetime = 36000
    > renew_lifetime = 36000
    > forwardable = true
    > krb4_convert = false
    > }
    >
    > [realms]
    > DMZ.KDCTEST.COM = {
    > kdc = kdcdmz.kdctest.com:88
    > admin_server = kdcdmz.kdctest.com:749
    > }
    >
    > KDCTEST.COM = {
    > kdc = adauth.kdctest.com:88
    >
    > }
    >
    > [domain_realm]
    > kdctest01.kdctest.com = KDCTEST.COM
    > .kdctest.com = DMZ.KDCTEST.COM
    > kdctest.com = DMZ.KDCTEST.COM
    >
    >
    > I am thinking that this is some problem with the cross realm
    > auththentication, but I've created the principals in the Linux kdc for the
    > cross-realm trust and configured it on the Windows2003 side via a one-way
    > domain trust. (tickets issued in the AD are trusted in the linux kdc) I'm
    > using NetIDMgr to manage the windows tickets.
    >
    > Here's the list of principals on the linux side:
    > kadmin: listprincs
    > K/M@DMZ.KDCTEST.COM
    > admin/admin@DMZ.KDCTEST.COM
    > host/kdcvps1.kdctest.com@DMZ.KDCTEST.COM
    > host/kdcvps1@DMZ.KDCTEST.COM
    > jason.mogavero@DMZ.KDCTEST.COM
    > kadmin/admin@DMZ.KDCTEST.COM
    > kadmin/changepw@DMZ.KDCTEST.COM
    > kadmin/history@DMZ.KDCTEST.COM
    > kdcadmin/admin@DMZ.KDCTEST.COM
    > kdcadmin@DMZ.KDCTEST.COM
    > krbtgt/DMZ.KDCTEST.COM@DMZ.KDCTEST.COM
    > krbtgt/DMZ.KDCTEST.COM@KDCTEST.COM
    > krbtgt/KDCTEST.COM@DMZ.KDCTEST.COM
    >
    > On the windows side, I've used ksetup.exe to configure both realms. Here's
    > the output:
    >
    > C:\Documents and Settings\Administrator.ADAUTH>ksetup
    > default realm = kdctest.com (NT Domain)
    > DMZ.KDCTEST.COM:
    > kdc = kdcdmz.kdctest.com
    > Realm Flags = 0x0 none
    > KDCTEST.COM:
    > kdc = adauth.kdctest.com
    > Realm Flags = 0x6 TcpSupported Delegate
    > Mapping all users (*) to a local account by the same name (*).
    >
    > I've checked "allow des encryption" and "account is trusted for delegation"
    > in the AD user manager for the user I am connecting as. I've also allowed
    > the windows ssh client computer to be trusted for delegation. I'm pretty
    > sure the cross-realm part is working because, in Windows, I am issued a tgt
    > for the linux kdc. (krbtgt/DMZ.KDCTEST.COM@KDCTEST.COM)
    >
    > So tell me, what am I missing? The windows username is not being
    > propagated, linux kdc reads it as and it is reporting that
    > the ssh server has no keytab, which is does. (because it works on a linux
    > ssh connection) Any point in the right direction would be great.
    > ________________________________________________
    > Kerberos mailing list Kerberos@mit.edu
    > https://mailman.mit.edu/mailman/listinfo/kerberos
    >
    >


    --

    Douglas E. Engert
    Argonne National Laboratory
    9700 South Cass Avenue
    Argonne, Illinois 60439
    (630) 252-5444
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  4. Re: Windows GSSAPI ssh connection via cross-realm authenticationproblems

    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@KDCTEST.COM for
    host/kdcvps1.kdctest.com@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@KDCTEST.COM for
    host/kdcvps1.kdctest.com@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@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 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@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
    > Argonne National Laboratory
    > 9700 South Cass Avenue
    > Argonne, Illinois 60439
    > (630) 252-5444
    >

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


  5. Re: Windows GSSAPI ssh connection via cross-realm authenticationproblems

    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@KDCTEST.COM for
    > host/kdcvps1.kdctest.com@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@KDCTEST.COM for
    > host/kdcvps1.kdctest.com@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@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 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@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
    >> Argonne National Laboratory
    >> 9700 South Cass Avenue
    >> Argonne, Illinois 60439
    >> (630) 252-5444
    >>

    >


    --

    Douglas E. Engert
    Argonne National Laboratory
    9700 South Cass Avenue
    Argonne, Illinois 60439
    (630) 252-5444
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  6. Re: Windows GSSAPI ssh connection via cross-realm authenticationproblems

    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 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@KDCTEST.COM for
    > > host/kdcvps1.kdctest.com@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@KDCTEST.COM for
    > > host/kdcvps1.kdctest.com@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@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 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@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
    > >> Argonne National Laboratory
    > >> 9700 South Cass Avenue
    > >> Argonne, Illinois 60439
    > >> (630) 252-5444
    > >>

    > >

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

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


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

    "Jason Mogavero" writes:

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


    In the absence of a .k5login file, you will be granted access if the
    result of krb5_aname_to_localname on the principal name is equal to the
    local account. In practice, this means that the Kerberos principal has to
    be in the default local realm. If it's not, you either need to create a
    ..k5login file or you need to set up an aname_to_localname mapping in your
    krb5.conf file that does what you want.

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


    I think the cross-realm issues are what are getting you here.

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


    kadm5.acl *only* controls access to run kadmin commands. It has nothing
    to do with authorization to log in to accounts and SSH never has anything
    to do with it.

    --
    Russ Allbery (rra@stanford.edu)

  8. Re: Windows GSSAPI ssh connection via cross-realm authenticationproblems



    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 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 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@KDCTEST.COM for
    >> > > host/kdcvps1.kdctest.com@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@KDCTEST.COM for
    >> > > host/kdcvps1.kdctest.com@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@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 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@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
    >> > >> Argonne National Laboratory
    >> > >> 9700 South Cass Avenue
    >> > >> Argonne, Illinois 60439
    >> > >> (630) 252-5444
    >> > >>
    >> > >
    >> >
    >> > --
    >> >
    >> > Douglas E. Engert
    >> > Argonne National Laboratory
    >> > 9700 South Cass Avenue
    >> > Argonne, Illinois 60439
    >> > (630) 252-5444
    >> >

    >>
    >>

    >


    --

    Douglas E. Engert
    Argonne National Laboratory
    9700 South Cass Avenue
    Argonne, Illinois 60439
    (630) 252-5444
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  9. Re: Windows GSSAPI ssh connection via cross-realm authenticationproblems



    Jason Mogavero 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)


    That is the default if no ~/.k5login is found. i.e. user@realm where user
    matches the unix account name, and realm is the default realm of the machine.

    It is easy to see if this is the problem, add a .k5login file. If that works,
    then you can address how to get alongf without it.


    >
    > 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 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@KDCTEST.COM for
    >> > host/kdcvps1.kdctest.com@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@KDCTEST.COM for
    >> > host/kdcvps1.kdctest.com@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@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 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@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
    >> >> Argonne National Laboratory
    >> >> 9700 South Cass Avenue
    >> >> Argonne, Illinois 60439
    >> >> (630) 252-5444
    >> >>
    >> >

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

    >


    --

    Douglas E. Engert
    Argonne National Laboratory
    9700 South Cass Avenue
    Argonne, Illinois 60439
    (630) 252-5444
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  10. Re: Windows GSSAPI ssh connection via cross-realm authenticationproblems

    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 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 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@KDCTEST.COM for
    > > > host/kdcvps1.kdctest.com@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@KDCTEST.COM for
    > > > host/kdcvps1.kdctest.com@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@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 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@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
    > > >> Argonne National Laboratory
    > > >> 9700 South Cass Avenue
    > > >> Argonne, Illinois 60439
    > > >> (630) 252-5444
    > > >>
    > > >

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

    >
    >

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


  11. Re: Windows GSSAPI ssh connection via cross-realm authenticationproblems

    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@B.EXAMPLE.COM". The question that then must be answered is this:

    Is name@B.EXAMPLE.COM 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 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 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@KDCTEST.COM for
    >>>> host/kdcvps1.kdctest.com@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@KDCTEST.COM for
    >>>> host/kdcvps1.kdctest.com@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@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 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@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
    >>>>> Argonne National Laboratory
    >>>>> 9700 South Cass Avenue
    >>>>> Argonne, Illinois 60439
    >>>>> (630) 252-5444
    >>>>>
    >>> --
    >>>
    >>> Douglas E. Engert
    >>> Argonne National Laboratory
    >>> 9700 South Cass Avenue
    >>> Argonne, Illinois 60439
    >>> (630) 252-5444
    >>>

    >>

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


+ Reply to Thread