Welcome to the VanDyke Software Forums

Join the discussion today!


Go Back   VanDyke Software Forums > Secure Shell

Reply
 
Thread Tools Display Modes
  #1  
Old 10-23-2006, 01:37 AM
Babyface Babyface is offline
Registered User
 
Join Date: Oct 2006
Posts: 4
Thumbs up Public-Key authentification not working on Windows Server 2003 x64?

Hi,

did anyone know if VShell Server works with public-key authentification on 64-bit windows systems? I have enabled LSA module on installation and rebooted the server, but the pubkey auth still not working. The vdspka10.dll is located in WINDOWS\SysWOW64 I have attached the full logfile from VShell, maybe someone knows a solution.

23:03:12,conn,00006: Connection accepted from 10.0.7.90:34921.
23:03:12,info,VShell configuration has been changed.
23:03:12,info,Deny hosts file is not enabled. No deny hosts file is currently loaded.
23:03:12,auth,00006: none for user <USER> rejected because it is unavailable.
23:03:12,auth,00006: Received unsigned public key; checking authorization (fingerprint: ca:61:c0:54:5f:90:58:79:df:c4:7c:65:36:36:d0:cd)
23:03:12,auth,00006: Searching C:\PROGRA~2\VShell\PublicKey\<USER> for matching public key.
23:03:12,auth,00006: Identity.pub contains matching public key for user <USER>
23:03:12,auth,00006: Received signed public key; attempting authentication (fingerprint: ca:61:c0:54:5f:90:58:79:df:c4:7c:65:36:36:d0:cd)
23:03:12,auth,00006: Searching C:\PROGRA~2\VShell\PublicKey\<USER> for matching public key.
23:03:12,auth,00006: Identity.pub contains matching public key for user <USER>
23:03:12,auth,00006: Could not get authentication token for user <USER>; further authentication is necessary: This function is not supported on this system.
23:03:12,auth,00006: publickey for user <USER> accepted, further authentication needed.
Reply With Quote
  #2  
Old 10-23-2006, 10:31 AM
tnygren's Avatar
tnygren tnygren is offline
Registered User
 
Join Date: May 2005
Posts: 1,408
---------------------------------------------------------------------
UPDATE: [jdev: 07-24-2018] When this post was originally made back in 2005, VShell was only available in a 32-bit version. As such, its LSA module (also being 32-bit) was not loadable by a 64-bit version of Windows.
As of VShell version 3.0 released in 2007, 64-bit versions of VShell have been made available, allowing for public-key-only authentication via the LSA module to work successfully on a 64-bit version of Windows.

---------------------------------------------------------------------

Hi Babyface,

VShell is currently not designed to run on the 64 bit Windows platform.

In general, VShell will work on the 64 bit platform except for the LSA module that controls PublicKey Authentication on Windows.

This module needs to be linked directly into Windows. In Windows 64 bit, this has changed.

We are looking in the possibility of creating a future version of VShell that does support the 64 bit Windows platform.

If this happens, a post will be made here.

We can also send an email to you if would prefer email notification.

If so, just send a message to support@vandyke.com with a subject of ATTN: Teresa Forum Thread 1809.
__________________
Thanks,

Teresa

Teresa Nygren

Last edited by jdev; 07-24-2018 at 06:53 PM.
Reply With Quote
  #3  
Old 10-23-2006, 11:46 AM
galb galb is offline
VanDyke Developer
 
Join Date: Feb 2004
Posts: 35
Note that you may be able to get public-key only authentication using
kerberos protocol transition if your x64 system is part of a SRV 03
windows domain and the user you are trying to authenticate as is
a domain user.

You have to twiddle this registery setting by hand (and have a
relatively recent 2.6.x copy of VShell, I think... I can't remember
for sure what version this went in at):

HKLM\Software\VanDyke\VShell\Server\Use Kerberos Protocol Transition

It should be a REG_DWORD, value 1 to enable.

Thanks,

Joseph
Reply With Quote
  #4  
Old 10-24-2006, 05:37 AM
Babyface Babyface is offline
Registered User
 
Join Date: Oct 2006
Posts: 4
Hi,

@galb: The user is a Domain User and part of a Windows Server 2003 Domain and my VShell Version is 2.6.2 (actually it is trial version to test) I have tried your tip with setting this value to 1 (i have to create registry key, because it does not exist) and i restarted Vandyke Service but it did not help.

babyface@testnode:~$ ssh 10.0.7.32
Authenticated with partial success.
root@10.0.7.32's password:
Reply With Quote
  #5  
Old 10-24-2006, 09:24 AM
galb galb is offline
VanDyke Developer
 
Join Date: Feb 2004
Posts: 35
Hmmm... a snippet from the server log might help us understand
what is happening.

Here is what a log on my XP x64 system looks like:

