NUTS AND BOLTS FreeIPA Lead image: Lead Image © Marqs, photocase.com
Lead Image © Marqs, photocase.com
 

Password management with FreeIPA

Safely Stored

Passwords should be safe, but easy to remember – a contradiction that can be difficult to resolve. One remedy is a password manager that stores all passwords centrally. The open source tip this month shows a different approach: FreeIPA. By Thorsten Scherf

Passwords need to be long, contain as many characters as possible, and use special characters and numbers. If you do this, then your password is secure, but unfortunately very hard to remember. Consequently, there are a variety of tools that let you deposit hard-to-remember passwords in a type of safe. The safe in turn is protected by a master password, and the passwords it contains are only released if you enter the password correctly. However, the user is then usually given access to the complete inventory of the safe. In the open source world, the KeePass [1] tool is a well-known candidate for this job.

Key Recovery Agent

Key Recovery Agents (KRAs) offer a different type of password safe. They are often part of a larger identity management solution, offering both users and services different forms of password safes – known as password vaults [2]. These are then available not only locally on a client, but throughout the network. The idea is that lost private user keys can be restored, since a copy is deposited in the password safe.

Version 4.2 or newer of the FreeIPA Identity Management framework also features password vaults, where you can store all sorts of data safely. When the data are stored, they are encrypted with a session key. If necessary, this is encoded with another symmetric or asymmetric key. The result is a package consisting of the actual secret (the data) and the keys used. Both together are encrypted again with the public key of the KRA instance and sent to the FreeIPA system, where the whole package is unpacked with the KRA instance's private key. The KRA instance thus gains access to the keys and the actual secret. The secret is again encoded with a storage key, before it is finally deposited on the LDAP back end. An escrow officer can gain access to a safe so that decryption of the data is still possible even if the owner no longer knows the password for accessing the safe.

Architecture

For this KRA function, FreeIPA uses a subsystem of the built-in Dogtag Certificate System. The system is known as the Data Recovery Manager (DRM) and can be installed in addition to the actual FreeIPA setup:

# dnf install ipa-kra-install

Three types of safes are available:

These three safe types can be used in three different containers. In their user container, each user can create any number of safes to store data safely. Safes are visible only to that user. Administrators can create shared containers. Since services also work with private data, these are assigned their own service containers where they can store encrypted data. Access to the service containers is then possible after successful authentication of a service – for example using a Kerberos ticket.

Creating Safes

To use a safe, a user just has to authenticate once before creating a safe:

# kinit tscherf
Password for tscherf@EXAMPLE.COM:
# ipa vault-add company-cc --desc "My company's credit card data" --type symmetric

The first safe has now been created. To store data in it, you can pass in a file to the tool:

# ipa vault-archive company-cc --in ~/company-cc.txt

To retrieve the data, just reverse the process:

# ipa vault-retrieve company-cc --out ~/company-cc.txt

If necessary, several safes can be created in the same container, which users can then view using ipa vault-find.

Shared Safes

Administrators can create safes and share them with different users (Listing 1). Then, the desired data can be stored in the Team Safe:

# ipa vault-archive team-keys --shared --in ~/team-keys.txt --password-file passwd.txt
--------------------------------
Archived data into vault "team-keys"
--------------------------------

Listing 1: Shared Safe

# kinit admin
Password for admin@EXAMPLE.COM:
# ipa vault-add team-keys --desc "Team keys" --type symmetric --shared --password-file passwd.txt
-----------------------------------
Added vault "team-keys"
-----------------------------------
  Vault name: team-keys
  Description: Team keys
  Type: symmetric
  Salt: J0aMaMWKgxf+0I59b2DKkA==
  Owner users: admin
  Shared vault: True
# ipa vault-add-member team-keys --shared --groups schalke --users tscherf
  Vault name: team-keys
  Description: Team keys
  Type: symmetric
  Salt: J0aMaMWKgxf+0I59b2DKkA==
  Owner users: admin
  Shared vault: True
  Member users: tscherf
  Member groups: schalke
--------------------------------------
Number of members added 2
--------------------------------------

When a user who is a member of the safe logs on, they can query the data, as long they remember the password:

# kinit tscherf
Password for tscherf@EXAMPLE.COM:
[root@ipa01 ~]# ipa vault-retrieve team-keys --shared --out my-team-keys.txt --password-file passwd.txt

Asymmetric keys can be used instead of simple passwords; this is not only more secure, but also simplifies the handling of the safes (Listing 2).

Listing 2: Asymmetric Keys

# openssl genrsa -out mykey.pem 2048
# openssl rsa -in mykey.pem -pubout > mykey.pub
# ipa vault-add private --type asymmetric --public-key-file mykey.pub
----------------------
Added vault "private"
----------------------
  Vault name: private
  Type: asymmetric
  Public key:
    LS0tLS1CRUdJTiBQVUJMSUMgS0VZLS0tLS0KTUlJQklqQU5CZ2txaGtpRzl3MEJBUUVGQUFPQ0FROE
    FNSUlCQ2dLQ0FRRUEycGtHL2YzTDd0VmpxblA2cTdPaApkMmJvbTFVTDhPeXdveXZTaXptdUYvME94
    NjErRWRIbmRld25icGlXYjdaaER4c05lVk14SXRpcGZZbW1tdzhKCml0RTVlcDhFa1U1VWhaemxsNW
    Q3eWFYU2VEa25pRVVE WUpMMkpHNDNJWmRFVVFuM1hWUWt4Q0xIN0xzVUI3V0oKUC94TFY4a1FHQXB
    QY1MzcUVyME44MTJ6Q1NPR1U1RDNvNTNoRFhhVG95Y1cwRW1UUldmNHQzNkFrcFhreGszbwo2eW0we
    UhJdmRCS3ZDbVRGVm1SeTdwVFlqbGxLVVNNYWpxSVNUdEFMRUxDclVySHZCSmJ6YzVqZmdUSVJYbVF
    nClhyV21UZXMzRHJqbFJjN2Q5MnpnZXJtUEtnbVRiMWxUL1pyVDhlQzB5Q0paSnNaSmJDOTVkVXRmK
    zNXZEFOY28KYXdJREFRQUIKLS0tLS1FTkQgUFVCTElDIEtFWS0tLS0tCg==
  Owner users: tscherf
  Vault user: tscherf
# ipa vault-archive private --in ~/data.txt
-----------------------------------
Archived data into vault "private"
-----------------------------------
# ipa vault-retrieve private --private-key-file=mykey.pem --out data.txt
--------------------------------------
Retrieved data from vault "private"
-------------------------------------

Conclusion

With KRA, FreeIPA introduces an extremely useful function that lets users set up safes, in which users and services can store data that is then passed securely to the FreeIPA back end.