Re-bind host to FreeIPA

The sudo command on one particular FreeIPA-bound host was taking an exceedingly long time to run. And when it finally ran, it would not accept my current password, but rather my previous password — somehow still cached on the system. It was a strange problem.

Instead of trying to figure out exactly why it was happening, I decided to remove & re-bind the host to my FreeIPA domain.

You’ll want to be the root user to re-install the FreeIPA client, since your non-local user accounts won’t exist once you uninstall the FreeIPA client. Therefore, before you break FreeIPA, allow root to log in via ssh by adding the following line to /etc/ssh/sshd_config:

PermitRootLogin Yes

Be sure to restart the sshd service:

sudo systemctl restart sshd

Log in as the root user and run:

ipa-client-install --uninstall

That worked just fine for me. Now for the re-bind:

ipa-client-install --domain=osric.net --server=freeipa.osric.net --realm=FREEIPA.OSRIC.NET --principal=admin --password=N3v3rGu355 --mkhomedir -U --hostname=www-dev-01.osric.net

This failed and produced a number of error messages:

Skip trinculo.osric.net: LDAP server is not responding, unable to verify if this is an IPA server
Skip stefano.osric.net: LDAP server is not responding, unable to verify if this is an IPA server
Skip ariel.osric.net: LDAP server is not responding, unable to verify if this is an IPA server

Weird. What’s going on? Other systems are connecting, but this particular host can’t connect to the IPA servers.

First I checked iptables on the client host (I had disabled firewalld and enabled iptables instead):

iptables --line-numbers -L INPUT

Sure enough, there was a subnet missing! I added it to the iptables rules:

iptables -I INPUT 10 -s 192.168.42.0/24 -j ACCEPT -m comment --comment "Pass traffic lab subnet"

That didn’t explain the failures for all 3 hosts though, since 2 of them were in another subnet.

Next, I tried using netcat to check the LDAP connection between the client and one of the FreeIPA servers:

nc stefano.oitsec.umn.edu 389
Ncat: Connection timed out.

I checked the iptables rules on the FreeIPA servers. Most of my FreeIPA servers are in the same /24 subnet as the client hosts, and my iptables rules allow all connections within that subnet. However, this FreeIPA host is in a different subnet and iptables had no ACCEPT rules in the INPUT chain for that subnet. I tried adding an allow rule for LDAP, which returned an error message:

-A INPUT -s 192.168.100.0/24 --dport 389 -m comment --comment "Pass LDAP requests for 192.168.100.0/24" -j ACCEPT

iptables: Applying firewall rules: iptables-restore v1.4.21: unknown option "--dport"

Right! The --dport option requires a protocol:

-A INPUT -s 192.168.42.0/24 -p tcp --dport 389 -m comment --comment "Pass LDAP requests for 192.168.42.0/24" -j ACCEPT

That wasn’t enough, though — FreeIPA requires a number of ports to be open to function. I added the others as well:

-A INPUT -s 192.168.100.0/24 -p tcp --dport 80 -m comment --comment "Pass HTTP requests for 192.168.100.0/24" -j ACCEPT
-A INPUT -s 192.168.100.0/24 -p tcp --dport 88 -m comment --comment "Pass Kerberos requests for 192.168.100.0/24" -j ACCEPT
-A INPUT -s 192.168.100.0/24 -p tcp --dport 389 -m comment --comment "Pass LDAP requests for 192.168.100.0/24" -j ACCEPT
-A INPUT -s 192.168.100.0/24 -p tcp --dport 464 -m comment --comment "Pass kpasswd requests for 192.168.100.0/24" -j ACCEPT
-A INPUT -s 192.168.100.0/24 -p udp --dport 88 -m comment --comment "Pass Kerberos requests for 192.168.100.0/24" -j ACCEPT
-A INPUT -s 192.168.100.0/24 -p udp --dport 464 -m comment --comment "Pass kpasswd requests for 192.168.100.0/24" -j ACCEPT

I ran the ipa-client-install command again:

Joining realm failed: libcurl failed to execute the HTTP POST transaction, explaining:  Failed connect to stefano.oitsec.umn.edu:443; Connection timed out

I missed one port: HTTPS.

-A INPUT -s 192.168.100.0/24 -p tcp --dport 443 -m comment --comment "Pass HTTPS requests for 192.168.100.0/24" -j ACCEPT

After that it worked!

And now I know why it wasn’t working before. At some point after the system was initially bound to FreeIPA, I must have either made the iptables host-based firewalls more restrictive or moved the client host to a different subnet. I’m surprised that the host, once it lost the ability to connect to the FreeIPA servers, continued to cache the credentials for several months. That’s both good and bad: everything on the system was still working, but it also wasn’t readily apparent that anything was wrong.

One more note: if you use firewalld, there is a much easier way to do this. See the FreeIPA QuickStart Guide – Open Ports in the Firewall, which has details about service rules included in Fedora and Fedora-derived Linux distributions (RedHat Enterprise Linux and CentOS).