For target accounts associated with UNIX target applications there are four different privilege elevation settings available. Changing this setting can make password synchronization work or fail. What we are missing are detailed descriptions of each privilege elevation setting that would help us determine which setting is right for which accounts.
This applies to any current PAM implementation.
The "Privilege Elevation" setting under the UNIX tab for target accounts associated with a UNIX target application has four options that relate to what privilege elevation capabilities the account has on the target server. The following list should provide enough information to choose the right setting for a given account. We assume here that the privilege elevation command is "sudo" and the password change command is "passwd".
1. "Do not use elevated privileges" - Select this option for an account that is not allowed to run sudo to elevate its privileges on the target server. When the account tries to change its own password using the passwd command, it has to provide the current password first. Accounts without privilege elevation will not be able to update passwords of other accounts.
2. "Use elevated privileges" - Select this option for an account that is allowed to run sudo commands without having to provide its own password to sudo. This would be the case if the account had the "NOPASSWD" flag set in the /etc/sudoers file, which generally is regarded insecure and not recommended. Such accounts can change passwords of other accounts including root.
3. "Use elevated privileges with authentication" - Select this option for accounts that can run sudo commands, but will be prompted for their own password by sudo before the command is executed with elevated privileges. This is the normal and recommended sudo configuration. Such accounts can change passwords of other accounts including root.
4. "This account is a root account" - Select this option for accounts that need no privilege elevation. Such accounts can change their own password w/o having to provide the current password first. They also can change passwords of other accounts w/o use of the sudo command.
Note that in older releases the default password update script invoked the sudo command even for root accounts while changing passwords of other accounts. This caused a problem if the root account was not listed in the sudoers file, which is not needed for root. From releases 3.0.3, 3.1.2 and 3.2 on the default script no longer will invoke the sudo command if the "This account is a root account" option is selected.
As of the writing of this document, January 3, 2019, the privilege elevation setting is only available for accounts using password authentication. It is not available for accounts using public key authentication. This does not matter for public key authentication accounts updating their own key, or if the key account is a root account. But it is a problem if a non-root key account is meant to update the password of other accounts. We expect a change in new releases in the near future to allow setting of the "Use elevated privileges" option for SSH key accounts. This will allow such accounts to update the passwords of other accounts using "sudo" w/o authentication. As PAM wouldn't have the account password stored, the "Use elevated privileges with authentication" option does not make sense for SSH key accounts.