Welcome to the VanDyke Software Forums

Join the discussion today!


Go Back   VanDyke Software Forums > Secure Shell

Notices

Reply
 
Thread Tools Display Modes
  #1  
Old 03-27-2011, 02:15 PM
jkoktan jkoktan is offline
Registered User
 
Join Date: Mar 2011
Posts: 5
TGT forwarding

Hello,

we're evaluating SecureCRT for SSH access from Windows workstations
to our linux hosts with cross-realm kerberos authentication.

It is working very well, but I've not yet succeeded with forwarding the TGT
issued by Win AD to the linux host.

Setup: WinXP SP3 & SecureCRT 6.6.2 on the client side
RHEL 5.5 & OpenSSH on the server side.
- the clients are in a different realm than the unix servers.
- authentication works fine
- TGT forwarding works when connecting from linux to linux, so server is probably configured ok.
- registry key allowtgtsessionkey set to 1
- SecureCRT's GSSAPI properties are set to "full delegation".
- the TGT has the "forwardable" flag set (TicketFlags: 0x40e00000)

Despite this, the TGT is not forwarded.

1) Is there any other configuration that needs to be done?
2) Is there anything wrong in the attached client's log?

Thank you.

Regards,
Jan


SecureCRT - Version 6.6.2 (build 350)
[LOCAL] : SSH2Core version 6.6.0.350
[LOCAL] : Connecting to lintest1.xxxx.xxx:22 ...
[LOCAL] : Changing state from STATE_NOT_CONNECTED to STATE_EXPECT_KEX_INIT
[LOCAL] : Using protocol SSH2
[LOCAL] : RECV : Remote Identifier = 'SSH-2.0-OpenSSH_4.3'
[LOCAL] : CAP : Remote can re-key
[LOCAL] : CAP : Remote sends language in password change requests
[LOCAL] : CAP : Remote sends algorithm name in PK_OK packets
[LOCAL] : CAP : Remote sends algorithm name in public key packets
[LOCAL] : CAP : Remote sends algorithm name in signatures
[LOCAL] : CAP : Remote sends error text in open failure packets
[LOCAL] : CAP : Remote sends name in service accept packets
[LOCAL] : CAP : Remote includes port number in x11 open packets
[LOCAL] : CAP : Remote uses 160 bit keys for SHA1 MAC
[LOCAL] : CAP : Remote supports new diffie-hellman group exchange messages
[LOCAL] : CAP : Remote correctly handles unknown SFTP extensions
[LOCAL] : CAP : Remote correctly encodes OID for gssapi
[LOCAL] : CAP : Remote correctly uses connected addresses in forwarded-tcpip requests
[LOCAL] : CAP : Remote can do SFTP version 4
[LOCAL] : CAP : Remote x.509v3 uses ASN.1 encoding for DSA signatures
[LOCAL] : SSPI : Requesting full delegation
[LOCAL] : SSPI : [Kerberos] SPN : host@lintest1.xxxx.xxx
[LOCAL] : SSPI : Requesting full delegation
[LOCAL] : SSPI : [Kerberos (Group Exchange)] SPN : host@lintest1.xxxx.xxx
[LOCAL] : SEND : KEXINIT
[LOCAL] : RECV : Read kexinit
[LOCAL] : Available Remote Kex Methods = diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
[LOCAL] : Selected Kex Method = diffie-hellman-group-exchange-sha1
[LOCAL] : Available Remote Host Key Algos = ssh-rsa,ssh-dss
[LOCAL] : Selected Host Key Algo = ssh-dss
[LOCAL] : Available Remote Send Ciphers = aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
[LOCAL] : Selected Send Cipher = aes256-ctr
[LOCAL] : Available Remote Recv Ciphers = aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
[LOCAL] : Selected Recv Cipher = aes256-ctr
[LOCAL] : Available Remote Send Macs = hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
[LOCAL] : Selected Send Mac = hmac-sha1
[LOCAL] : Available Remote Recv Macs = hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
[LOCAL] : Selected Recv Mac = hmac-sha1
[LOCAL] : Available Remote Compressors = none,zlib@openssh.com
[LOCAL] : Selected Compressor = none
[LOCAL] : Available Remote Decompressors = none,zlib@openssh.com
[LOCAL] : Selected Decompressor = none
[LOCAL] : Changing state from STATE_EXPECT_KEX_INIT to STATE_KEY_EXCHANGE
[LOCAL] : SEND : KEXDH_GEX_REQUEST
[LOCAL] : RECV : KEXDH_GEX_GROUP
[LOCAL] : SEND : KEXDH_INIT
[LOCAL] : RECV : KEXDH_REPLY
[LOCAL] : SEND : NEWKEYS

