Password Management is the core functionality of the PIM suite – the reason your organization

bought the product. Some of the key components of password management include:
• Credentials Storage and Retrieval – at its most basic level, the vault allows you to store your
passwords in an highly secured environment while allowing appropriate users monitored access
to these passwords. This is an obvious first step to configuring password management. Some
customers will opt to use CyberArk only for storage and retrieval for short period as they
become comfortable with the system. Loading credentials can be done manually, through a
Password Upload Utility or through Auto-Detection.
• With Password Verification, CyberArk will confirm that the password stored in the vault can
actually be used to login to the target system. Password verification can be user-initiated or
handled automatically.
• CyberArk can initiate a Password Change on a target system automatically or through a user
action. Passwords generated by CyberArk must conform to the password requirements of the
target system and the organization’s security policy.
• Reconciliation of unknown or lost passwords – Passwords on target can become out of sync
with those stored in the Vault. Users might change a password manually or it could be an
automatically detected server in which the password is not known. For these occasions
another account (called a reconcile account) with the appropriate rights can be configured to
force a password change.
• All of the above can be configured to manage the Automatic application of organizationally
defined password rules through CyberArk policies.
Policy Type – Regular or Group
• Regular is the default and is used by most accounts
• Group is used when you have multiple systems with the same account id and password.
• Typically used in a clustered environment
Search for Usages – Are there any service accounts associated with the Target account
• Default is Yes for Windows platforms
• Default is No for Linux Platforms
Allowed Safes – Which safes will be checked for accounts that use this platform
• Safes can contain accounts associated with different platforms
• This help processing load on the CPM by limiting which safes have to be checked
• This field is Regular Expression
• Default includes wild card characters “.*”
• It is case sensitive
• Entry above = *.*LIN* - every safe name that includes Lin in the name
Safe are logical access unit used by groups, who have rights based on access rules.

To create a safe:
• Logged in as a user with the Create Safe authorization, such as the administrator, from
the menu bar go to System Configuration and press Add Safe
Safe Name
A logical, structured safe naming convention is very important because it will greatly simplify system
administration and help.
• A safe name cannot be more than 28 characters
• Due to performance considerations, a maximum number of objects stored in a safe is 20000.
This includes versions of objects, therefore the recommended number of actual accounts or
files stored in a safe is 2000
• Due to security considerations, it is recommended to follow a “lowest common denominator”
concept to avoid providing access to multiple groups of accounts when access to only one
group of accounts is required. For example you may have groups of Windows administrators
who are responsible for maintaining servers for specific departments (HR, Finance, Marketing,
etc.). If you create a safe called Windows Accounts with the passwords for all of the Windows
systems, all of the users with access to the safe will have access to any account contained
therein. Instead you should create accounts specific to the exact job function, providing no
more rights than necessary (WinSrvAdminsHR, WinLocalSrvFin, WinSvsMark, etc). This may
result in the creation of more safes but it will ensure that only the proper users have access to
each safe.
• The naming convention can also simply the AllowedSafes setting in policies, which will be
covered later in this section.
Add Member
Users who are members of several Groups that own the same Safe, will either have the
authorizations of the first group that the user was added to, or a combination of the
authorizations of all the groups that they belong to, depending on the
‘GroupMergeAlgorithm’ parameter in the DBParm.ini file, as follows:
DenyOverrides – users will benefit from a combination of all the authorizations granted to
all the groups to which they belong.
FirstApplicable – users will benefit from the authorizations that are specified in the first
group that they were added to as a member.

Users that are also independent Owners of the same Safe will benefit from the
authorizations specified in their individual user accounts, and not from those specified in
the group definitions.
Error in changepass to user 10.0.1.5\admin on domain 10.0.1.5(\\10.0.1.5).(winRc=2245)
The password does not meet the password policy requirements. Check the minimum
password length, password complexity and password history requirements. The CPM is
trying to change this password because its status matches the following search criteria:
ResetImmediately.
Remote desktop must be configured correctly on target system (enabled, user authorized)

Copy shortcut – used to create a Windows short cut --- do screen shorts of this.
http://10.0.1.4/PasswordVault/directaccess.aspx?ObjectDetails.aspx&Object=Operating+Sys
tem-WinServerLocalFin-10.0.1.5-
admin&Folder=Root&Safe=WinSrvFin&OpenConnectWindow=yes&ConnectionClient=RDP
/etc/ssh/sshd_config
PermitRootLogin no
84