Setting up IPA with a specific CA cert subject

If you are doing experiments with IPA where you install and reinstall IPA servers, you may notice SSL certificate errors when connecting to an IPA server using Firefox. The reason is that always the same Organization and serial is used when the CA cert is created.

Normal users are usually only affected when using the same Realm and DNS subdomain for the test and production environment which is not recommended anyway.

Reproducing the issue
1. Set up IPA with ipa-server-install.
2. Connect to the WebUI using Firefox.
3. Unconfigure IPA with ipa-server-install –uninstall.
4. Configure IPA again with ipa-server-install.
5. Connect to the WebUI using Firefox again and figure out its not working and trows an error message like “An error occurred during a connection to ipa1.example.com. You have received an invalid certificate”.

See also FreeIPA Ticket #2016.

Unfortunately it is not trivial to fix this behavior as different components need to be changed.

Workaround
There is an easy workaround for this issue. Just provide the –subject when configuring IPA.

[root@ipa1 ~]# ipa-server-install --subject="O=EXAMPLE.COM 201511291216" --more-options-as-you-need

The O=EXAMPLE.COM should be replaced with the Realm you plan to set up, the number should be something like <year><month><day><hour><minute>

Unfortunately I dont know if there is an easy way to change already set up servers as the CA cert would need to be recreated.

Identity Management und 2FA mit (Free)IPA @Chemnitzer Linuxtage 2015

My first post in German, publishing the Slide Deck (in German) for my presentation about IPA and 2FA held at Chemnitzer Linux days 2015.

Mein erster Post in Deutsch. Hier die Slides von meinem Vortrag an den Chemnitzer Linux Tagen 2015.

Abstract:
IPA ist ein Identity Management System für Linux und Unix, das stetig an Bedeutung gewinnt. Mittlerweile ist es des öfteren in Behörden, Banken, Versicherungen, aber auch in KMUs im Einsatz. IPA kann man sich als «Active Directory» für Linux vorstellen. IPA verheiratet LDAP und Kerberos zu einem Opensource Produkt das leicht zu installieren und zu unterhalten ist. Mit IPA kann dank Kerberos Single-Sign-On realiert werden (Authentifizierung). Regelsätze legen fest, welche Benutzer von welchen Benutzergruppen auf welche Services und Hosts zugreifen dürfen.

Seit einiger Zeit lassen sich mit IPA auch sehr einfach 2FA-Lösungen (Zwei-Faktor-Autentifizierung) realisieren, um die Sicherheit weiter zu erhöhen.

Das Slide Deck gibt es hier:

Slides vom Vortrag

Die Slides habe ich übringens bei einem Spontanvortrag bei der Berliner Linux User Group am 2015-04-08 wiederverwendet. Aufgrund des Feedbacks wird in den nächsten Wochen ein ca. 4h Workshop an einem Samstag organisiert.

Ich hoffe es hat allen anwesenden Spass gemacht und konnte Euch etwas Wissen vermitteln. Feedback zu beiden Anlässen willkommen.

2FA with (Free) IPA. The good, the bad and the ugly

Two factor authentication (2FA) is more and more emerging which is good to enhance security. Since the release of IPA4 it comes with 2FA included.

Over time I made a lot of experiments and experience I wanted to share with you. Its is easy to set up and maintain as long as you use it only for system authentication. If you are using such things as webmail, it fails. This post shows you the capabilities as they are of today. Almost all bad issues apply not only to Fee(IPA) but 2FA in general.

The good
All your systems are Fedora 21, RHEL 7.1 or Ubuntu 14.02 all is working fine as the included SSSD is new enough to handle 2FA. All kerberized services can be used with 2FA w/o logging in again during the validity of your Kerberos ticket. Very convenient, very secure.

3rd Party applications can use LDAP authentication (Depending on the usecase)

The bad
Systems with older distributions such as RHEL6.6 come with a SSSD version which is to outdated to handle kerberized 2FA at all. This will probably change soon.

