|
     |
The following sections give workaround instructions for a few problem situations that may occur with Tectia Server:
For server failing to start because of wrong host key permissions on Windows, see Invalid Host Key Permissions on Windows
For server failing to start because of wrong configuration file permissions on Windows, see Invalid Configuration File Permissions on Windows
For domain account authentication issues on Windows, see Authentication Fails for Domain Account on Tectia Server on Windows
For incorrect login times on Windows, see Last Login Time is Incorrect on Windows
For failing access to Windows domain resources, see Virtual Folders Defined on Windows Network Shared Folders Are Not Available on Tectia Server on Windows
Symptom: Tectia Server fails to start and reports error "Invalid hostkey permissions for hostkey". This occurs usually after restroring backups or after upgrading Tectia Server from 4.x to 6.x.
The permissions of the server host key file and directory have been made more strict since the 4.x releases. In 6.x, full permissions are allowed only for the Administrators group and the SYSTEM account, and no other permissions are set at all.
The host key permissions can be updated manually by using the ssh-keygen-g3 tool:
Go to the Tectia Server installation directory:
"C:\Program Files (x86)\SSH Communications Security\SSH Tectia" on 64-bit Windows versions
Set the permissions for the host key by running command:
$ ssh-keygen-g3 --set-hostkey-owner-and-dacl hostkey
For more information on the tool, see ssh-keygen-g3(1).
Symptom: Tectia Server fails to start and logs "Error in initial configuration".
Make sure that the permissions of the server configuration file
ssh-server-config.xml are as follows:
The owner of the file is a member of the Administrators group.
Only Administrators and SYSTEM may have Full control of the file.
Users have at most Read & execute permissions - they are not allowed to modify the file.
Other accounts do not have access to the file.
Symptom: User authentication fails for domain accounts on Tectia Server.
This problem could be caused by a number of reasons:
Start the troubleshooting by checking that you are able to log on to the Windows host where Tectia Server is installed. Attempt the logon at the console using domain accounts. Additionally, check that the Windows host where Tectia Server is installed can reach the Domain Controller. While Windows allows you to log on (by using cached passwords) at the console even when the Domain Controller is down, Tectia Server requires active communication with the Domain Controller in order to authenticate domain users.
Another possible cause for this is having additional groups in the "Pre-Windows 2000 Compatible Group" on the Domain Controller. Some Windows updates, such as the multilanguage pack, can result in adding entries to this group, which breaks the mapping for the groups' SIDs, and Tectia Server is no longer able to create access tokens for the domain users. In order to prevent this, check on the Domain Controller that the "Pre-Windows 2000 Compatible Group" contains only the "Authenticated Users" group.
Symptom: After a successful user authentication, Tectia Server displays the previous time when the same user logged in to this server. However, in some cases the last login time shown is incorrect.
The last login time may differ from the server's time because the timestamp comes from the domain controller (DC), not from the host where Tectia Server is running. In large environments with multiple DCs, the timestamps are not replicated between DCs. Logging in using one DC will not update the timestamps shown by other DCs. The last login time may be unreliable if the time on the DCs is not set accurately.
Symptom: Users cannot see or access their virtual folders defined to point to Windows network shared folder on Tectia Server running on a Windows platform.
Folders on Windows network shares are accessible with password authentication on all supported Windows platforms as long as the Windows interactive logon is used. Ensure the domain user has 'log on locally' access right and Tectia Server configuration has windows-logon-type set as interactive.
With other authentication methods (such as public keys, GSSAPI, or certificates), access to Windows network shares can be enabled only when combined with Tectia Server password-cache feature or in older native domains with functional level of Windows Server 2003 when the following requirements are met (or if these methods are used together with password authentication, see Accessing Resources on Windows Network from Logon Sessions Created by Tectia Server ):
The Kerberos extension S4U is applied
The delegation is set correctly on the Domain Controller
Follow these instructions to set up the delegation in the Active Directory:
Log in to the Domain Controller.
Open the Active Directory Users and Computers snap-in
OR open the corresponding tool in Start→Programs→Administrative Tools.
Open the Computers tree and select the computer where the Tectia Server is located.
Right-click and select Properties.
Select the Delegation tab and make the following settings:
Select Trust this computer for delegation to specified services only.
Select Use any authentication protocol.
Click the Add button.
Click the Users or Computers button.
Enter the name of the host where the network share is located and click Ok.
Select cifs (common internet file system) from the available services.
Click Ok to close the open windows.
| |