FreeIPA Install on CentOS 7

chrischarles2002 · 03-13-2015, 03:02 PM

I am trying to install a new stand alone instance of FreeIPA on CentOS 7.

I am doing this in an Amazon AWS EC2 environment.

The install completes flawlessly every time, however, when I attempt to run for the first time:

Code:

kinit admin

I always get back:

Code:

kinit: Cannot contact any KDC for realm 'DOMAIN.COM' while getting initial credentials

Googling, I found a way to trace this command:

Code:

KRB5_TRACE=/dev/stdout kinit admin

In which case I get the following output:

Code:

[root@ipa1 ~]# KRB5_TRACE=/dev/stdout kinit admin
[3320] 1426267179.15039: Getting initial credentials for admin@DOMAIN.COM
[3320] 1426267179.17085: Sending request (164 bytes) to DOMAIN.COM
[3320] 1426267179.17225: Resolving hostname ipa1.domain.com
[3320] 1426267179.17715: Sending initial UDP request to dgram 10.209.10.19:88
[3320] 1426267179.17786: UDP error receiving from dgram 10.209.10.19:88: 111/Connection refused
[3320] 1426267179.18382: Initiating TCP connection to stream 10.209.10.19:88
[3320] 1426267179.18431: Terminating TCP connection to stream 10.209.10.19:88
kinit: Cannot contact any KDC for realm 'DOMAIN.COM' while getting initial credentials

Continuing to Google for "UDP error receiving from dgram" & "Connection refused", I see that this is a common recent issue with the FreeIPA install, but have yet to find a posted solution.

Here are the packages that I have installed:

Code:

[root@ipa1 ~]# rpm -qa  | grep ipa
ipa-python-3.3.3-28.0.1.el7.centos.3.x86_64
python-iniparse-0.4-9.el7.noarch
sssd-ipa-1.11.2-68.el7_0.6.x86_64
ipa-client-3.3.3-28.0.1.el7.centos.3.x86_64
ipa-server-3.3.3-28.0.1.el7.centos.3.x86_64
libipa_hbac-1.11.2-68.el7_0.6.x86_64
ipa-admintools-3.3.3-28.0.1.el7.centos.3.x86_64
libipa_hbac-python-1.11.2-68.el7_0.6.x86_64

Does anyone know how to get around this issue to complete the install on CentOS 7 in Amazon AWS EC2?

Thanks in advance.

unSpawn · 04-12-2015, 05:15 AM

Quote:

Originally Posted by chrischarles2002

Code:

[3320] 1426267179.17715: Sending initial UDP request to dgram 10.209.10.19:88
[3320] 1426267179.17786: UDP error receiving from dgram 10.209.10.19:88: 111/Connection refused

See comment #2 at https://ask.fedoraproject.org/en/question/65300/installing-freeipa-on-centos-7-kinit-cannot-contact-any-kdc-for-realm/

//NTLB

ericson007 · 08-23-2015, 05:45 AM

On top of what unSpawn said, I have just set up a server and took these logs.

Code:

System information
KVM virtual machine
1 CPU, 2048MB RAM
Connected to LAN via virtual router (pfsense)

#Set hostname
[root@ipa-test ~]# hostnamectl set-hostname ipa-test.xxxx.xxx

#Opened the following ports, reloaded firewalld verified ports are open
[root@ipa-test ~]# for i in 80 443 464 88 389 53 636; do firewall-cmd --permanent --zone=public --add-port=$i/tcp; done

[root@ipa-test ~]# for i in 88 464 123 53; do firewall-cmd --permanent --zone=public --add-port=$i/udp; done

[root@ipa-test ~]# firewall-cmd --list-ports
443/tcp 80/tcp 464/tcp 88/udp 464/udp 88/tcp 123/udp 389/tcp 53/tcp 53/udp 636/tcp

#Installed IPA (IdM) packages
[root@ipa-test ~]# yum -y install ipa-server bind-dyndb-ldap

#Configure IPA server (No ntp because it is a VM, on bare metal don't use this option)
[root@ipa-test ~]# ipa-server-install --setup-dns --no-ntp