Workaround:

  • Use LDAP authentication (See later on)
  • Use a Jump host with a recent Linux distribution

If you are logging in to your workstation with a local user, you can not grab a Kerberos ticket with kinit and use this ticket further on. (i.e for ssh logins on remote server, mail etc.)

Workaround:

The ugly

Looks like most mobile applications such as the IMAP client in Android do not prompt for the password, they expect it configured. Needless to say that you can not reconfigure the password each time you want to check your emails with your phone.

Workaround:

  • 3rd party email app? One that prompts for the password if needed
  • Configure IPA to accepts password and 2FA which lets the user choose to either use the password only or 2FA. Needless to say that this makes 2FA less useful as people tend to be lazy
  • Turn off 2FA in IPA and use a Yubikey with a static password (spit password). This is not a real 2FA it is a single password split in two. Password change is a horror.
  • Accessing Webmail clients (I tested roundcube mail) causes headaches as well. They authenticate the users with IMAP and use this credentials to access the mail storage. As the second factor is a one time password (OTP) this will result in failure to retrieve mails after logging in.

    Workaround: Same as for mobile applications. I would appreciate if someone can point me to a webmail software which can handle this.

Offline usage

One sentence: Offline usage does not work because it can not work.

Workaround:

  • Create a local user and use a Yubikey and configure it with a static password (split password). This is not a real 2FA it is a single password split in two. Password change is a horror.
  • Install a IPA server on your Notebook 😉 This will scale up to 18 Notebooks (plus two replicas in the datacenter) but introduce a lot of other problems, so: Not seriously to be considered.

LDAP Authentication as a Workaround
Configure PAM/SSSD to use LDAP authentication for your users. IPA comes with a very nice feature called ipa-advise.

[root@ipa1 ~]# ipa-advise config-redhat-nss-pam-ldapd
#!/bin/sh
# ----------------------------------------------------------------------
# Instructions for configuring a system with nss-pam-ldapd as a IPA
# client. This set of instructions is targeted for platforms that
# include the authconfig utility, which are all Red Hat based platforms.
# ----------------------------------------------------------------------
# Schema Compatibility plugin has not been configured on this server. To
# configure it, run "ipa-adtrust-install --enable-compat"
# Install required packages via yum
yum install -y wget openssl nss-pam-ldapd pam_ldap authconfig

# NOTE: IPA certificate uses the SHA-256 hash function. SHA-256 was
# introduced in RHEL5.2. Therefore, clients older than RHEL5.2 will not
# be able to interoperate with IPA server 3.x.
# Please note that this script assumes /etc/openldap/cacerts as the
# default CA certificate location. If this value is different on your
# system the script needs to be modified accordingly.
# Download the CA certificate of the IPA server
mkdir -p -m 755 /etc/openldap/cacerts
wget http://ipa1.example.com/ipa/config/ca.crt -O /etc/openldap/cacerts/ipa.crt

# Generate hashes for the openldap library
command -v cacertdir_rehash
if [ $? -ne 0 ] ; then
 wget "https://fedorahosted.org/authconfig/browser/cacertdir_rehash?format=txt" -O cacertdir_rehash ;
 chmod 755 ./cacertdir_rehash ;
 ./cacertdir_rehash /etc/openldap/cacerts/ ;
else
 cacertdir_rehash /etc/openldap/cacerts/ ;
fi

# Use the authconfig to configure nsswitch.conf and the PAM stack
authconfig --updateall --enableldap --enableldapauth --ldapserver=ldap://ipa1.example.com --ldapbasedn=cn=compat,dc=example,dc=com

[root@ipa1 ~]#

The output actually reflects your environment, example.com will be replaced with your domain, its copy-paste ready. I love this feature 🙂 For other Linux systems, run ipa-advise without parameters to see which advises are available.

Conclusion
2FA works well, convenient and secure in a datacenter and office environment. Notebooks are fine as well as long as there is a network connection available. The mobile world (Smartphones and Tablets) is not yet ready for 2FA. Some issues can be worked around (with some drawbacks) while others render 2FA not usable at all (offline usage).

Hopefully there will be some smart solutions available for mobile usage soon, as mobile usage causes the most of the security headaches.

Migrating legacy servers to FreeIPA authentication using ID-views

ID-Views are a new feature of FreeIPA4 which allows you to map UID/GID user/group names to another. This is a very handy solution when migrating legacy servers.

There are legacy servers in the field with a lot of history. They have been migrated from one operating system to another since the last decade(s). It is unfortunately also not uncommon on those legacy servers to find software with hardcoded UID/GID and/or user/group names. Along with an unknown number of scripts installed on such servers, its always problematic to migrate such systems when it comes to users and authentication. Another issue is that in the early years it was very common to have regular users with UID of >=500 while it is >=1000 as of today.

Unfortunately, almost nobody has the time to clean up the mess. Here is solution: ID-views. ID-Views can be applied to single hosts or group of hosts.

At the moment ID-Views are only working with newer SSSD versions as it is available with RHEL 7.1.

Creating a view

[root@ipa1 ~]# ipa idview-add --desc "Old servers with legacy users" oldservers
--------------------------
Added ID View "oldservers"
--------------------------
  ID View Name: oldservers
  Description: Old servers with legacy users
[root@ipa1 ~]# 

Override a group

[root@ipa1 ~]# ipa idoverridegroup-add --desc "Old group" --gid=500 --group-name=users oldservers users
-------------------------------
Added Group ID override "users"
-------------------------------
  Anchor to override: users
  Description: Old group
  Group name: users
  GID: 500
[root@ipa1 ~]#

Override a user
If you ommit the --login parameter (or any other) then the value in question is not overridden. Ususally you just override the numeric UID and/or GID.

[root@ipa1 ~]# ipa idoverrideuser-add --desc="John Doe is actually Hans Tester" --login=jdoe --uid=500 --gidnumber=500 --homedir=/home/jdoe --shell=/bin/csh oldservers tester
-------------------------------
Added User ID override "tester"
-------------------------------
  Anchor to override: tester
  Description: John Doe is actually Hans Tester
  User login: jdoe
  UID: 500
  GID: 500
  Home directory: /home/jdoe
  Login shell: /bin/csh
[root@ipa1 ~]# 

Apply the ID-View to a server

[root@ipa1 ~]# ipa idview-apply --hosts=legacy.example.com oldservers
----------------------------
Applied ID View "oldservers"
----------------------------
  hosts: legacy.example.com
---------------------------------------------
Number of hosts the ID View was applied to: 1
---------------------------------------------
[root@ipa1 ~]# 

To enable the view on the client side, clean the SSSD cache and restart the sssd service. Login to legacy.example.com.

[root@legacy ~]# sss_cache -E
[root@legacy ~]# systemctl restart sssd

You also need to change the PAM configuration to accept logins with UID &lt1000.

Now do some tests. Both users, “jdoe” and “tester” have UID 500.

[root@legacy ~]# getent passwd jdoe
jdoe:*:500:500:Hans Tester:/home/jdoe:/bin/csh
[root@legacy ~]# getent passwd tester
jdoe:*:500:500:Hans Tester:/home/jdoe:/bin/csh
[root@legacy ~]# 

On other servers, the “jdoe” login is unknown, and “tester” has the normal UID assigned by IPA

[root@ipa1 ~]# getent passwd jdoe
[root@ipa1 ~]# echo $?
2
[root@ipa1 ~]# getent passwd tester
tester:*:1225800004:1225800004:Hans Tester:/home/tester:/bin/bash
[root@ipa1 ~]# 

Please keep in mind that not cleaning up a messy system is just a workaround 🙂