|
     |
The password authentication method is set up by default, so it is easy to implement and requires no configuring. Since all communication is encrypted, passwords are not available for eavesdroppers.
On Windows, Tectia Server does not need a user management program of its own – the user accounts are created with the standard Windows User Manager.
Tectia Server will record a login failure for each failed password authentication attempt.
On Windows, password authentication uses the Windows password to authenticate the user at login time.
On a Unix system, password authentication uses the
/etc/passwd or /etc/shadow file, depending on how the passwords
are set up. The shadow password files can be used on Linux and Solaris servers, but not on
AIX servers.
To enable password authentication on the server, the
authentication-methods element of the ssh-server-config.xml file
must contain an auth-password element. For example:
<authentication-methods>
<authentication action="allow">
<auth-password failure-delay="2" max-tries="3" />
...
</authentication>
</authentication-methods>
Also other authentication methods can be allowed.
By using selectors, it is possible to allow or require password authentication only for a specified group of users. For more information, see Using Selectors in Configuration File.
Using the Tectia Server Configuration tool, password authentication can be allowed on the Authentication page. See Authentication.
![[Note]](images/note.gif) | Note |
|---|---|
Passwords can also be used as a submethod in keyboard-interactive authentication. For more information, see Password Submethod. |
On Unix, Tectia Server enforces the changing of expired passwords. For more information, see the section called “Forcing Password Change”.
On Windows, password change is handled differently than on Unix platforms, and it is not configurable. If the server requires a password change for an account, the user will be prompted to change the password during authentication, right after the validation of the old password. The user will be logged on after a successful password change.
Some third-party SSH clients may allow users to request password change themselves during authentication. In that case, it will be handled the same way as it would have been enforced by server.
| Note |
|---|---|
For accounts with empty password, and whose logon is disabled by policy: "Accounts: Limit local account use of blank passwords to console logon only", the user will be prompted to change the password even when the user is not able to log on otherwise using password authentication. |
Tectia Server allows users with empty passwords to log in by password authentication method.
On Windows, local users with empty password can be restricted to log on from a physical console only by using the security policy “Accounts: Limit local account use of blank passwords to console logon only”. If this policy is enabled (as it is by default), users with empty password cannot log on to Tectia Server using password authentication. However, the same users can still log on to Tectia Server using other authentication methods that do not involve using the account's password, for example public key authentication.
| Note |
|---|---|
The policy “Accounts: Limit local account use of blank passwords to console logon only” does not apply to domain accounts. |
User login requires the rights to log on locally and
access this computer from the network. On domain controllers, these
rights are disabled by default. If Tectia Server has been installed on a domain controller, the log
on locally and the access this computer from the network permissions must be enabled on the
domain controller for the Domain Users group.
Tectia Server allows
defining locally the user logon types that are allowed on the host. By default, the
Windows-set logon types are used, but for password-based authentication methods you can
define windows-logon-type. For XML configuration instructions, see
settings
. For Tectia Server Configuration GUI instructions, see General.
For example, in case you need to enable accounts
that do NOT have the right to log on locally, use setting
windows-logon-type="network".
| |