{"id":2579,"date":"2018-06-16T16:49:24","date_gmt":"2018-06-16T21:49:24","guid":{"rendered":"http:\/\/osric.com\/chris\/accidental-developer\/?p=2579"},"modified":"2025-08-14T15:24:15","modified_gmt":"2025-08-14T20:24:15","slug":"re-bind-host-to-freeipa","status":"publish","type":"post","link":"https:\/\/osric.com\/chris\/accidental-developer\/2018\/06\/re-bind-host-to-freeipa\/","title":{"rendered":"Re-bind host to FreeIPA"},"content":{"rendered":"

The sudo<\/code> 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.<\/p>\n

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

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<\/code> by adding the following line to \/etc\/ssh\/sshd_config<\/code>:<\/p>\n

PermitRootLogin Yes<\/code><\/pre>\n
Be sure to restart the sshd service:<\/p>\n
sudo systemctl restart sshd<\/code><\/pre>\n
Log in as the root user and run:<\/p>\n
ipa-client-install --uninstall<\/code><\/pre>\n
That worked just fine for me. Now for the re-bind:<\/p>\n
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<\/code><\/pre>\n
This failed and produced a number of error messages:<\/p>\n
Skip trinculo.osric.net: LDAP server is not responding, unable to verify if this is an IPA server\r\nSkip stefano.osric.net: LDAP server is not responding, unable to verify if this is an IPA server\r\nSkip ariel.osric.net: LDAP server is not responding, unable to verify if this is an IPA server<\/code><\/pre>\n
Weird. What’s going on? Other systems are connecting, but this particular host can’t connect to the IPA servers.<\/p>\n
First I checked iptables<\/code> on the client host (I had disabled firewalld<\/code> and enabled iptables<\/code> instead):<\/p>\n
iptables --line-numbers -L INPUT<\/code><\/pre>\n
Sure enough, there was a subnet missing! I added it to the iptables rules:<\/p>\n
iptables -I INPUT 10 -s 192.168.42.0\/24 -j ACCEPT -m comment --comment \"Pass traffic lab subnet\"<\/code><\/pre>\n
That didn’t explain the failures for all 3 hosts though, since 2 of them were in another subnet.<\/p>\n
Next, I tried using netcat to check the LDAP connection between the client and one of the FreeIPA servers:<\/p>\n
nc stefano.osric.net 389\r\nNcat: Connection timed out.<\/code><\/pre>\n
I checked the iptables<\/code> rules on the FreeIPA servers. Most of my FreeIPA servers are in the same \/24<\/code> subnet as the client hosts, and my iptables<\/code> rules allow all connections within that subnet. However, this FreeIPA host is in a different subnet and iptables<\/code> had no ACCEPT rules in the INPUT chain for that subnet. I tried adding an allow rule for LDAP, which returned an error message:<\/p>\n
-A INPUT -s 192.168.100.0\/24 --dport 389 -m comment --comment \"Pass LDAP requests for 192.168.100.0\/24\" -j ACCEPT\r\n\r\niptables: Applying firewall rules: iptables-restore v1.4.21: unknown option \"--dport\"<\/code><\/pre>\n
Right! The --dport<\/code> option requires a protocol:<\/p>\n
-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<\/code><\/pre>\n
That wasn’t enough, though — FreeIPA requires a number of ports to be open to function. I added the others as well:<\/p>\n
-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\r\n-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\r\n-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\r\n-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\r\n-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\r\n-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<\/code><\/pre>\n
I ran the ipa-client-install<\/code> command again:<\/p>\n
Joining realm failed: libcurl failed to execute the HTTP POST transaction, explaining:  Failed connect to stefano.oitsec.umn.edu:443; Connection timed out<\/code><\/pre>\n
I missed one port: HTTPS.<\/p>\n
-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<\/code><\/pre>\n
After that it worked!<\/p>\n
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<\/code> 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.<\/p>\n
One more note: if you use firewalld<\/code>, there is a much easier way to do this. See the FreeIPA QuickStart Guide – Open Ports in the Firewall<\/a>, which has details about service rules included in Fedora and Fedora-derived Linux distributions (RedHat Enterprise Linux and CentOS).<\/p>\n","protected":false},"excerpt":{"rendered":"
One of my FreeIPA client hosts was taking a long time to run sudo commands and, strangely, accepted my old password and not my current password to run sudo. I decided to remove the host and re-bind it to the FreeIPA domain to try to fix this. During the process, I discovered that the problem was due to iptables firewall rules on both the client and the FreeIPA servers.<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[422],"tags":[453,417,408],"class_list":["post-2579","post","type-post","status-publish","format-standard","hentry","category-sysadmin","tag-firewalld","tag-freeipa","tag-iptables"],"_links":{"self":[{"href":"https:\/\/osric.com\/chris\/accidental-developer\/wp-json\/wp\/v2\/posts\/2579","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/osric.com\/chris\/accidental-developer\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/osric.com\/chris\/accidental-developer\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/osric.com\/chris\/accidental-developer\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/osric.com\/chris\/accidental-developer\/wp-json\/wp\/v2\/comments?post=2579"}],"version-history":[{"count":15,"href":"https:\/\/osric.com\/chris\/accidental-developer\/wp-json\/wp\/v2\/posts\/2579\/revisions"}],"predecessor-version":[{"id":3877,"href":"https:\/\/osric.com\/chris\/accidental-developer\/wp-json\/wp\/v2\/posts\/2579\/revisions\/3877"}],"wp:attachment":[{"href":"https:\/\/osric.com\/chris\/accidental-developer\/wp-json\/wp\/v2\/media?parent=2579"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/osric.com\/chris\/accidental-developer\/wp-json\/wp\/v2\/categories?post=2579"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/osric.com\/chris\/accidental-developer\/wp-json\/wp\/v2\/tags?post=2579"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}