One Identity Safeguard 2.7 - User Guide

Introduction

The One Identity Safeguard for Privileged Passwords User Guide is intended for non-administrative users who are authorized to request, approve or review access requests. It provides detailed instructions for performing these tasks using the Safeguard for Privileged Passwords desktop client.

Introduction to One Identity Safeguard for Privileged Passwords

The One Identity Safeguard for Privileged Passwords Appliance is built specifically for use only with the Safeguard for Privileged Passwords privileged management software, which is pre-installed and ready for immediate use. The appliance is hardened to ensure the system is secured at the hardware, operating system and software levels. The hardened appliance approach protects the privileged management software from attacks while simplifying deployment and ongoing management -- and shortening the timeframe to value.

Safeguard privileged management software suite

Safeguard privileged management software is used to control, monitor, and govern privileged user accounts and activities to identify possible malicious activities, detect entitlement risks, and provide tamper proof evidence. The Safeguard products also aid incident investigation, forensics work, and compliance efforts.

The Safeguard products' unique strengths are:

  • One-stop solution for all privileged access management needs
  • Easy to deploy and integrate
  • Unparalleled depth of recording
  • Comprehensive risk analysis of entitlements and activities
  • Thorough Governance for privileged account

The suite includes the following modules:

  • One Identity Safeguard for Privileged Passwords automates, controls and secures the process of granting privileged credentials with role-based access management and automated workflows. Deployed on a hardened appliance, Safeguard for Privileged Passwords eliminates concerns about secured access to the solution itself, which helps to speed integration with your systems and IT strategies. Plus, its user-centered design means a small learning curve and the ability to manage passwords from anywhere and using nearly any device. The result is a solution that secures your enterprise and enables your privileged users with a new level of freedom and functionality.
  • One Identity for Privileged Sessions is part of One Identity's Privileged Access Management portfolio. Addressing large enterprise needs, Safeguard for Privileged Sessions is a privileged session management solution, which provides industry-leading access control, as well as session monitoring and recording to prevent privileged account misuse, facilitate compliance, and accelerate forensics investigations.

    Safeguard for Privileged Sessions is a quickly deployable enterprise appliance, completely independent from clients and servers - integrating seamlessly into existing networks. It captures the activity data necessary for user profiling and enables full user session drill-down for forensics investigations.

  • One Identity Safeguard for Privileged Analytics integrates data from Safeguard for Privileged Sessions to use as the basis of privileged user behavior analysis. Safeguard for Privileged Analytics uses machine learning algorithms to scrutinize behavioral characteristics and generates user behavior profiles for each individual privileged user. Safeguard for Privileged Analytics compares actual user activity to user profiles in real time and profiles are continually adjusted using machine learning. Safeguard for Privileged Analytics detects anomalies and ranks them based on risk so you can prioritize and take appropriate action - and ultimately prevent data breaches.

Overview of the entities

Safeguard for Privileged Passwords is a password, keys, and secrets vault to secure assets including computers, servers, network devices, directories, and applications. Two types of access may be granted to assets 1) passwords (including secrets) and 2) sessions.

A high level introduction to the Safeguard for Privileged Passwords entities and how they relate follows.

Assets, partitions, and partition profiles

Assets include computers, servers, network devices, directories, or applications for Safeguard to manage. Assets have associated users and service accounts. Assets and accounts may be imported (for example, from Active Directory). Assets may or may not be part of an asset group.

The partition is a container for delegated management for account passwords (including check and change). Partitions are also useful to segregate assets to various owners to achieve Separation of Duties (SoD). Partitions allow you to set up multiple asset managers, each with the ability to define password guidelines for the managed systems in their own workspace. Typically you would partition assets by geographical location, owner, function, or by operating system. For example, you can group Unix assets in a partition and delegate the Unix administrator to manage it. Every partition should have a partition owner.

An asset can be assigned to only one partition at a time. When you assign an asset to a partition, all accounts associated with that asset are automatically reassigned to that partition, as well. Then, any new accounts you add for that asset are automatically assigned to that partition.

The partition profile includes the schedules and rules governing the partition’s assigned assets and the assets' accounts. For example, the partition profile defines how often a password check is required on an asset or account.

A partition can have multiple partition profiles, each assigned to different assets, if desired. An account is governed by only one profile. If an account is explicitly assigned to a profile, the account is governed by the one assigned to the parent asset. If that asset does not have an assigned profile, the partition's default profile is assigned.

