Remote Password Rotation
The Remote Password Rotation functionality allows the password of the corresponding privileged user account to be changed automatically (to a new randomly-generated password) at a specified frequency, as well as manually at any time.
Remote Password Rotation can only be enabled for Active Directory account, Windows account, Unix account (SSH), and MS SQL account secret types, and by a user with the Owner permission for the secret.
To configure Remote Password Rotation for the account that users will access by using a secret in the Syteca Connection Manager, do the following:
1. Log in to the Management Tool, and click the Password Management navigation link (on the left).
2. On the Password Management page, click anywhere on the required Active Directory account, Windows account, Unix account (SSH), or MS SQL account secret to edit it.
2. In the Edit Secret pop-up window that opens, select the Automation tab.
3. On the Automation tab, select the Enable remote password rotation checkbox, and specify how frequently the account's password will be changed automatically (in the Rotate Password Every fields), or click the Rotate Now button to change the password immediately.
NOTE: If Remote Password Rotation ever fails, the secret is marked with the red circular () icon next to its name (on the left) in the list of secrets, and the corresponding error event will be displayed on the System Health page. In this case, subsequent password changes will no longer occur.
For remote password rotation to function correctly for the accounts (that the secrets access), both:
• It needs to be configured appropriately on the corresponding hosts (including to ensure that the policies do not conflict with the remote password rotation).
• The required preconditions need to be met as described below.
Table of Contents
1. Preconditions for Windows Account Secrets
The following preconditions need to be met on the remote computer where the Windows account is located (i.e. on the computer that the secret connects to by using the Syteca Connection Manager):
• On computers running the Windows 11 and Windows 10 desktop operating systems:
- Remote UAC must be disabled.
- The Remote Registry service must be running.
• Make sure that the local security policy is configured correctly.
• Make sure that the password settings for the account are configured correctly.
• In the firewall, the following rules must be enabled:
- Remote Service Management (NP-ln).
- Remote Service Management (RPC).
• Also, on the computer where the Syteca Application Server is installed, the EkranServer service must be run under any user account other than the LocalSystem account.
NOTE: Remote Password Rotation is only available for local administrator accounts.
To disable remote User Account Control (UAC), do the following:
1. Open the Windows Registry Editor.
2. Locate and select the following key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System.
3. If the LocalAccountTokenFilterPolicy registry entry does not exist, select Edit > New > DWORD (32-bit) Value, and add the following new values in the fields:
• Value name: LocalAccountTokenFilterPolicy
• Value data: 1
4. If a LocalAccountTokenFilterPolicy registry entry already exists, right-click it and select Modify in the context menu, then enter “1” in the Value data field, and click OK.
5. Restart the computer.
To make sure the local security policy is configured (so that the account will never be locked out), do the following:
1. Press Win+R, then enter secpol.msc, and click Enter.
2. In the Local Security Policy window that opens, select the Security Settings section (on the left).
3. Open Account Policies, and select Account Lockout Policy.
4. Double-click on the Account lockout threshold policy (on the right) to open the settings Account lockout threshold Properties window.
5. Make sure that the value specified in the Account will lock out after field is “0” to disable account lockout, and click Apply and then OK to save any changes made.
To make sure the password is configured to never expire, do the following:
1. Press Win+R, then enter lusrmgr.msc, and click Enter.
2. In the Local Users and Groups (Local) section, select the Users section.
3. Right-click on the user required, and select Properties.
4. On the General tab, make sure that the Password never expires checkbox is selected, and then click OK.
2. Preconditions for Unix Account (SSH) Secrets (for both Password Rotation and SSH Key Rotation)
NOTE: [For the Unix (SSH) account secret type only:] PuTTY needs to be installed on the computer with the Syteca Connection Manager for the secret to work, and the "Use SSH key" option can also be selected instead of the "Use password" option when adding the secret.
Syteca allows the passwords and SSH keys of Unix Account (SSH) secrets to be rotated, which means that they are changed automatically (to a new randomly-generated password) on a regular basis to reduce the risk of them being compromised.
An SSH secret has two account options for connection:
• Using a password
• Using an SSH key
Accordingly, rotation of SSH passwords and SSH keys work in different ways.
NOTE: In most cases, the target host defined in the secret will use an OpenSSH server that is commonly used in most Linux systems. For this reason, for the purposes of this document it is assumed that this SSH server is used. For correct usage and password/key rotation of Unix account (SSH) secrets, the target host defined in the SSH secret should first of all be correctly configured and running the OpenSSH server.
SSH Password Rotation for Unix Account (SSH) Secrets
Preconditions: The user Login and Password defined in the Unix account (SSH) secret should be valid for the target host.
Rotation logic: The Syteca Application Server connects to the target host using the credentials defined in the secret, and changes the password of the current user to the new one generated.
Both the old and new passwords are stored in the Application Server database during all operations, and the old password is deleted from the database only after all operations have completed successfully.
In the case of failure, the secret's password is restored to a valid state using one of the two passwords.
SSH Key Rotation for Unix Account (SSH) Secrets
Preconditions: The user Login and Private Key (and the Private Key Passphrase) defined in the Unix account (SSH) secret should be valid for the target host, and the corresponding public key needs to be located in the ~/.ssh/authorized_keys file (in the user's home directory on the target host).
As an SSH client, the PuTTY application can be used, and should be installed on the computer with the Syteca Connection Manager (although this is not required for rotation, the SSH key used in the secret should be in the PuTTY format). For PuTTY key generation, and for OpenSSH server configuration using PuTTY, see: https://www.ssh.com/academy/ssh/putty/windows/puttygen.
Rotation logic: The Syteca Application Server connects to the target host using the Login and Private Key defined in the secret, and replaces the public key defined in the ~/.ssh/authorized_keys file with the new one that corresponds to the new PuTTY key generated.
Both the old and new keys (and their passphrases) are stored in the Application Server database during all operations, and the old key is deleted from the database only after all operations have completed successfully.
In the case of failure, the secret key (and passphrase) are restored to a valid state using one of the two keys.
If the connection via a Unix Account (SSH) secret to the remote Linux computer using an SSH key is successful, but the password rotation for this secret fails (with the following error added to the System Health Transaction log: "Password rotation for Secret SSH failed. Error: Permission denied (publickey)"), then "PubkeyAcceptedKeyTypes +ssh-rsa" needs to be added to the /etc/ssh/sshd_config file, as follows.
• In the /etc/ssh directory, open the ./sshd_config file (which is read-only) in an editor to be able to make changes.
• Add "PubkeyAcceptedKeyTypes +ssh-rsa" to the file, and save the changes.
• Run the following command: sudo systemctl restart sshd