2018-09-15 Installing FreeIPA
Installation of FreeIPA, an alternative identity/policy provider
Goal
Configure FreeIPA - a free open source enterprise grade authentication server comparable to Microsoft Active Directory
Background
Summary
Microsoft has dropped Identity Management for Unix from MS Server 2016, policy with domain joined Linux systems won’t receive special treatment from it’s Windows instances. There have since been some brilliant client side authentication features built into the SSSD client. For example UID/GID values are synthesized (TL:DR; using ID_Mapping=true using sssd-ad plugins) as these are not passed anymore from MS AD-DS2016. But on the server side we have a big effort by Red Hat to modernize the disparate Krb5/LDAP/Certificate tools. They are calling it FreeIPA, so I decided to pick it up and have a look.
Gaps in FreeIPA install guide
Hortonworks have been enjoying a very good experience delivered with FreeIPA as the Identity/Policy provider as well. So I spun up a few Centos7 VM’s and got to work. I followed the quickstart guide and noted a couple of bits that slowed the basic install down:
Firewall Daemon settings:
TL:DR; to open up the relevant ports using this zone based firwall system, declare the following additional services on the default zone (ports: tcp 80,443,389,636,88,464,53 udp 88,464,53,123):
me@ipa> sudo firewall-cmd --permanent \
--add-service=freeipa-ldaps,freeipa-ldap,dns
me@ipa> sudo firewall-cmd --reload
Detailed firewall checks firewalld is a daemon that hooks into the kernel, can interpret old IPTables but importantly can live patch new systems, open/close ports. Without the permanent option it will update the process directly, with permanent, it will create override files. the reload option will then pull from the newly created config files.
Viewing all your after install is blocked by default with an external tool like nmap because filewalld blocks ping by default. Hence you may turn off the firewall and view these before selecting the port services:
me@ipa> sudo systemctl stop firewalld
me@ipa> exit
me@home> nmap ipaStarting Nmap 7.01 ( https://nmap.org ) at 2018-09-15 13:59 AEST
Nmap scan report for centos7-1 (192.168.122.10)
Host is up (0.00011s latency).
Not shown: 988 closed ports
PORT STATE SERVICE
22/tcp open ssh
53/tcp open domain
80/tcp open http
88/tcp open kerberos-sec
111/tcp open rpcbind
389/tcp open ldap
443/tcp open https
464/tcp open kpasswd5
636/tcp open ldapssl
749/tcp open kerberos-adm
8080/tcp open http-proxy
8443/tcp open https-altme@home> ssh ipa
me@ipa> sudo systemctl start firewalld
me@ipa> cd /usr/lib/firewalld/services/
me@ipa> grep -Hrn '\"\(80\|443\|389\|636\|88\|464\|53\|88\|464\|53\|123\)\"' .
./RH-Satellite-6.xml:5: <port protocol="tcp" port="53"/>
./RH-Satellite-6.xml:6: <port protocol="udp" port="53"/>
./RH-Satellite-6.xml:8: <port protocol="tcp" port="80"/>
./RH-Satellite-6.xml:9: <port protocol="tcp" port="443"/>
./freeipa-trust.xml:8: <port protocol="tcp" port="389"/>
./freeipa-trust.xml:9: <port protocol="udp" port="389"/>
./dns.xml:5: <port protocol="tcp" port="53"/>
./dns.xml:6: <port protocol="udp" port="53"/>
./freeipa-ldap.xml:5: <port protocol="tcp" port="80"/>
./freeipa-ldap.xml:6: <port protocol="tcp" port="443"/>
./freeipa-ldap.xml:7: <port protocol="tcp" port="88"/>
./freeipa-ldap.xml:8: <port protocol="udp" port="88"/>
./freeipa-ldap.xml:9: <port protocol="tcp" port="464"/>
./freeipa-ldap.xml:10: <port protocol="udp" port="464"/>
./freeipa-ldap.xml:11: <port protocol="udp" port="123"/>
./freeipa-ldap.xml:12: <port protocol="tcp" port="389"/>
./freeipa-ldaps.xml:5: <port protocol="tcp" port="80"/>
./freeipa-ldaps.xml:6: <port protocol="tcp" port="443"/>
./freeipa-ldaps.xml:7: <port protocol="tcp" port="88"/>
./freeipa-ldaps.xml:8: <port protocol="udp" port="88"/>
./freeipa-ldaps.xml:9: <port protocol="tcp" port="464"/>
./freeipa-ldaps.xml:10: <port protocol="udp" port="464"/>
./freeipa-ldaps.xml:11: <port protocol="udp" port="123"/>
./freeipa-ldaps.xml:12: <port protocol="tcp" port="636"/>
./http.xml:5: <port protocol="tcp" port="80"/>
./https.xml:5: <port protocol="tcp" port="443"/>
./kerberos.xml:5: <port protocol="tcp" port="88"/>
./kerberos.xml:6: <port protocol="udp" port="88"/>
./kpasswd.xml:5: <port protocol="tcp" port="464"/>
./kpasswd.xml:6: <port protocol="udp" port="464"/>
./ldap.xml:5: <port protocol="tcp" port="389"/>
./ldaps.xml:5: <port protocol="tcp" port="636"/>
./ntp.xml:5: <port protocol="udp" port="123"/>
As you can see we cover all the important ports with activating firewalld’s existing configurations for dns, freeipa-ldap and freeipa-ldaps except “proxy/alt” for http/s.
Using FreeIPA Web UI from a remote computer.
TL:DR; Two imperfect hacks: You either need to turn off Krb5 authentication for the Web UI, or you ssh tunnel to the IPA serve with the -XCt option, then kinit admin yourself and finally X11 forward a native firefox browser to you by calling firefox https://ipa.rupert.com on the remote host (really slow). Best is that you set your native computer to allow kinit with you IPA server.
Detailed Learning
Using the browser through a secure tunnel is possible, but it’s a desperate and slow way to work with the UI. This works:
# painful way...
ssh -XCt root@ipa ‘kinit admin; firefox https://localhost'
But lets setup our Linux desktop to connect we need to kinit against that IPA server. To do this not only do we need the Kerberos configuration file pointing to the ipa’s kerberos server details, we need the generated pki public keys. These are required for Kerberos ini file to reference for kinit and for loading into the browser to trust the IPA system as a trusted authority for http.
First the /etc/krb5.conf file from the IPA server holds the Kerberos config details that your native machine needs to connect, so this config can be copied across. Inspired by this Fedora post I added a local environment variable for the kerberos config
me@home> scp root@ipa:/etc/krb5.conf ~/krb5_ipa.conf
me@home> sudo mkdir /var/lib/ipa-client/pki
me@home> scp -r root@ipa:/var/lib/ipa-client/pki/{ca-bundle.pem,kdc-ca-bundle.pem} /var/lib/ipa-client/pki/
me@home> sudo mv ~/krb5_ipa.conf /etc/
me@home> echo "export KRB5_CONFIG=/etc/krb5_ipa.conf" >> ~/.bashrc
me@home> source ~/.bashrc
me@home> echo "<<IPA_IP>> <<IPA_FQHN>> <<IPA_HN>>" >>/etc/hosts
me@home> kinit admin
me@home> klist
Ticket cache: KEYRING:persistent:1000:1000
Default principal: admin@RUPERT160.INTValid starting Expires Service principal
15/09/18 15:29:28 16/09/18 15:29:23 krbtgt/RUPERT160.INT@RUPERT160.INT
Please note that KRB5 is pedantic about the order of hostnames in /etc/hosts. I had an additional hostname before the IPA names and when I checked the krb5kdc.log files on the IPA server it stated that:
me@ipa> sudo grep -i '<<myhostname>>' /var/log/krb5kdc.log
Sep 15 00:58:51 ipa.rupert160.int krb5kdc[1520](info):
TGS_REQ (6 etypes {18 17 16 23 25 26}) 192.168.122.1: LOOKING_UP_SERVER: authtime 0,
admin@RUPERT160.INT for HTTP/myhostname@RUPERT160.INT,
Server not found in Kerberos database
Browser tweeks required:
Finally there is two adjustments that are required to your browser:
- Register that you wish to use GSS negotiation for that
.rupert160.int(leading “period” not a typo) domain. - Upload the
ca-bundle.pemfile that you pulled from IPA to the trusted authorites of your browser and (in Firefox)
Outcome: And now you should be able to access the Web UI without a password, using the password issued from FreeIPA.
Linux Desktops vastly improved the Kerberos support now that since 2020 Gnome has “Enterprise Login” options for users since out-of-the-box from Gnome user setup from Ubuntu 20.10+ and Fedora 34+. Linux Desktops have tended to lag “Enterprise level support” for Desktop users in comparrison to Windows 10/11 that now offer Windows Account over the internet without requiring a host to be in the same network. We are very much hoping modern federation tools like KeyCloak might be able to offer remote authentication options for our laptops.