When you create a new partition, Safeguard for Privileged Passwords creates a corresponding default profile with default schedules and rules. You can create multiple profiles to govern the accounts assigned to a partition. Both assets and accounts are assigned to the scope of a profile.

For example, suppose you have an asset with 12 accounts and you configure the partition profile to check and change passwords every 60 days. If you want the password managed for one of those accounts every 7 days, you can create another profile and add the individual account to the new profile. Now, Safeguard for Privileged Passwords will check and change all the passwords on this asset every 60 days except for this account, which will change every 7 days.

In the example above, Partition A has three profiles (Profile A, B, and C) and a default profile. Profile A checks passwords every 30 days. Profile B checks passwords every 3 months, and Profile C has the highest level of security, checking passwords every 7 days. Note that the asset Server has two partition profiles each governing different accounts associated with the asset. Profiles A, B, and C are all explicitly assigned to the accounts and assets shown. Asset Cloud service doesn't have an explicitly assigned profile so the default will be used to manage accounts on the asset.

Details: Assets and asset groups

  • An asset may be a computer, server, network device, directory, or application.
  • You can log into an asset with more than one account, but an account can only be associated with one asset.
  • If you select an asset for a profile, all accounts are included.

  • An asset must be assigned to only one partition. An asset typically has a profile, but it is not mandatory.
  • You can create multiple assets for the same device or application then manage different accounts on each asset. For example, a directory asset can manage a subset of the forest.

  • An Asset Group is a set of assets that can be added to the scope of an entitlement's access request policy.

Details: Partitions and partition profiles

  • A partition is a group of assets (and the assets’ associated accounts) governed by a partition profile and used to delegate asset management. An asset can only be in one partition at a time. All accounts associated with that asset are automatically added to the partition.
  • Partition profiles are the schedules and rules that govern a partition’s assets and the assets’ accounts. You can set a default partition profile to assign or you can manually assign a partition profile to an asset or account.
  • When a partition is created, a default profile is created for that partition. This profile is implicitly associated with all assets and accounts added to the partition. Later, a different profile can be manually assigned to assets and account which is referred to as an explicit association. Explicit associations (manual assignments) override implicit associations (auto-assignments).

Accounts, account groups, entitlements, and entitlement access request policies

Assets have associated accounts, like a user account or an account for a Windows service. An account can only be associated with one asset.

Entitlements grant access to users, user groups, or both. An entitlement includes one or more access request policies and may be related to job functions like help desk support or Unix administrators.

An entitlement access request policy defines what is managed by the policy and is referred to as the "scope of the policy". There are two types of access requests: password and sessions.

  • To define an access request policy for a password request, the valid scope properties are accounts and account groups.
  • To define an access request policy for a sessions request, the valid scope properties are accounts, account groups, assets, and asset groups. If only assets or asset groups are defined in the access request policy, the Asset Based Session Access must have an option other than None.

Entitlement access request policies may include:

  • The access type: Password or sessions which include SSH or RDP (remote desktop)
  • The scope: Accounts, account groups, assets, and asset groups as needed
  • Requestor settings: For example, reason for the request, comment, ticket number, and access duration
  • Approver and Reviewer settings: If required, the approvers and reviewers along with notifications
  • Access configuration: Settings based on the type of access (Password, SSH, or RDP set earlier)
  • Session settings: If used, record sessions
  • Time restrictions: If used, days and hours of access
  • Emergency settings: If used, who to contact

In the example above, each account or account group is assigned to only one asset. The Server asset is associated with Account D and Account Group A which is made up of several accounts. Entitlement access request policy A is assigned to Account Group A so that group can check out passwords from 8 am to 5 pm Monday through Friday with no approval required. Entitlement access request policy B, which is associated with Account D, allows for password checkout for the same time frame but the checkouts require approvals. Entitlement access request policy C allows for password checkout from 12:59 am to 11:01 pm to allow for the system maintenance window.

Details: Accounts and account groups

  • An account can only be associated with one asset.

  • An account group is a set of accounts that can be added to the scope of an entitlement's access request policy. An account group can span multiple assets.
  • Directory accounts are associated with assets that are directories.
  • Both directory accounts and directory assets can can be visible or "shared" across partition boundaries, for specific purpose. Directory assets can be shared for for Asset Discovery jobs. Directory accounts can be used as a service account or dependent account to a Windows service or task.