Code:
00001: [LOCAL DEBUG] SEND: SERVICE_ACCEPT[ssh-userauth]
00001: [LOCAL DEBUG] SENT : SSH_MSG_USERAUTH_BANNER
00001: Client specified username Xxx, resolved as Xxx@domain.name
00001: none for user Xxx@domain.name rejected because it is unavailable.
00001: Received unsigned public key; checking authorization (fingerprint: e6:8c:ae:c8:60:9a:0c:69:c0:e7:54:0c:7f:9d:f2:ca)
00001: Searching E:\Program Files\VShell\PublicKey\Xxx for matching public key.
00001: Key.pub contains matching public key for user Xxx@domain.name
00001: Received signed public key; attempting authentication (fingerprint: e6:8c:ae:c8:60:9a:0c:69:c0:e7:54:0c:7f:9d:f2:ca)
00001: Searching E:\Program Files\VShell\PublicKey\Xxx for matching public key.
00001: Key.pub contains matching public key for user Xxx@domain.name
00001: Using kerberos protocol transition to obtain a token for Xxx@domain.name
00001: publickey for user Xxx@domain.name accepted.
Note the second to the last line about "Using kerberos protocol transition"

On an interesting (but probably irrelevant) technical note, MS claims that kerberos protocol transition won't work on an XP box (only SRV 03 or better.)

This turns out to be partially true: I am able to use Kerberos protocol transition to obtain a token on XP x64 (which is what VShell needs in order to authenticate the user.) However, the real purpose behind kerberos protocol transition is to enable delegation (or more precisely, partial delegation.)

Normally, when a user logs on using public key authentication, they can't access any network resources because we don't have credentials that a network server (like a file server) will accept. By using kerberos protocol transition, we actually obtain a kerberos ticket, which can then get us into the file server on your behalf, for example.

Using XP x64 (not win32) I was able to get a token, but not get partial delegation to work. My guess is that it works at all because XP x64 is actually based on the SRV 03 code base.

Thanks,

Joseph

PS. I think our support crew has prepped a document to help with the setup of all this ... maybe I can convince one of them to post that document here :-)
Reply With Quote
  #6  
Old 10-25-2006, 05:09 AM
Babyface Babyface is offline
Registered User
 
Join Date: Oct 2006
Posts: 4
Hi,

@galb:

Hmm... there is nothing in logfile about Kerberos protocol transition. What i forgot to tell is that the client from where i make the connection is an OpenSSH 3.9p1
Reply With Quote
  #7  
Old 10-25-2006, 10:04 AM
galb galb is offline
VanDyke Developer
 
Join Date: Feb 2004
Posts: 35
Quote:
Originally Posted by Babyface
What i forgot to tell is that the client from where i make the connection is an OpenSSH 3.9p1
The client shouldn't matter as VShell will attempt to use kerberos protocol transition for all public key authentication (where it could work.)

Do you have a line like this:

00001: Client specified username Xxx, resolved as Xxx@domain.name

and does the resolved name have @domain.name on it?

Thanks,

Joseph
Reply With Quote
  #8  
Old 10-25-2006, 02:33 PM
Babyface Babyface is offline
Registered User
 
Join Date: Oct 2006
Posts: 4
Hi,

no i don't have such line, but it is definitely a Domain User, also this name does not exist on local machine.
Reply With Quote
  #9  
Old 10-25-2006, 02:36 PM
galb galb is offline
VanDyke Developer
 
Join Date: Feb 2004
Posts: 35
Would you be willing to send your actual log file to support@vandyke.com,
so I can take a look at it?

Just reference this thread and that Joseph asked for the log file and they'll get it to me.

Thanks,

Joseph
Reply With Quote
  #10  
Old 10-25-2006, 07:02 PM
miked's Avatar
miked miked is offline
Registered User
 
Join Date: Feb 2004
Posts: 2,040
Access Network Resources Using Public Key Only Authentication

SUMMARY
How to allow access to network resources with public key only authentication using VShell and Windows 2003 (minimum) Kerberos Protocol Transition.

PRODUCTS AFFECTED
  • VShell version 2.6.4 for Windows or newer. The "Use Kerberos Protocol Transition" option is not available in earlier versions of VShell.
  • Windows 2003 minimum. Earlier versions of Windows do not support Kerberos Protocol Transition.

DESCRIPTION
This article discusses how to gain access to network resources (UNC paths, for example) with public key only authentication by using VShell's "Use Kerberos Protocol Transition" option. This option only affects VShell's behavior when VShell is installed on a Windows 2003 (or newer) machine that is a member of an Active Directory Domain in which the domain controller is also running Windows 2003 (minimum).

