Enabling client-based login

Client-based login is a way that you can use the Centrify Client to log in to other systems that you have registered in Privileged Access Service. There are two main components to enabling client-based login:

  • Grant client-based login permission (also called the AgentAuth permission) to the desired user accounts or roles.

  • Enable the client-based login feature (also called the AgentAuth feature) when you enroll a system with the Centrify Client.

Below is some information about how client-based login differs on Windows and Linux systems, and then how to enable client-based login.

About client-based login on Windows

The first time that you log in to a Windows system using client-based login, the service creates a new, local user that corresponds to your Privileged Access Service account if your account is a Centrify Directory or a federated account. Each time that you log in this way the service rotates the password to a random string of 32 characters. If your account is based in Active Directory, the service does not create a local account for you; you log in with your Active Directory credentials.

The service also assigns this user to local groups according to local group mapping rules that you have configured. Any changes that you make to the local group mapping configurations take effect the next time the user logs in. If an affected user is currently logged in when you make the changes, the changes take effect after the user logs out and logs in again.

This local user operates as a background user and does not show up in any lists of local users inside of Privileged Access Service; you can see this local user in the Local Users and Groups on Windows. This local account stays provisioned until you uninstall the client.

Removing the Windows local account

You can choose to remove this local Windows user account when the session terminates; the setting is Removing local accounts upon session termination - Windows only. Removing the local account helps fulfill compliance requirements and also helps facilitate just-in-time (JIT) privilege elevation with ephemeral account provisioning, in conjunction with local group mapping and the client-based login (Agent Auth) workflow.

In general, administrators configure client-based login with local group mapping as follows:

  • Enable the Agent Auth Workflow in a policy that applies to all systems, a set, or the individual system

  • Map the user's role to the Administrators group

  • Enable the setting to remove local account in a policy that applies to the desired scope

Here's an example of how the process of just-in-time privilege elevation works; this example involves a user named Kayla who needs to run some administrator scripts on a Windows system:

The administrators have already enabled the Agent Auth feature on the Windows system. They have specified that the service will delete the local Windows account upon session termination; they have specified this using a policy.

For more information, see the following topics:

  1. Kayla requests and receives permission to log in to the designated Windows system:

    1. She logs in to the Admin Portal and navigates to the desired Windows system.

    2. She follows the Agent Auth workflow to request permission to access a particular Windows system.

    3. Her manager approves the request and grants Kayla permission for 1 hour.

  2. Kayla logs in to the designated Windows system successfully.

    Upon login, the service creates a local admin account and provisions it into the Administrators group based on the local group mapping (configured by the administrator).

  3. She performs the necessary work on the Windows system.

  4. Kayla logs out of the designated Windows system.

    The service deletes the local Windows account that was created in Step 3 and revokes all access for that account. The user will need to request login permissions when needed.


About client-based login on Linux

The first time that you log in to a Linux system using client-based login, the PAM and NSS modules for the Centrify Client handle the authentication and group membership of your account. The service does not create a local user account. If desired, you can modify any default Linux user configuration settings under Settings > Enrollment > Linux Settings.

Enabling the AgentAuth feature and granting the AgentAuth permission

To enable client-based login for a system and a user or role

  1. Enroll the computer in the Privileged Access Service and enable the AgentAuth feature.

    In the Centrify Client for Windows installer, you can enable all features by not entering anything in the Optional Parameters section. Or, you can enter AgentAuth as a parameter to only enable client-based login.

    If you're using the cenroll command either on Windows or Linux, you can include either of the following options to enable either just the client-based login or all features:

    --features AgentAuth

    --features All

    You can also enable Centrify Client features in the Admin Portal. For details, see Enabling client features.

    For details about Centrify Client commands and options, see Using Centrify Client commands.

  2. Log on to the Privileged Access Service.

  3. Click Resources > Systems, then click the computer you registered to display its details.

  4. Click Permissions.

  5. Click Add, if necessary, to find and select the user account or role, then select Agent Auth.

    For example, if you want to add client-based login for the user kris-pubs@acme.com.720 on this computer, you would add the user to the list of accounts that have permission on the system then select the Agent Auth permission.

    Note:   You can configure client-based login for a specific system or a set of systems.

  6. Click Save.