Details: Entitlements and access request policies

  • An entitlement is a set of access request policies that restrict resources, typically by job role.
  • Entitlements are used to authorized users or members of user groups to access accounts in the scope of the set of the entitlement's access request policies. One entitlement may have zero, one, or multiple access request policies. Users and user groups can be added to entitlements.
  • Access request policies contain the details of the type of access as well as conditions. For example, the type of access may include password versus session (RDP, SSH, other protocols), time limits, individual accountability (change after check-in), and other settings. Conditions may include number of approvers, time of day, ticketing system, reason codes, and other conditions. An access request policy can only be associated with one entitlement.

  • Access request policies are scoped to resources. Sometimes that scoping is done directly to accounts and the asset is implied. Or, the scoping is done to the asset and the access request policy identifies the account.

Users and user groups

Users are individuals. A user may be assigned administrative permissions to govern assets, partitions, accounts, and entitlement access request policies. A user may be assigned more than one set of permissions by the Authorizer Administrator. It is a best practice to follow the principles of separation of duties (SoD) in administration assignments. For example, the assignment of Asset Administrator, Policy Administrator, User Administrator, and Auditor should be different users.

Standard users do not have administrative permissions. They can request access, approve access requests, or review completed access requests.

Users can be configured for two-factor authentication.

Details: Users and user groups

  • A user is a person who can log into SPP. A user can be associated with an identity provider that is local or a user can be a directory user from an external identity store such as Microsoft Active Directory. A user may be associated with user groups, partitions, entitlements, and linked accounts.

  • A user group is set of users that can be added to an entitlement, typically based on roles. The user group's access is governed by the entitlement’s access request policies. Both local user groups and directory user groups can be added to SPP.
  • A user can be assigned administrative permissions over assets, security, and so on. A standard user has no administrative permissions and performs other duties, for example, to approve access requests.

Discovery

You can discover assets and accounts that are not being managed so you can place them under management, if appropriate. Discovery jobs can be configured to discover assets and accounts.

Password request high level workflow

  1. A user or service requests the password of an account.

  2. Based on the entitlement access request policy, the password is automatically granted or the password request can be sent through an approval process. The workflow can also include a reviewer to review all access activities for legitimacy.
  3. The session launches on a machine or via a graphical user interface such as SSH or RDP (Remote Desktop Protocol).

Passwords can be checked in or are otherwise valid for the duration of the request. Safeguard resets the password and passwords are constantly changing to monitor and audit access to assets.

Session access

Session access and activities are proxied through Safeguard and are captured in audit logs. Session activities at the screen and keystroke level can be captured, viewed, and used for forensic audits.

Key features

The following key features are available in Safeguard for Privileged Passwords.

Table 1: One Identity Safeguard for Privileged Passwords key features
Feature Description

Auto-login

Auto-login and sessions access request launch enhances security and compliance by never exposing the account credentials to the user.

Activity Center

Using the Activity Center, you can quickly and easily view all actions executed by Safeguard for Privileged Passwords users and integrated processes. Activity Center reports can be searched, customized and filtered to zero-in on the actions of a single user or to audit a variety of actions across a subset of departments. In addition, you can schedule queries, and save or export the data.

Always online

Safeguard for Privileged Passwords Appliances can be clustered to ensure high availability. Passwords and sessions can be requested from any appliance in a Safeguard for Privileged Passwords cluster.

This distributed clustering design also enables the recovery or continuation of vital technology infrastructure and systems following a natural or human-induced disaster.

Approval Anywhere

Leveraging One Identity Starling, you can approve or deny any access request anywhere without being on the VPN.

Directory integration

You can leverage your existing directory infrastructure (such as Microsoft Active Directory). You import import directory users and directory groups. Directory users authenticate to Safeguard for Privileged Passwords with their directory credentials.

Active Directory and LDAP data is automatically synchronized by asset or identity and authentication providers schema as shown in the following lists.

Asset schema list

  • Users
    • Username
    • Password (modifiable in LDAP and not modifiable in Active Directory)
    • Description
  • Groups
    • Name
    • Member
  • Computer
    • Name
    • Network Address
    • Operating System
    • Operating System Version
    • Description

Identity and Authentication Providers schema list

  • Users
    • Username
    • First Name
    • Last Name
    • Work Phone
    • Mobile Phone
    • Email
    • Description
    • External Federation Authentication
    • Radius Authentication
    • Managed Objects
  • Groups
    • Name
    • Members
    • Description