RESOLUTION
In order to use the "Use Kerberos Protocol Transition" option and see the benefits, you'll need to make sure that the Windows environment satisfies the following conditions:
  • You are using Active Directory.
  • Users authenticating to VShell must authenticate using user accounts that are part of Active Directory; local machine accounts are not available for Kerberos Protocol Transition.
  • The Active Directory domain must be configured to operate at the Windows 2003 (minimum) compatibility level.
  • All servers involved must be running Windows 2003 (or newer), and must be members of the AD domain. This includes the domain controller, the machine on which VShell is installed, and any machines that would be providing network resources such as shared directories (e.g., fs.somedomain.com).
  • The virtual root path in the VShell configuration must be specified using the same cifs computer name for which constrained delegation has been enabled on the domain controller. For example, if the cifs server is named fs.somedomain.com, constrained delegation must be configured on the domain controller for fs.somedomain.com and the VShell virtual root path must be specified in terms of \\fs.somedomain.com\share\...

    Note: Historically, Network Attached Storage (NAS) devices have stripped down operating systems and did not run Windows 2003 or newer. Therefore, these devices may not work correctly with Kerberos Protocol Transition within a Windows 2003 (or higher) AD network environment. However, we have recently received reports from customers that their virtual CIFS share servers are compatible and they have had success using Kerberos Protocol Transition to connect to these devices' fileshares. If using a NAS device you'll need to check your NAS documentation or the NAS vendor to find out whether it operates at the Windows 2003 (or higher) compatibility level.

If your Windows environment meets the above criteria, you should be able to follow the instructions below to enable the use of the "Use Kerberos Protocol Transition" option in VShell.

Before configuring VShell to use the "Use Kerberos Protocol Transition" option, you must configure constrained delegation for the systems that you wish to handle authentication requests (i.e. the machines on which VShell is installed).

In our example, we assume the following:
  • The goal is to allow access to a network share over SFTP for users authenticating only with public key authentication.
  • A Windows 2003 (or newer) domain controller named dc.somedomain.com
  • A Windows 2003 (or newer) fileserver named fs.somedomain.com which provides a shared folder named "fileshare".
  • There is a Windows 2003 (minimum) domain member named vshell.somedomain.com. vshell.somedomain.com is a machine on which VShell 2.6.4 or newer has been installed.

Configuring Constrained Delegation on the Domain Controller
To configure constrained delegation for this example environment, log on to dc.somedomain.com as a domain administrator and launch the "Active Directory Users and Computers" MMC interface (Start, Administrative Tools):
  1. In the tree view select somedomain.com domain.
  2. Open the "Computers" container.
  3. Find vshell.somedomain.com in the list of computers.
  4. Right-click on the entry for vshell.somedomain.com and select "Properties" from the context menu.
  5. Click on the Delegation tab and enable the following options:
    • "Trust this computer for delegation to specified services only"
    • "Use any authentication protocol"
  6. Click on the "Add" button.
  7. When the "Add Services" dialog appears, click on the "Users or Computers" button.
    • In the "Select Users or Computers" dialog, enter the name of the fileserver (fs.somedomain.com) in the "Enter the object names to select" field, and click "OK". If the name of the fileserver offering the share is actually the domain controller, you would type dc.somedomain.com rather than fs.somedomain.com.
  8. Back in the "Add Services" dialog, select "cifs" from the list of Available services.
  9. Click OK.
  10. In the "Properties" dialog, confirm that the service type you just added (cifs) is listed, and that the User or Computer is fs.somedomain.com (or the name of the file server you selected in step 7 above).
  11. Reboot the machine on which VShell is installed (vshell.somedomain.com). This action causes updated credentials for the VShell machine to be obtained, which will allow for the delegation changes to take effect.

Configuring VShell to Use Kerberos Protocol Transition
Assuming VShell has been installed on vshell.somedomain.com, you'll need to enable the "Use Kerberos Protocol Transition" option in VShell. Currently this needs to be done by editing the registry.
WARNING: If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. There is no guarantee that you can solve problems that result from using the Registry Editor incorrectly. Use the Registry Editor at your own risk.
  1. Launch regedit (Start, Run, regedit), and navigate to:
    HKEY_LOCAL_MACHINE\SOFTWARE\VanDyke\VShell\Server
  2. Find the "Use Kerberos Protocol Transition" REG_DWORD value, and change it from the default ("0") to "1" and close the registry editor.

  3. Restart the VShell service.

With VShell and the AD domain controller configured properly as described above, users should be able to authenticate to VShell running on vshell.somedomain.com using public key only authentication and gain access to SFTP roots that refer to the share "fileshare" on fs.somedomain.com.
__________________
Mike
VanDyke Software
Technical Support
[http://www.vandyke.com/support]

Last edited by bgagnon; 08-21-2019 at 03:09 PM. Reason: Jake and I added some info regarding configuration
Reply With Quote
  #11  
Old 02-15-2007, 08:57 AM
miked's Avatar
miked miked is offline
Registered User
 
Join Date: Feb 2004
Posts: 2,040
For those interested in using public key authentication, but not Kerberos Protocol Transition, we now have a VShell installer for x64 platforms. This will allow you to use the LSA module required for public key authentication, without needing Kerberos Protocol Transition. If you're interested in trying a pre-release version, please let us know.
__________________
Mike
VanDyke Software
Technical Support
[http://www.vandyke.com/support]
Reply With Quote
Reply


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
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 02:46 AM.