So it’s time to upgrade some of the devices within the network here. But it would be really good to do it in the right order. Identity and access management (IAM) is important to make sure that only those people you want to attach to network services do so and that they are who they claim. Without this, user management would be done across each server, and systems and is prone to errors and latent users (e.g. when an employee leaves, they are not deleted from all the servers they had access to).
FreeIPA provides a self-contained platform for managing this using some of the best tools around integrating them into a coherent whole. You could use an enterprise scale tool for doing this, and have the backup of large organisations for support. (For example, Oracle, IBM and RSA all have solutions that combine elements of Identity, Management, Governance and Security in their product names).
But FreeIPA offers similar functionality, but implemented as an Open-Source solution, with plenty of support via the Internet. Let’s get it installed, and see what happens.
1. Check we have a correctly usable hostname
We start with a basic CentOS 7 server and then ensure that we have correctly added it to the DNS server on the network. (FreeIPA also offers a DNS integration, and we’ll take that opportunity later). We need to make sure that the server can resolve its own hostname and also do a reverse lookup as well.
# hostnamectl set-hostname ipa.domain.tldWe then start the process of the installation
2. Download and install FreeIPA
This is a fairly simple step, as CentOS, like RedHat Enterprise Linux and Fedora, has Free
# yum install free-ipa-server
3. Configure the FreeIPA server
Now we get to the fun parts. There are quite a few questions we need to go through in order to get this working. We’re doing a basic install of the FreeIPA server so that we get LDAP, Kerberos and the certificate services setup. We’ll add more bits later as we come to each of the updated servers later.
# ipa-server-install ...
Do you want to configure integrated DNS (BIND)? [no]:
…
Server host name [ipa.domain.tld]:
…
Please confirm the domain name [domain.tld]:
…
Please provide a realm name [DOMAIN.TLD]
…
Directory Manager Password: <s0m3s3cr3t>
For this, we need to choose a secure password, as we’ll later create users with more restricted rights that we can then utilise for the day-to-day tasks. We’ll also need a secure password for the day-to-day admin user.
IPA admin password: <an0th3rs3cr3t>
The IPA Master Server will be configured with:
Hostname: ipa.domain.tld
IP address(es): 192.0.2.1
Domain name: domain.tld
Realm name: DOMAIN.TLD
Continue to configure the system with these values? [no]: yes
Now it’s a bit of waiting game whilst the script configures the various FreeIPA elements, build certificates and validation chains, and starts the various services.
4. Securing access to the server
We now need to add the services that are accessed via the FreeIPA server by adjusting the firewall using the command shown below.
# firewall-cmd --add-service freeipa-ldaps --permanent success # firewall-cmd --add-service freeipa-ldap --permanent success # firewall-cmd --reload success
So we now have a server that should respond to our HTTPS requests., and a connection to https://ipa.domain.tld gets us to the login page of the FreeIPA server. We complete the login using the admin username and the password we defined earlier.
This gets us the ability to add new users, groups and manage the many other elements of the FreeIPA environment.
5. Adding a Bind User for LDAP access from other systems
It’s not good security practice to use the directory manager for accessing the LDAP server in the FreeIPA environment from other systems. With the manager’s ability to make changes across the board, it’s normally good practice to create a Bind user, which is then used to connect to the LDAP server for authentication.
There are arguments that say each individual system should have their own bind user, uniquely tuned for the requirements of each server. But there are also arguments that you need to avoid the complexity overhead from this.
So let’s add a single user, and use that for the moment.
Firstly we need to create a binder.ldif file,
dn: uid=binder,cn=sysaccounts,cn=etc,dc=example,dc=com
changetype: add
objectclass: account
objectclass: simplesecurityobject
uid: binder
userPassword: n0tr34lly4s3cr3t
passwordExpirationTime: 20380119031407Z
nsIdleTimeout: 0
We now need to give this to the LDAP server using the ldapmodify command as shown below.
ldapmodify -x -D "cn=Directory Manager" -W -f binder.ldif
When asked for credentials, we use the LDAP Directory Manager password.
Now we check we can scan the LDAP directory using this user. This time the credentials are for the bind user we’ve just added.
ldapsearch -D "uid=binder,cn=sysaccounts,cn=etc,dc=example,dc=com" -W binder
And we should get back a screed of information covering the various LDAP entries our bind user can get access to.