User impersonation

This topic explains how to set up user impersonation for Deployment Automation agents on Windows and UNIX/Linux.

Overview

Deployment Automation enables you to apply user impersonation when an agent must run a command for which it might not have permission, or when a specific user must be employed for a given process.

For example, to run a database update script, an agent might need to be the oracle user. However, to update the application, the agent needs to be the websphere user. By using impersonation, the same agent can run the script and update the application as part of a single process.

To set up user impersonation:

  • On UNIX/Linux systems, use the ssh, sudo, or su commands.
  • On Windows, use a utility program provided by Deployment Automation.

    Note: User impersonation is not supported for z/OS agents.

Back to top

User impersonation on UNIX/Linux

For agents running on UNIX/Linux platforms, you can provide the agents with the user impersonation capability when you configure a process step.

Select from these options: ssh (secure shell), sudo (superuser "doer"), and su (superuser).

When a process step has user impersonation configured, the ssh, sudo, or su command runs the step as the impersonated user.

Note: Each process step that needs user impersonation must be configured independently.

Process steps can be considered individual shells. The ssh, sudo, or su command enables a user to start a shell as another user.

To configure impersonation:

  1. In Deployment Automation, open or create a process. For details, see Create and design component processes.
  2. In the process designer, select the process step in the design space to view its properties.
  3. In Properties, select the Use Impersonation check box. Additional fields are displayed.
  4. Specify the following information:

    Field Description
    User The username to authenticate as during impersonation.

    Password

    The password to use during impersonation.

    For *nix impersonation types:

    • SSH. The password of user to impersonate.
    • SU. The password should be blank.

    • SUDO. The password of user that the agent is running under, if required.

    For Windows: The password of the user to impersonate.

    *nix Impersonation Type

    Select SSH, SUDO, or SU:

    • SSH

      SSH authentication is used to perform impersonation. You must install, configure, and start the SSH daemon on your agent machines.

    • SUDO

      Before you can use it, you must provide impersonation privileges as follows:

      • Password Required. Impersonation privileges must be defined in the /etc/sudoers file along with grant privileges to run scripts from the agent temp directory, for example:

        User1<>ALL=(User2)/home/User1/agent/var/temp/*
        

        Grants User1 the privilege to impersonate User2 to run plugin steps as User2.

        Defaults:X!requiretty
        X ALL=(Y) 

        where X and Y are user names, and user X can run any command as user Y.

      • No Password Required. Impersonation privileges must be defined in the /etc/sudoers file, for example:

        Defaults:X!requiretty
        X ALL=(Y) NOPASSWD: ALL 

        where X and Y are user names, and user X can run any command as user Y without supplying a password.

    • SU

      You can use it only on agents running under the root account.

    For more information on configuring ssh, sudo, and su, see the UNIX/Linux documentation.

Back to top

Passwordless SSH impersonation on UNIX/Linux

For agents running on UNIX/Linux platforms, you can set up passwordless SSH impersonation using either default SSH keys or SSH keys with a non-default name or location.

Note: Take into account the following limitations:

  • SSH Protocol version 1 is not supported.
  • Passwordless SSH impersonation on Windows agents is not supported.
  • DA only reads SSH keys and is not responsible for their delivery and maintenance.

The following table explains how to use both methods:

Method How to

Use default SSH keys

You need:

  • A successful SSH connection using the console client without specifying an identity file.
  • SSH key default location and name without additional configurations, for example: ~/.ssh/id_rsa
Use non-default SSH keys

Specify the location and name of the keys in one of these configuration files:

/etc/ssh/ssh_config
<agent_user_home>/.ssh/config

Example: Sample configuration file:

Host 127.0.0.1
	IdentityFile ~/.ssh/key_file_123

where IdentityFile is the path to the secret key.

Take into account the following:

  • Only the configuration parameter IdentityFile is supported. All other parameters are ignored.
  • The value for the parameter User is taken from the impersonation settings.
  • For details about the configuration file format, enter man ssh_config in the terminal of any UNIX or Linux system that has SSH installed.
  • Host should be 127.0.0.1, not localhost.

Back to top

User impersonation on Windows

For agents running on Windows platforms, Deployment Automation provides a program that handles impersonation.

You implement impersonation for Windows-based agents the same way you do for UNIX/Linux-based agents. When you configure a process step, you specify the credentials that will be used to log in on the agent when the step is processed. This is a different user than the user under which the agent normally runs.

To run process steps on a Windows agent, you must:

  • Have a user name and password stored on the target agent computer.
  • Be a part of the Administrators group.
  • Have, at a minimum, the following privileges:

    Constant Privileges
    SE_INCREASE_QUOTA_NAME Adjust memory quotas for a process.
    SE_ASSIGNPRIMARYTOKEN_NAME Replace a process-level token.
    SE_RESTORE_NAME Restore files and directories.
    SE_BACKUP_NAME Back up files and directories.
    SE_TCB_NAME Act as part of the operating system. Required for Windows Vista and later.

In addition, they must have at least one of the following logon permissions.

Constant Permissions
SE_INTERACTIVE_LOGON_NAME Log on locally.
SE_SERVICE_LOGON_NAME Log on as a service.
SE_BATCH_LOGON_NAME Log on as a batch job.

Back to top

See also: