Setting up email notifications
To demonstrate how Safeguard for Privileged Passwords sends out event notifications, you must configure Safeguard for Privileged Passwords to automatically send email notifications when certain events occur. For the purposes of this software evaluation, we have you set up a template for Access Request Auto-Approval.
To setup email notifications
- Navigate to Administrative Tools and select Settings.
- In Settings, select External Integration | Email.
- To configure the Email notifications, enter these settings for all Safeguard for Privileged Passwords emails:
|SMTP Server Address
Enter the IP address or FQDN of the mail server.
NOTE: If you are using a mail exchanger record (MX record), you must specify the domain name for the mail server.
Enter the TCP port number for the email service.
Enter your email address.
|Require Transport Layer Security
||Select this option to require that Safeguard for Privileged Passwords uses TLS to provide communication security over the internet.|
To validate your setup
- Select the Test Email Settings link.
- Enter your email address as the Send To email address and click Send.
Safeguard for Privileged Passwords sends an email using the configuration settings.
Creating local users
Standard users do not have any Safeguard for Privileged Passwords administrative permissions. These users can be granted rights to request access, approve access requests, or review completed access requests. For more information, see the Safeguard for Privileged Passwords Administration Guide, Adding a user section.
Note: You can perform the exercises in this guide with directory users as well as local users. To do that, you must add a directory, directory users, and an authentication provider.
To streamline your software evaluation, we recommend that you simply use local users. The access request workflow is the same no matter what users perform them. To make your user experience more realistic, you can set up other local users from your test lab to be a Requester, Approver, and Reviewer or use the test users we suggest creating below.
To create local users
- Log in to the Windows desktop client as UserAdmin.
- From the Home page, navigate to Administrative Tools and select Users.
- In Users, click Add User to add the following Safeguard for Privileged Passwords non-administrator users:
||The Requester user, authorized to request access.|
The Approver user, authorized to approve access requests.
See the following procedure for more information on how to configure Abe for two-factor authentication.
||The Reviewer user, authorized to review past (or completed) access requests.|
||The delegated partition owner.|
To configure a user for two-factor authentication
NOTE: Abe will be authorized to approve access requests.
- As the UserAdmin add a new local user named Abe.
- On the Authentication page:
- Authentication Provider: Select Local.
- User Name: Enter Abe.
- Password | Confirm Password: Enter Test123.
- Require Secondary Authentication: Select this check box.
- Authentication Provider: Select the Starling 2FA service provider.
- Use alternate mobile phone number: Optionally, select this check box and enter an alternate mobile number to be used for two-factor authentication notifications.
- On the Contact page:
- Mobile Phone: Enter your mobile phone number.
- Email Address: Enter a valid email address.
- Finish adding the local user to Safeguard for Privileged Passwords.
- Log out of Safeguard for Privileged Passwords.
- Log in as the PolicyAdmin and navigate to Administrative Tools | Settings | External Integration | Approval Anywhere.
- Click Add to add Abe as a user authorized to use the Approval Anywhere feature.
- Log out of Safeguard for Privileged Passwords.
Adding assets and accounts
Now let's add some systems so that you can see how Safeguard for Privileged Passwords manages them. A background in the assets, entities, partitions, and accounts will help your understanding. For more information see the following sections in Overview of the entities :
To add partitions, assets, and accounts to Safeguard for Privileged Passwords
- Log in as AssetAdmin and navigate to Administrative Tools.
- In Partitions, click Add Partition to add these partitions. For more information, see the Safeguard for Privileged Passwords Administration Guide, Adding a partition section.
||The Linux Administrator's workspace
||The Windows Administrator's workspace
The Directory Administrator's workspace
- Configure the Profile check and change schedules to run daily. For more information, see the Safeguard for Privileged Passwords Administration Guide, Creating a partition profile section.
- Navigate to Settings | Profile | Check Password (and Change Password).
- Double-click each schedule to modify the schedule.
- Select Schedule and choose the Day interval, set the time of day, and leave the daily repeat interval set to one day.
- In Assets, add some Linux, Windows, and Directory devices. Be sure to put them into the appropriate partition. For more information, see the Safeguard for Privileged Passwords Administration Guide, Adding an asset section.
Note: To observe how Safeguard for Privileged Passwords automatically changes passwords, set up assets from your test lab, with actual network addresses, service accounts, and passwords.
Run Test Connection on the Connection tab to ensure that Safeguard for Privileged Passwords can communicate with the asset.
Once you add an asset, add one or more unique accounts for each asset. These are the accounts Safeguard for Privileged Passwords will use to give people access to the asset. In Assets, select the asset and opened the Accounts tab. Click Add Account. For more information, see the Safeguard for Privileged Passwords Administration Guide, Adding an account to an asset section.
- After you add the account, right-click (or press and hold) the new account to set the password (Account Security | Set Password).
- Make the asset available for discovery. Select the asset then, on the General pane, scroll to Account Discovery and click Edit. Add the details for the discovery including the rules.
- Log out.
Now that we have demonstrated that Safeguard for Privileged Passwords is actually managing your account passwords, let's define some rules for requesting password release and session access requests, such as the maximum duration, how many approvals are required, and so forth.
For more information see the following section in Overview of the entities
To write the entitlements that govern access requests
- Log in as PolicyAdmin and navigate to Administrative Tools.
- In Settings, select Access Request | Reasons and add these access request reason codes:
||SSH Session Request|
||RDP Session Request|
- In User Groups add these user groups. For more information, see the Safeguard for Privileged Passwords Administration Guide, Adding a user group section.
||Users authorized to approve password release requests.
||Users authorized to request passwords.
||Users authorized to review password release requests.
- On the Users tab, add each user to the specified user group.
- In Account Groups, add the following account groups. For more information, see the Safeguard for Privileged Passwords Administration Guide, Adding an account group section.
|Linux Server Accounts
||Accounts for the Linux machines|
|Windows Server Accounts
||Accounts for the Windows machines|
Directory Server Accounts
Accounts for the Directory machines
- On the Accounts tab, add the appropriate accounts to each account group.
- In Entitlements, add the following entitlements. For more information, see the Safeguard for Privileged Passwords Administration Guide, Adding an entitlement section.
Note: At this time, do not set entitlement time restrictions.
|Linux Password Requests
||The rules that govern password release requests for the Linux Servers|
|Windows Password Requests
||The rules that govern password release requests for the Windows Servers|
Directory Password Requests
The rules that govern password release requests for the Directory Servers
||The rules that govern session access requests|
- Stay logged in as the Security Policy Administrator (PolicyAdmin) and proceed to the next exercise.
Now let's add access request policies to each of these entitlements that restrict system access to authorized users.