– It is necessary to keep track of service account passwords (assuming that the organization isn’t using operating systems that support managed service accounts)
– You need to keep track of administrative passwords for networking devices and non-domain joined computers
– You want to keep track of directory service restore mode passwords
– It is necessary to keep track of specially privileged administrative accounts.
Some organizations have so much trouble with keeping track of these special passwords that they use a single shared complex password for all administrative things. Want to change the router setting? Use the super secret password! Want to recover private certificates from the certificate services database? Use the super secret password! Want to extend the Active Directory Schema? Super secret password.
The clear and obvious problem with this scheme is that if you know the super secret password for one task, you know them for all tasks. While administrators may need to share passwords for privileged accounts, they need to do it selectively. The password for managing one router should be different from the password used to manage another router, just as the password for the SQL Server service account should be different form the password that has permission to extend the Active Directory schema.
Even when passwords are different, some organizations use a password protected Excel file to keep track of complex account passwords. While this is certainly better than the same password being used everywhere, it means that whoever has the password to the password protected Excel file has access to all the secret account passwords. Best security practice is that only people who should have access to a sensitive password do have access to a sensitive password. Of course if you had a separate Excel file with separate passwords for each sensitive account, you run back into the problem of “how does someone remember the passwords for all the different excel files that hold all the passwords?”
A better system is one that allows an administrator to use a single set of credentials to be able to view the shared sensitive account passwords they have permission to view and to not be able to view the shared sensitive account passwords they don’t have permission to view.
- Windows XP, Vista, 7 or 8
- Server 2003, 2008 or 2012
- Microsoft .NET Framework 4.0
- iOS (supported since May, 2013)
- Internet Explorer
- Mozilla Firefox
Managing Privileged Account Passwords with Pleasant Password Server
Pleasant Password Server provides a solution for organizations that want to implement a solution for storing and retrieving complex secure passwords, including being able to control who can view and who can change those passwords. For example, your organization might have three people on the systems administration team, Socrates, Plato and Aristotle. You could use Pleasant Password Server to implement the following scheme:
- Give permission to Socrates to view and update the password of the account used to approve certificate requests. Give Plato the ability to view, but not alter, the password of the account used to approve certificate requests. Block Aristotle from either viewing or changing the password of the account used to approve certificate requests.
- Give permission to Aristotle to view and update the password configured for the account used to extend the Active Directory schema. Give Socrates the ability to view this password and block Plato from having access to the password.
Pleasant Password Server uses KeePass Password Safe, a free open source password manager that you can use to manage personal passwords, such as the password to different social media accounts, e-mail accounts, administrator accounts and so on. Because of its free and open source nature, KeePass Password Safe is deployed widely by many people who want a simple and efficient tool to manage their passwords. You can download the single user version of KeePass Password safe at keepass.info.
Pleasant Password Server extends KeePass Password safe so that instead of each user having a single password database, there is a shared password database with configurable access levels. Using configurable access levels, you can provide different administrators access to different sensitive passwords.
How Pleasant Password Server Works
Pleasant Password Server doesn’t sync with account databases. It maintains its own separate password database. To explain by example:
1. You create an entry in Pleasant Password Server for a sensitive account. You can use the password generator, shown below, to create a complex password for that account. It’s a good idea to use password generators because they are better at thinking up randomized passwords than people are.
2. Once you’ve got a password, as shown in the exhibit below, you manually configure the account that you are securing to use that password.
3. You then apply access levels to determine which users are able to view the password and which users are able to update the password in the Pleasant Password Database. For example, giving Socrates permission to create a new password, giving Plato the ability to view the current password.
Groups and Access
You configure who can view and change passwords by creating containers known as groups and then adding password entries to those groups. You apply access permissions to those group containers. For example, you could assign one user the ability to change the passwords for all entries in the Enterprise Admin group and assign another user the ability to only retrieve the passwords for entries in the Enterprise Admin group. Groups can be nested.
The exhibit below shows the Pleasant Password Server management interface. In the exhibit, user Plato is being configured so that he is able to view the passwords in the Active Directory and Exchange Service Accounts containers, and is able to modify the passwords in the Data Protection and SQL Server Service Accounts containers.
You can integrate Active Directory with Pleasant Password Server so that users are able to authenticate with Pleasant Password Server using their Active Directory credentials. It’s important to note that.
Pleasant Password Server only forwards authentication requests to AD. Changing a password of a sensitive account stored in Pleasant Password Server doesn’t change the password in AD. You still have to configure AD with appropriate security so that the guy on the help desk can’t go and change the password of sensitive accounts to which he shouldn’t have access. Because the passwords generated by the KeePass Password Safe component of Pleasant Password Server are very complex, it won’t be necessary to change them as often as you would with less complex passwords.
Pleasant Password Server has extensive logging options which allows you to view which users have requested passwords, which users have changed passwords, as well as extensive logging of administrative events such as changing access levels. In secure environments you’ll need to keep an eye on this log to verify that only the people who should have access to specific privileged accounts do have access to those accounts. You can see an example of the log in the exhibit. You can use filters with the log to view only entries that are of interest, such as the activity of specific users, display only certain events, or limit log entries to those that were generated during a specific period.
Installing and Running Pleasant Password Server
Pleasant Password Server has two components, the password server itself, which hosts a database and a web server through which you access a web application to perform administrative tasks, and Pleasant Password Server KeePass Password Safe, a version of KeePass Password Safe that interacts with the Pleasant Password Server database. Pleasant Password Server users are also able to perform password retrieval, modification, and generation tasks through the web client or the Pleasant Password Server Android or iPhone apps.
Pleasant Password Server doesn’t use IIS, but instead uses its own web server to host a website. Other than ensuring that .NET Framework 4.5 is installed on your server, installation is pretty straightforward. You can change the port that the password server web application listens on and it’s a good idea to
create or obtain an SSL certificate that clients will trust rather than to use the self signed certificate generated at installation.
You can add users manually to Pleasant Password Server, or you can configure integration with Active Directory. When you configure integration with Active Directory, the user is able to authenticate with Pleasant Password server using their Active Directory credentials. The first time they do this, a user associated with that Active Directory account is created in Pleasant Password Server. Administrators can then assign that user read and modify permissions on password groups. Pleasant Password Server is not limited to Active Directory, and can also use other LDAP account databases for authentication.
You configure client settings for the KeePass client through XML configuration files. These configuration files are downloaded by the KeePass server each time the client interacts with Pleasant Password Server. While you can use this to configure almost all aspects of the client’s operation, it’s necessary to edit this file in a text editor. I know a couple of administrators who have an aversion to editing XML and who would probably prefer there be a simplified web interface in the Pleasant Password Server administration area that allows them to modify these configuration files.
Pleasant Password Server offers organizations a cheap and effective way of generating and granularly sharing complex passwords for sensitive accounts to authorized members of the IT team. It allows your organization to move beyond storing complex passwords for privileged accounts in spreadsheets and instead provides a solution where IT professionals have ready access to the complex passwords that they need to do their job without giving them access to complex passwords for infrastructure outside their sphere of responsibility.