#Check IPA Log for what is supposed to start during startup
[root@ipa-test ~]# cat ipa | grep "to start"
  [38/38]: configuring directory to start on boot
  [18/27]: configuring certificate server to start on boot - system did enable this by default
  [10/10]: configuring KDC to start on boot - status disabled - systemctl enable krb5kdc.service - OK
  [2/2]: configuring kadmin to start on boot - status disabled - systemctl enable kadmin.service - OK
  [2/2]: configuring ipa_memcached to start on boot - status disabled - systemctl enable ipa_memcached - OK
									systemctl enable memcached
  [2/2]: configuring ipa-otpd to start on boot - status disabled - systemctl enable ipa-otpd.socket - OK
  [16/16]: configuring httpd to start on boot - status disabled - systemctl enable httpd - OK
  [11/12]: configuring named to start on boot - status disabled - systemctl enable named - OK

#verify IPA is working BEFORE RESTART
[root@ipa-test ~]# klist
Ticket cache: KEYRING:persistent:0:0
Default principal: admin@xxxxx.yyy

Valid starting       Expires              Service principal
08/23/2015 19:29:30  08/24/2015 19:28:44  krbtgt/xxxxx.yyy@xxxxx.yyy

[root@ipa-test ~]# ipa user-find admin
--------------
1 user matched
--------------
  User login: admin
  Last name: Administrator
  Home directory: /home/admin
  Login shell: /bin/bash
  UID: 860000000
  GID: 860000000
  Account disabled: False
  Password: True
  Kerberos keys available: True
----------------------------
Number of entries returned 1
----------------------------


--------------REBOOT---------------------

[user@ipa-test ~]$ su -
Password: 
Last login: Sun Aug 23 17:42:00 JST 2015 on pts/0

[root@ipa-test ~]# kinit admin
Password for admin@xxxxx.yyy: 

[root@ipa-test ~]# klist
Ticket cache: KEYRING:persistent:0:0
Default principal: admin@xxxxx.yyy

Valid starting       Expires              Service principal
08/23/2015 19:34:28  08/24/2015 19:34:14  krbtgt/xxxxx.yyy@xxxxx.yyy

[root@ipa-test ~]# ipa user-find admin
--------------
1 user matched
--------------
  User login: admin
  Last name: Administrator
  Home directory: /home/admin
  Login shell: /bin/bash
  UID: 860000000
  GID: 860000000
  Account disabled: False
  Password: True
  Kerberos keys available: True
----------------------------
Number of entries returned 1
----------------------------

I did notice that even though the installer said it is enabling service for boot, my systemctl status service_name resulted in the items showing that the services has actually not been enabled. As such I think try making sure all services are enabled and it is not those that cause the failure.

Easy command to do it would be

Code:

for i in krb5kdc.service kadmin.service ipa-otpd.socket memcached ipa_memcached ipa-otpd.socket httpd named; do systemctl enable $i; done

reboot and report back. I use to get the Kerberos failure too, after manually enabling those services it works for me.

Reading over your post again. There was the KRB debug which stated connection refused. That would mean to me either the service is not running or the firewall is blocking. If that is the case. The steps above should solve it.

ericson007 · 08-24-2015, 03:00 AM

I have read up about this for a bit and it seems that free-ipa is actually quite a temporal beast. It either works first go or it does not.

Correctly resolving DNS seems to be the biggest cause of headache for admins, but I have found this article which is really interesting and shows some of the finer points of getting things done.

https://www.happyassassin.net/2013/0...freeipa-badge/

Of special interest is the fact that the first entry next to the machine IP must be the FQDN

Code:

192.168.1.xx ipa.host.com ipa

from the above site

Quote:

Sometimes, it seems, when you boot a FreeIPA server machine, the directive in /etc/tmpfiles.d/dirsrv-YOUR-DOMAIN.conf which tells systemd to create a directory called /var/lock/dirsrv/slapd-YOUR-DOMAINjust doesnt work. That causes 389 Directory Server (FreeIPAs LDAP server) to fail to start.

edit: Thanks to viking-ice and nkinder, I find that this was recently re-reported, and the new bug reports have been far more fruitful. This is getting fixed, in multiple places (not just 389-ds has the problem, it turns out):

FreeIPA https://bugzilla.redhat.com/show_bug.cgi?id=996716
pki-core https://bugzilla.redhat.com/show_bug.cgi?id=996847
389-ds https://bugzilla.redhat.com/show_bug.cgi?id=1008306

run

#systemd-tmpfiles create /etc/tmpfiles.d/dirsrv-YOUR-DOMAIN.conf

This means that I like the author was also stumped by the startup of services not really working, but it seems that manually enabling the services is not the answer.

Another rather interesting read is the troubleshooting guide from free-ipa http://www.freeipa.org/page/Troubleshooting

Hope this helps. I will eventually get around to setup another test server and will try to cause it to fail and check if those steps can be verified to bring the system back up.

Hope this helps and points you in the right direction.