Discovery

Quickly discover any privileged account or system on your network with host , directory, and network-discovery options.

Event notification options

Safeguard for Privileged Passwords allows you to configure the appliance to send event notifications to external systems such as Email, Syslog, and SNMP.
Favorites Quickly access the passwords that you use the most right from the Home screen.

Partitions and Profiles

Safeguard for Privileged Passwords allows you to group managed systems into secure work areas that can be designated for delegated management.

Release control

Manages password requests from authorized users for the accounts they are entitled to access via a secure web browser connection with support for mobile devices.
RESTful API Safeguard for Privileged Passwords uses a modernized API based on a REST architecture which allows other applications and systems to connect and interact with it. The API enables quick and easy integration with diverse systems and applications spanning many programming languages.

Role-based access control (RBAC)

Safeguard for Privileged Passwords uses a role-based access control hierarchy using administrator permissions sets. Numerous roles are available for administrating Safeguard for Privileged Passwords enabling granular delegation and workflows along with least privileged access.
Secure access to legacy systems

Use smartcard, two-factor authentication or other strong authentication methods to gain access to systems. Because Safeguard for Privileged Passwords acts as a gateway or proxy to the system, it enables strong authentication to targets that cannot or do not support those methods natively.

Smartcard support Authentication of your privileged users can be integrated with Microsoft's Active Directory support for Smartcards or manually uploaded to the Safeguard for Privileged Passwords Appliance itself.

Two-factor authentication support

Protecting access to passwords with another password isn't enough. Enhanced security by requiring two-factor authentication to Safeguard for Privileged Passwords. Safeguard for Privileged Passwords supports any Radius-based 2FA solution and One Identity's Starling Two-Factor Authentication service.
Workflow engine A workflow engine supports time restrictions, multiple approvers and reviewers, emergency access, and expiration of policy. It also includes the ability to input reason codes and/or integrate directly with ticketing systems. An access request can be automatically approved or require multiple sets of approvals.
Sessions key features

To record and playback sessions, you may use one of the following methods:

  • The embedded sessions module that comes with Safeguard for Privileged Passwords.

    CAUTION:The embedded sessions module in Safeguard for Privileged Passwords version 2.7 will be removed in a future release (to be determined). For uninterrupted service, organizations are advised to join to the more robust Safeguard for Privileged Sessions Appliance for sessions recording and playback.

  • Use Safeguard for Privileged Sessions via a join to Safeguard for Privileged Passwords.

    The join is initiated from Safeguard for Privileged Sessions. For details about the join steps and issue resolution, see the One Identity Safeguard for Privileged Sessions Administration Guide at this link: One Identity Safeguard for Privileged Sessions - Technical Documentation.

Table 2: Key features using sessions

Command detection

During a privileged session, commands that are being run on the target host are detected. All actions are logged and can be sent out, if configured, to various logging mechanisms (syslog, email, SNMP).

NOTE: For an RDP session, Safeguard for Privileged Passwords can detect the title of any window that is opened on the desktop during a privileged session.

Full session audit, recording and replay

With sessions, every packet sent and action that takes place on the screen -- including mouse movements, clicks and keystrokes -- is recorded and available for review. The time and content of the session are cryptographically signed for forensics and compliance purposes. Only actual activity is recorded, and recordings are compressed to a fraction of the size required by other solutions to minimize offline storage requirements.

Indexing

With sessions, you can create a searchable list of commands and programs that were run during the recorded session. Auditors have a quick and easy view to session activities.

Protocol support

The embedded sessions module provides full support for the SSH and RDP protocols. In addition, administrators can decide what options within the protocols they want to enable/disable.

Proxy access All sessions are proxied to target resources. Since users have no direct access to resources, the enterprise is protected against viruses, malware, and other dangerous items on the user's system. The embedded sessions module can proxy and record Unix/Linux, Windows, network devices, firewalls, routers and more.

Work the way you want

Sessions enables administrators to choose their access tools and tool preferences (for example, PuTTY) when gaining access to privileged sessions. This creates a frictionless solution that gives administrators the access they need while meeting compliance and security regulations.

Self Service Tools
Knowledge Base
Notifications & Alerts
Product Support
Software Downloads
Technical Documentation
User Forums
Video Tutorials
Contact Us
Licensing Assistance
Technical Support
View All
Related Documents