Using Privacyidea with FreeIPA - part 1/n

[ This mail sets the stage for more parts, which will get into technical
details. Comments or suggestions are welcome, possibly we should add
refined texts in the relevant wikis/documentations. - Jochen ]

When I first looked at privacyidea I was quite unsure how it would
integrate into my existing network and what tokens and applications I
would use privacyidea for. After lots of thought and experiments I now
think I have a useful scenario to work with. I run a family network with
a local mail server (Kolab), webmail, ssh, and VPN access and think the
structure might also work for small or medium offices too.

Originally I had the userstore in Kolab’s LDAP server which I wanted
to use for more applications, e.g. Linux logins. pam_ldap and
pam_ldapd could access the userstore in LDAP, but require that the
server is available. How should that work for a roadwarrior setup?
I’ve found sssd, but never had time to play with it. So that idea
never got off the ground.

Former tries with Kerberos/LDAP have not been successful, but once I
found FreeIPA[1] I was kind of hooked. FreeIPA has:

  • LDAP as backend (e.g. userstore)
  • a versatile command line interface (“ipa”)
  • a useful web interface
  • client software to join a Linux machine into the FreeIPA realm
  • sssd for clients by default
  • works “out of the box”

If you need a central userstore with host based access control, SSO
and lots of other features - I can really recommend it.

I’ll discuss later, what features I use with which software and why.

The latest FreeIPA version has some OTP features included, for example
Yubikeys or FreeOTP tokens. So, why would you want to use another OTP
provider than FreeIPA? I use (and plan to extend the usage) Yubikey
tokens. Since the Yubikeys only have two slots[2], we need to decide
what we want to use the slots for.

I want to have the following applications running with my Yubikeys:

  • Second Factor for my keepass file
  • Second Factor for login/ssh (later webmail access)
  • Second Factor for sudo authentication

I’ve settled for the following usage of the slots:

  • Slot 1: This is a (reprogrammed) Yubico-AES token, which
    authenticates against Privacyides yubico mode instead of Yubicos
    cloud server.

    Why Yubico and not HOTP or TOTP?

    Here FreeIPA fails for me: Yubikey can’t do TOTP, HOTP token can get
    out of sync, when we use them for local authentication, FreeIPA and
    Kolab (each application has a count, which needs to be “in near
    sync” with the counter in the Yubikey. I wouldn’t trust such a

    But providing access to a Yubico Token via privacyidea works for all
    cases I have in mind.

  • Slot 2: Yubikey Challenge Response

    I use that as a second factor for my keepass file with
    keechallenge. The second application is my LUKS encrypted Laptop with
    privacyidea’s privacyidea-luks-assign help. With pam_yubico I restrict
    access to Laptops with a second factor, without the need for a central
    authentication server[3]. For the laptops (local login) I skip
    entering a sudo password when a yubico is present and authenticated.

    Since there is no token count, the token will not get
    out of sync.

For my local net u2f didn’t seem useful, but I’ll use it for remote

I consider that design more secure than using only a password, but
also more convenient. Let’s see how far that will take us.

[2] How does that relate to PIV, U2F, and smart card features?
[3] pam_python+privacyidea might help, but the packages are not in
distro repositories and even more of a niche product than pam_yubico.

The rest of this series expects that the PI host is enrolled in IPA.
On Debian/Ubuntu systems, add the ca.crt to the local ca store:

ln -s /etc/ipa/ca.crt /usr/local/share/ca-certificates update-ca-certificates–
The only problem with troubleshooting is that the trouble shoots back.