[LOCAL] : Changing state from STATE_KEY_EXCHANGE to STATE_EXPECT_NEWKEYS
[LOCAL] : RECV: Remote Hostkey: 73:3e:c7:d7:a9:ce:60:a6:a2:16:5a:22:cf:e9:73:44
[LOCAL] : RECV : NEWKEYS
[LOCAL] : Changing state from STATE_EXPECT_NEWKEYS to STATE_CONNECTION
[LOCAL] : SEND: SERVICE_REQUEST[ssh-userauth]
[LOCAL] : RECV: SERVICE_ACCEPT[ssh-userauth] -- OK
[LOCAL] : SENT : USERAUTH_REQUEST [none]
[LOCAL] : RECV : USERAUTH_FAILURE, continuations [publickey,gssapi-with-mic,password]
[LOCAL] : GSS SPN : host@lintest1.xxxx.xxx
[LOCAL] : [SSPI/1.2.840.113554.1.2.2] : This mechanism might work.
[LOCAL] : SENT : USERAUTH_REQUEST [gssapi-with-mic]
[LOCAL] : [SSPI/1.2.840.113554.1.2.2] : Using this mechanism.
[LOCAL] : GSS : Requesting full delegation
[LOCAL] : SENT : USERAUTH_GSSAPI_TOKEN [1326 bytes]
[LOCAL] : SENT : SSH_MSG_USERAUTH_GSSAPI_MIC
[LOCAL] : RECV : AUTH_SUCCESS
[LOCAL] : SEND[0]: SSH_MSG_CHANNEL_OPEN('session')
[LOCAL] : SEND[0]: Pty Request (rows: 35, cols: 97)
[LOCAL] : RECV[0]: pty request succeeded
[LOCAL] : SEND[0]: shell request
[LOCAL] : RECV[0]: shell request succeeded
[user60037@lintest1 ~]$
Reply With Quote
  #2  
Old 03-28-2011, 10:31 AM
rtb rtb is offline
VanDyke Technical Support
 
Join Date: Aug 2008
Posts: 4,305
Hi Jan,

Thanks for the outline of your environment and the trace. As you mention, authentication is happening as expected.

What is the trust relationship between the AD realm and the UNIX realm?

What action are you taking once connected to the UNIX realm that is resulting in failure?

What realms are involved in the action?
__________________
--Todd

VanDyke Software
Technical Support
support@vandyke.com
505-332-5730
Reply With Quote
  #3  
Old 03-28-2011, 04:17 PM
jkoktan jkoktan is offline
Registered User
 
Join Date: Mar 2011
Posts: 5
Hello Todd,

1) trust
There is a one-way trust, the linux realm is trusting
the windows top-level realm/domain.

2) what action
just "klist" after logon. It shows no credentials cache file exists. Sorry for not including this listing.

3) realms:
The client is in the domain client.windows.company.cz, which has a bidirectional trust with its parent domain windows.company.cz.
The linux servers are in domain/realm linux.company.cz, which is trusting the realm windows.company.cz
The client can transit this path without any problems, authentication happens fine.

Thank you,
Jan
Reply With Quote
  #4  
Old 03-29-2011, 12:52 PM
rtb rtb is offline
VanDyke Technical Support
 
Join Date: Aug 2008
Posts: 4,305
Hi Jan,

Thanks for the additional information. Even though the TGT is delegatable, the necessary trust relationships may not exists to allow the delegation to occur.

You will need to ensure the following:
  • Your AD user account, the UNIX server, and the Windows client machine are all trusted for delegation in the AD domain. To do this go to "Manage Users and Computers in Active Domain" on the AD domain controller and:
    1. In the "Computers" part of the tree, find your Windows box (on which you're running SecureCRT), and choose its Properties. On the General page, turn on the "Trust computer for delegation" option.
    2. Do the same thing for the UNIX server (it may not be in the "Computers" part -- it will depend on where you added it).
    3. Also, find your AD user account and make sure it is also enabled for delegation (in the Users section; choose Properties for your account; in the "Account" tab, enable the option "Account is trusted for delegation", and make sure the option "Account is sensitive and cannot be delegated" is *not* enabled.
  • Make sure SecureCRT is configured for delegation (it sounds like you've probably done this already). Delegation should be set to Full on the Properties Dialog for GSSAPI authentication in the Connection / SSH2 category located in SecureCRT's Session Options Dialog.
It is important to note that this information may be different based on the version of Windows in use.

Does this help you resolve the credentials issue in your Kerberos environment?
__________________
--Todd

VanDyke Software
Technical Support
support@vandyke.com
505-332-5730
Reply With Quote
  #5  
Old 03-30-2011, 12:39 PM
jkoktan jkoktan is offline
Registered User
 
Join Date: Mar 2011
Posts: 5
Hi Todd,

I need to catch our win admin to check this.
I'll give you answer asap, probably tomorrow.

Thank you,
Jan
Reply With Quote
  #6  
Old 03-30-2011, 02:52 PM
rtb rtb is offline
VanDyke Technical Support
 
Join Date: Aug 2008
Posts: 4,305
Hi Jan,

Thanks for the update. I look forward to hearing the results of your testing.
__________________
--Todd

VanDyke Software
Technical Support
support@vandyke.com
505-332-5730
Reply With Quote
  #7  
Old 04-02-2011, 12:49 PM
jkoktan jkoktan is offline
Registered User
 
Join Date: Mar 2011
Posts: 5
Hi Todd,

sorry for the delay, the changes we've done took us longer than expected.
Still no TGT forwarding.

To Your advice:
1) The client machine was not set to trust, we set this to "full delegation"
The attribute "userAccountControl" for this machine account is now 528384 (0x81000), which means WORKSTATION_TRUST_ACCOUNT|TRUSTED_FOR_DELEGATION.
The client machine has been rebooted.

- The domain controllers are all W2008R2
- I've decoded the attribute value according to the: http://support.microsoft.com/kb/305144

2) I haven't done any changes, as the linux server is in the linux realm.
I've checked this account/principal's properties in the MIT kerberos database,
but there is nothing related to forwarding/delegation:
===========================================
Principal: host/lintest1.linux.company.cz@LINUX.COMPANY.CZ
Expiration date: [never]
Last password change: Sun Mar 20 21:05:16 CET 2011
Password expiration date: [none]
Maximum ticket life: 0 days 10:00:00
Maximum renewable life: 5 days 00:00:00
Last modified: Sun Mar 20 21:05:16 CET 2011 (root/admin@LINUX.COMPANY.CZ)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 2
Key: vno 13, ArcFour with HMAC/md5, no salt
Key: vno 13, AES-256 CTS mode with 96-bit SHA-1 HMAC, no salt
Attributes:
Policy: [none]
==================================================

3) User account is now set as per your advice.
The userAccountControl attribute has the value of 590336 (0x90200), which means NORMAL_ACCOUNT | WORKSTATION_TRUST_ACCOUNT | TRUSTED_FOR_DELEGATION .

