PingDirectory

Minimize access to the underlying system

If administrators can access the underlying system, then the mechanism they use to do so should be as secure as possible.

All shell access must occur over an encrypted session that uses strong authentication, such as relying on SSH keys rather than passwords, and ideally using a second authentication factor like TOTP or U2F.

Keep the number of users authorized to access the system to a minimum, and ensure each authorized user has their own account rather than sharing accounts across multiple individuals. This makes it easier to audit access and identify which administrator made a given change. Using separate accounts also avoids problems that might arise whenever the credentials need to be changed. With a separate account per administrator, each has their own distinct credentials.

The account used to run and manage the PingDirectory software itself should not be able to directly authenticate to the underlying system. Instead, each user authorized to interact with the PingDirectory software on the underlying system must authenticate with their own account before using some mechanism, such as su or sudo on UNIX-based systems, to interact with the server software.

The accounts for the users who manage the PingDirectory software and the account used to run that software should be configured with the minimum set of capabilities required to perform their duties. Those who manage the underlying system might require full access, but those who just maintain the PingDirectory software can be given restricted access. If possible, restrict the set of commands that those users can invoke and their access to other running processes and areas of the filesystem.

If a system account becomes compromised or its owner leaves, terminate that account as quickly as possible. While managing system accounts is usually best left to a centralized naming service like LDAP, this is not recommended for the accounts used to manage the PingDirectory software itself because an issue with the server might prevent users from authenticating to the system to address it. Local file-based accounts are the most reliable, but it is important to keep a current list of all users with access to these systems and of all systems they can access with those credentials so that the credentials can quickly be revoked if necessary.