Client: Windows XP pro, in an AD 2003 domain, running SecureCRT 4.1.11. I've also got MIT Kerberos for Windows installed on the client, and Leash shows that my tickets ARE forwardable. Server: Solaris 8 Sparc server, with MIT Kerberos (krb5-1.4.1), and OpenSSH 4.0p1. I've created two AD accounts, and extracted keys mapped to "host/hostname.domainname.com at REALM.COM" and "ssh/hostname.domainname.com at REALM.COM" and installed them into /etc/krb5.keytab. I can login to the server just fine - GSSAPI-with-mic authentication works fine. But when I "klist" after logging in, I have no tickets. So... is this supposed to work? Should my tickets get forwarded? If not, is there a patch that would make this work? Any help would be appreciated... I can provide server-side debug traces if it'll help, but I really just need to know if tgt-forwarding is supposed to work in OpenSSH 4.0... -Simon
Hi, Simon. On Tue, 10 May 2005, Simon Gales wrote:> So... is this supposed to work? Should my tickets get forwarded? If not, > is there a patch that would make this work?I can verify that TGT forwarding certainly works between openssh client and server. I've been using it extensievly with openssh 4.0p1 linked to a heimdal-based GSSAPI impl. I see a similar problems here but with PuTTY modified to use SSPI for gssapi-with-mic. It too is in an AD 2003 realm. One thing I thought of that could stop delegation is if the target host has not been flagged as 'Trusted for delgation' in AD, as SSPI will silently ignore the request to delegate when the service ticket doesn't have the 'ok to delegate' flag. But, kerbtray.exe (from the windows reskit) and some ethereal traces show this isn't the problem.> I can login to the server just fine - GSSAPI-with-mic authentication works > fine. But when I "klist" after logging in, I have no tickets.Same here. What's interesting is that here the GSSAPI seems to receive from SSPI an *empty* set of delegated credentials. So, I see a credential cache constructed with the right default UPN, but with zero tickets.> I've created two AD accounts, and extracted keys mapped to > "host/hostname.domainname.com at REALM.COM" and > "ssh/hostname.domainname.com at REALM.COM" and installed them into > /etc/krb5.keytab.I don't think the ssh/ service key would ever get used. Because you're getting a shell, it's using host/. d -- David Leonard Resource Central software engineer Vintela Inc.; Brisbane, Australia VoIP: US: 801-655-2755 AU: 07-3023-5133
* Simon Gales [2005-05-10 20:38:05 -0500]:> Client: Windows XP pro, in an AD 2003 domain, running SecureCRT 4.1.11. > I've also got MIT Kerberos for Windows installed on the client, and Leash > shows that my tickets ARE forwardable. > > Server: Solaris 8 Sparc server, with MIT Kerberos (krb5-1.4.1), and > OpenSSH 4.0p1. > > I've created two AD accounts, and extracted keys mapped to > "host/hostname.domainname.com at REALM.COM" and > "ssh/hostname.domainname.com at REALM.COM" and installed them into > /etc/krb5.keytab. > > I can login to the server just fine - GSSAPI-with-mic authentication works > fine. But when I "klist" after logging in, I have no tickets. > > So... is this supposed to work? Should my tickets get forwarded? If not, > is there a patch that would make this work?That's a SecureCRT question. If you were using the OpenSSH client, you would have to set the GSSAPIDelegateCredentials option (it's off by default) in order for your TGT to be forwarded. I have no idea what the corresponding option for SecureCRT is called.> Any help would be appreciated... I can provide server-side debug traces > if it'll help, but I really just need to know if tgt-forwarding is > supposed to work in OpenSSH 4.0...It works for me.
Simon Gales wrote:> Client: Windows XP pro, in an AD 2003 domain, running SecureCRT 4.1.11. > I've also got MIT Kerberos for Windows installed on the client, and Leash > shows that my tickets ARE forwardable.We have a similiar setup.> > Server: Solaris 8 Sparc server, with MIT Kerberos (krb5-1.4.1), and > OpenSSH 4.0p1. > > I've created two AD accounts, and extracted keys mapped to > "host/hostname.domainname.com at REALM.COM" and > "ssh/hostname.domainname.com at REALM.COM" and installed them into > /etc/krb5.keytab.(The ssh/... principal is not needed, as sshd uses the host.)> > I can login to the server just fine - GSSAPI-with-mic authentication works > fine. But when I "klist" after logging in, I have no tickets. > > So... is this supposed to work? Should my tickets get forwarded? If not, > is there a patch that would make this work?Yes it should work, but it could be a number of things: SSHD is not setting the KRB5CCANME. See if there are ticket caches created from the session. /tmp/krb5cc_* Windows AD has an attribute for servers called ok_to_delegate (something like this) It sets this on the server ticket, so the client knows if it is safe to delegate credentials. Your AD admin might have to change this on the host/... principal Also see the Windows "ksetup /listRealmFlags". As a test you could set the Delegate flag for the realm. This would tell the client its OK to delegate credentials to any host in the realm even if te AD was not sure.> > Any help would be appreciated... I can provide server-side debug traces > if it'll help, but I really just need to know if tgt-forwarding is > supposed to work in OpenSSH 4.0... >Yes itshoulod work. It works in 3.9 from SecureCRT.> -Simon > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > >-- Douglas E. Engert <DEEngert at anl.gov> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444
P.S. Since you have Leash, tell the SecureCRT to use the MIT Kerberos rather then SSPI. I dont believe the MIT code looks at the ok_to_delegate flag. Simon Gales wrote:> Client: Windows XP pro, in an AD 2003 domain, running SecureCRT 4.1.11. > I've also got MIT Kerberos for Windows installed on the client, and Leash > shows that my tickets ARE forwardable. > > Server: Solaris 8 Sparc server, with MIT Kerberos (krb5-1.4.1), and > OpenSSH 4.0p1. > > I've created two AD accounts, and extracted keys mapped to > "host/hostname.domainname.com at REALM.COM" and > "ssh/hostname.domainname.com at REALM.COM" and installed them into > /etc/krb5.keytab. > > I can login to the server just fine - GSSAPI-with-mic authentication works > fine. But when I "klist" after logging in, I have no tickets. > > So... is this supposed to work? Should my tickets get forwarded? If not, > is there a patch that would make this work? > > Any help would be appreciated... I can provide server-side debug traces > if it'll help, but I really just need to know if tgt-forwarding is > supposed to work in OpenSSH 4.0... > > -Simon > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > >-- Douglas E. Engert <DEEngert at anl.gov> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444
[ sorry if you got this twice...] Simon Gales wrote:> Client: Windows XP pro, in an AD 2003 domain, running SecureCRT 4.1.11. > I've also got MIT Kerberos for Windows installed on the client, and Leash > shows that my tickets ARE forwardable.We have a similiar setup.> > Server: Solaris 8 Sparc server, with MIT Kerberos (krb5-1.4.1), and > OpenSSH 4.0p1. > > I've created two AD accounts, and extracted keys mapped to > "host/hostname.domainname.com at REALM.COM" and > "ssh/hostname.domainname.com at REALM.COM" and installed them into > /etc/krb5.keytab.(The ssh/... principal is not needed, as sshd uses the host.)> > I can login to the server just fine - GSSAPI-with-mic authentication works > fine. But when I "klist" after logging in, I have no tickets. > > So... is this supposed to work? Should my tickets get forwarded? If not, > is there a patch that would make this work?Yes it should work, but it could be a number of things: SSHD is not setting the KRB5CCANME. See if there are ticket caches created from the session. /tmp/krb5cc_* Windows AD has an attribute for servers called ok_to_delegate (something like this) It sets this on the server ticket, so the client knows if it is safe to delegate credentials. Your AD admin might have to change this on the host/... principal Also see the Windows "ksetup /listRealmFlags". As a test you could set the Delegate flag for the realm. This would tell the client its OK to delegate credentials to any host in the realm even if the AD was not sure.> > Any help would be appreciated... I can provide server-side debug traces > if it'll help, but I really just need to know if tgt-forwarding is > supposed to work in OpenSSH 4.0... >Yes it should work. It works in 3.9 from SecureCRT.> -Simon > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > >-- Douglas E. Engert <DEEngert at anl.gov> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444
"Simon Gales" <sgales at firewall.simonandchristy.com> said:> Client: Windows XP pro, in an AD 2003 domain, running SecureCRT 4.1.11. I've also got MIT Kerberos for Windows installed on the client, and Leash > shows that my tickets ARE forwardable. > > Server: Solaris 8 Sparc server, with MIT Kerberos (krb5-1.4.1), and > OpenSSH 4.0p1. > > I've created two AD accounts, and extracted keys mapped to > "host/hostname.domainname.com at REALM.COM" and > "ssh/hostname.domainname.com at REALM.COM" and installed them into > /etc/krb5.keytab. > > I can login to the server just fine - GSSAPI-with-mic authentication works > fine. But when I "klist" after logging in, I have no tickets. > > So... is this supposed to work? Should my tickets get forwarded? If not, > is there a patch that would make this work? > > Any help would be appreciated... I can provide server-side debug traces > if it'll help, but I really just need to know if tgt-forwarding is > supposed to work in OpenSSH 4.0..."Simon Gales" <sgales at firewall.simonandchristy.com> also said:> After more experimentation last night, I found that: > + Putty (with patches) can authenticate but doesn't forward the tickets. > + SecureCRT can authenticate but doesn't forward the tickets. > + OpenSSH works fine, using kinit to get my tickets initially.SecureCRT does indeed support this. You need to make sure that: + Your user, the server, and the client are all trusted for delegation in the AD domain. To do this go to "Manage Users and Computers in Active Domain." In the "Computers" part of the tree, find your Windows XP box, and do Properties. On the general page, turn on the "Trust computer for delegation" check box. Do the same thing for the unix server (it may not be in the "Computers" part-- it will depend on where you added it. Also, find your username and make sure it is also enabled for delegation (in the users section; do properties; on the "Account" tab, "Account is trusted for delegation") + Make sure SCRT is configured for delegation (you've probably already done this.) Delegation should be set to "Full" on the properties dialog for GSSAPI authentication. If you do this, you should not need to use the mit kerberos stuff at all. As Douglas noted, you may get away w/o doing this if you use the mit stuff (change Method: from Auto to MS Kerberos.) If this doesn't work, turning on File / Trace Options before you connect might help use figure out what is going on. Thanks, Joseph (PS. I don't usually follow the mailing list, so please keep me cc'd on any responses-- presuming my post actually gets to the mailing list; I don't know if it is open or not.)