Managing Account Authorization and Password Expiration When Using Public Key Authentication on UNIX Servers

  • 7022093
  • 12-Dec-2012
  • 02-Mar-2018

Environment

Reflection for Secure IT UNIX Server version 8.0

Situation

Authentication with passphraseless public keys can be used to enable automated login to the Reflection for Secure IT server. On UNIX platforms, after successful authentication using a public key, the Reflection server checks the password database to ensure that the user is still authorized to access the server. This means that even users who have been configured for public key authentication may need to enter a password when their account password has expired. This technical note explains the settings involved and discusses ways to handle password expiration so that users can continue to log in without having to respond to password prompts.

Resolution

Account Management

Public key authentication is one way to confirm the identity of a client user. When connecting to UNIX servers, public key authentication establishes the user identity (authentication), but does not establish whether the user is currently entitled to access resources on the server (authorization). After successful public key authentication, the Reflection server uses operating system resources to confirm that the user account is still current and authorized to log in.

The AccountManagement keyword in the server configuration file (/etc/ssh2/sshd2_config) controls how the server handles account authorization. The available settings are:

pam
The server uses PAM modules for account authorization.
If an account is locked, the connection is refused. If the password has expired the user is prompted to change the password.
Note: With public key authentication, sftp and scp connections are refused if the password is expired.
password
The server uses system calls to check the account status in the system's password database.
If an account is locked, the connection is refused. If the password has expired the user is prompted to change the password.
Note: With public key authentication, sftp and scp connections are refused if the password is expired.
aix
For use on AIX systems only. (On non-AIX systems, this value is equivalent to 'none'.)
If the account is locked using the AIX account_locked flag, the connection is refused. The server ignores password accounting restrictions. If the password has expired, no password change prompt appears and the user is allowed access.

none
The server does not check account authorization.
If an account is locked, the user is allowed to connect. If the password has expired, no password change prompt appears and the user is allowed access.

The default is 'pam,password', which requires the user account to pass account validation by both the operating system password and PAM systems.

Using Public Keys to Authenticate Without User Input

You can enable client authentication without requiring any user input by configuring public key authentication using a key that is not passphrase protected. This approach is frequently used to support automated processes.

Note: Passphraseless public keys allow client login without requiring user input only while the user account is current. When AccountManagement='pam, password' (the default), the connection is refused or requires user input if the user account has been locked or the user's password has expired.

Handling Expired Passwords

On most supported UNIX systems, the same system files handle both account locking and password expiration. The system provides no way to turn off checking of expired passwords without also allowing access by accounts that have been locked out of the server.

Client users who have been connecting successfully using the ssh command with public key authentication will be presented with password update prompts when their password expires. Users who have been connecting successfully using the scp or sftp command with public key authentication will have the connection refused when their password expires. This can present problems for automated processes, or for users who do not know their password because they have been relying on authentication using passphraseless public keys.

The following approaches can be used to avoid password change prompts and refused connections.

On AIX, check for account locking and ignore password expiration

IBM AIX supports an account locking system that is independent of password expiration. If you are running Reflection for Secure IT on an AIX system, you can set AccountManagement = aix. This setting ensures that a user will not be allowed to log in if that user account is locked using the AIX account_locked flag, even if public key authentication is successful. Expired passwords are ignored.

Note: This option is available on AIX systems only. On non-AIX systems, setting AccountManagement = aix is equivalent to setting AccountManagement = none.

Have the UNIX system administrator update passwords before they expire

Using this approach enables you to continue to use the recommended default AccountManagement settings.

Use passwords that don't expire for user accounts that require automated login

Configure passwords that don't expire for client users who require automated logins. To help minimize the security risk of keeping the same password indefinitely, use long, strong passwords. Because users relying on public key authentication do not need to enter their UNIX system passwords, long passwords won't present a problem for these users.

Disable account management for some users

You can set AccountManagement = none to disable account management. With this configuration, Reflection for Secure IT server allows authenticated users to log in without checking to see if the account is locked or the user password has expired.

Caution: Disabling account management means that locked user accounts can continue to gain access to server resources. Any system settings that are in place to automatically lock out users (for example after a set number of failed login attempts) are ignored.

If you choose to use this approach, the following actions reduce but do not remove this risk.

  • Use a subconfiguration to change the AccountManagement setting for only those user accounts that require an automated login. For details, see "Server Subconfiguration Files" in the User Guide, which is available from https://support.microfocus.com/manuals/rsit_unix.html.
  • If you need to deny access to a particular user, you can do this manually by deleting the user from the system or by using the Reflection for Secure IT DenyUsers setting.

Additional Information

Legacy KB ID

This article was originally published as Attachmate Technical Note 2650.

Feedback service temporarily unavailable. For content questions or problems, please contact Support.