4) I've installed MIT's Kerberos for windows, just as a troubleshooting tool.
Maybe You'd find the output from klist -fe (after logon to the linux server) useful:
==============================================
C:\Program Files\MIT\Kerberos\bin>klist -fe
Ticket cache: MSLSA:
Default principal: ita60037@CLIENT.WINDOWS.COMPANY.CZ

Valid starting Expires Service principal
04/02/11 19:34:38 04/03/11 05:34:26 krbtgt/LINUX.COMPANY.CZ@WINDOWS.COMPANY.CZ
renew until 04/09/11 19:34:26, Flags: FRA
Etype (skey, tkt): ArcFour with HMAC/md5, AES-256 CTS mode with 96-bit SHA-1 HMAC
04/02/11 19:34:38 04/03/11 05:34:26 krbtgt/WINDOWS.COMPANY.CZ@CLIENT.WINDOWS.COMPANY.CZ
renew until 04/09/11 19:34:26, Flags: FRA
Etype (skey, tkt): ArcFour with HMAC/md5, ArcFour with HMAC/md5
04/02/11 19:34:26 04/03/11 05:34:26 krbtgt/CLIENT.WINDOWS.COMPANY.CZ@CLIENT.WINDOWS.COMPANY.CZ
renew until 04/09/11 19:34:26, Flags: FRIA
Etype (skey, tkt): ArcFour with HMAC/md5, ArcFour with HMAC/md5
04/02/11 19:34:38 04/03/11 05:34:26 host/lintest1.linux.company.cz@LINUX.COMPANY.CZ
renew until 04/07/11 19:34:38, Flags: FRA
Etype (skey, tkt): ArcFour with HMAC/md5, ArcFour with HMAC/md5

C:\Program Files\MIT\Kerberos\bin>
=============================================



I've noticed, that the TicketFlags still has the same value of 0x40e00000 (from the windows native klist), even after the changes to machine & user account's properties.
I'd like to verify first, that the SecureCRT client can
actually grab the TGT (including the session key) from the Win LSA subsystem. Is there any debug option to check this?

Thank You.

Regards,
Jan
Reply With Quote
  #8  
Old 04-05-2011, 11:09 AM
rtb rtb is offline
VanDyke Technical Support
 
Join Date: Aug 2008
Posts: 4,305
Hi Jan,

We should have a new build of SecureCRT later today or tomorrow that will report whether a TGT delegation request is succeeding or failing. Would you send an e-mail to support@vandyke.com with a subject of Attn: Todd - thread #7275?

Additionally, would you use the same e-mail address to send the message that you used to create your download account at www.vandyke.com, or include the download account e-mail address in the body of the e-mail so that I can make the new build available to you when it is ready?
__________________
--Todd

VanDyke Software
Technical Support
support@vandyke.com
505-332-5730
Reply With Quote
  #9  
Old 11-27-2011, 06:57 PM
jkoktan jkoktan is offline
Registered User
 
Join Date: Mar 2011
Posts: 5
solved

Hello Todd,

I've finally solved the problem:
After modifying trust attributes using ksetup /setrealmflags REALMNAME delegate,
the tgt is being forwarded now. I assume that this wouldn't be necessary
if the unix KDC would be able to set ok-as-delegate ticket flag.

Thank you for your support!

Good bye,
Jan
Reply With Quote
  #10  
Old 11-28-2011, 11:53 AM
rtb rtb is offline
VanDyke Technical Support
 
Join Date: Aug 2008
Posts: 4,305
Hi Jan,

Thanks for the update and posting the specific solution. I am glad to hear that you have resolved this problem.
__________________
--Todd

VanDyke Software
Technical Support
support@vandyke.com
505-332-5730
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -6. The time now is 03:52 PM.